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 wa
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 McRae 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 thin
> 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)
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
>>
>> wrote:
>>> On Sun, 02 May 2010 17:49:13 +0200
>>>
>>> Pierre Schmitz wrote:
This new kernel just exports some additional symbols
On Sun, May 9, 2010 at 12:03 PM, Marek Otahal wrote:
> Loading initramfs
> Starting udevd
> Done
> /Init: export: line 52: Variable name missing...
You're not the only one seeing it:
http://bugs.archlinux.org/task/19403
--
Byron Clark
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: Variable name missing...
>
> Thank you both for looking at this.
I sincerely apologize, that was
On Sunday 09 of May 2010 19:23:28 Pierre Schmitz wrote:
> On Sun, 9 May 2010 19:20:31 +0200, Marek Otahal
>
> 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 te
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
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
Hello,
On Sun, May 09, 2010 at 12:06:34PM -0400, Loui Chang wrote:
> On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
> > On Sun, May 9, 2010 at 2:44 PM, Allan McRae wrote:
> > > Sourcing is dangerous if the PKGBUILD is from an untrusted source. It
> > > also
> > > fails with package split
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 entir
On Sun, 9 May 2010 19:20:31 +0200, Marek Otahal
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 kerne
On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote:
> On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck
>
> wrote:
> > On Sun, 02 May 2010 17:49:13 +0200
> >
> > Pierre Schmitz wrote:
> >> This new kernel just exports some additional symbols for aufs2 which
> >> was updated to a new snaps
On Sun, May 9, 2010 at 6:06 PM, Loui Chang 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:
> ht
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
> On Sun, May 9, 2010 at 2:44 PM, Allan McRae 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 :
> mak
On Sun, May 9, 2010 at 4:57 PM, Kaiting Chen wrote:
> 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 p
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
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 wrote:
> On 09/05/10 16:08, vlad wrote:
>
>> On Sun, May 09, 2010 at 01:09:46AM +0300, Ionut Biru
On Sun, May 9, 2010 at 2:44 PM, Allan McRae 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 do
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 h
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
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
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 parseBu
On Sun, May 9, 2010 at 12:15 AM, Calvin McAnarney 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 o
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
25 matches
Mail list logo
