January 2014 - Arch-general - lists.archlinux.org

[arch-general] Thank you
by Genes Lists 09 Jan '14

09 Jan '14

Over the last 2 weeks I have replaced 3 fedora servers with Arch - and want to say thank you . That's the last of my fedora machines now and I am all Arch and they are all working really well. The new boxes are haswell UEFI and boot using refind. Setting this up was straightforward with Arch. Thank you for making Arch the best linux distro. Happy New Year gene

16 16

[arch-general] Package management
by Temlin Olivér 07 Jan '14

07 Jan '14

On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen <kalrish.antrax(a)gmail.com> wrote: > > Hello, > > Before starting, I'd like to remind that we're all humans, so we can > discuss these ideas politely and making use of nothing more than > reason. I am NOT a pedantic person looking to impose my will; please, > excuse me if you feel I'm doing it. I hope this turns into an > interesting conversation, and not into an unjustified battle, as it > too often does. > > Recently, I realized I was not using Arch in the way it was > "intended"; I was building most of the packages of my system, much "a > la Gentoo", with modified PKGBUILDs and a local repository. While it > worked with no major inconveniences, I started looking for truly > source-based distros, and found Gentoo. However, I disliked some parts > about it. This is my attempt at taking what I consider to be "good" > ideas to Arch. > > **Binary packages are right** > It is possible to either build packages by yourself, and then store > them for later use, or directly take them in prebuilt form. This is > specially useful when time matters or when the machine is unable to > build things (in my case, I broke a laptop, and it seems it was > because of overheating). > > **Versioning** > If I have understood it right, Gentoo makes it possible to have > several versions of the same package through "slots". Consider the > following scenario in Arch: > bar1 -> libfoo-1.0 > bar2 -> libfoo-1.0 > `libfoo´ is updated to 2.0. `bar2´ catchs up, but `bar1´ does not. > Thus, updating `libfoo´ to the latest version would break `bar1´, but > is necessary for `bar2´. The solution I've seen is adding the major > version number in the package name (e.g. "gtk2", "freetype2"), which > would turn the older version of `libfoo´ into `libfoo1´. I think, > however, that we could implement Gentoo's "slots", and add the concept > of "alternatives". That way, there would be PKGBUILDs for both > versions of the library, each with the same name but different > version. Each library would be installed as, say, > "/usr/lib/libfoo-${pkgver}.so", and an additional script for handling > of the named "alternatives" could then create a symlink at > /usr/lib/libfoo.so pointing to the right version _if needed_. The > script would exist in a per-package basis, so there would only be one > for both versions of `libfoo´. For example: > $ alternatives-manager libfoo --choose 2.0 > ln -s /usr/lib/libfoo-2.0.so /usr/lib/libfoo.so > (The name and syntax is just an example.) > This is easier to understand with libraries. With programs, however, > it's more difficult; someone could want to install different versions > of the same program, or, more likely, an outdated version (a typical > case would be GNOME 2). We could add "-${pkgver}" to the name of the > binaries in such cases, and then use alternatives to create convenient > symlinks. It would be horrible to have "cp-8.9.2" and the like. > Packages that could benefit from this are freetype, python, and I > guess every library out there. It would be, however, hard to > implement. > > **Package selection** > When pacman finds several versions of the same package in various > repositories, it fetches the one in the prevalent repo. This implies > that, if I've configured my local repository before the official > repos, I will never notice that a package has been updated. I'll have > to do `pacman -Ss pkg-that-ive-compiled´ to check if there's a newer > version, or track each project by myself. I think that, if pacman > finds itself in the described situation, it should prompt to ask which > package to install, unless --noconfirm is passed, in which case it > should stick with the default. [If I do `pacman -S repo/pkg´, however, > pacman should have no problem in choosing the package, and it > shouldn't ask.] > > These were all the ideas. If you haven't understood something, please > ask. Thanks, > Kalrish Hello! It's a nice idea to have, but packages need to link to the proper library version (eg. libfoo.so.1, not libfoo.so), thus making the repeated linking unnecesary. If that's a problem, then you can file a bug report. There already are a lot of symlinks in /lib, to ensure compatibility. If a new library version brakes old packages (many), than the old library is released as you said, with corrected dependencies for all packages (see libpng12 in community). Handling old versions is nearly impossible, as neither packagers nor upstream can be bothered to provide support for outdated packages. Even if Gentoo found a way, the biggest problem would be that it goes against the Arch Way: outdated packages go to the repos and it would complicate the system even more, using the libpng example, the AUR contains three additional packages, making the count 5. Putting these in the official repos would encourage developers to keep using old libraries for their projects and force the user to (in your alternatives-manager-style version) to change library symlinks repeatedly. So the arch solution to your problem is to notify bar1 upstream, and if they don't make a solution (usually because debian/ubuntu not having the new library versions yet), then make a custom patch, or if there are only a few users, and/or a dead upstream, drop the package, which has a (high) chance to resurrect in the AUR. Just bringing up an example search for gnome at the forums around 2011-04 and a few months forth. Dozens of people wanted back the old Gnome 2 (including myself), whined (not me), but to no avail. All the answers were all no. Arch is not going to support (or even ship) packages that are out-of-date. The current solution is to use the since-developed MATE and Cinnamon derivatives. But I'm just a user, and these are my thoughts, not completely matching the arch developers' ones. -- Temlin Olivér

4 5

[arch-general] Package management
by Kalrish Bäakjen 06 Jan '14

06 Jan '14

Hello, Before starting, I'd like to remind that we're all humans, so we can discuss these ideas politely and making use of nothing more than reason. I am NOT a pedantic person looking to impose my will; please, excuse me if you feel I'm doing it. I hope this turns into an interesting conversation, and not into an unjustified battle, as it too often does. Recently, I realized I was not using Arch in the way it was "intended"; I was building most of the packages of my system, much "a la Gentoo", with modified PKGBUILDs and a local repository. While it worked with no major inconveniences, I started looking for truly source-based distros, and found Gentoo. However, I disliked some parts about it. This is my attempt at taking what I consider to be "good" ideas to Arch. **Binary packages are right** It is possible to either build packages by yourself, and then store them for later use, or directly take them in prebuilt form. This is specially useful when time matters or when the machine is unable to build things (in my case, I broke a laptop, and it seems it was because of overheating). **Versioning** If I have understood it right, Gentoo makes it possible to have several versions of the same package through "slots". Consider the following scenario in Arch: bar1 -> libfoo-1.0 bar2 -> libfoo-1.0 `libfoo´ is updated to 2.0. `bar2´ catchs up, but `bar1´ does not. Thus, updating `libfoo´ to the latest version would break `bar1´, but is necessary for `bar2´. The solution I've seen is adding the major version number in the package name (e.g. "gtk2", "freetype2"), which would turn the older version of `libfoo´ into `libfoo1´. I think, however, that we could implement Gentoo's "slots", and add the concept of "alternatives". That way, there would be PKGBUILDs for both versions of the library, each with the same name but different version. Each library would be installed as, say, "/usr/lib/libfoo-${pkgver}.so", and an additional script for handling of the named "alternatives" could then create a symlink at /usr/lib/libfoo.so pointing to the right version _if needed_. The script would exist in a per-package basis, so there would only be one for both versions of `libfoo´. For example: $ alternatives-manager libfoo --choose 2.0 ln -s /usr/lib/libfoo-2.0.so /usr/lib/libfoo.so (The name and syntax is just an example.) This is easier to understand with libraries. With programs, however, it's more difficult; someone could want to install different versions of the same program, or, more likely, an outdated version (a typical case would be GNOME 2). We could add "-${pkgver}" to the name of the binaries in such cases, and then use alternatives to create convenient symlinks. It would be horrible to have "cp-8.9.2" and the like. Packages that could benefit from this are freetype, python, and I guess every library out there. It would be, however, hard to implement. **Package selection** When pacman finds several versions of the same package in various repositories, it fetches the one in the prevalent repo. This implies that, if I've configured my local repository before the official repos, I will never notice that a package has been updated. I'll have to do `pacman -Ss pkg-that-ive-compiled´ to check if there's a newer version, or track each project by myself. I think that, if pacman finds itself in the described situation, it should prompt to ask which package to install, unless --noconfirm is passed, in which case it should stick with the default. [If I do `pacman -S repo/pkg´, however, pacman should have no problem in choosing the package, and it shouldn't ask.] These were all the ideas. If you haven't understood something, please ask. Thanks, Kalrish

3 4

[arch-general] Default value of "j" in makeflags of makepkg.conf
by Mark Lee 06 Jan '14

06 Jan '14

Salutations, I was wondering if we could change the default value for j in MakeFlags in makepkg.conf to "-j$(nproc)". This would allow makepkg to scale the number of threads per pc as default. Regards, Mark -- Mark Lee <mark(a)markelee.com>

15 33

[arch-general] MAKEFLAGS remodelation
by Kalrish Bäakjen 06 Jan '14

06 Jan '14

Hello, Some projects (e.g., mpv, in community) are moving from Autotools to other build systems. I think we should create a JOBS variable indicating the number of parallel jobs, leaving MAKEFLAGS for make-specific options. We could also implement SCONSFLAGS, WAFFLAGS,… although that may be a bit premature. The reason behind this is that a given build system might not understand "-j N". (And, also, for SCons projects, the "-Q" flag could be desired.) In the proposed model, each PKGBUILD would appropiately tell the build system how many jobs to do in parallel, or ignore the setting. As an extra question, may I ask why aren't MAKEFLAGS used in official PKGBUILDs? I mean, as in: make ${MAKEFLAGS} Perhaps make automatically fetches options from the environment? Or maybe because package construction is automated in a server and other processes are running in other cores? Thanks, Kalrish

4 9

Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
by Isaac Dupree 04 Jan '14

04 Jan '14

On 01/03/2014 04:03 PM, Mark Lee wrote: > On Fri, 2014-01-03 at 15:55 -0500, Isaac Dupree wrote: >> On 01/03/2014 10:37 AM, Anatol Pomozov wrote: >>> Using -j$(cpunum) is a sane default that saves a lot of time to users. >> >> I agree, but for the record, 'nice' and scheduling are no panacea in my >> experience. It's fine for CPU loads, but compilations are also >> disk-heavy (which mattered when I used a spinning disk) and sometimes >> RAM-heavy (-j8 on my pet C++ project uses 2GB of RAM, which could push >> other programs I'm using into swap). >> >> -Isaac >> >> > > Salutations, > > I got to ask why you are running make with 8 threads on a system with > only 2 GB of ram? Heh. Well, I have 8 GB of RAM, but I'm often using most of it already. $(nproc) is 8 because there are 4 cores with each with hyperthreading (Intel Core i7). The project builds roughly at the same speed on this box at anywhere from -j4 to -j8; if that generalizes to other projects and there's an easy way to count cores not hyperthreads, cores might be a better Arch default. Shrugs. There are quite a few 4GB i7 systems out there too. Quad core ARM systems are another point on the cores-to-RAM-ratio spectrum. Probably most code doesn't consume 256 MB RAM per GCC invocation. C++'s templates and lack of module system... -Isaac

2 1

[arch-general] USB S-ATA Adapter
by Silvio Siefke 03 Jan '14

03 Jan '14

Hello, my Notebook is broken and so i buy a Adapter that i can take my Data from the Harddisk. siefke ~ $ lsusb Bus 001 Device 003: ID 0402:9665 ALi Corp. Gateway Webcam Bus 001 Device 004: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3 siefke ~ $ ls /dev | grep sd sda sda1 sda2 sdb SDB is the HDD but i can not mount and fdisk give nothing out. siefke ~ $ sudo fdisk -l [sudo] password for siefke: Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectors Units: Sektoren of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x47a0cee0 Gerät Boot Start Ende Blocks Id System /dev/sda1 2048 4196351 2097152 82 Linux swap / Solaris /dev/sda2 * 4196352 488397167 242100408 83 Linux Has someone an idea or can i forget it? Thank you for help & Nice Day Silvio

5 4

[arch-general] Patching in PKGBUILDS
by Mark Lee 03 Jan '14

03 Jan '14

Salutations, While debugging a libva-intel-driver issue, I found that makepkg was not reporting failures to patch source files. Is there a reason behind this behavior? Regards, Mark P.S. Happy New Year! -- Mark Lee <mark(a)markelee.com>

3 4

Re: [arch-general] arch-general Digest, Vol 110, Issue 18
by Mark Lee 01 Jan '14

01 Jan '14

On Tue, 2013-12-31 at 22:33 -0500, arch-general-request(a)archlinux.org wrote: > On Tue, 31 Dec 2013 19:39:03 +0100 > Thomas B?chler <thomas(a)archlinux.org> wrote: > > > Really? Who? > > Hmm, me. Intel atom here... > > > You are suggesting not changing to a sane default because some > packages > > (especially in the AUR) have crappy maintainers. That's hardly a > reason > > for anything. > > A sane default would probably be $(nproc)-1. But in general, is it a > good > idea to have calls to binaries in a config file? So far, makepkg.conf > doesn't > have anything like this. > > Happy new year, > Leonid. > Salutations, What if there is one core? What would be the output of make -j0? If makepkg.conf is to avoid binary calls, where else could this be placed? Would it be added directly to /usr/bin/makepkg as a flag that can be toggled in makepkg.conf? Regards, Mark -- Mark Lee <mark(a)markelee.com>

2 1

Re: [arch-general] build and test packages automatically
by Mark Lee 01 Jan '14

01 Jan '14

On Wed, 2013-12-25 at 21:12 -0500, arch-general-request(a)archlinux.org wrote: > Am Sonntag, den 22.12.2013, 19:51 +0800 schrieb Guangyu Zhang: > > [?] and to show the status of all packages which is just like > > the buildd <http://www.debian.org/devel/buildd/> in Debian. > > For my small repository I created a website? which lists all the > packages in the repository with a button to check the status. > It compares the version with the one in [AUR] but it could be adopted > to > check the status in CVS. > Of course it doesn?t build the packages automatically. > > Regards, > coderkun Salutations, Something similar was discussed on the Arch message board: https://bbs.archlinux.org/viewtopic.php?id=159304 I have experience with building computational servers; with enough funding for operational and startup costs, I'd like to build a cluster of AMD APUs computers for quantum chemistry, Arch Linux test packaging, and automated git building. It would be like a render/compiling farm. Regards, Mark -- Mark Lee <mark(a)markelee.com>

1 0