Re: [arch-general] PKGBUILD contributor, maintainer, author...
On Sun, May 09, 2010 at 01:09:46AM +0300, Ionut Biru wrote: On 05/09/2010 01:02 AM, Andre Osku Schmidt wrote: Hello Arch, i'm doing (for fun) a PKGBUILD parser in javascript, and now as i was testing it with random PKGBUILD files from AUR, i noticed that there is more than one way people use to define authors... (/usr/share/PKGBUILD.proto shows only Contributor) till now i've found: - Contributor - Maintainer - Author so i wonder what others should i parse ? or could you/we make a standard ? cheers .andre in proto was fixed in the next version of pacman. The standard is Maintainer and Contributor. Maintainer the current person who's maintaining the packager. Contributor past maintainers or persons who did contribute in a way to the build(if the current maintainer wants to add them) Finally a clear definition! -- Ionut --
Re: [arch-general] PKGBUILD contributor, maintainer, author...
On 09/05/10 16:08, vlad wrote: On Sun, May 09, 2010 at 01:09:46AM +0300, Ionut Biru wrote: On 05/09/2010 01:02 AM, Andre Osku Schmidt wrote: Hello Arch, i'm doing (for fun) a PKGBUILD parser in javascript, and now as i was testing it with random PKGBUILD files from AUR, i noticed that there is more than one way people use to define authors... (/usr/share/PKGBUILD.proto shows only Contributor) till now i've found: - Contributor - Maintainer - Author so i wonder what others should i parse ? or could you/we make a standard ? cheers .andre in proto was fixed in the next version of pacman. The standard is Maintainer and Contributor. Maintainer the current person who's maintaining the packager. Contributor past maintainers or persons who did contribute in a way to the build(if the current maintainer wants to add them) Finally a clear definition! The main principle I use when deciding on things like this is the phrase Who gives a shit?. :P Seriously... it is a comment so it does nothing. Does either label make it less informative if it is the only one there? Allan
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On 08/05/10 23:11, Matěj Týč wrote: What's wrong with that pacmatic functionality that shomehow tries to solve this, since it is not implemented in pacman? pacmantic's functionality is Arch specific while pacman is not. Message 29 in a thread that had the initial question answered in post #2... :)
Re: [arch-general] PKGBUILD contributor, maintainer, author...
On Sun, 2010-05-09 at 16:30 +1000, Allan McRae wrote: On 09/05/10 16:08, vlad wrote: On Sun, May 09, 2010 at 01:09:46AM +0300, Ionut Biru wrote: On 05/09/2010 01:02 AM, Andre Osku Schmidt wrote: Hello Arch, i'm doing (for fun) a PKGBUILD parser in javascript, and now as i was testing it with random PKGBUILD files from AUR, i noticed that there is more than one way people use to define authors... (/usr/share/PKGBUILD.proto shows only Contributor) till now i've found: - Contributor - Maintainer - Author so i wonder what others should i parse ? or could you/we make a standard ? cheers .andre in proto was fixed in the next version of pacman. The standard is Maintainer and Contributor. Maintainer the current person who's maintaining the packager. Contributor past maintainers or persons who did contribute in a way to the build(if the current maintainer wants to add them) Finally a clear definition! The main principle I use when deciding on things like this is the phrase Who gives a shit?. :P Seriously... it is a comment so it does nothing. Does either label make it less informative if it is the only one there? Allan I see it another way, its the AUR, by definition some of the PKGBUILDs are going to mislabel things, especially in the comments. Perhaps I should edit my PKGBUILDs to say Owner-And-Master-Of-This-Package's-Universe instead =)
Re: [arch-general] PKGBUILD contributor, maintainer, author...
On Sun, May 9, 2010 at 12:15 AM, Calvin McAnarney c...@gmx.us wrote: Maintainer specifies the actual maintainer of a package, while Contributor refers to previous maintainers of the package. So when the maintainer of a package changes, the old one is listed as Contributor from there on and the new one as Maintainer. Source: Arch Packaging Standards[1] on the Archwiki [1] http://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_Packages_to_the_AUR ah, thank you! i was only reading http://wiki.archlinux.org/index.php/PKGBUILD but now noticed that APS (and more) is in related links at http://wiki.archlinux.org/index.php/Creating_Packages
[arch-general] PKGBUILD parser
Well, my second rewrite seems also come to a dead-end, and before i rewrite this again, i was hoping someone here could give me tips on what would be the best method to parse a PKGBUILD file ? you can play with my latest fail here: http://osku.de/dump/pkgbuild.js/test-pkgbuild.html @todo parseBuild() fails if you have } in body @todo some array content in PKGBUILD mix ' and , so this fails ATM... (and the test-pkgbuild.html somehow doesn't parse build() on every second run...) cheers .andre
Re: [arch-general] PKGBUILD parser
On 05/09/2010 05:53 AM, Andre Osku Schmidt wrote: Well, my second rewrite seems also come to a dead-end, and before i rewrite this again, i was hoping someone here could give me tips on what would be the best method to parse a PKGBUILD file ? you can play with my latest fail here: http://osku.de/dump/pkgbuild.js/test-pkgbuild.html @todo parseBuild() fails if you have } in body @todo some array content in PKGBUILD mix ' and , so this fails ATM... (and the test-pkgbuild.html somehow doesn't parse build() on every second run...) cheers .andre Is this something that's strictly intended for the web? Because you could just source it, and that would only leave you with the comments to inspect.
Re: [arch-general] PKGBUILD parser
On 09/05/10 22:35, Matthew Monaco wrote: On 05/09/2010 05:53 AM, Andre Osku Schmidt wrote: Well, my second rewrite seems also come to a dead-end, and before i rewrite this again, i was hoping someone here could give me tips on what would be the best method to parse a PKGBUILD file ? you can play with my latest fail here: http://osku.de/dump/pkgbuild.js/test-pkgbuild.html @todo parseBuild() fails if you have } in body @todo some array content in PKGBUILD mix ' and , so this fails ATM... (and the test-pkgbuild.html somehow doesn't parse build() on every second run...) cheers .andre Is this something that's strictly intended for the web? Because you could just source it, and that would only leave you with the comments to inspect. Sourcing is dangerous if the PKGBUILD is from an untrusted source. It also fails with package splitting... Allan
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On 05/09/2010 12:35 AM, Allan McRae wrote: On 08/05/10 23:11, Matěj Týč wrote: What's wrong with that pacmatic functionality that shomehow tries to solve this, since it is not implemented in pacman? pacmantic's functionality is Arch specific while pacman is not. Message 29 in a thread that had the initial question answered in post #2... :) Touché Glad someone said it.
Re: [arch-general] PKGBUILD parser
On Sun, May 9, 2010 at 2:44 PM, Allan McRae al...@archlinux.org wrote: Sourcing is dangerous if the PKGBUILD is from an untrusted source. It also fails with package splitting... Makes me wonder why pkgbuilds are written in bash. Sounds like a big design flaw. But it depends on what our needs are : 1) we don't care about untrusted source or security, we always trust the source, then bash sourcing is very convenient (original idea behind that design) 2) we care about security and dealing with untrusted source in a secure way : the existing format sucks Currently we are neither in 1), nor in 2), we are somewhere in the middle with the inconvenient of both sides. We lost the convenience of 1) bash sourcing with package splitting. (I've been meaning to fix this for one year or so, just never got to it). And we don't have any ideas about how we could ever suit 2). Changing pkgbuild format doesn't sound really doable and realistic, it might be the most important characterization of what Arch is, changing it would make a new distrib. 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. To re-iterate : PKGBUILD format was meant to be easy to parse by using bash source. The moment you stop using bash source, it's just all wrong, and it's the format you have to change.
Re: [arch-general] PKGBUILD contributor, maintainer, author...
I don't think it's just a comment, I see it as meta-information. The only time that you appreciate meta-information is when you need it and its not there. On Sun, May 9, 2010 at 2:30 AM, Allan McRae al...@archlinux.org wrote: On 09/05/10 16:08, vlad wrote: On Sun, May 09, 2010 at 01:09:46AM +0300, Ionut Biru wrote: On 05/09/2010 01:02 AM, Andre Osku Schmidt wrote: Hello Arch, i'm doing (for fun) a PKGBUILD parser in javascript, and now as i was testing it with random PKGBUILD files from AUR, i noticed that there is more than one way people use to define authors... (/usr/share/PKGBUILD.proto shows only Contributor) till now i've found: - Contributor - Maintainer - Author so i wonder what others should i parse ? or could you/we make a standard ? cheers .andre in proto was fixed in the next version of pacman. The standard is Maintainer and Contributor. Maintainer the current person who's maintaining the packager. Contributor past maintainers or persons who did contribute in a way to the build(if the current maintainer wants to add them) Finally a clear definition! The main principle I use when deciding on things like this is the phrase Who gives a shit?. :P Seriously... it is a comment so it does nothing. Does either label make it less informative if it is the only one there? Allan -- All musicians are drug addicts, no question about it. The ecstasy we get during a concert is proof enough. yet there is a slight difference between us, the musicians, and the typical 'street-junkie'... Instead of consuming powder, we consume vibrations Will et/ou Gregory Eric Sanderson Turcot Temlett MacDonnell Forbes et/ou Touffa! :)
Re: [arch-general] PKGBUILD parser
Just to let you know dude, you can't parse that with a regular expression. A
regular expression is modeled / parsed by a finite automaton = a state
machine with a finite number of states. Braces allow nesting which creates a
source with potentially an infinite number of states consider,
a() { echo 1; b() { echo 2; }; }
Potentially I could next expressions like that endlessly. 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
Kaiting.
On Sun, May 9, 2010 at 10:21 AM, Xavier Chantry chantry.xav...@gmail.comwrote:
On Sun, May 9, 2010 at 2:44 PM, Allan McRae al...@archlinux.org wrote:
Sourcing is dangerous if the PKGBUILD is from an untrusted source. It
also
fails with package splitting...
Makes me wonder why pkgbuilds are written in bash. Sounds like a big
design flaw.
But it depends on what our needs are :
1) we don't care about untrusted source or security, we always trust
the source, then bash sourcing is very convenient (original idea
behind that design)
2) we care about security and dealing with untrusted source in a
secure way : the existing format sucks
Currently we are neither in 1), nor in 2), we are somewhere in the
middle with the inconvenient of both sides. We lost the convenience of
1) bash sourcing with package splitting. (I've been meaning to fix
this for one year or so, just never got to it).
And we don't have any ideas about how we could ever suit 2).
Changing pkgbuild format doesn't sound really doable and realistic, it
might be the most important characterization of what Arch is, changing
it would make a new distrib.
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.
To re-iterate : PKGBUILD format was meant to be easy to parse by using
bash source. The moment you stop using bash source, it's just all
wrong, and it's the format you have to change.
--
Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] PKGBUILD parser
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote: On Sun, May 9, 2010 at 2:44 PM, Allan McRae al...@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
Re: [arch-general] PKGBUILD parser
On Sun, May 9, 2010 at 6:06 PM, Loui Chang louipc@gmail.com wrote: 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 Ah, that's great, never heard of that before ! A few comments : - using the PKGINFO format sounds like a good idea, but not sure why you want to keep the same name. As you noticed yourself, this would cause stupid problems like a possible confusion between source and package tarballs. Better just call it SRCINFO, so pacman will never be confused. - for split pkgbuilds and arch , well... Maybe it would be simpler to write as many SRCINFO as there are PKGINFO/packages , i.e. one for every combination of split name / arch. Maybe all these files could be all combined into just one, I am not sure. But I would not care about data duplication, I would rather keep it as dummy and easy to parse as possible.
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote: On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck die...@plaetinck.be wrote: On Sun, 02 May 2010 17:49:13 +0200 Pierre Schmitz pie...@archlinux.de wrote: This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1 In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso. http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso boots fine on my system. signoff i686. once i have rebuilt images (with correct copyright statement) i will let the community test, then you'll have a bit more feedback about how well it works ;) Dieter It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this? Thanks and have a nice day Mark -- Marek Otahal :o)
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
Am 09.05.2010 19:23, schrieb Pierre Schmitz: please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. Wow, this is so helpful, what about writing it down? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sunday 09 of May 2010 19:23:28 Pierre Schmitz wrote: On Sun, 9 May 2010 19:20:31 +0200, Marek Otahal markota...@gmail.com wrote: It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this? Thanks and have a nice day Mark 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. Pierre: hmm, thanks for a constructive idea, yes I'm using logo.nologo boot param and I did update mkinitcpio recently. I'll try booting without the parameter. Thomas: Why such an unfriendly tone.. Anyways, I did write it down and it goes: Loading initramfs Starting udevd Done /Init: export: line 52: some unreadable characters Variable name missing... Thank you both for looking at this. -- Marek Otahal :o)
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
Am 09.05.2010 20:03, schrieb Marek Otahal: Thomas: Why such an unfriendly tone.. Anyways, I did write it down and it goes: Loading initramfs Starting udevd Done /Init: export: line 52: some unreadable characters Variable name missing... Thank you both for looking at this. I sincerely apologize, that was entirely uncalled for. It seems gcc screwed up, see my latest post here. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sun, May 9, 2010 at 12:03 PM, Marek Otahal markota...@gmail.com wrote: Loading initramfs Starting udevd Done /Init: export: line 52: some unreadable characters Variable name missing... You're not the only one seeing it: http://bugs.archlinux.org/task/19403 -- Byron Clark
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On 05/09/2010 06:20 PM, Marek Otahal wrote: On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote: On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck die...@plaetinck.be wrote: On Sun, 02 May 2010 17:49:13 +0200 Pierre Schmitz pie...@archlinux.de wrote: This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1 In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso. http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso boots fine on my system. signoff i686. once i have rebuilt images (with correct copyright statement) i will let the community test, then you'll have a bit more feedback about how well it works ;) Dieter It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this? Thanks and have a nice day Mark If you have something like radeon.modeset=1 in your kernel line, remove that, that caused me some trouble and I got a kernel panic during startup with this message: /init: export: line 52: (garbled chars): bad variable Kernel panic - not syncing: Attempted to kill init! -- Mauro Santos
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
I sincerely apologize, that was entirely uncalled for. It seems gcc screwed up, see my latest post here. not a problem :) I'm glad the bug is fixed and my systems boot again. Thank you! -- Marek Otahal :o)
Re: [arch-general] PKGBUILD parser
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.
Allan
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sunday 09 May 2010 23:22: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. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43987 is that related? -- Regards Shridhar
