Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote: I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P What worries me about this is that you're making a clear distinction between users and developers. I'm not convinced that is really consistent with the Arch Way, which I have always admired because it expects that the line between users and developers is blurry, and actively encourages users to experiment and cross over. The idea of needing to switch to ruby's (purpose-built) method of handling gems when a user wants to achieve developer status seems wrong to me. And for what? sudo pacman -S ruby-json sudo pacman -R ruby-json instead of: sudo gem install json sudo gem uninstall json It doesn't seem worth it to me. The commands can easily be documented in the wiki, and then the bar is lowered that tiny bit more for hacking something together in Ruby. Bear in mind that rubygems doesn't spread files all over the system, either. They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 11:03:32 Bigby James wrote: That was how I discovered the multi-version dependencies: As pacman will only allow a single version of a package to be installed on the system at a given time, I was frequently alerted to updates of dependency gems I had installed. Middleman depends on a later version of a particular library than does Jekyll; if I update the gem via pacgem, Middleman will function, while Jekyll will break. It simply wasn't possible to use both simultaneously, and since I depend on Jekyll for work I do, that's unacceptable. It's far simpler (in my opinion) to use gem install as $USER to install to my /home directory and add the installation directory to $PATH, as I'm the only one who uses my machine. In the event that gems do (for whatever horrific reason) become unmanageable, one can simply nuke the directory where they're installed and reinstall all necessary gems rather quickly, without risk to the system at large. Thanks, Bigby, for articulating the point far better than I was doing :) I'd like to add to this that I also use Ruby for general scripting and monitoring on several servers that I maintain, mostly through cron jobs. These small system scripts run as root. I could install the gems into /root, but I prefer to have them installed system-wide, as they're more visible that way (element of least surprise), and means I can write and test the scripts as non-root first. That's why I use sudo gem install to manage system gems, and why I remove the --user-install option in my /etc/gemrc. Paul
[arch-general] Empty resolv.conf after PXE boot
Hello, I'm having problem with resolv.conf. After booting LiveCD (every version), sometimes it's empty. Problem occurs when using more than 1 interface and probably when one of them isn't connected. Mostly it takes place when I'm booting Arch under ESXi 5.5.0. After running 'dhcpcd' resolv.conf is filled and has correct data. Adding 'copy_resolvconf=y' to kernel params doesn't help. Also FYI: I'm using iPXE to boot this ISO. To reproduce this issue: 1. Boot ArchLinux ISO on any machine (ie. virtual) with 2 or more NIC's 2. Log in as root and cat /etc/resolv.conf - it will be empty or containing empty line 3. Try to ping any foreign domain, ie. google.com - it should fail 4. Run 'dhcpcd' and check if resolv.conf is filled correctly - fixed If it would work automatically, not by explicite calling 'dhcpcd or systemctl start dhcpcd@'. Any ideas? --- Best regards, Loper
Re: [arch-general] libgcrypt.so.20 missing
On 13.01.2014 22:52, Thomas Bächler wrote: Am 13.01.2014 22:48, schrieb Mark Lee: Salutations, All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away? As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them. I've had the problem on both my Arch computers. I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :) Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 -- damjan
Re: [arch-general] libgcrypt.so.20 missing
I confirm [killruana@fanstasmic tmp]$ gpg --verify libgcrypt-1.6.0-1-i686.pkg.tar.xz.sig gpg: Signature made Mon Dec 16 23:30:48 2013 CET using RSA key ID 0F2A092B gpg: Good signature from Andreas Radke andy...@archlinux.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: ADC8 A1FC C15E 01D4 5310 419E 9465 7AB2 0F2A 092B [killruana@fanstasmic tmp]$ sha512sum libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 libgcrypt-1.6.0-1-i686.pkg.tar.xz Le 14/01/2014 13:13, Damjan a écrit : On 13.01.2014 22:52, Thomas Bächler wrote: Am 13.01.2014 22:48, schrieb Mark Lee: Salutations, All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away? As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them. I've had the problem on both my Arch computers. I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :) Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 signature.asc Description: OpenPGP digital signature
Re: [arch-general] libgcrypt.so.20 missing
On 14/01/14 22:13, Damjan wrote: On 13.01.2014 22:52, Thomas Bächler wrote: Am 13.01.2014 22:48, schrieb Mark Lee: Salutations, All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away? As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them. I've had the problem on both my Arch computers. I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :) Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 pacman -S libgcrypt will verify the package in your cache before reinstalling.
Re: [arch-general] libgcrypt.so.20 missing
On вто, 14 јан 2014 13:26:15 CET, Allan McRae wrote: On 14/01/14 22:13, Damjan wrote: On 13.01.2014 22:52, Thomas Bächler wrote: Am 13.01.2014 22:48, schrieb Mark Lee: Salutations, All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away? As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them. I've had the problem on both my Arch computers. I'll have to manually install libgcrypt-1.6.0-1 now without checking its signature. Which is a bit scary :) Can anyone confirm the checksum of the 32bit package file? I used sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036 pacman -S libgcrypt will verify the package in your cache before reinstalling. at that point it's too late. but ok, I'm not that paranoid -- дамјан
Re: [arch-general] Packages Verified with MD5
2014/1/12 Taylor Hornby ha...@defuse.ca -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2014 01:56 PM, Kyle Terrien wrote: On 01/12/2014 12:40 PM, Taylor Hornby wrote: I guess I just don't understand what happens when I type pacman -S firefox. Does that run the PKGBUILD on my system, or does it download and install pre-compiled (and signed) Firefox binaries that were created by one of the Arch developers using the PKGBUILD? pacman -S firefox installs a pre-compiled binary maintained by an Arch Dev. On the other hand, PKGBUILDs are for building packages. And the official firefox package is cryptographically signed by the package maintainer (not Mozilla). Hopefully, that clears things up. Thank you, that makes so much more sense! So, really, the vulnerability only exists while the Arch dev (or package maintainer or whatever they're called) is building the package. Once they do, and sign it, all Arch users will verify their signature to make sure they get the same file the Arch dev created. That's not so bad, then, since you can't really do any better unless the upstream source (Mozilla) signs their files, and the package maintainer has their public key. I think this could yet be a problem if the sys admin wants to build all of it's system. Then he will fall into the same problem with the AUR PKGBUILDs, or am i wrong?
Re: [arch-general] Failure to resume on kernel 3.9.9
On Thu, Dec 5, 2013 at 1:54 AM, Patrick Burroughs (Celti) celticmad...@gmail.com wrote: Hi list, [unnecessary babble clipped] Hi again list, Just wanted to say that this is partially fixed with 3.12.7 (or possibly a bit earlier, haven't tested) and the radeon driver: the screen stays off and nothing short of a reboot will reactivate it; and fully fixed with 3.12.7 and fglrx. Time for me to go update bug reports. Regards, ~Celti
[arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts
All,
Updating PKGBUILDs as specified in VCS_PKGBUILD_Guidelines, I have a svn based
source that builds with cmake. In the past I have forced out of source building
for all cmake built packages. e.g.:
build() {
cd $srcdir
msg Creating out-of-source build directory: ${srcdir}/${_builddir}
mkdir -p build
cd build
msg Starting cmake...
cmake ${srcdir}/blah \
snip
msg Building - $pkgname...
make
}
In https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines it specifies
that The local repo is left untouched, thus invalidating the need for a -build
directory.
Am I reading this correctly to say - creating a separate out-of-source build
directory is no longer required -- even for cmake built packages? Or am I just
confused again...
--
David C. Rankin, J.D.,P.E.
Re: [arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts
On 01/14/2014 03:26 PM, David C. Rankin wrote: Am I reading this correctly to say - creating a separate out-of-source build directory is no longer required -- even for cmake built packages? Or am I just confused again... WOW, I confirmed on a smaller build that with VCS packages no longer require an out-of-source build with cmake. What about normal packages built with cmake. Is an out-of-source build directory still required? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts
On Tue, Jan 14, 2014 at 10:58 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 01/14/2014 03:26 PM, David C. Rankin wrote: Am I reading this correctly to say - creating a separate out-of-source build directory is no longer required -- even for cmake built packages? Or am I just confused again... WOW, I confirmed on a smaller build that with VCS packages no longer require an out-of-source build with cmake. What about normal packages built with cmake. Is an out-of-source build directory still required? -- David C. Rankin, J.D.,P.E. It is indeed no longer required with VCS sources, and has never been with tarballs since those are extracted every time you run makepkg so files you might have changed are overwritten anyway. However I sometimes find useful to keep doing that with cmake when you need to figure out why sth won't build, because that way files generated by cmake at build time are in a separate dir. Cheers, -- Maxime
[arch-general] Mirrors out of date
Salutations, Pardon me but does anyone know how mirrors are synced and flagged out of date? Regards, Mark -- Mark Lee m...@markelee.com signature.asc Description: This is a digitally signed message part
Re: [arch-general] Mirrors out of date
On Tue, Jan 14, 2014 at 11:34 PM, Mark Lee m...@markelee.com wrote: Salutations, Pardon me but does anyone know how mirrors are synced and flagged out of date? Regards, Mark -- Mark Lee m...@markelee.com I don't understand your question. What do you mean by 'how'? https://www.archlinux.org/mirrors/status/ https://wiki.archlinux.org/index.php/Mirroring https://wiki.archlinux.org/index.php/Mirrors
Re: [arch-general] Mirrors out of date
On Tue, 2014-01-14 at 23:37 +0100, Karol Blazewicz wrote: On Tue, Jan 14, 2014 at 11:34 PM, Mark Lee m...@markelee.com wrote: Salutations, Pardon me but does anyone know how mirrors are synced and flagged out of date? Regards, Mark -- Mark Lee m...@markelee.com I don't understand your question. What do you mean by 'how'? https://www.archlinux.org/mirrors/status/ https://wiki.archlinux.org/index.php/Mirroring https://wiki.archlinux.org/index.php/Mirrors Salutations, How do Arch users know if a mirror's out of date. It seems like the requirements involve using rsync. How does this link : https://www.archlinux.org/mirrors/status/ know what percentage synced a mirror is? Regards, Mark -- Mark Lee m...@markelee.com
Re: [arch-general] Ruby gem packages in Arch
On Tue, Jan 14, 2014 at 11:04 AM, Paul Gideon Dann pdgid...@gmail.comwrote: On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote: I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P What worries me about this is that you're making a clear distinction between users and developers. I'm not convinced that is really consistent with the Arch Way, which I have always admired because it expects that the line between users and developers is blurry, and actively encourages users to experiment and cross over. The idea of needing to switch to ruby's (purpose-built) method of handling gems when a user wants to achieve developer status seems wrong to me. The Arch Way is not about encouraging you to be a developer, it is about leaving all the tools in your hands so that you can decide what you want to do with them. I don't have a problem making a distinction between users and developers, and clearly you are not dealing with users on a daily basis if you can't do the same :P I don't consider myself a developer, but I still make the most out of Arch Linux in my own way, which is, the Arch Way. There is no typical Arch user/developer, each person uses it differently for their own purpose, be it a server, home media center, gaming rig or a ruby hacking machine. And for what? sudo pacman -S ruby-json sudo pacman -R ruby-json instead of: sudo gem install json sudo gem uninstall json It doesn't seem worth it to me. The commands can easily be documented in the wiki, and then the bar is lowered that tiny bit more for hacking something together in Ruby. Bear in mind that rubygems doesn't spread files all over the system, either. They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH. Paul It seems to me (maybe I'm wrong, but that's how it feels) you wish to force people to use rubygem instead of pacman, but I say it is not necessary if pacman is sufficient for their need. If you feel the need to do so, and I'm sure other people do, I'm just stating that in my opinion it is bad practice to interfere with pacman's ecosystem via another package manager, all the more if you give it root permissions. Now I understand you have a need for root permissions, and I won't insist , but keep in mind that gems can be installed anywhere outside pacman's jurisdiction and still be run as root. I know rubygem is not messy at all, I'm using it to repackage gems for pacman, still I think it is a good idea for most people to point it to a safe directory, and you always have the possibility to add the relevant dir to your PATH. As for multiple versions, the root of all evil is that there are too many gems that are not updated to support the latest version of a gem. Pacman does not have to deal with that because we make sure packages are always compatible with the latest and greatest, by submitting patches and/or bug reports upstream. That's one of the 2 reasons why rubygem can be a better choice for advanced ruby users, the other being the effort needed to repackage gems (which is not much, unless you have hundreds of them). Now I feel this discussion has dragged out for too long, and I believe I've made my point several times already, so I will take my leave and go back to my cave to geek to my heart's content :P Cheers, -- Maxime
[arch-general] How stable are the new version number formats on eg. filesystem, usbutils, etc.
All, Updating different minimum dependency package version info for tde PKGBUILDs, I note there have been a number of 'version number format' changes for various packages. E.g.: filesystem 0.x.y-z == 2013.05-2 usbutils 0.x.y-z == 006-1 There is a big difference going from filesystem=0.7.3 to filesystem=2013. When I run across packages like this where the version has changed format -- Are they likely going to stay with the new format? Or will they likely revert back to major.minor-rel numbers at some time? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] How stable are the new version number formats on eg. filesystem, usbutils, etc.
On Tue, Jan 14, 2014 at 6:39 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: All, Updating different minimum dependency package version info for tde PKGBUILDs, I note there have been a number of 'version number format' changes for various packages. E.g.: filesystem 0.x.y-z == 2013.05-2 usbutils 0.x.y-z == 006-1 There is a big difference going from filesystem=0.7.3 to filesystem=2013. When I run across packages like this where the version has changed format -- Are they likely going to stay with the new format? Or will they likely revert back to major.minor-rel numbers at some time? -- David C. Rankin, J.D.,P.E. This is handled with the `epoch` part of the version now, so it's a non-issue. Arch generally doesn't make use of minimum version requirements at all because partial upgrades are not supported.
[arch-general] connman conflicts
I was wondering why connman conflicts with openresolv. Looking through the files in each package, there don't seem to be any in common. So I figure there must be something that I am missing or just completely unaware of. I am primarily a connman user, but I use connman-git from the AUR, both because it seems to be in pretty active development and because it does not have as many of the features that I don't need built into it. In the AUR, connman-git does not conflict with openresolv. So I am kind of wondering if it should. I like having netctl on my machine as well, but if this poses some kind of risk or true conflict somehow, I would just like to know if I should make a decision between one or the other. Thanks. -- Curtis Shimamoto pgpfEZ56bJJ26.pgp Description: PGP signature
Re: [arch-general] Ruby gem packages in Arch
On 14 January 2014 18:04, Paul Gideon Dann pdgid...@gmail.com wrote: They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH. You use your system as you wish, but that is not recommended/supported practice. You can use other directories and still make them accessible system-wide. Heck, you can even have your home in system PATH. -- GPG/PGP ID: C0711BF1
Re: [arch-general] How stable are the new version number formats on eg. filesystem, usbutils, etc.
On 15 January 2014 07:39, David C. Rankin drankina...@suddenlinkmail.com wrote: All, Updating different minimum dependency package version info for tde PKGBUILDs, I note there have been a number of 'version number format' changes for various packages. E.g.: filesystem 0.x.y-z == 2013.05-2 This has been the format since at least April 2008. [1] usbutils 0.x.y-z == 006-1 And this since January 2011. [2] There is a big difference going from filesystem=0.7.3 to filesystem=2013. When I run across packages like this where the version has changed format -- Are they likely going to stay with the new format? Or will they likely revert back to major.minor-rel numbers at some time? There is always a reason for the change, enforced by upstream or necessitated by a move to a different release source (e.g. VCS). I can't recall filesystem's history, but it might have been due to the need for a version format that makes sense for such a package. And the versioned dep you are citing is probably a leftover that got updated. Anyway, as Daniel already said, changes like this shouldn't bother you now that epoch is used to force upgrades in the event vercmp returns negative. [1] http://goo.gl/AA6Xn9 [2] http://goo.gl/5Dm5k3 -- GPG/PGP ID: C0711BF1
