Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote: Am 09.05.2010 19:37, schrieb Thomas Bächler: Am 09.05.2010 19:23, schrieb Pierre Schmitz: I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case logo.nologo in the kernel parameter line was causing this. That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged. Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems. I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3 the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic Removing logo.nologo boot param solves the problem. Thank you -- Marek Otahal :o)
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On 05/10/2010 12:57 PM, Marek Otahal wrote: On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote: Am 09.05.2010 19:37, schrieb Thomas Bächler: Am 09.05.2010 19:23, schrieb Pierre Schmitz: I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case logo.nologo in the kernel parameter line was causing this. That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged. Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems. I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3 the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic Removing logo.nologo boot param solves the problem. Thank you did you forgot to regenerate initrd? -- Ionut
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Monday 10 of May 2010 12:11:28 Ionut Biru wrote: On 05/10/2010 12:57 PM, Marek Otahal wrote: On Sunday 09 of May 2010 19:52:19 Thomas Bächler wrote: Am 09.05.2010 19:37, schrieb Thomas Bächler: Am 09.05.2010 19:23, schrieb Pierre Schmitz: I noticed the same. But this is caused by the mkinitcpio update and not the kernel. In my case logo.nologo in the kernel parameter line was causing this. That is plan bullshit. The mkinitcpio update didn't even _touch_ the init file, it is entirely unchanged. Okay, gcc 4.5.0 still fucks up, I am pushing a new mkinitcpio-busybox directly to core, built with -O0 this time, as this will keep breaking people's systems. I'm not sure if my mirrors are synced, but now probably yes..i have: mkinitcpio 0.6.4-1 mkinitcpio-busybox 1.16.1-3 the problem on boot still appears, maybe it's slightly different. It says: Loading initramfs Starting udevd Done /Init: export: line 52: ...unreadable chars.. : bad variable name Kernel panic Removing logo.nologo boot param solves the problem. Thank you did you forgot to regenerate initrd? Oh, my bad.. of course I didn't regenerate it. Problem solved. Thank you for pointing me in the good direction. -- Marek Otahal :o)
Re: [arch-general] PKGBUILD parser
On Mon, May 10, 2010 at 1:23 AM, Allan McRae al...@archlinux.org wrote:
On 10/05/10 02:06, Loui Chang wrote:
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
On Sun, May 9, 2010 at 2:44 PM, Allan McRaeal...@archlinux.org wrote:
Sourcing is dangerous if the PKGBUILD is from an untrusted source. It
also
fails with package splitting...
But I just had an idea now, if we're thinking about AUR use case :
makepkg --source could generate a suitable and parsable file providing
all information that AUR needs, and ships that next to the PKGBUILD in
the source tarball. Does that sound crazy ?
This would not fix the problem now, but it could fix it eventually,
when most pkgbuilds are re-submitted. Or this parsable file could be
generated for all pkgbuilds in a row, just for the conversion, in a
chroot/jail on a machine not in production.
Yeah I've thought about this as well. Source packages could have a
similar format as binary packages with a .PKGINFO file to present the
metadata in an easily parsable format.
You can read some of my incomplete brainstormings here:
http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz
I am told I like to be really negative anytime this is bought up... it is
not deliberate, I just see the barriers to this working. So here we go! I
know you have pointed out some problems already and this is related.
makepkg does not actually parse any of the splitpkg overrides until build
time. How do we get the packaging variable overrides without actually making
the package (and on every architecture)? We would need to extract the
needed fields from the package functions somehow. So that brings us back to
needing to hack a bash parser in makepkg or to actually require the package
building to take place before you can create a source package. And this is
not restricted to package splitting...
e.g.
pkgname=foo
...
# depends not needed at make time
# depends=('bar')
...
package() {
depends=('bar')
}
Welcome to the world of makepkg hacks... And do not think such hacks are
not used. The old klibc PKGBUILD generated a provides array in the build
function on the basis of a file name only available at the end of the build
process.
The joy of PKGBUILDs is that they are so flexible. The problem with
PKGBUILDs is that they are so flexible.
The biggest problem indeed comes from any variables that are declared
inside a function. Well, it's easy, let's just make a rule to forbid
it.
Any AUR packager who breaks the rule will have its package data messed
up in the AUR interface. Too bad for him/her.
The klibc package is/was an exception, not the rule, and it wasn't on
AUR so less problematic (still problematic for other tools like my
python check-packages for integrity check, but well).
So the main thing is split variables that need to be moved top-level.
Dan, Aaron and I had some proposals / examples how to deal with that.
You were included in the few mail exchanges we had but I am not sure
if you did receive all of them as you didn't reply directly in that
thread, I will forward it to you.
Re: [arch-general] PKGBUILD parser
my journey ended here: http://en.wikipedia.org/wiki/Parsing_expression_grammar i tried couple hours to understand how to use the two js librarys that are listed there... but yeah, i have no expertise in that (PEG) field and couldn't find any newbie friendly tutorials on that subject... so another freezed/dead project on my side. .andre ps. i just wanted to experiment on making a web gui for editing PKGBUILD files. you know, with validation, completion, help bubbles, whistlesbells, etc...
[arch-general] extra/hibernate-script out of date - new version
Hi everyone, As stated by mrbrich in this thread [1], package extra/hibernate-script [2] is out of date (old version 1.99 ; new version should be 2.0). I made this new one [3] that installs fine but I can't test it. Could anyone using it give it a try please? Thanks Guillaume ALAUX [1] http://bbs.archlinux.org/viewtopic.php?id=95899 [2] http://www.archlinux.org/packages/extra/i686/hibernate-script/ [3] http://archlinux.alaux.net/hibernate-script-2.0-2.src.tar.gz
Re: [arch-general] extra/hibernate-script out of date - new version
Hi everyone, As stated by mrbrich in this thread [1], package extra/hibernate-script [2] is out of date (old version 1.99 ; new version should be 2.0). I made this new one [3] that installs fine but I can't test it. Could anyone using it give it a try please? At this time it might be better to use the -git version There's a small number of fairly important changes (and 2.0 has been released more that a year ago) -- damjan
Re: [arch-general] extra/hibernate-script out of date - new version
Am 10.05.2010 15:13, schrieb Guillaume ALAUX: Hi everyone, As stated by mrbrich in this thread [1], package extra/hibernate-script [2] is out of date (old version 1.99 ; new version should be 2.0). I made this new one [3] that installs fine but I can't test it. Could anyone using it give it a try please? Thanks Guillaume ALAUX [1] http://bbs.archlinux.org/viewtopic.php?id=95899 [2] http://www.archlinux.org/packages/extra/i686/hibernate-script/ [3] http://archlinux.alaux.net/hibernate-script-2.0-2.src.tar.gz I used to maintain this, but neither have the time nor the possibility to test it right now. I orphaned it and requested another Dev or TU to take it. Nobody ever responded, which means you can put the package in the AUR and I'll delete it from the repository. signature.asc Description: OpenPGP digital signature
Re: [arch-general] extra/hibernate-script out of date - new version
OK So Thomas as you were the maintainer: could you just tell me which way would be the best: git version as advised by Damjan or standalone as you did for v1.99? On 10 May 2010 15:50, Thomas Bächler tho...@archlinux.org wrote: Am 10.05.2010 15:13, schrieb Guillaume ALAUX: Hi everyone, As stated by mrbrich in this thread [1], package extra/hibernate-script [2] is out of date (old version 1.99 ; new version should be 2.0). I made this new one [3] that installs fine but I can't test it. Could anyone using it give it a try please? Thanks Guillaume ALAUX [1] http://bbs.archlinux.org/viewtopic.php?id=95899 [2] http://www.archlinux.org/packages/extra/i686/hibernate-script/ [3] http://archlinux.alaux.net/hibernate-script-2.0-2.src.tar.gz I used to maintain this, but neither have the time nor the possibility to test it right now. I orphaned it and requested another Dev or TU to take it. Nobody ever responded, which means you can put the package in the AUR and I'll delete it from the repository.
Re: [arch-general] extra/hibernate-script out of date - new version
Am 10.05.2010 15:57, schrieb Guillaume ALAUX: OK So Thomas as you were the maintainer: could you just tell me which way would be the best: git version as advised by Damjan or standalone as you did for v1.99? In the past I always used the stable version. However, I never used it together with tuxonice, but only with usual suspend to RAM, so I don't know how good the tuxonice support is in the stable release. As I said, I haven't actually been maintaining this recently. signature.asc Description: OpenPGP digital signature
Re: [arch-general] extra/hibernate-script out of date - new version
Hi Thomas, Here is the package I have just uploaded in AUR: http://aur.archlinux.org/packages.php?ID=37110 You can delete it from extra then. I checked others PKGBUILD and none of them make any reference to it so we should'nt have issues with dependencies. I will add some explanation on the AUR page to explain that this pkg requires testing and feedback. I will also get the wiki page up to date to reflect this repo change if you confirm you deleted it. Thanks. Guillaume ALAUX On 10 May 2010 16:01, Thomas Bächler tho...@archlinux.org wrote: Am 10.05.2010 15:57, schrieb Guillaume ALAUX: OK So Thomas as you were the maintainer: could you just tell me which way would be the best: git version as advised by Damjan or standalone as you did for v1.99? In the past I always used the stable version. However, I never used it together with tuxonice, but only with usual suspend to RAM, so I don't know how good the tuxonice support is in the stable release. As I said, I haven't actually been maintaining this recently.
Re: [arch-general] Removing padevchooser and paman
Anyone else? If I don't get any objections, I'll move them to AUR and disown. On Sat, May 8, 2010 at 2:23 AM, Jan Steffens jan.steff...@gmail.com wrote: I would like to remove these two packages from community and move them to unsupported (AUR). Both are marked as obsolete by upstream[1] and weren't updated since 2007. padevchooser is a notification area app that allows choosing default sinks and sources, as well as starting some other PulseAudio applications. It has been obsoleted by pavucontrol, which also allows much finer control over sink and source usage. paman is a diagnostic tool that provides information similar to pacmd list, as well as allowing control of stream volumes (provided by pavucontrol) and playing samples from the cache (pacmd play-sample). Your thoughts? 1: http://pulseaudio.org/wiki/PerfectSetup
Re: [arch-general] Removing padevchooser and paman
On Mon, May 10, 2010 at 2:13 PM, Jan Steffens jan.steff...@gmail.com wrote: Anyone else? If I don't get any objections, I'll move them to AUR and disown. Go go go -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-general] PKGBUILD parser
Andre Osku Schmidt andre.osku.schm...@googlemail.com a écrit : A regular expression will never be able to parse that.because it can never decide which brace is the final one. This might be better explained here. http://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-match-nested-patterns thank you. i'll continue my journey on parsing this another way. Actually if you read the page linked above completely you will notice that it says that you can. Regexps like POSIX that use finite automata can't but PCRE (that are everywhere) can, at least recent versions. That's also why they are slower. -- catwell (from mobile phone)
Re: [arch-general] PKGBUILD parser
On Mon, May 10, 2010 at 1:14 PM, Pierre Chapuis catw...@archlinux.us wrote: Andre Osku Schmidt andre.osku.schm...@googlemail.com a écrit : A regular expression will never be able to parse that.because it can never decide which brace is the final one. This might be better explained here. http://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-match-nested-patterns thank you. i'll continue my journey on parsing this another way. Actually if you read the page linked above completely you will notice that it says that you can. Regexps like POSIX that use finite automata can't but PCRE (that are everywhere) can, at least recent versions. That's also why they are slower. yes via a recursive expression. another option would be to use a multipass setup (i havent looked at the OP's code) to break the problem into smaller chunks instead of trying to to it all in one expression (i.e. use an expression to count the braces/etc. and build another expression dynamically based off the results of the first)
Re: [arch-general] PKGBUILD parser
Interesting I didn't realize that. But then it's not really a 'regular' expression then. They should call it a 'limited-context-free' expression... Kaiting. On Mon, May 10, 2010 at 2:21 PM, C Anthony Risinger anth...@extof.mewrote: On Mon, May 10, 2010 at 1:14 PM, Pierre Chapuis catw...@archlinux.us wrote: Andre Osku Schmidt andre.osku.schm...@googlemail.com a écrit : A regular expression will never be able to parse that.because it can never decide which brace is the final one. This might be better explained here. http://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-match-nested-patterns thank you. i'll continue my journey on parsing this another way. Actually if you read the page linked above completely you will notice that it says that you can. Regexps like POSIX that use finite automata can't but PCRE (that are everywhere) can, at least recent versions. That's also why they are slower. yes via a recursive expression. another option would be to use a multipass setup (i havent looked at the OP's code) to break the problem into smaller chunks instead of trying to to it all in one expression (i.e. use an expression to count the braces/etc. and build another expression dynamically based off the results of the first) -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] PKGBUILD parser
On Mon 10 May 2010 09:23 +1000, Allan McRae wrote:
On 10/05/10 02:06, Loui Chang wrote:
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
But I just had an idea now, if we're thinking about AUR use case :
makepkg --source could generate a suitable and parsable file providing
all information that AUR needs, and ships that next to the PKGBUILD in
the source tarball. Does that sound crazy ?
This would not fix the problem now, but it could fix it eventually,
when most pkgbuilds are re-submitted. Or this parsable file could be
generated for all pkgbuilds in a row, just for the conversion, in a
chroot/jail on a machine not in production.
Yeah I've thought about this as well. Source packages could have a
similar format as binary packages with a .PKGINFO file to present the
metadata in an easily parsable format.
You can read some of my incomplete brainstormings here:
http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz
I am told I like to be really negative anytime this is bought up...
it is not deliberate, I just see the barriers to this working. So
here we go! I know you have pointed out some problems already and
this is related.
No problem. I didn't really share this before because I hadn't even
thought of a real solution. Since it was mentioned though, I thought I'd
share my thoughts. There are definitely many barriers to sort out.
makepkg does not actually parse any of the splitpkg overrides until
build time. How do we get the packaging variable overrides without
actually making the package (and on every architecture)? We would
need to extract the needed fields from the package functions somehow.
So that brings us back to needing to hack a bash parser in makepkg or
to actually require the package building to take place before you can
create a source package. And this is not restricted to package
splitting...
e.g.
pkgname=foo
...
# depends not needed at make time
# depends=('bar')
...
package() {
depends=('bar')
}
Welcome to the world of makepkg hacks... And do not think such
hacks are not used. The old klibc PKGBUILD generated a provides
array in the build function on the basis of a file name only
available at the end of the build process.
Yeah there'd have to be some kind of standard constructs for all these
kinds of hacks like platform specific dependencies, etc. That would
probably mean changing or expanding the PKGBUILD spec. I wouldn't be
afraid to do that, but it might not sit well with compatibility or with
Arch principles.
The joy of PKGBUILDs is that they are so flexible. The problem with
PKGBUILDs is that they are so flexible.
Indeed.
[arch-general] Arch shutdown because of firefox
hi all, I am a newbie for ArchLinux. My computer often shuts down suddenly when I browse web site. It brings me to TTY and said The system is going down for system halt NOW!. I found that is because of the crash of flash plugin of firefox. And my question is why the crash of firefox can cause my computer shuts down? PS. my system environment: Arch + awesome, no DE. Thanks! hc
[arch-general] 回复： Re: Arch shutdown b ecause of firefox
any web site. 在 2010-5-11 上午11:16，Jeffrey Lynn Parke Jr. jeffrey.pa...@gmail.com编写： which website does this for you. any website or one in particular. On Mon, May 10, 2010 at 10:14 PM, Handsome Cheung handsomeche...@gmail.comwrote: hi all, I am a newbie for ArchLinux. My computer often shuts down suddenly when I browse ...
Re: [arch-general] Arch shutdown because of firefox
On 05/11/2010 08:44 AM, Handsome Cheung wrote: hi all, I am a newbie for ArchLinux. My computer often shuts down suddenly when I browse web site. It brings me to TTY and said The system is going down for system halt NOW!. I found that is because of the crash of flash plugin of firefox. And my question is why the crash of firefox can cause my computer shuts down? PS. my system environment: Arch + awesome, no DE. Thanks! hc Are you using some sort of AutoShutdown schedule? check 'sudo crontab -l' -- Regards, Gaurish Sharma www.gaurishsharma.com
