Re: [arch-general] multiarch support like debian, pro and cons?
The big difference is that we need to maintain a completely separate second set of packages for multilib, while on Debian you use the exact same packages whether i386 is your main architecture or a secondary architecture. For us, the native i686 and x86_64 packages almost always contain the same files cannot be installed at the same time. Multilib packages are modified to only contain the needed i686 parts in another directory (/usr/lib32) while depending on the native x86_64 package for the rest. On Fri, Sep 26, 2014 at 8:38 AM, Eugenio M. Vigo wrote: > Hi, > IMHO, we already have multiarch support; I come from Debian and I really > don't see any substantial difference with what we have in Arch. > > OK, in Arch you have to add a repo, but in Debian you have to tell dpkg to > accept "i386" as a secondary architecture (# dpkg --add-architecture i386). > If you don't do that you don't get multiarch neither in Arch nor in Debian. > Everything else is absolutely the same for both users and mantainers: user > will still have to explicitly tell the package manager that they want a > 32-bit package and mantainers will still have to compile packages for both > architectures. > > I may be missing something, of course. > > Greeting, > Eugenio > > 2014-09-26 1:08 GMT+02:00 Ranomier : > >> I wrote my idea first on the irc, but i think here is a better place. >> >> The idea is to give up multiarch repo and make pacman and archlinux >> capable for real multiarch support >> >> That means u could install a 32bit package from the normal repos core, >> extra, community usw and not from multilib repo in 64bit arch. (example: >> pacman -S firefox:i386) >> >> And that means package maintainer don´t have to maintain two 32bit >> packages, >> plus all 32bit package where available ob 64bit. >> >> What are u guys thinking, about that ideas. >> What where the pro and cons, that i don´t see. >> >> Greetings, >> Ranomier >>
Re: [arch-general] multiarch support like debian, pro and cons?
Hi, IMHO, we already have multiarch support; I come from Debian and I really don't see any substantial difference with what we have in Arch. OK, in Arch you have to add a repo, but in Debian you have to tell dpkg to accept "i386" as a secondary architecture (# dpkg --add-architecture i386). If you don't do that you don't get multiarch neither in Arch nor in Debian. Everything else is absolutely the same for both users and mantainers: user will still have to explicitly tell the package manager that they want a 32-bit package and mantainers will still have to compile packages for both architectures. I may be missing something, of course. Greeting, Eugenio 2014-09-26 1:08 GMT+02:00 Ranomier : > I wrote my idea first on the irc, but i think here is a better place. > > The idea is to give up multiarch repo and make pacman and archlinux > capable for real multiarch support > > That means u could install a 32bit package from the normal repos core, > extra, community usw and not from multilib repo in 64bit arch. (example: > pacman -S firefox:i386) > > And that means package maintainer don´t have to maintain two 32bit > packages, > plus all 32bit package where available ob 64bit. > > What are u guys thinking, about that ideas. > What where the pro and cons, that i don´t see. > > Greetings, > Ranomier >
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, 2014-09-26 at 07:04 +0800, lolilolicon wrote: > /bin/sh has to exist. The question is what should really be? My > answer is whatever is closest to what pure sh is supposed to be, thus > dash (definitely not bash). +1 *buntu a long time ago switched to dash, Arch should do this too.
[arch-general] multiarch support like debian, pro and cons?
I wrote my idea first on the irc, but i think here is a better place. The idea is to give up multiarch repo and make pacman and archlinux capable for real multiarch support That means u could install a 32bit package from the normal repos core, extra, community usw and not from multilib repo in 64bit arch. (example: pacman -S firefox:i386) And that means package maintainer don´t have to maintain two 32bit packages, plus all 32bit package where available ob 64bit. What are u guys thinking, about that ideas. What where the pro and cons, that i don´t see. Greetings, Ranomier
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 6:54 AM, Ralf Mardorf wrote: > On Fri, 2014-09-26 at 06:24 +0800, lolilolicon wrote: >> Anything that has the #!/bin/sh line should be written in pure sh. >> If you want bash, ask for bash. > > I absolutely agree with your statement and that is why I don't care > about the sh link ;). IMO it's the useless link ever. But you're missing the fact that /bin/sh is hardcoded in system calls, such as system(3), popen(3). So /bin/sh has to exist. The question is what should really be? My answer is whatever is closest to what pure sh is supposed to be, thus dash (definitely not bash).
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, 2014-09-26 at 06:24 +0800, lolilolicon wrote: > Anything that has the #!/bin/sh line should be written in pure sh. > If you want bash, ask for bash. I absolutely agree with your statement and that is why I don't care about the sh link ;). IMO it's the useless link ever. My scripts ask for dash or bash (and assumed I would use something else, then for this) and just some old scripts use sh. Btw. if possible I try to write dash-bash-compatible scripts, e.g. by using printf instead of echo.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 6:06 AM, Leonid Isaev wrote: > Has anyone proven a theorem saying that no such bugs exist in dash > (zsh, ksh, etc.)? Oh, "such bugs" really only exist in bash. I believe no other shell processes an env var with a magic token into a function definition.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 6:06 AM, Leonid Isaev wrote: > >> Is there anything preventing us from making the switch from bash to dash >> as /bin/sh now? We can then have dash provide sh instead. > > Yes -- due to the same reasons. Care to elaborate? Is there a wiki page tracking progress on this, or something? > Also, I don't understand what the switch has to > do with the CVEs? If they are found -- good; if promptly fixed -- great. The bug is not really fixed. As far as I can tell the bug has been present since forever, but nobody discovered it due to the fact that function export is an obscure little known feature. If you look into the reason of this bug, to see how this feature works, if you're like many others, you will feel a bit uneasy about using bash as /bin/sh. > At the > very least this means that people are looking at the code... Has anyone proven > a theorem saying that no such bugs exist in dash (zsh, ksh, etc.)? No, there's no such theorem... But we can still use some heuristics, dash is small. Less code = fewer bugs. (For reasonably mature projects.) dash is the closest thing to sh. Anything that has the #!/bin/sh line should be written in pure sh. If you want bash, ask for bash.
Re: [arch-general] Gstreamer upgrade broke rhythmbox streams?
> On 09/26/2014 03:31 AM, Stephen Martin wrote: >> I don't use ffmpeg-complete (I just use the one from [extra]. >> >> I downgraded to gst-plugins-*-1.4.2* and all streams work again. The >> issue lies in gst-plugins-*-1.4.3* . > > strange; my streams still work with gst-plugins 1.4.3* > > something different in how rhythmbox & clementine do things. please let me > know when you file a bug. can't reproduce but would like to know how this > develops. > Actually, it affects pithos as well. Pithos spits out the same error when loading a station. Downgrading fixed that issue too. I'll report the issue now. --SM signature.asc Description: OpenPGP digital signature
Re: [arch-general] Gstreamer upgrade broke rhythmbox streams?
On 09/26/2014 03:31 AM, Stephen Martin wrote: I don't use ffmpeg-complete (I just use the one from [extra]. I downgraded to gst-plugins-*-1.4.2* and all streams work again. The issue lies in gst-plugins-*-1.4.3* . strange; my streams still work with gst-plugins 1.4.3* something different in how rhythmbox & clementine do things. please let me know when you file a bug. can't reproduce but would like to know how this develops. -- phani.
Re: [arch-general] A good time to switch to dash as /bin/sh?
> On Fri, Sep 26, 2014 at 05:37:57AM +0800, lolilolicon wrote: >> With the disclosure of the new bash bug (CVE-2014-6271, CVE-2014-7169), >> it seems timely to bring this up. >> >> Dan added dash to core/base around seven years ago [1], intending the >> eventually link /bin/sh to dash instead of bash. >> >> [1] >> https://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html >> >> We didn't make the switch, supposedly due to the bashism in our scripts >> which had a #!/bin/sh shebang line? >> >> Seven years passed. >> >> Is there anything preventing us from making the switch from bash to dash >> as /bin/sh now? We can then have dash provide sh instead. > > Yes -- due to the same reasons. Also, I don't understand what the switch has > to > do with the CVEs? If they are found -- good; if promptly fixed -- great. At > the > very least this means that people are looking at the code... Has anyone proven > a theorem saying that no such bugs exist in dash (zsh, ksh, etc.)? > > Cheers, > One of the primary reasons people wanted to switch to dash in the first place is not usability, but its performance for large shell scripts. For interactive shells, bash may still be more useful. As for shell performance, it was more relevant when bootup and service management relied on shell scripts. That is no longer really the case. With systemd, shell scripts for services and bootup are few and far between, afaik. So why risk breakages? --SM signature.asc Description: OpenPGP digital signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 05:37:57AM +0800, lolilolicon wrote: > With the disclosure of the new bash bug (CVE-2014-6271, CVE-2014-7169), > it seems timely to bring this up. > > Dan added dash to core/base around seven years ago [1], intending the > eventually link /bin/sh to dash instead of bash. > > [1] > https://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html > > We didn't make the switch, supposedly due to the bashism in our scripts > which had a #!/bin/sh shebang line? > > Seven years passed. > > Is there anything preventing us from making the switch from bash to dash > as /bin/sh now? We can then have dash provide sh instead. Yes -- due to the same reasons. Also, I don't understand what the switch has to do with the CVEs? If they are found -- good; if promptly fixed -- great. At the very least this means that people are looking at the code... Has anyone proven a theorem saying that no such bugs exist in dash (zsh, ksh, etc.)? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLFD8F0PBP1.pgp Description: PGP signature
Re: [arch-general] Gstreamer upgrade broke rhythmbox streams?
> On 09/25/2014 09:22 PM, Stephen Martin wrote: >> I listen to quite a few radio stations through rhythmbox, and all of >> them now fail to play with an error of "Could not determine type of >> stream." >> >> I noticed that gstreamer updated yesterday to 1.4.3. Might that be >> the issue? Are others experiencing similar problems? >> >> > > not sure if that's the reason in your case, i'm using clementine, not > rhythmbox, but i think it might very well be: > > i used to use ffmpeg-complete, a package from AUR instead of the ffmpeg > package from [extra]. after that AUR package received an update to a decoder > file it became impossible to decode network streams. (forgot the exact file / > codec name.) > > switching back to the ffmpeg package from [extra] solved the problem for me. > looking now i don't see that package, ffmpeg-complete, anymore, so no point > reporting this as a bug. > I don't use ffmpeg-complete (I just use the one from [extra]. I downgraded to gst-plugins-*-1.4.2* and all streams work again. The issue lies in gst-plugins-*-1.4.3* . --SM signature.asc Description: OpenPGP digital signature
[arch-general] A good time to switch to dash as /bin/sh?
With the disclosure of the new bash bug (CVE-2014-6271, CVE-2014-7169), it seems timely to bring this up. Dan added dash to core/base around seven years ago [1], intending the eventually link /bin/sh to dash instead of bash. [1] https://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html We didn't make the switch, supposedly due to the bashism in our scripts which had a #!/bin/sh shebang line? Seven years passed. Is there anything preventing us from making the switch from bash to dash as /bin/sh now? We can then have dash provide sh instead.
Re: [arch-general] New CVE - https://access.redhat.com/security/cve/CVE-2014-7169
On 09/25/2014 10:14 AM, Karol Blazewicz wrote: On Thu, Sep 25, 2014 at 9:26 AM, David C. Rankin wrote: It's like a game of Whack-a-Mole lately... Further reading: https://bugzilla.redhat.com/show_bug.cgi?id=1146319 -- David C. Rankin, J.D.,P.E. Why not send it to arch-security ML? Good point, but are not the same devs here as there? I see all the usual suspects. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Gstreamer upgrade broke rhythmbox streams?
On 09/25/2014 09:22 PM, Stephen Martin wrote: I listen to quite a few radio stations through rhythmbox, and all of them now fail to play with an error of "Could not determine type of stream." I noticed that gstreamer updated yesterday to 1.4.3. Might that be the issue? Are others experiencing similar problems? not sure if that's the reason in your case, i'm using clementine, not rhythmbox, but i think it might very well be: i used to use ffmpeg-complete, a package from AUR instead of the ffmpeg package from [extra]. after that AUR package received an update to a decoder file it became impossible to decode network streams. (forgot the exact file / codec name.) switching back to the ffmpeg package from [extra] solved the problem for me. looking now i don't see that package, ffmpeg-complete, anymore, so no point reporting this as a bug. -- ys phani.
Re: [arch-general] archlinux.org down
On 25.09.2014 19:15, Karol Blazewicz wrote: > At least for the last 15 minutes (since around 7 PM CEST) some of Arch > Linux sites have been down: Unexpected issues during maintenance. We're working on it. That said thanks for reporting issues ;) signature.asc Description: OpenPGP digital signature
Re: [arch-general] mkinitcpio debugging with systemd
Hi Martti, I did mention that I have been playing with the hooks and systemd in my initial mail. At least I thought that would be clear. Sorry if it was not. I will try to make that more clear next time. Was my first post here, I only joined this list recently. My question about how to open a debug shell is not effected by my changes in any way. Best Regards, Tobias On Sep 25, 2014 3:28 PM, "Martti Kühne" wrote: > > hi tobias, > > I wasn't taking you rude. But implying you were using custom packages > while we're trying to debug an issue is generally seen as a serious > undermining of any help... Such things are to be mentioned beforehand, > since the basic assumption is a repo install. > > cheers! > mar77i
[arch-general] archlinux.org down
At least for the last 15 minutes (since around 7 PM CEST) some of Arch Linux sites have been down: http://www.archlinux.org/ https://www.archlinux.org/packages/ https://bugs.archlinux.org/ https://www.archlinux.org/download/ The forum and wiki seem unaffected.
[arch-general] Gstreamer upgrade broke rhythmbox streams?
I listen to quite a few radio stations through rhythmbox, and all of them now fail to play with an error of "Could not determine type of stream." I noticed that gstreamer updated yesterday to 1.4.3. Might that be the issue? Are others experiencing similar problems? signature.asc Description: OpenPGP digital signature
Re: [arch-general] New CVE - https://access.redhat.com/security/cve/CVE-2014-7169
On Thu, Sep 25, 2014 at 9:26 AM, David C. Rankin wrote: > It's like a game of Whack-a-Mole lately... > > Further reading: > > https://bugzilla.redhat.com/show_bug.cgi?id=1146319 > > -- > David C. Rankin, J.D.,P.E. Why not send it to arch-security ML?
Re: [arch-general] mkinitcpio debugging with systemd
hi tobias, I wasn't taking you rude. But implying you were using custom packages while we're trying to debug an issue is generally seen as a serious undermining of any help... Such things are to be mentioned beforehand, since the basic assumption is a repo install. cheers! mar77i
Re: [arch-general] mkinitcpio debugging with systemd
Hi Martti, It was definitely not my intention to be rude. I am sorry if I gave that impression. Thanks again for taking the time to help me! Best Regards, Tobias On Thu, Sep 25, 2014 at 9:32 AM, Martti Kühne wrote: > On Wed, Sep 24, 2014 at 1:47 PM, Tobias Hunger > wrote: >> >> My C-foo is a bit rusty, so who knows what I actually put into my >> patched version of systemd-fstab-generator that I have on that >> initrd;-) >> > > > I was planning to complain already. > Try not to insult people trying to help you like that... > > cheers! > mar77i
Re: [arch-general] mkinitcpio debugging with systemd
On Wed, Sep 24, 2014 at 1:47 PM, Tobias Hunger wrote: > > My C-foo is a bit rusty, so who knows what I actually put into my > patched version of systemd-fstab-generator that I have on that > initrd;-) > I was planning to complain already. Try not to insult people trying to help you like that... cheers! mar77i
[arch-general] New CVE - https://access.redhat.com/security/cve/CVE-2014-7169
It's like a game of Whack-a-Mole lately... Further reading: https://bugzilla.redhat.com/show_bug.cgi?id=1146319 -- David C. Rankin, J.D.,P.E.
