- Arch-general - lists.archlinux.org

[arch-general] wrong file permissions in /var/lib/pacman/local
by Hubert Grzeskowiak 18 Dec '08

18 Dec '08

hi there, can it be, that the some dirs written to /var/lib/pacman/local/* are not chmod'ed properly? sometimes i get errors because as user i don't have the permissions to do anything with it (it's set to drwx------). this only occurs on some packages (eg. the new nmap package). other dirs and files inside all (also the corrupted) directories seem okay (files: -rw-r--r--; dirs: drwxr-xr-x) i played around with umask and sudo (always used on de-/installations) with no result -everything was okay- so i conclude it's a per-package problem. is anybody else encountering this? thx in advance Hubert Grzekowiak

6 19

[arch-general] new AIF release
by Dieter Plaetinck 17 Dec '08

17 Dec '08

Hello Arch devs and users, here is my holidays present for you: AIF alpha-0.6 ! * Changes since alpha 0.5: - fully reworked disk subsystem - support for lvm and dm_crypt - Autoprepare looks exactly the same (ui-wise) - Manual mode UI is entirely reworked and has a general editor (see screens) - Unified, more flexible/reusable backend code for partitioning, making filesystems and mounting them. Uses structured file formats for defining partitions and filesystems - Rollback functionality: when something failed while processing, or user changes his mind afterwards, you can do a rollback (things like umount, lvremove etc are done automatically in the correct order) and start over/retry - fully decoupled UI (dia/cli): - there are now generic, transparent functions for asking dates,numbers,strings,checklist,.. etc with an implementation in both ncurses (dialog) and cli. - all code now uses these functions, making the codebase much cleaner. (look at the code for autoprepare for instance) - with a simple command line flag you can toggle between running the program in cli or dialog mode. - support for commandline args - /arch/aif -p interactive -d # runs the interactive profile with debugging enabled - /arch/aif -p interactive -i cli # runs the interactive profile in CLI mode. - updated howto for using AUR packages - replaced all refs to previous name (fifa) to aif. - enabled date/time setting - a massive amount of bugfixes - a lot of code cleanups * Screenshots - AIF manual filesystems, here showing a setup with /dev/sda3 containing a dm_crypt, containing /, and /dev/sda3 containing an LVM setup with 1 LV for /home http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-overview-dia.png - Processing the filesystems. The installer automatically reorders everything http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-processing-dia.png - a CLI shot where the partitions/filesystems of the autoprepare just have been processed http://users.edpnet.be/dieter/aif/aif-alpha_0.6-autoprepare_processed-cli.p… * Usability I tested the installer personally in virtualbox in different scenarios (ftp & cdrom based, autoprepare, manually with normal disk layout,/ on lvm, dm_crypt,.. ), and all produced working installations. Although I often need to fix bugs after testing a specific scenario, I don't re-test all scenarios each time. YMMV Note that the installer doesn't automatically add the lvm2/encrypt modules to mkinitcpio yet, and doesn't add the right string for lvm/dm_crypt in grubs menu.lst yet. There are some known issues (which are not critical, just avoid them or live with them). Here are the biggest ones (for more, see TODO) - don't remove lvm LV's if you have more then one in one lvm VG. So think before you create :-) - make the correct devicemapper devices directly because they are not cleaned up correctly if you remove them again - keyboard and timezone settings from installer don't go into target systems config - long selections (eg packages) are very cumbersome to do in CLI mode. - rollback of dm_crypt partitions doesn't work yet * How? http://github.com/Dieterbe/aif/tree/master/HOWTO Use package aif-git from AUR. Even though I tag releases in git, I don't build packages for them. I now use the master branch as "stable" branch where I pull in code from the experimental branch after it has been tested. So the master branch (package aif-git) always contains the latest, stable code. Use "/arch/aif -p interactive -d" (the interactive procedure is the port of /arch/setup) Have fun, Dieter

4 6

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist
by Grigorios Bouzakis 17 Dec '08

17 Dec '08

On Sun, Dec 14, 2008 at 12:40 AM, Dan McGee <dpmcgee(a)gmail.com> wrote: > This is a dual signoff. I have split the pacman mirrorlist into its > own package because > 1) Pacman releases are not all that common (because its perfect > software, of course!) > 2) Our packaged mirrorlist often lags waaay behind the actual one in > SVN, because I find it a waste to rebuild pacman just for mirrorlist > changes. This will prevent that. > > I don't actually run pacman, so 2 signoffs per arch would be > wonderful. In addition, PLEASE let me know if anything goes awry > during a normal upgrade process. This could include mirrorlist not > being written to pacsave, mirrorlist disappearing, etc. > May i ask why pacman requires pacman-mirrorlist and not the other way around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can not operate without pacman.. Greg

7 8

Re: [arch-general] Build from source question.
by Anton 17 Dec '08

17 Dec '08

On Wed, 17 Dec 2008 08:49:48 +0600 Allan McRae <allan(a)archlinux.org> wrote: So ... this is from CRUX's pkgmk: for REPO in ${PKGMK_SOURCE_MIRRORS[@]}; do REPO="`echo $REPO | sed 's|/$||'`" wget $RESUME_CMD $DOWNLOAD_OPTS $REPO/$BASENAME error=$? if [ $error == 0 ]; then break fi done I think it is not hard to patch my local copy of makepkg with this pice of code :). May be I will do this if I can to find a time ... I even did not install archlinux yet :-). I use crux ... I'll try. > Anton wrote: > > On Tue, 16 Dec 2008 22:28:55 +0600 > > Lukáš Jirkovský <l.jirkovsky(a)gmail.com> wrote: > > > > > >> 2008/12/16 Anton <warm(a)stack.ru>: > >> > >>> Good day. > >>> > >>> I'm going to compile all needed packages for archlinux. There are many source mirrors at the net not > >>> only URLs from PKGBUILD. Usually it is "distfiles" dir from gentoo or freebsd. It contains sources for > >>> their ports. I want use this sources. > >>> > >>> How can I to make makepkg to look for source in my LAN mirrirs to get it first from there and only then > >>> from PKGBUILD's url ? > >>> > >>> For example in CRUX pkgmk.conf there is PKGMK_SOURCE_MIRRORS=(...) wich point to list of such mirrors. I > >>> looking for the same in archlinux. > >>> > >>> > >>> > >>> -- > >>> Anton [WARM-RIPE] > >>> Stack ltd division head > >>> tel. 8 (3822) 555-797 > >>> > >>> > >>> > >> Hello, > >> you can use SRCDEST="/path/to/folder" option in makepkg.conf. makepkg > >> looks into this directory first and if there are no sources, it will > >> download them there. > >> > > > > This is not exactly what I looking for. In this case I should manually download sources to the SRCDEST > > from my local mirrirs but I want automatic try to download the sources to SRCDEST from my list of URLs > > where source can be found or not. If source tar ball can not be found at URLs from the list then source > > should be downloaded from its true home page or location specified in PKGBUILD. CRUX's pkgmk can do this, > > can makepkg ? > > makepkg can not do this. > > Allan > > -- Anton [WARM-RIPE] Stack ltd division head tel. 8 (3822) 555-797

1 0

[arch-general] Build from source question.
by Anton 17 Dec '08

17 Dec '08

Good day. I'm going to compile all needed packages for archlinux. There are many source mirrors at the net not only URLs from PKGBUILD. Usually it is "distfiles" dir from gentoo or freebsd. It contains sources for their ports. I want use this sources. How can I to make makepkg to look for source in my LAN mirrirs to get it first from there and only then from PKGBUILD's url ? For example in CRUX pkgmk.conf there is PKGMK_SOURCE_MIRRORS=(...) wich point to list of such mirrors. I looking for the same in archlinux. -- Anton [WARM-RIPE] Stack ltd division head tel. 8 (3822) 555-797

4 4

[arch-general] INFO, Java SE 6 Update 12 Build 02
by Amanai 17 Dec '08

17 Dec '08

The earlier (unstable) build from Sun Java SE Update 12 Build 02 have now full 64 bit broswer support. Finally Sun have make it.

3 2

[arch-general] Status of swt and azureus/vuze
by Ondřej Kučera 16 Dec '08

16 Dec '08

Hello all, this has been brought on a couple of times before but never resolved. The situation is to my knowledge as follows: (1) There is an azureus package in [extra]. It is very much outdated (I think it hasn't been really updated for about at least a year) and it has been orphaned for most of the time. (I'm not sure if it even works anymore but perhaps it does.) The only nice thing about is package is that it is built from Azureus sources instead of using the precompiled Azureus binaries provided by upstream (although it is maybe questionable whether or not this is an advantage or how big). (2) There is a swt package in [extra], version 3.3.2. It has been flagged out of date (I may have done that myself, I'm not sure) for some time now, version 3.4 has been released in June, almost half a year ago. This package, too, is built from sources instead of provided binaries. The only package depending on swt is the above mentioned azureus. (3) There is a vuze package in unsupported (vuze is the new name of azureus for those who aren't familiar). It is up-to-date, only it is not built from sources. It just more or less takes the provided binaries and uncompress them into /opt/vuze. This package has its own version of SWT bundled in, I've tried at least to save some disk space by removing bundled swt.jar and using the one from [extra], unfortunately vuze then wouldn't start. I'm not sure where the error lies, I suspect it has something to do with the way swt in [extra] is built but I may be wrong (I can provide more details, the error message for example, if anyone's interested). My personal conclusion: not that many users really use vuze, because I seem to be the only one complaining here all the time (I think this is at least the third time I'm opening this). :-) (On the other hand vuze in unsupported has almost 50 votes, so probably users use this version instead of the outdated version in [extra].) Also, devs probably don't want to maintain vuze or swt, I'm not blaming them at all (there has been an e-mail describing how tricky it is to compile it from sources), and when there's no one to use it, what's the point anyway? I think one of two things should happen. (a) Someone (ideally just one person) - a dev I mean - will adopt azureus again, rename it to vuze and update it to the latest version, alongside with swt. Then the vuze package in unsupported can be deleted. (b) Both azureus and swt will be dropped from extra. Then the vuze in unsupported will become more or less "official" (or at least the only available version in ArchLinux world) and perhaps a TU can then move it to [community] if they feel like maintaining it. It might also be possible to create a swt package in unsupported and let vuze depend on it (because perhaps there are more applications out there that could depend on swt) - if one sticks to the precompiled binaries, it's not that hard to maintain it. Any ideas or solutions? Should I for example file a bug report instead? Ondřej -- Cheers, Ondřej Kučera

3 3

[arch-general] Fwd: [arch-dev-public] Move repo-maint emails to the arch-commits list?
by Grigorios Bouzakis 16 Dec '08

16 Dec '08

On Tue, Dec 16, 2008 at 6:04 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Am Dienstag 16 Dezember 2008 16:55:33 schrieb Aaron Griffin: >> I got an email today saying that the repo maintenance emails are kinda >> spammy on the arch-dev-public list. What do you guys think about >> moving it off to another list. Either the private list, or the commits >> list? >> >> Opinions? > > What about moving them to the dust bin? ;-) Seriously, it would be enough if > only a mail were sent when something went wrong. Those "The following files > are out of date" are of no use imho. (I doubt that anyone reads and checks > them all) After months on manual deletion, i decided and made a filter to delete em automagically without me even seeing them some days ago. I think it would be much more helpful and desired if such emails were generated for new packages entering the repos, community too. Greg

1 0

[arch-general] [signoff] kernel26 2.6.27.9-1
by Tobias Powalowski 14 Dec '08

14 Dec '08

Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] request for toolchain signoffs
by Andreas Radke 14 Dec '08

14 Dec '08

I've pushed a glibc 2.9-2 to testing. I have added all changes made in Fedora's FC10 2.9-3 rpm. They have included some minor fixes and a workaround for the name resolving issue. This should fix our FS #12215. Now we need to know if there are still DNS problems. If it's solved I'd like to push it quickly to core. New gcc versions are not far away... -Andy

1 0