[arch-general] go community package bug #19730
This bug has been open for a year now. Can somebody please look at the attached patches. https://bugs.archlinux.org/task/19730 Regards, Mike
Re: [arch-general] pacman seems to leak ftp connections
> After playing around i a throwaway-chroot, the problem seems to be > libfetch >=2.30. I just modified the PKGBUILD to different versions > (without replacing or rebuilding pacman at all). > > Libfetch 2.26 fetches files without a problem, 2.30+ fails after > downloading 5 files while MaxInstances in proftpd is set to 8. If I set > MaxInstances to 3, downloading fails outright (also only for 2.30+), so > something there seems to consume 3 connections before actually > downloading something at all. > > I'd try to break it down further, but NetBSDs CVS server isn't talking > to me at the moment. Ok maybe upate the bug with these results, so they have more information.
Re: [arch-general] pacman seems to leak ftp connections
> How would I best go about researching this? I have all the components
> right here, and it's easy enough to trigger, but I have no experience
> whatsoever in debugging libraries or C code in general.
>
> I could try and set up a chroot to bisect pacman /
> lib{fetch,archive,alpm} but I have no clue how good or bad random
> pacman versions interact with the rest of the system.
What I did to replicate this was create a chroot ie
sudo mkdir -p archtest/var/lib/pacman
and then test with a large group something like this
sudo pacman -Sy gnome --cachedir
$(pwd)/archtest/var/cache/pacman/pkg/ -r ./archtest/
if you need to download again you can just purge chroot cachedir.
after that I'm not sure how best to debug libfetch possibly using
netstat, lsof and strace?
Re: [arch-general] /etc/profile PATH variable wrong
On Mon, Aug 16, 2010 at 4:50 PM, Heiko Baums wrote: > Am Mon, 16 Aug 2010 18:42:55 -0400 > schrieb Matthew Monaco : > >> http://bugs.archlinux.org/task/12231 > > I requested to re-open this bug. > > Heiko > Thank you Heiko, I'll submit the patch if the task ever gets reopened. Mike
Re: [arch-general] /etc/profile PATH variable wrong
> Haha. Don't be so aggressive against discussion on an issue that you > brought up in the first place. We're just trying to help put things in > their proper place. But yeah I agree there are too many silly tangents > on this issue. So let somebody submit a patch and get it over with. Ah wasn't meant to sound aggressive. But I haz patch! see attached. Mike 001-profile.patch Description: Binary data
Re: [arch-general] /etc/profile PATH variable wrong
> Someone unaware of dotfiles might miss them, but others (blind or
> sighted) should be able to access them without issue.
And all of this has nothing to do with the orignal issue /usr/local. I
only suggested using something in $HOME for "user" based scripts which
can be anything it does not matter.
It only serves to deflect from why is /usr/local/{bin,sbin} not part
of the default search PATH? when its a FHS standard and has always
been used for custom system wide installs? Obviously a competent
system administrator can add this. However does this mean we should
remove /usr/bin now to? since any competent admin can add that also.
Mike
Re: [arch-general] /etc/profile PATH variable wrong
> > I use ~/.local/bin for user specific applications and scripts. ~/bin would > create visible clutter to the home folder. > > -- > Ape > That might work for you however in Jude's case being a blind user I would think he would want something that is very visible in a braille terminal. Either way I'm sure he can find something that works for him. But this also derails from the topic of /usr/local which is still a valid point. MIke
Re: [arch-general] /etc/profile PATH variable wrong
On Sun, Aug 15, 2010 at 5:44 AM, Heiko Baums wrote:
> Am Sun, 15 Aug 2010 11:21:24 +0200
> schrieb Laurent Carlier :
>
>> Le dimanche 15 août 2010 11:20:33, Allan McRae a écrit :
>> > On 15/08/10 18:50, Jude DaShiell wrote:
>> > > In order for that to be correct it needs to also
>> > > have :/usr/local/bin inside of the quote marks.
>> > > The /usr/local/bin directory on Linux systems like slackware and
>> > > debian is where stuff gets put that anyone can execute that's on
>> > > the system. I put a simple shell script I wrote there then tried
>> > > to use it and it wouldn't work until I keyed in
>> > > the /usr/local/bin/myd command. That small script makes the date
>> > > and time more readable for me. Since that file was copied from
>> > > suse, people in that other distribution probably also ought to be
>> > > notified.
>> >
>> > What is wrong with not including that? If the system administrator
>> > can install files to /usr/local/bin then I am sure that they are
>> > competent enough to add that to their path.
>> >
>> > Allan
>>
>> And as an user you can add the path in your .bashrc/
>>
>> ++
>
> Of course they can, but Jude is not completely wrong with that,
> because /usr/local and /usr/local/bin are part of the official Linux
> Filesystem Hierarchy Standard (FHS). So it's an official path for local
> scripts and binaries, which are e.g. written by the administrator. And
> official paths, even if the package manager doesn't touch them, and
> standards should be officially supported by Arch, too.
>
> And why does it hurt adding this directory to the PATH?
>
> From
> http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarchy.html#usr:
>
> "/usr/local
>
> The original idea behind '/usr/local' was to have a separate ('local')
> '/usr' directory on every machine besides '/usr', which might be just
> mounted read-only from somewhere else. It copies the structure of
> '/usr'. These days, '/usr/local' is widely regarded as a good place in
> which to keep self-compiled or third-party programs. The /usr/local
> hierarchy is for use by the system administrator when installing
> software locally. It needs to be safe from being overwritten when the
> system software is updated. It may be used for programs and data that
> are shareable amongst a group of hosts, but not found in /usr. Locally
> installed software must be placed within /usr/local rather than /usr
> unless it is being installed to replace or upgrade software in /usr."
>
> Heiko
>
I agree with this /usr/local/ is a pretty common location to install
system wide software and imo /usr/local/bin /usr/local/sbin should be
included in the default path. FHS covers this and GNU conf also
defaults to this.
However in Judd's case I would think ~/bin would be better suited for
user scripts unless he needs to use them system wide ie. as another
user. since its much easier to edit save the files and does not
require root privileges to modify
Mike
Re: [arch-general] bash - pathname expansion controls 'set -f' or 'set -o noglob' on broken?
Dave you need to quote your variables ie. var="*pacman*"; echo "$var" so printf "Search: %s\n" $myvar should read printf "Search: %s\n" "$myvar" On Thu, Aug 12, 2010 at 11:39 PM, David C. Rankin wrote: > On 08/13/2010 01:32 AM, David C. Rankin wrote: >> >> On 08/13/2010 01:15 AM, mike rosset wrote: >>> >>> quote command arguments like you would normally do. >>> >>> ie. $ myscript "*pacman*" >> >> Nope: >> >> 01:32 nirvana:~/scr/arch/tmp> ./tst.sh "pacman*" >> Search: pacman-foo >> >> > > Mike, > > I'm sorry, that was a short answer. My thoughts in this situation > were that partial or soft-quoting "" would not offer any additional > protection that full or hard-quoting '' did not already provide. From ABS: > > partial quoting [double quote]. "STRING" preserves (from interpretation) > most of the special characters within STRING. > > full quoting [single quote]. 'STRING' preserves all special characters > within STRING. This is a stronger form of quoting than "STRING". > > I'd run across this a couple of days ago on the pacman -Ss reformat > script work. > > > -- > 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 >
Re: [arch-general] bash - pathname expansion controls 'set -f' or 'set -o noglob' on broken?
On Thu, Aug 12, 2010 at 11:06 PM, David C. Rankin wrote: > 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 ...] > > -f Disable pathname expansion. > > -o option-name > The option-name can be one of the following: > > 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 > quote command arguments like you would normally do. ie. $ myscript "*pacman*"
Re: [arch-general] mandriva beat us to a new version
On Thu, Jul 29, 2010 at 5:06 PM, Allan McRae wrote: > On Thu, Jul 29, 2010 at 1:37 PM, Caleb Cushing > wrote: >> >> Just so you know I volunteered to be a junior dev and was >> rejected. I have ~400 >> http://aur.archlinux.org/packages.php?SeB=m&L=2&K=xenoterracide >> packages on the AUR. I file out of date packages on on Arch every day. >> I think I filed ALL the rebuild bugs (for perl- packages ) for 5.12. >> I've been running it for 3 months. I think I've done everything I >> /can/ to get this rolled out. The fact is the small, very small amount >> of work that has yet to be done... I can't do. > > The goal of Arch Linux is not to package things faster than everybody else. > The goal of Arch is to make the distribution that the developers want to > use. It just happens that Arch developers like having most things packaged > quickly so that is what we do. > > If we happen to be delayed updating something, it is either because no > developer has the time to update it or no developer particular cares about > updating it. We develop this distribution in our own free time so will get > to things when we want to, not when demand dictates it. > > And yes you have filed bugs about rebuilds, and yes you applied to be a > junior dev. However, your demanding attitude in repeated emails with > regards to this update means that we would much rather have a delayed perl > release that have you on the developer team. We rate not being an ass much > high than technical skill when selecting people when selecting people to > "work" with. > > Allan > I think everyone is missing the OP's point. Seems he has done a lot of work already to bring this version of perl to Arch. Work that is going to be done anyways by a Arch developer. If there is some technical reason to not except them. Then by all means just state the technical reasons maybe he can fix them. But this is not the first time I have seen this kinda of contradiction. If anyone has a bug or problem they are told to submit patches. When they have patches they then have to jump through so many hoops they never get submitted. Or they get flamed to the point they rather not contribute every again. I find it hard to believe that a distribution that contains how many thousands of opensource project in it's repositories. Has failed to adopt a more open development process then this. Regards, Mike
