August 2010 - Arch-general - lists.archlinux.org

[arch-general] Fwd: [arch-dev-public] /dev/shm permissions and building in chroot
by Thomas Dziedzic 14 Aug '10

14 Aug '10

On Fri, Aug 13, 2010 at 10:51 PM, Allan McRae <allan(a)archlinux.org> wrote: > Hi, > > I have been tracking down a python3 bug and it turns out to be caused by > our chroot building. Essentially the permissions of /dev/shm are different > in the chroot than on the system: > > allan@mugen /home/arch/chroot/stable-i686/copy/dev > > ls -ld shm > drwxr-xr-x 2 root root 40 Jul 12 15:16 shm > > allan@mugen /dev > > ls -ld shm > drwxrwxrwt 2 root root 40 Aug 14 10:23 shm > > So when configure scripts try to test for POSIX semaphores by writing in > that directory, they fail. > > Looking at the relevant line in mkarchroot: > mount -o bind /dev "${working_dir}/dev" > > Doing that manually show the same issue. Should we add > > chmod 1777 "${working_dir}/dev/shm" > > after the mount? It fixes my issue but feels hackish. Any other > suggestions? > > Allan > > > > oops I don't have time to try it now, but we could try mounting it without a bind as described here: http://www.linuxfromscratch.org/lfs/view/stable/chapter06/kernfs.html Cheers! Sorry for sending it to arch-general, but I don't have "write" access to arch-dev-public :P

1 0

[arch-general] Mailman update
by Dan Vratil 13 Aug '10

13 Aug '10

Hi, please, could someone update the mailman package? It's outdated quite a long (at least since February 2009) and there is a new version 2.1.13 from December 2009. Thank you! Dan -- --------------------------------- Dan Vrátil vratil(a)progdansoft.com ICQ 249163429 Jabber progdan(a)jabber.cz Tel. +420 732 326 870 Tento email neobsahuje žádné viry, protože odesílatel nepoužívá Windows. / This email does not contain any viruses because the sender does not use Windows.

6 10

[arch-general] bash - pathname expansion controls 'set -f' or 'set -o noglob' on broken?
by David C. Rankin 13 Aug '10

13 Aug '10

Guys, I'm either misunderstanding how to control expansion of wildcards on the command line when passing the parameter containing the wildcard as a cli option to a script or the bash controls to allow that are broken. I want to set up a little script alias to search /var/abs for packages and I want the ability to pass either 'name' or 'name*' or '*name*' as input, but if there is anything matching in the current directory, expansion happens before the cli is passed to the script. Reading, I should be able to turn globbing off with either 'set -f' or 'set -o noglob' and then I should be able to pass the parameter contained a wildcard to the script without any pathname expansion. That appears broken -- or my logic is broken. From man bash 'set -f' or 'set -o noglob on' should prevent expansion: set [+abefhkmnptuvxBCEHPT] [+o option] [arg ...] <snip> -f Disable pathname expansion. <snip> -o option-name The option-name can be one of the following: <snip> noglob Same as -f. EXAMPLE: touch pacman-foo then use the following as your test script (tst.sh): #!/bin/bash myvar="$1" printf "Search: %s\n" $myvar exit 0 Now since i have a file called pacman-foo in my directory trying to pass 'pacman*' should result in expansion before the cli is read resulting in: 00:42 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo single-quoting doesn't even protect the cli?? : 00:42 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo Now try 'set -f' to disable pathname expanstion: 01:00 nirvana:~/scr/arch/tmp> set -f 01:02 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:02 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo Huh? Now try 'set -o noglob' 01:02 nirvana:~/scr/arch/tmp> set -o noglob 01:03 nirvana:~/scr/arch/tmp> ./tst.sh pacman* Search: pacman-foo 01:04 nirvana:~/scr/arch/tmp> ./tst.sh 'pacman*' Search: pacman-foo Huh? Again.. What gives is it bash or is it something I'm reading wrong? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

3 6

[arch-general] [signoff] kernel26 2.6.35.1-1
by Thomas Bächler 13 Aug '10

13 Aug '10

Upstream update, please test and sign off. We should probably be able to move this to core by the end of the week unless major problems occur. Please also sign off on 2.6.34.3 (see http://mailman.archlinux.org/pipermail/arch-dev-public/2010-August/017557.h…), I'd like to move that to core today already, as it fixes a number of problems with .34.2.

2 1

Re: [arch-general] [arch-dev-public] [signoff] sudo-1.7.4.p2-1
by Florian Pritz 13 Aug '10

13 Aug '10

On 11.08.2010 04:58, Allan McRae wrote: > Upstrema update. Upstream moved the location of the timestamp files, so > everyone will receive the sudo lecture on first usage. > > Signoff both, > Allan User signoff both Some defaults changed too. (1 timestamp per tty or behavior of -s, maybe more I didn't look) -- Florian Pritz -- {flo,bluewind}(a)server-speed.net

1 0

[arch-general] mirror.cs.vt.edu outdated
by Harry Strongburg 12 Aug '10

12 Aug '10

Hello, this mirror has an old lasysync of 1279951267. Googling this number returns a few results for other mirrors at this time. What does it mean? Lastly, what mirror is the "most trusted"? I trust vt.edu, their uptime has been wonderful until it stopped updating packages. I don't want to use the archlinux.org server, as it's limited (and you guys probably don't like the extra load). Thanks.

4 3

[arch-general] Fw: [arch-dev-public] [staging] repository: Let's give it a try!
by Mario Figueiredo 12 Aug '10

12 Aug '10

Forward Rationale: To give end users (and potential devs) an opportunity to discuss this too. On 11-08-2010 16:29, Pierre Schmitz wrote: > Hi devs, > > my last attempt for this didn't get much feedback so I try to keep it > short this time...for more details see the old thread at: > http://mailman.archlinux.org/pipermail/arch-dev-public/2010-May/016770.html > > This time I am just asking to give it a try. It's implementation is > trivial and if we feel it wont work out we could easily remove it later. > If there are no real objections I'd like to implement this soon; let's > say next week. Even if you don't see the benefit right now I would be > pleased to at least give it a try. > > The idea can be summed up like this: > > testing: > * don't break packages intentionally > * don't push incomplete rebuilds > This would definitely get me interested in Testing. Right now my Linux knowledge is limited and thus Testing is a no-go zone. If however I could have a guarantee that Testing offers the same package sanity insurance of the other mirrors, I could start participating. > staging: > * a global staging repository for collaboration > its more similar to your ~/staging dir than a regular repository > * mostly meant for incomplete rebuilds > * will be excluded from mirroring (for now) > > I am open for any questions or suggestions. Thanks for reading, > > Pierre > It needs to be said that this is also reflection of what one should expect to encounter in the development process in the wild. Apart from the potential for collaboration, the idea that the Arch repos could mimic this development cycle is very appealing to me. __________________________ | | V V Development <-> Staging <-> Testing -> Release Packaging maintenance is taken away from the end user, giving them "safe" (it's still a beta, hence the quotes) access to Testing. Meanwhile developers would separate packaging from Testing, considerably giving them a lot more control over what users can access from Testing.

3 3

Re: [arch-general] [arch-dev-public] [staging] repository: Let's give it a try!
by Evangelos Foutras 11 Aug '10

11 Aug '10

On Wed, Aug 11, 2010 at 7:24 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Let me underline again that [staging] would be no regular repo that > would be used by anyone directly. It mainly meant for collecting > rebuilds. However, it would have to be used by anyone wanting to rebuild a package against a new library that has been pushed to [staging]. Therefore, it would need to be mirrored and added to /etc/pacman.conf in our [testing] chroots. (By `our [testing] chroots' I mean the chroots that developers and TUs have been using until now for building packages for [testing].)

4 6

[arch-general] script to reformat 'pacman -Ss' output into 2 readable columns (prevents blindness)
by David C. Rankin 11 Aug '10

11 Aug '10

Guys, I developed a script to help me read the output of pacman -Ss in 2 nicely formatted columns. The output of 'pacman -Ss srchterm' drives me nuts trying to read down the package names and descriptions with all the tab indented and wrapped text -- so I fixed it. Download the script here: http://www.3111skyline.com/dl/Archlinux/scripts/srch2list.sh The script takes this: extra/ttf-khmer 5.0-2 TTFont collection for Khmer (Cambodia) extra/ttf-linux-libertine 4.4.1-3 Serif (Libertine) and Sans Serif (Biolinum) OpenType fonts with large Unicode coverage extra/ttf-mph-2b-damase 001.000.4.dfsg.2-2 Super-Unicode TTFont covering full Plane 1, and the following scripts: Armenian, Buginese, Cherokee, Cypriot Syllabary, Cyrillic, Deseret, Georgian, Asomtavruli, Nuskhuri but no Mkhedruli, Glagolitic, Gothic, Greek, Hanunoo, Hebrew, Latin, Limbu, Linear B, Old Italic, Old Persian cuneiform, Osmanya, Shavian, Syloti Nagri, Tai Le, Thaana, Tifinagh, Ugaritic, Vietnamese extra/ttf-ms-fonts 2.0-3 Core TTF Fonts from Microsoft and turn it into this: ttf-khmer TTFont collection for Khmer (Cambodia) ttf-linux-libertine Serif (Libertine) and Sans Serif (Biolinum) OpenType fonts with large Unicode coverage ttf-mph-2b-damase Super-Unicode TTFont covering full Plane 1, and the following scripts: Armenian, Buginese, Cherokee, Cypriot Syllabary, Cyrillic, Deseret, Georgian, Asomtavruli, Nuskhuri but no Mkhedruli, Glagolitic, Gothic, Greek, Hanunoo, Hebrew, Latin, Limbu, Linear B, Old Italic, Old Persian cuneiform, Osmanya, Shavian, Syloti Nagri, Tai Le, Thaana, Tifinagh, Ugaritic, Vietnamese ttf-ms-fonts Core TTF Fonts from Microsoft or with the '-d' option for semi-doublespace: ttf-khmer TTFont collection for Khmer (Cambodia) ttf-linux-libertine Serif (Libertine) and Sans Serif (Biolinum) OpenType fonts with large Unicode coverage ttf-mph-2b-damase Super-Unicode TTFont covering full Plane 1, and the following scripts: Armenian, Buginese, Cherokee, Cypriot Syllabary, Cyrillic, Deseret, Georgian, Asomtavruli, Nuskhuri but no Mkhedruli, Glagolitic, Gothic, Greek, Hanunoo, Hebrew, Latin, Limbu, Linear B, Old Italic, Old Persian cuneiform, Osmanya, Shavian, Syloti Nagri, Tai Le, Thaana, Tifinagh, Ugaritic, Vietnamese ttf-ms-fonts Core TTF Fonts from Microsoft The script needs 1 input. That is a filename 'srchfile' that contains the output from 'pacman -Ss srchterm > srchfile' There are 2 options, '-h or --help' gives a brief description and '-d' which causes the output to be essentially double-spaced. (each package description remains single spaced if it requires multiple lines, but a blank line is included between package descriptions) On the todo list is having the script take the input from stdin and eliminate the srchfile. NOTE: the '-d' option goes AFTER the filename. (I'll make the cli input position independent in the next version) The script does some pretty cool stuff and has some of my favorite funtions for the bash addicts out there. It reads 'srchfile' and formats the output in two columns 'pkgname' and 'description'. The pkgname column width is adjusted to the longest filename and the description column (in multiple lines, if necessary) spans the remainder of the xterm width leaving a one-char margin on the right. To make reading easier the description is parsed before being output so that descriptions that span multiple lines only break on spaces and not words while staying withing the column width. The column widths are dynamic based on the terminal window size. (via obtaining the terminal width and height from stty output). (for some reason, $COLUMNS and $LINES are not available in my scripts?? environment? exports?) The script was fun to write as it incorporated a good many of the finer points of bash. It is also well commented so if you are learning bash, or want to learn, this script can be a useful tool for some of the cooler things that can be done with arrays and strings using index manipulation and substring parsing/parameter substitution. The ultimate goal was to make the pacman search output readable, and I think this makes reading the search results *much* easier, at least for me. I guess what I should do for the next version is just incorporate the pacman -Ss call into the script itself and simply read the output of the search directly into the input array instead of reading the input file into an array. Simple enough, but I'll have to put that out as the next revision. Give this a whirl and see what you think. Let me know what works and what doesn't and also how I do things better/cleaner than I have currently done them. Who knows, maybe we will look at 'zenity --list' and provide a gui output next time :p Enjoy. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

8 21

[arch-general] Fwd: [arch-dev-public] Fwd: Junior Developer Mentor Scheme
by ALAUX, Guillaume 11 Aug '10

11 Aug '10

---------- Forwarded message ---------- From: Tobias Powalowski <t.powa(a)gmx.de> Date: 2 August 2010 21:46 Subject: [arch-dev-public] Fwd: Junior Developer Mentor Scheme To: Public mailing list for Arch Linux development < arch-dev-public(a)archlinux.org> ---------- Weitergeleitete Nachricht ---------- Betreff: Junior Developer Mentor Scheme Datum: Montag 02 August 2010, 14:44:06 Von: Tajidin Abd <tajidinabd(a)archlinux.us> An: tpowa(a)archlinux.org Hello there Tobias I had seen in past News something about bringing more contributors to Archlinux. I did email Allan in regards to this but so far no reply back. I was wondering is this still open for users to contribute the Project. Perhaps i need to post something in the devs mailing list to get more opinion about this. I mean I am a contributor to Fedora Project. I would hope since Arch is a smaller project it can bit more transparent in regards to this. Also it will take the load off other contributors. Any suggestions would be appreciated Tajidin ---------------------------------------------------- --------- -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org Hi there, Have I missed some news about the "Junior Mentor Scheme"? I guess this is over but I haven't heard of it since it was launched. Do we have new junior devs/TUs? If "yes" then kudos. Guillaume

1 0