User talk:Lonaowna

From ArchWiki
Jump to: navigation, search

problem in lib32-nvidia-libgl and steam

well, I do really think that it's a steam problem, because the package asks for a lib32-libgl package and it accepts the nvidia one. However, you can't launch steam properly unless you have lib32-mesa-libgl. I spent hours trying to find a solution, and the last comment on https://github.com/ValveSoftware/steam-for-linux/issues/3954 told me to do so, and it worked. Try yourself, and you'll see it's a problem. —This unsigned comment is by Dudasat (talk) 2015-11-24. Please sign your posts with ~~~~!

Hi, thanks for your response!
Steam asks for lib32-libgl. This is provided by lib32-mesa-libgl or lib32-nvidia-libgl.
If you are using the proprietary NVIDIA driver, you need lib32-nvidia-libgl. If you are using a different driver, you need lib32-mesa-libgl. You really need to install the one that fits the driver you are using. This should be explained on the drivers' wiki articles.
The last comment on the issue you mentioned is a very specific case when using an Intel/NVIDIA combo with Bumblebee. Do you use such a setup?
Can you maybe clarify which graphics card and driver you are using? Then we can find out what was really the cause.
Lonaowna (talk) 17:28, 24 November 2015 (UTC)
Oh and by the way, I'm using the Nvidia driver with lib32-nvidia-libgl, which works just fine. Lonaowna (talk) 17:30, 24 November 2015 (UTC)
The last comment on the Github issue mentions Bumblebee, which has has been left out by Dudasat in his edit. -- Lahwaacz (talk) 17:38, 24 November 2015 (UTC)

pacstrap base-devel group

I notice that wireless tools are now in base which was the primary reason before that I would have installed base-devel. Thus making the change moot. :) gkey (talk) 19:59, 7 June 2013 (UTC)

Ah sure, thanks for the explanation! :) --Lonaowna (talk) 20:05, 7 June 2013 (UTC)

Template breakage response

Thank you for reacting so promptly to the news requesting to fix the recently broken templates, and also for reverting your edits once everything has been fixed :) Good job, keep up the good work! -- Kynikos (talk) 13:58, 10 December 2013 (UTC)

Sure, always happy to help! :) Most credits go to you though, for fixing the templates so quickly! --Lonaowna (talk) 12:51, 11 December 2013 (UTC)

UEFI Beginners' Guide Changes

Hi Lonaowna,

Please could you clarify what problems would apparently be cause by using --bootloader-id=boot for the Grub installation script? As far as I am aware, this will only place the grubx64.efi stub in $esp/EFI/boot. Gummiboot automatically does the same thing, as does the recommended rEFInd installation method.

As far as I am aware UEFI that requires $esp/EFI/boot/bootx64.efi to detect the bootloader is not "faulty", either; just uses a different specification. Carlduff (talk) 11:30, 28 September 2014 (UTC)

Edit: I also noticed the loader.conf instructions have been removed from the Gummiboot section. As this provides a timeout function, Gummiboot will likely thus instantly boot right into the first option - whatever that is - impeding the users' ability to select any other options (e.g. other OSs, UEFI shell, etc.).

Hi! About bootloader_id:
First of all, the grub source code says the following:
The EFI specification requires that an EFI System Partition must
contain an "EFI" subdirectory, and that OS loaders are stored in
subdirectories below EFI.  Vendors are expected to pick names that do
not collide with other vendors.  To minimise collisions, we use the
name of our distributor if possible.
I'm sure "boot" doesn't follow this guideline.
Second of all, and more important: it doesn't matter anyway, as you still need to copy grubx64.efi to bootx64.efi, and it does not matter if they're both in the same directory or not. To name it "boot" can only lead to confusion IMO.
And as far as I know, a proper UEFI motherboard allows the user to pick an EFI file to boot from. The default boot/bootx64.efi is only meant for things such as bootable DVDs, where the location of the EFI file is not known. I know that not all motherboards present this option, so I agree that we should leave this "workaround", but I still think that we should note it is not the proper way.
About loader.conf:
I am sorry, I did not know that was the default. I will revert the edit.
-- Lonaowna (talk) 12:45, 28 September 2014 (UTC)
I'm against showing workarounds in the BG, unless at least 50% of common UEFI motherboards require the workaround. -- Lahwaacz (talk) 13:24, 28 September 2014 (UTC)
@Lonaowna Agreed, and good call. I suppose keeping the original grub .efi stub is a "safer" option, too.
@Lahwaacz That figure would not surprise me, given a lot of firmware seems to be written specifically with MS in mind. However, happy to put that into the grub article instead.
I am not sure how widespread the problem is. See for instance [1] for an explanation of the problem. --Lonaowna (talk) 15:59, 1 October 2014 (UTC)

EFI Grub Installation (Beginners' Guide)

Please see my comments on Indigo's discussion page. The grub-mkconfig command is the same, irrespective of whether it's for BIOS or UEFI systems, and irrespective of the mountpoint in the latter instance: https://wiki.archlinux.org/index.php/User_talk:Indigo#Beginners.27_Guide Carlduff (talk) 12:53, 22 October 2014 (UTC)

Adobe Flash player maintained until 2017

Hi Lonaowna,

Regarding your recent changes on Browser plugins#Adobe Flash Player, I would like from where do you have heard Flash Player will be supported until May 2017? The exact month has not been disclosed. As Adobe Flash Player was released in March 2012 (according to Wikipedia:Adobe Flash Player#Release history), if I could 5 years from that date it will be on March 2017. -- wget (talk) 00:44, 9 January 2015 (UTC)

Hi! I got "Adobe will continue to provide security updates to non-Pepper distributions of Flash Player 11.2 on Linux for five years from its release." from [2], and the release date of 11.2, 4 May 201228 March 2012, from here [3]. Lonaowna (talk) 09:58, 9 January 2015 (UTC)
edit: you're right, I misread the page and the 11.2 release date is indeed in March 2012, sorry! Lonaowna (talk) 10:01, 9 January 2015 (UTC)

Brother printer pages / CUPS overhaul

Thanks for joining in! You've re-added the drivers to the individual pages, which I'm not sure about. Wouldn't it be better to just link to CUPS_printer-specific_problems#Brother? I consider those pages to be almost ready for deletion/redirection, but I'm not sure what to do with the scanner driver information, so I left them for now (there doesn't appear to be a table or similar for that on the SANE pages, but I haven't looked that hard). I'd rather remove them, since otherwise it's not clear where new information should go.

Also, you've added the protocol/url for some of the printers to CUPS_printer-specific_problems. I assume this is because that information is not available readily? Perhaps it would be better to create another column in the table for it? Or, since the URL's for the different protocols appear to be the same, add a note somewhere on that page?

-- Pypi (talk) 22:30, 11 September 2015 (UTC)

Hi, thanks for your work too!
I'm not so sure what to do about the multifunction printers. We could indeed move the printer stuff to the CUPS page and the scanner stuff to the SANE page, but on the other hand it might be nice to have it on a single page. There would hardly be any information left though, so the first option might be better indeed.
About the protocol.. I'm still figuring it out myself. It might be so that all Brother network printers work with IPP, but I'm not sure about that. I think I want to do some more research to see if that's the case, and if it is, we could indeed remove it from the table and put a general remark about it next to the table.
Lonaowna (talk) 11:57, 12 September 2015 (UTC)
Could you clarify what you mean by "the first option"?
I'll assume that you will figure out a solution for the protocols :D
-- Pypi (talk) 02:11, 13 September 2015 (UTC)
I meant that it is probably better to completely get rid of the printer specific pages, and move everything to CUPS/Printer-specific problems and SANE (maybe also split the scanner specific stuff into SANE/Scanner-specific problems?).
I've also moved the "use network address ..." to a separate section, as you suggested!
Lonaowna (talk) 06:43, 16 September 2015 (UTC)
Well, good (if jerky) progress is being made. What about fax support (eg Brother_MFC-420CN)? I'm thinking that a note on the Brother section of CUPS/Printer-specific problems#Brother would be enough.
-- Pypi (talk) 07:54, 23 September 2015 (UTC)
You're doing a great job!
Brother MFC-420CN has no real information about the fax functionality. The page with the manufacturer's driver is not that hard to find. If that's the only fax info across all Brother pages (looks like it is?), I think we can just remove it completely.
Lonaowna (talk) 21:58, 26 September 2015 (UTC)
Okay, so all scanner "information" that's left on the Brother pages is "install brscan*". That is already mentioned in SANE/Scanner-specific problems#Brother, which refers to this page, which has a pretty clear table, I think. So in my opinion, we can just delete the remaining Brother printer/scanner pages. Lonaowna (talk) 19:46, 26 October 2015 (UTC)
Looks good, thanks! I've redirected most of the pages to CUPS/Printer-specific problems, and the talk pages to Talk:CUPS/Printer-specific problems. Some of the pages need a little bit more work to double check that all the information is really redundant, though, so I'm leaving them for now (and pages with recent-ish discussions that need closing). -- Pypi (talk) 00:00, 27 October 2015 (UTC)

49-sane.rules

Hi, the problem in [4] is more subtle: there is no /etc/udev/rules.d/49-sane.rules by default and therefore it does not make sense to look for something there. -- Lahwaacz (talk) 11:19, 29 October 2015 (UTC)

Oops, guess I didn't properly read the section. Thanks for noticing the mistake! I'll see if I can find out a better method. (reverted in the meantime) Lonaowna (talk) 11:37, 29 October 2015 (UTC)
Should be okay now. Lonaowna (talk) 12:07, 29 October 2015 (UTC)
Great, thank you. -- Lahwaacz (talk) 16:48, 29 October 2015 (UTC)


CUPS edits

Hi Lonaowna

  • [5] seems to be misplaced - it's in the HP section of [CUPS/Troubleshooting]. Was that intentional?
  • [6] is essentially the same as [7]; I believe the reason still holds. However, it might be better to not link to the foomatic-db package, and instead link to foomatic, since this seems to be a source of confusion? I'm mostly concerned about not overly cluttering the 'driver' column of the tables. If changing it is the best option, there is also the CUPS/Printer-specific_problems#Konica entries that will need updating.

-- Pypi (talk) 19:46, 20 May 2016 (UTC)

Hi Pypi, I think you're right. I was a bit hasty with my edits after spending too long figuring out why the printer driver wouldn't work on a new machine..
To be honest I'm not sure anymore what which driver needs. I've undone the edits for now until we have a better solution.
Thanks for keeping an eye out! Lonaowna (talk) 22:28, 20 May 2016 (UTC)