Your message dated Thu, 24 Dec 2009 03:38:19 +
with message-id
and subject line Bug#542282: fixed in hw-detect 1.74
has caused the Debian Bug report #542282,
regarding firmware.agent broken with current udev
to be marked as done.
This means that you claim that the problem has been dealt with.
Your message dated Thu, 24 Dec 2009 03:38:19 +
with message-id
and subject line Bug#534413: fixed in hw-detect 1.74
has caused the Debian Bug report #534413,
regarding hw-detect: should not rely on testing for /proc/bus/usb
to be marked as done.
This means that you claim that the problem has
Your message dated Thu, 24 Dec 2009 03:38:19 +
with message-id
and subject line Bug#552497: fixed in hw-detect 1.74
has caused the Debian Bug report #552497,
regarding hw-detect: file conflict with udev-udeb for /lib/udev/firmware.agent
to be marked as done.
This means that you claim that the
debian-installer_20090123lenny5_amd64.changes uploaded successfully to localhost
along with the files:
debian-installer_20090123lenny5.dsc
debian-installer_20090123lenny5.tar.gz
debian-installer_20090123lenny5_amd64.deb
debian-installer-images_20090123lenny5_amd64.tar.gz
Greetings,
hw-detect_1.74_amd64.changes uploaded successfully to localhost
along with the files:
hw-detect_1.74.dsc
hw-detect_1.74.tar.gz
hw-detect_1.74_amd64.udeb
ethdetect_1.74_all.udeb
disk-detect_1.74_all.udeb
archdetect_1.74_amd64.udeb
Greetings,
Your Debian queue daemon (running on
tag 552497 - pending
thanks
On Thursday 24 December 2009, Frans Pop wrote:
> There are however two issues.
> 1) The custom script never gets included in initrds as hw-detect gets
> unpacked first and thus the original udev version of the script
> overwrites the modified hw-detect version.
> 2) The
Processing commands for cont...@bugs.debian.org:
> tag 552497 - pending
Bug #552497 [hw-detect] hw-detect: file conflict with udev-udeb for
/lib/udev/firmware.agent
Ignoring request to alter tags of bug #552497 to the same tags previously set
> thanks
Stopping processing here.
Please contact me
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
debian-installer_20090123lenny5.dsc
debian-installer_20090123lenny5.tar.gz
debian-installer_20090123lenny5_amd64.deb
This looks like an upload, but a .changes file is missing, so the job
cannot be pro
tag 552497 - pending
thanks
There is a difference between the scripts. The hw-detect version writes
some info to a file needed to support firmware loading.
There are however two issues.
1) The custom script never gets included in initrds as hw-detect gets
unpacked first and thus the original ud
Processing commands for cont...@bugs.debian.org:
> tag 552497 - pending
Bug #552497 [hw-detect] hw-detect: file conflict with udev-udeb for
/lib/udev/firmware.agent
Removed tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system ad
Your message dated Thu, 24 Dec 2009 01:48:53 +
with message-id
and subject line Bug#536353: fixed in debian-installer 20070308etch6
has caused the Debian Bug report #536353,
regarding debian-installer: [s390,etch] gpgv: Can't check signature: public key
not found
to be marked as done.
This m
debian-installer_20070308etch6_amd64.changes uploaded successfully to localhost
along with the files:
debian-installer_20070308etch6.dsc
debian-installer_20070308etch6.tar.gz
debian-installer_20070308etch6_amd64.deb
debian-installer-images_20070308etch6_amd64.tar.gz
Greetings,
You
On Wednesday 23 December 2009, Adam D. Barratt wrote:
> On Tue, 2009-12-22 at 00:20 +0100, Frans Pop wrote:
> > There are only a few udebs left that still depend on libc6 rather than
> > libc6-udeb. In most cases the reason is simply that they have not been
> > uploaded since glibc got support for
On Wednesday 23 December 2009, Sergei Sadovski wrote:
> In my case (net iso of 22 dec 2009) this was a file marker, i.e.
>
> $ /cdrom/.disk/base_installable
>
> rename/remove it (since we want to get files from outside), e.g.
>
> $ mv /cdrom/.disk/base_installable /cdrom/.disk/base_installable.fals
Your message dated Wed, 23 Dec 2009 16:00:36 +0100
with message-id <1261580436.21129.1.ca...@rbg-nb.strikeforce>
and subject line Squeeze Installation was successfully
has caused the Debian Bug report #528083,
regarding Squeeze installation fails during network configuration
to be marked as done.
Hi,
In my case (net iso of 22 dec 2009) this was a file marker, i.e.
$ /cdrom/.disk/base_installable
rename/remove it (since we want to get files from outside), e.g.
$ mv /cdrom/.disk/base_installable /cdrom/.disk/base_installable.false
in that case mirror settings will be used to retrieve com
On Wednesday 23 December 2009, Frans Pop wrote:
> Now what if that cleanup for some reason does not happen and we are left
> with the Packages file that was filtered for iop32x? That would explain
> why all iop32x targets succeed and the first non-iop32x target fails.
Ooooh. I've found a bug in th
On Wednesday 23 December 2009, Frans Pop wrote:
> On Wednesday 23 December 2009, Frans Pop wrote:
> > It could explain a difference between the buildd's and my build logs
> > though: it looks as if the correct kernel udebs may be getting
> > filtered out.
>
> The first difference is in the "get-pac
On Wednesday 23 December 2009, Frans Pop wrote:
> It could explain a difference between the buildd's and my build logs
> though: it looks as if the correct kernel udebs may be getting filtered
> out.
I've looked at the diff between my log and that from the buildd. It's
quite complex and I can't be
Peoplehelp dankt für ihre Spende.
Peoplehelp hilft Menschen in Not.
http://www.peoplehelp.ciroll.com/
Möchten Sie schnell viel Geld verdienen?
Beginnen Sie mit Forex zu Handeln.
http://www.forexyard.com/en/?zone_id=158
On Wednesday 23 December 2009, Frans Pop wrote:
> On Wednesday 23 December 2009, Frans Pop wrote:
> > Still, I don't see how it can be anything other than a mirror problem
> > as it built fine using my own mirror.
>
> The only other possibility I can think of is that something is going
> wrong with
On Wednesday 23 December 2009, Frans Pop wrote:
> Still, I don't see how it can be anything other than a mirror problem as
> it built fine using my own mirror.
The only other possibility I can think of is that something is going wrong
with the Kernel-Version filtering in utils/get-packages. If th
> armel fails to build like this:
>
> E: Couldn't find package input-modules-2.6.30-2-ixp4xx-di
> make[7]: *** [stamps/get_udebs-ixp4xx_netboot-stamp] Error 100
Hmm. It failed again I see.
Still, I don't see how it can be anything other than a mirror problem as it
built fine using my own mirror.
23 matches
Mail list logo
