- Arch-general - lists.archlinux.org

[arch-general] gpg source validation for kernel.org style signatures
by Christian Hesse 06 Jan '15

06 Jan '15

Hello everybody, pacman 4.2.0 gained support for verifying source tarballs with kernel.org style signature. Some (even essential) packages could benefit from that, linux and git come to mind. How to handle this? Report a bug for every package? Provide a list here? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

5 10

[arch-general] list of user/group ids supplied by official packages
by member graysky 05 Jan '15

05 Jan '15

Is there a list of user/group IDs that official packages from [core] [extra] and [community] provide? I wish to insure that the user/group id in an AUR package I provide[1] does not conflict a user created by an official package. I can grep for 'useradd' in my abs tree and parse through the resulting 137 lines but there must be a better way. Thanks. 1. https://aur.archlinux.org/packages/kodi-standalone-service

4 7

[arch-general] makepkg as root
by Magnus Therning 05 Jan '15

05 Jan '15

I just noticed that `makepkg` no longer accepts '--asroot', does that mean there now is no way to convince `makepkg` to build despite being run as root? /M P.S. I am fully aware of the problems with building as root, but as I'm only building packages I'm myself creating, and doing it in a docker image, I feel I can live with the dangers... especially when it saves me some work in setting up docker images. -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters

12 42

[arch-general] rsync patches
by Ido Rosen 04 Jan '15

04 Jan '15

Hi, I'd like to add --time-limit / --stop-at added to ArchLinux's rsync since it's available in some other distributions. (This patch is distributed from the same source as rsync itself, just in a different tarball called rsync-patches, along with a bunch of other patches for optional functionality that rsync can support but that isn't built into the core rsync by default.) Below is an updated PKGBUILD for rsync that adds time-limit support. There are several other patches in rsync-patches that could be useful, but this is the one that most affects me. Pierre did not respond to my email back in October, so Pierre, if you are monitoring this list, see the attached PKGBUILD, it's a trivial addition. I hope you'll make the change. :-) Cheers, Ido

2 2

Re: [arch-general] makepkg as root
by Maxwell Anselm 04 Jan '15

04 Jan '15

Respecting backwards compatibility is more complicated than just never removing features from software. Sometimes less is more: extra features can be bad for maintenance, a source of bugs, or a source of vulnerabilities. Sometimes features are added as workarounds or hacks in lieu of a proper solution and serve no real purpose after a later update. It's highly unfair to the pacman devs to claim that removing a makepkg option is a slippery slope towards DRM, Microsoft, and the dark side. If you consider The Arch Way, the pacman update seems very much in-line with the distro. "Arch Linux defines simplicity as without unnecessary additions, modifications, or complications..." A few people have mentioned workarounds for --asroot, so it certainly isn't _necessary_ and the devs seem to think its continued maintenance would be a complication. "Simplicity of implementation, code-elegance, and minimalism shall always remain the reigning priorities of Arch development." This one speaks for itself. "Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system." As mentioned previously, removing --asroot does not remove one's control over the system. At worst it is an inconvenience in an unusual corner case. Our competent users should be able to figure out how to live with the new pacman options. Arch has an especially complicated relationship with backwards compatibility. This isn't the first case of a breaking change in an update, and I think it's actually pretty minor in terms of impact. There's always an outcry when something like this happens, but as long as it doesn't violate Arch's philosophy I think we'll be okay. In keeping with semantic versioning, it would make sense to bump pacman's major version. Max

4 4

[arch-general] Djvu
by Csányi Pál 01 Jan '15

01 Jan '15

Hi, I'm trying to make from jpg images in Atnevezettek/ directory a djvu document with the command: img2djvu -d600 -v1 ./Atnevezettek/ As output I get following: 321 files: <C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C><C> Done. but when I open the Atnevezettek/ directory I can't find there any djvu file. What am I missing here? -- Regards from Pal

2 1

[arch-general] Problems using AUR since upgrade of pacman db version
by Marcel Kleinfeller 01 Jan '15

01 Jan '15

Hi! I'm facing some problems using the AUR with many helper programs (cower, packer etc). That might be due to the latest upgrade of the pacman database to version 4.2. Is there a simple way to use AUR? Thanks in advance! Marcel Kleinfeller P.S.: I'm really not sure whether this is the right place to ask.

8 8

[arch-general] Could not receive my Bugtracker Activation Code
by Minh Nhut Duong 01 Jan '15

01 Jan '15

Hi, I registerd my Arch Linux Bugtracker account from this link https://bugs.archlinux.org/ but I cannot receive my activation code to complete registration. Anyone can help me resend my activation code to nhutdm at gmail dot com. Thanks,

4 6

[arch-general] Trusted User application
by Jerome Leclanche 31 Dec '14

31 Dec '14

Hi list My name is Jerome Leclanche and this is my application for becoming an Arch Linux TU. Both Balló György and Sven-Hendrik Haase have encouraged me to apply, and Sven-Hendrik has agreed to sponsor me for the occasion. I am a French Python developer living in Stockholm. I work on FOSS both for my full-time job and in my free time, with my focus being on the LXQt project of which I am one of the lead developers (http://lxqt.org/) All my contributions are available on Github: https://github.com/jleclanche My main goal is of course to bring LXQt to [community]. I emailed Antonio Rojas about that a while back as he was also interested in this. I'm on my third year with Arch Linux and absolutely love the distro; been hanging around IRC and the community as jleclanche. This is my package list: https://aur.archlinux.org/packages/?SeB=m&K=jleclanche I have started the release process to get LXQt 0.9 out some time in January. I would really like to see it become available on Arch Linux at the same time =) Other than LXQt, I also maintain ruby-sass and its dependencies, which I would also like to move to [community] - although it is something I'd like to bring up with Anatol Pomozov first as he maintains a large array of Ruby packages himself already. I also saw that libfm and libfm-extra are currently orphaned there and since they are LXDE projects, I will happily pick them up. If any of you are going to FOSDEM, I will also be able to meet you there - I'd love to get to know the Arch community in person as well. Thanks for the great distribution and happy 2015 to everyone. I've kept this as terse as possible but I'll be happy to answer any questions. J. Leclanche

2 1

[arch-general] depends vs. optdepends
by Troy Engel 30 Dec '14

30 Dec '14

So, I found 4 executable/binary files installed (out of thousands - good job guys) that fail a 'ldd' check (missing shared libraries). The packages in question mark the missing libraries as 'optdepends' so they never get installed - I filed 4 bug reports, all 4 got closed as "not a bug" by the same person. I disagree with this choice as I believe it's ignoring system integrity needlessly - 4 files are installed which knowingly do not *function* (cannot launch) at all. The person who closed it even wrote "So what? Non-functional executables are not an issue here, this is the point of optional dependencies." The wiki states "optdepends: An array of package names that are not needed for the software to function but provides additional features." OK, so per the wiki it's pretty clear - missing libs fail the function test. The man PKGBUILD states "optdepends (array) An array of packages (and accompanying reasons) that are not essential for base functionality, but may be necessary to make full use of the contents of this package." Per this, there is a huge grey area open to interpretation. It is my opinion this is a dangerous precedent to install binaries from an official package that are linked to shared libraries which are not required to be installed. I'm wondering why Arch considers it acceptable to just ignore the problem (which could be solved in all 4 cases by simply splitting the package for that binary and adding a proper depends). Thoughts? -te [1] https://bugs.archlinux.org/task/43260 [2] https://bugs.archlinux.org/task/43261 [3[ https://bugs.archlinux.org/task/43262 [4] https://bugs.archlinux.org/task/43263

7 12