- Arch-general - lists.archlinux.org

[arch-general] [signoff] kernel26 2.6.33.3-2 (and aufs2)
by Pierre Schmitz 08 May '10

08 May '10

This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1 In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

4 3

Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo
by Ray Kohler 07 May '10

07 May '10

On Fri, May 7, 2010 at 1:40 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > On Fri, 7 May 2010 12:13:33 -0500, Aaron Griffin <aaronmgriffin(a)gmail.com> > wrote: >> So in effect, it seems we're saying the same things, except I am using >> REPO_NAME="foo-rebuild" for each rebuild "foo", and you are using >> REPO_NAME="staging" for *all* rebuilds. > > Somehow yes, but the detail is quite important. But a already existing > repo will make things a lot easier. Maybe its worth to manually create a > separate repo but probably not for just a few. We also sometimes upload > packages somewhere to share or let others grab them from our home dirs on > gerolde. Such a repo would simplify this and induce a general work flow for > e.g. rebuilds. > > But still, the main intention is to make testing more usable to get more > feedback and in turn have less bugs in core/extra. > >> This can already be done, the staging dir just needs to be added to the >> server. >> >> It would, however, need to be excluded from rsync if you want that. > > Sure, the implementation of this is a peace of cake: mostly a mkdir and > maybe adding some shortcuts to devtools and dbscripts to have something > like stagingpkg and staging2extra etc.. This makes me wonder, what about the TUs and [community-testing]? The current use of that repo would make it seem sensible to rename it to [community-staging] instead, since it's rare there's anything in there but in-progress rebuilds. Or should there be a pair of [community-testing] and [community-staging]? Sorry about adding complexity to this, as I realize that makes it less likely that it actually gets implemented...

2 1

Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo
by Ray Kohler 07 May '10

07 May '10

On Fri, May 7, 2010 at 12:44 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Hi all, > > here is another crazy idea I was thinking about for some days. This should > improve our overall package quality and simplify our work flow. The > problem > with out current [testing] repository are these: > * it is only used by very few people. Most of the times we don't get much > feedback until packages are moved to core or extra > * it is often in a inconsistent state; especially during incomplete so > name bump rebuilds > * sometimes packages are known to be broken or unstable > > On the other side we are sometimes in need of some intermediate > repository. For example single people stack a pile of packages in their > home dirs until they can be moved to a repo at once. We have also seen > temporary repos like jpng to manage larger rebuilds. > > My idea is to redefine the testing repo and introduce a new staging one. > (remember the good old days? ;-)) > With the implementation of the package pooling moving packages between > repos can be done with nearly no overhead. So ideally > we should be able to use testing more often, even for a very short period > like a > day. > > proposal for [testing] > * never push any known-to-be-broken packages here (for example incomplete > rebuilds) > * candidates for core are put here > * ideally new builds of important/critical packages or major rebuilds can > be put here to test them by a larger audience. > * don't put any package in here which are never meant to be moved to > core/extra. (like experimental alpha software etc.) > > proposal for [staging] > * this repo should only used by devs and tus > * it is not meant to be used on a production system > * it should only be enabled in a packages build environment (chroot) > * this could be even excluded from outbound rsync. Due to package pooling > packages would still be propagated. And moving those packages to other > repos will be "instantly". > > Summing things up more packages should be passed through testing, more > users should be able to use testing without breaking their systems and we > don't have to make them reading the high traffic arch-dev-public list. We > also should be able to collaborate more in packaging: Dev A puts a new lib > into [staging] and another one can start rebuild other packages using that > lib. Another common use case would be large builds like KDE we usually > start packaging one week before release. Till now those were put into > users' staging dirs and the other devs had to manually download them, > create a local repo and install them. > > So, what do you think about this idea? Even though I'm just a user, I'd like to add my support to this idea. I even considered proposing it myself less than a month ago. I run [testing], since I want to contribute to finding problems before they reach [core] and [extra], but I don't like having to deal with [testing] having rebuilds in it. I have never broken my systems by a bad package in [testing] but have unfortunately pulled incomplete rebuilds a few times now. I guess the point of this post is to show that there is at least one user who cares enough about this idea to speak up for it. I suspect there are others who don't run [testing] now who would begin doing so if this plan were implemented.

3 2

[arch-general] [xmonad] Screenshot of all workspaces?
by Nick Stepa 07 May '10

07 May '10

Hello all! I use xmonad and want to make screenshot of all workspaces at once. How can I do it? Plz don`t say: "For each workspace - switch to it and use scrot" (=

4 3

[arch-general] [signoff] kernel26-lts 2.6.32.12-1
by Tobias Powalowski 07 May '10

07 May '10

Hi guys, first try of lts bump to .32 series: - udev-compat is not needed anymore for this kernel - updated lts config to this kernel series - lzma compression is now used With this LTS release, i want to provide binary kernel modules too. Shall the binary modules be part of [core] then too, if the kernel26 module is there too? Thanks for feedback and input. Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-general] Is preload really working ??
by Nilesh Govindarajan 07 May '10

07 May '10

Hi, I'm running preload since about two months, but I haven't seen any improvement in program startup times especially firefox, which I launch and close every now and then. -- Nilesh Govindarajan Site & Server Administrator www.itech7.com मेरा भारत महान ! मम भारत: महत्तम भवतु !

9 12

[arch-general] about arch
by Juan Diego Tascón 07 May '10

07 May '10

Good day amigos, I was reading the "about" page (http://www.archlinux.org/about/) in the archlinux website and I noticed that this line is a little outdated: "Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts" It should say "over 21.000 build scripts". And one more question: is there a proposed starting date or a proposed selection procedure or just additional information for the Junior Developer scheme? I sent an email to Allan (@archlinux.org) the day it opened but I have not received any reply yet, I am starting to think that I sent it to the wrong email address. Have a nice day. Chao.

7 7

[arch-general] BTRFS integration
by C Anthony Risinger 07 May '10

07 May '10

hello, i maintain an unofficial btrfs initcpio hook in AUR: http://aur.archlinux.org/packages.php?ID=33376 the hook provides rollback support among other (future) features. hook is also required for anyone using a multi-device btrfs setup. i would like to start/be included in discussion involving btrfs integration into AIF, and other aspects of Arch. i think it would be nice for users to be able to have the option to use the new filesystem by default-ish, and have the tools needed to work with it. specifically, it would be really neat to have "rollback" support in a "rolling" distro. people would likely be more willing to ride the edge of the testing repo if they knew they could simply reboot and all could be well again when things did break. right now, the rollback feature provided by the hook is volatile, but this is only an implementation detail. what i mean by this is once you rollback, you CANNOT promote the "rollback" subvolume to be the new "active" (default) subvolume; you must fix the default subvolume manually and reboot again. anything you do in rollback mode will be lost on the next rollback. this is something i intend to change, but i need some input from other developers. what i propose is to do away with installing the system onto the default subvolume (like a typical installation); system will be installed to it's own subvolume (/root/__active). something like this: . ├── home │ ├── __active │ ├── __rollback │ ├── snap_11-11-1111_11-11-11 │ └── snap_22-22-2222_22-22-22 └── root ├── __active ├── __rollback ├── snap_11-11-1111_11-11-11 └── snap_22-22-2222_22-22-22 this is the "subroot" structure; underneath your / [root]. "." is the original default subvolume. /root/__active is your "primary" (default) system. /root/ __rollback is a volatile copy of a /root/snap_XX (you boot into this [__rollback] when you "rollback"). since snap_XX gets copied to __rollback... if you decide you want to ditch your changes to __active (since it's messed up anyways), you just replace __active with __rollback (delete/rename), reboot, and voilà! your system's __active subvolume works again, and none of your snapshots got messed with. same logic for /home/__active and /home/__rollback (and snap_XX) except you wouldn't have to reboot... maybe we can create login manager ([xkg]dm) hooks to remount your home folder with a "rollback" on the next logout or something? who knows. we could take a snapshot after install (on the very first boot), called "__original" or something, then users would always have a copy of their system immediately after installation; they could revert/use/delete that if they wanted to at any time. however, this setup would require mounting the default subvolume somewhere else in order to gain access to the "subroot" structure, but it would guarantee that you could not destroy your system no matter what you did to your / [root]. any ideas on this? my attempts to generate interest in the forums are falling on deaf ears so i thought i'd try my luck here. thanks, C Anthony

5 10

Re: [arch-general] [arch-dev-public] [toolchain] gcc 4.5 breakage
by Rogutės Sparnuotos 06 May '10

06 May '10

Thomas Bächler (2010-05-06 09:45): > Am 06.05.2010 09:44, schrieb Thomas Bächler: > > Am 05.05.2010 02:46, schrieb Allan McRae: > >> Interesting... Does fixing the aliasing fix this one too? I see no > >> upstream bug reports that seem related so you should follow it up there. > >> I will pull in a new gcc-4.5 snapshot next week when I do the > >> glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I > >> am missing... > > > > There is no fix in the latest 4.5 branch (or trunk) yet. > > http://gcc.gnu.org/PR43987 has more details. > > > > Basically, the problem is caused by -ftree-fta, which is on by default > > with -O1 and higher (and also -Os, which I use for busybox). The bug can > > be worked around with -fno-tree-fta until a fix becomes available. > > > > Writing is difficult - it's -free-pta and -fno-tree-pta, of course. I wasted a lot of time yesterday: 1. Compiled the kernel from git (for radeon stuff), rebooted. 2. 'ninit' segfaulted, 'ls' from busybox segfaulted. 3. Read your mail about busybox breakage, upgraded busybox with -fno-tree-pta, but... the same segfaults with kernels compiled by gcc-4.5. 4. Played with the kernel config for hours until finding out that CONFIG_CC_OPTIMIZE_FOR_SIZE=y causes the segfaults (and only on x86_64). I wonder whether this is something more specific to my setup, or nobody is compiling kernels with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86_64 with gcc-4.5 (building with gcc-4.4 works)... All this is probably unrelated to http://gcc.gnu.org/PR43987, but perhaps it will save some time for someone, as your post about busybox helped me. I'll wait for a new gcc package before reporting a gcc bug. -- -- Rogutės Sparnuotos P.S. The only good thing about the wasted time was that I found out how to use qemu for testing: $ qemu-system-x86_64 -kernel bzImage -initrd initrd.img

3 2

Re: [arch-general] [arch-dev-public] lts kernel bump to .32 series?
by Guilherme M. Nogueira 06 May '10

06 May '10

On Wed, May 5, 2010 at 1:33 PM, Tobias Powalowski <t.powa(a)gmx.de> wrote: > Hi guys, > i have some time tomorrow, shall we bump the old .27 lts kernel to the new > LTS > kernel series .32? > I would also like to provide binary modules for this series then. > If I remember correctly, the .32 series has a bug with Intel cards that causes screen flickering and the patch that corrects this was only merged in the .33 series During the .32 series I tried a few arch releases and they all caused the flickering in my laptop, so I rolled back and went from .31 to .33 when it was released. Don't know if this is relevant, but it doesn't hurt to tell. -- Guilherme M. Nogueira "Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke

4 4