- Arch-dev-public - lists.archlinux.org

[arch-dev-public] back after long break
by Varun Acharya 05 Oct '07

05 Oct '07

Hi devs, The mammoth event which I was busy with is finally over, and it turned out to be a huge success. Will get back to arch work in a few days. I've been following the ML regularly, but forgive me if I ask a stupid question once in a while. Its good to be back :) Varun

3 3

[arch-dev-public] pending devtools issues
by Andreas Radke 04 Oct '07

04 Oct '07

Whenever I had tried out the devtools I had these issues: - I always set a certain pkgdest in makepkg.conf. So (old and) new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that. - As I only have poor bandwidth and like to keep working while down-/uploading I want to have a bandwidth-limit option for filetransfer. At least for uploading. Afaik the scripts use scp. Man scp tells me there's -l limit - Limits the used bandwidth, specified in Kbit/s. Yes I like the idea to "force" all devs using devtools to reduce unneeded mistakes and issues. Forcing us with an integrated namcap run is something I would like to see. But we should still be able to do everything by hand. There always might appear some reason why the tools get broken and we need to fix something manually. Andy

7 31

[arch-dev-public] archlinux water
by Damir Perisa 04 Oct '07

04 Oct '07

just got a nice picture remembering me on archlinux: http://lux.perisa.ch/tmp/ img_6366_uxga.jpg enjoy! if i'm running over similar pictures and have enough, i'm considering making a arch gallery :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

3 4

[arch-dev-public] critical: fakeroot broken again, breaks makepkg
by Thomas Bächler 04 Oct '07

04 Oct '07

Oops, this should have gone to the public list directly, so I'll repost it here: I saw this problem a while ago already, but didn't really investigate it. When building a package, you would often end up with non-world-readable /usr/man/manX directories. This happens whenever this code in makepkg is executed: # move /usr/share/man files to /usr/man if [ -d $startdir/pkg/usr/share/man ]; then cd "$startdir" mkdir -p pkg/usr/man cp -a pkg/usr/share/man/* pkg/usr/man/ rm -rf pkg/usr/share/man fi This can be reproduced easily: [09:29:39][thomas@artin shm]$ fakeroot bash-3.2# mkdir -p foo/ab bar bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 2 root root 40 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# cp -a foo/* bar/ bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwx------ 2 root root 40 Jul 12 09:29 ab foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# I can't find out exactly what's causing this, so if anyone has an idea, feel free to share it. This should definitely be fixed quickly, as it prevents me from updating several packages.

4 6

[arch-dev-public] 2007.10 ISO release on saturday 6th october?
by Tobias Powalowski 04 Oct '07

04 Oct '07

Hi i moved in the 0.3 test isos to ftp/iso directory. If no real showstopper is reported till Saturday i would suggest to announce them officially, and remove the other old ISOs from ftp. Your thoughts on it? Announcement on homepage: --- start Hi Arch community, Arch Linux Don't Panic 2007.10 ISO release I changed everything to fit to the new core repository, 2 ISOs left ftp ISO and core ISO. Changelog: GENERAL: - kernel 2.6.22.9 usage - disabled arch_addons hook by default, it is now triggered by arch-addons boot parameter In order to boot and install successfully, the new RAM recommendations: - RAM usage increased to 256 MB (FTP-ISO,CORE-ISO arch boot image) - RAM usage 96 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit - fixed grub installing with xfs filesystem - fixed package clearing if setup option was chosen NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config editing dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation As usual check md5sum before using the images and also be aware of the new RAM recommendations the images have. Have fun greetings tpowa --- end have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 19

[arch-dev-public] GIT Daemon up on projects.archlinux.org
by Dan McGee 04 Oct '07

04 Oct '07

For all out there that may not be aware, we now have a subdomain at http://projects.archlinux.org where we host some of our internal Arch projects. We have been moving a lot of our projects from other version control systems to GIT as of late, and currently have quite a bunch of these projects hosted, as you can see here: http://projects.archlinux.org/git/ For those interested in helping out with these projects or just following along with the code, we now have a git daemon up and running. All of these projects can still be fetched over http if need be, but using the GIT native protocol is much more efficient. The following two examples should get you started on cloning one of our projects: (Over HTTP) git clone http://projects.archlinux.org/git/namcap.git namcap (Over GIT) git clone git://projects.archlinux.org/pacman.git pacman Note the slight difference in URLs- for cloning over GIT, no /git directory is used. Happy git-cloning, and we'd really like to see some community participation with these projects if you have something to contribute! Patches always welcome on the mailing lists. -Dan

1 0

[arch-dev-public] A big baad idea: ArchCon 2009
by Tom K 03 Oct '07

03 Oct '07

High concept: "What do you think would happen if as many Arch people as possible gathered in the same place at the same time?" Audience breakdown: All members of the dev team (well, duh) TU-selected members of the TU team Other Archers fanatical enough to attend People off the street Program: Hacking Talking Bonding (aww....) Drinking (woohoo!) etc TBC: Continent Country City Venue Menu Activities Restrooms Size of Mugs Imperial or Metric Yadda Yadda etc Teaser: one particular member of the dev team will volunteer to organise the whole shebang! I'm posting this here, because if the devs aren't interested, well... All the best Tom.

13 17

[arch-dev-public] Test Isos 2007.10-0.3 with core repository and 96MB RAM image
by Tobias Powalowski 03 Oct '07

03 Oct '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. GENERAL: - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 256MB (FTP-ISO,CORE-ISO arch boot image) - Ram usage 96 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit - fixed grub installing with xfs filesystem - fixed packages are now cleared if setup option was chosen NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation TODO: - nothing from my side, it's nearly perfect :) you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 About memory usage: It's a pacman bug that it increased to 256MB and 96MB so don't blame me on it ;) http://bugs.archlinux.org/task/8155 We should really replace our current Isos with them soon, the old ones are all a bit bugged and ftp is broken on them anyway. so removing old isos from server and place those ones instead is highly recommenden from my side. Your thoughts on it? have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] namcap status
by Jason Chu 03 Oct '07

03 Oct '07

Since I emailed out about devtools and pacbuild, here's the last email about namcap. Development on namcap is moving along nicely now that I've had help from Jesse Young and JJDaNiMoTh. I only have one thing left on my todo list related to namcap: updated licensepkg code. I want to actually inspect the packages and verify that they have the custom licenses distributed with them that they say they do. After I make that update, I plan on releasing namcap 2.0. Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet... Jason

3 2

[arch-dev-public] Moving forward [was: Cleanup/Orphans]
by Aaron Griffin 03 Oct '07

03 Oct '07

On 10/2/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Hm. Your words are sounding more polite. True. > > But don't you get the same feeling that some of our developers lost > their interest/time in maintaining packages? Some were even hired to do > other jobs. Who else should do it? We had a decision to not give away > the packaging process to the community. So we have too do it our best. Oh yes, don't get me wrong, I agree with you. But I think _demanding_ the drive back is not the right way to do it. In fact, while you criticized me (us?) for it - I strongly feel that the thread discussing what we do in our free time is _critical_ to us moving forward. See. Here's the thing. This isn't a job. This is a hobby. And a lot of us have started treating it like a job. We're all serious and stoic. Acting like we _must_ do things this way, etc etc. That's not going to cut it. That's the fastest way to defeat if we're not getting any sort of compensation. The compensation is our enjoyment. We should be having fun here. This shouldn't be a chore. It needs to be rewarding. > I just don't want to fall back into the time when Jan, Tobias and me > were doing the majority of packaging almost alone again. And now we have > to take about two architectures. Let's spread it over all our shoulders. See now again, it's important to point out that everyone has other duties here. Writing code is just as time intensive as packaging. And in the end, it's beneficial to _you_ too. If someone improves our packaging tools, streamlines the process, it makes everyone's job easier. > Let's improve our infrastructure step by step but don't forget our > daily work of packaging. We have become famous for our good compromise > of bleading edge and quality. We should try to keep this alive. Everyone has daily work. But I need to emphasize something that I feel is overlooked - pacman, devtools, the web site, gerolde maintenance - these are all AS important. > One possible way it to force a dev to also maintain all dependencies > for his packages. But what about the rest? I actually like this idea, and I will use it to autoassign packages at the end of the week - if you maintain a package and one of the dependencies is an orphan, I'll assign that to you - it just makes sense that way. Thanks Andy!

3 3