Re: Plug applications into browsers
On Wed, Feb 21, 2007 at 11:11:02AM +, Howard Young wrote: > Hello > > I had wanted to use MSYS to develop for the other platform. Most of my > experience is with WIN32 API, ATL3/COM+ and DirectX on the other platform. > > Ron Johnson wrote: > >Huh? ActiveX is woven deeply into, and relies upon the Win32 API. > > > Yes. > > 1 I want to develop on Linux only. Writing: > a) An Active X for Windows which makes development time go down a little, because you can write 'native' applications > b) Linux equivalent Which doubles development time, since you have to do the same thing over again > c) MacOS equivalent through QT Triples > d) Java applet (for all) Quadruples. Then again, you can just stick to Java and keep it at that. If you want to write a plugin, however (as opposed to an applet that is shown on a page), then you could indeed use the netscape plugin API (which is supported by almost every browser for the Linux platform). You should probably ask the mozilla people about that, though. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
YOUR SINCERITY, STRAIGHTFORWARDNESS AND ONENESS NEEDED.
新しいメールアドレスをお知らせします新しいメールアドレス： [EMAIL PROTECTED] FRIEND, CAN YOU BE TRUSTED???. I AM DAVID,SERVINGARMY痿儡 3RD INFANTRY DIVISION IN IRAQ. FOLLOWING THE SITUATION IN IRAQ.WE HAVE DECIDED TO ENTRUST THIS FUND INTO YOUR COSTUDY.FOR SAFETY PURPOSES. YOU HAVE NOTHING TO LOSE OR REGRET. PLS GET BACK FOR FURTHER DETAILS ASAP. REGARDS. - DAVID SS. SERVING ARMY IN IRAQ. YOUR FULL TRUST,
Where did Bacula 1.38.11-7+b1 come from?
Hi, sid seems to contain bacula 1.38.11-7+b1, a binary-only NMU for i386, which breaks bacula-console and various other packages due to broken deps. The changelog file is signed only "buildd_i386-saens". packages.qa.debian.org doesn't know about 1.38.11-7+b1. Strangely, packages.debian.org's page for bacula-console shows 1.38.11-7+b1 on all platforms except kfreebsd-i386. It doesn't make sense why the package would be bin NMU'd everywhere. The changelog message also doesn't reference any bug number. I can't find a notice of the NMU in the BTS either. Does anybody know what is going on here? (This problem was reported in bug #411652) I think someone deserves a serious thwacking... they obviously didn't even try to install the result of the NMU, filed no bug about it, etc. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Wed, Feb 14, 2007, Ryan Murray wrote: > wiki.debian.org has been moved to a new host with lots of available > disk space, so updates should be fine now. For the first 90 minutes > after the move exim wasn't running, so updates during this period > would have failed to send notifications. > > If any problems are found with the move, please contact debian-admin > with details. Hi! There must have been a problem with the move because bugs.d.o and wiki.d.o have been down the whole day while no maintenance was planned (or there's a problem with -devel-anounce, too, I don't know). Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On 2007-02-22, John Goerzen <[EMAIL PROTECTED]> wrote: > Strangely, packages.debian.org's page for bacula-console shows > 1.38.11-7+b1 on all platforms except kfreebsd-i386. It doesn't make > sense why the package would be bin NMU'd everywhere. maybe problems with one of the dependencies made a rebuild needed ? (IIRC some packages depending on mysql built against some specific versions needed to be rebuilt) > The changelog message also doesn't reference any bug number. > I can't find a notice of the NMU in the BTS either. That's how binNMUs are - just a simple rebuild on one or more archs. > Does anybody know what is going on here? Your package is not binNMU-safe. > (This problem was reported in bug #411652) > > I think someone deserves a serious thwacking... Maybe the maintainer for making non-binNMU-safe packages ? > they obviously didn't > even try to install the result of the NMU, filed no bug about it, etc. it is only a rebuild - there is nothing to file about it. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Thu, 2007-02-22 at 17:37 +0100, Sam Hocevar wrote: > On Wed, Feb 14, 2007, Ryan Murray wrote: > > wiki.debian.org has been moved to a new host with lots of available > > disk space, so updates should be fine now. For the first 90 minutes > > after the move exim wasn't running, so updates during this period > > would have failed to send notifications. > > > > If any problems are found with the move, please contact debian-admin > > with details. > >Hi! There must have been a problem with the move because bugs.d.o and > wiki.d.o have been down the whole day while no maintenance was planned > (or there's a problem with -devel-anounce, too, I don't know). I get both, lickety split. Both are up and available. This problem/move was done 8 days ago. I suspect your ISP has bad caching for its DNS resolution. Proper DNS stuff: [EMAIL PROTECTED]:~$ dig bugs.debian.org ; <<>> DiG 9.4.0rc2 <<>> bugs.debian.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44084 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;bugs.debian.org. IN A ;; ANSWER SECTION: bugs.debian.org.186 IN A 140.211.166.43 ;; AUTHORITY SECTION: debian.org. 1204IN NS klecker.debian.org. debian.org. 1204IN NS raff.debian.org. debian.org. 1204IN NS rietz.debian.org. ;; ADDITIONAL SECTION: raff.debian.org.14365 IN A 192.25.206.59 rietz.debian.org. 36866 IN A 140.211.166.43 klecker.debian.org. 14365 IN A 194.109.137.218 ;; Query time: 30 msec ;; SERVER: 208.64.37.170#53(208.64.37.170) ;; WHEN: Thu Feb 22 12:02:45 2007 ;; MSG SIZE rcvd: 158 Hope this helps. -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Thu, Feb 22, 2007 at 12:03:51PM -0500, Greg Folkert wrote: > On Thu, 2007-02-22 at 17:37 +0100, Sam Hocevar wrote: > > On Wed, Feb 14, 2007, Ryan Murray wrote: > > > wiki.debian.org has been moved to a new host with lots of available > > > disk space, so updates should be fine now. For the first 90 minutes > > > after the move exim wasn't running, so updates during this period > > > would have failed to send notifications. > > > > > > If any problems are found with the move, please contact debian-admin > > > with details. > > > >Hi! There must have been a problem with the move because bugs.d.o and > > wiki.d.o have been down the whole day while no maintenance was planned > > (or there's a problem with -devel-anounce, too, I don't know). > [...] > I suspect your ISP has bad caching for its DNS resolution. FYI rietz (the machin the bts is on) has been down for 8 hours or so. To understand sam's post http://en.wikipedia.org/wiki/Irony#Verbal_irony may be useful. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgplGv9IyfTCe.pgp Description: PGP signature
Re: bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Thu, Feb 22, 2007, Greg Folkert wrote: > ;; ANSWER SECTION: > bugs.debian.org.186 IN A 140.211.166.43 > > Hope this helps. It sure did! Thanks! Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: > > (This problem was reported in bug #411652) > > > > I think someone deserves a serious thwacking... > > Maybe the maintainer for making non-binNMU-safe packages ? That is so much bullshit. Whoever uploaded the binNMU uploaded broken packages. No excuses. End of story. Now, it may be that the bacula package could be improved to generate better results for a binNMU. The proper way to do that is to submit bugs, preferably with patches, so that the bacula maintainer can fix the source packages. Broken uploads are Not The Right Thing. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On 2007-02-22, Steve Greenland <[EMAIL PROTECTED]> wrote: > On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: >> > (This problem was reported in bug #411652) >> > >> > I think someone deserves a serious thwacking... >> >> Maybe the maintainer for making non-binNMU-safe packages ? > > That is so much bullshit. if the topic was something more 'gently' than 'serious thwacking', then yes. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
John Goerzen <[EMAIL PROTECTED]> wrote:
> sid seems to contain bacula 1.38.11-7+b1, a binary-only NMU for i386,
> which breaks bacula-console and various other packages due to broken
> deps. The changelog file is signed only "buildd_i386-saens".
> packages.qa.debian.org doesn't know about 1.38.11-7+b1.
> Strangely, packages.debian.org's page for bacula-console shows
> 1.38.11-7+b1 on all platforms except kfreebsd-i386. It doesn't make
> sense why the package would be bin NMU'd everywhere.
Hello,
A binNMU does not show up in the pts, since there are no source
changes.
> The changelog message also doesn't reference any bug number.
> I can't find a notice of the NMU in the BTS either.
binNMUs are done without the bug-report. (It would be rather
pointless, since the maintainer himself cannot schedule binNMUs on
Debian's buildds.)
> Does anybody know what is going on here?
http://lists.debian.org/debian-release/2007/02/msg00647.html
> (This problem was reported in bug #411652)
> I think someone deserves a serious thwacking... they obviously didn't
> even try to install the result of the NMU, filed no bug about it, etc.
The bug is that a binNMU for bacula was scheduled although it is not
binNMU-able. Usually checking is done whether the package would break
before triggereing the rebuilt. Looks like this was missed this time.
If your next sourceful upload would fix this it would make the
release-team's work easier. The fix is simple:
1. Add a Build-dependency on dpkg-dev (>=1.13.19)
2. For all in bacula-foo packages that are arch:all replace any
occurence of
Depends: bacula-foo (= ${Source-Version})
with Depends: bacula-foo (= ${source:Version})
3. (optional, but clarify things) For all in bacula-foo packages that
are arch:any replace any
occurence of
Depends: bacula-foo (= ${Binary-Version})
Untested (For testing just set the version number to 1.38.11-7+b1 in
debian/changelog and rebuild with dpkg-buildpackage -b), I'll not have
time for a tested patch today or tomorrow but I can probably come up
with one on the weekend if you have not had time to resolve this then.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 11:53:23AM -0600, Steve Greenland wrote: > On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: > > > (This problem was reported in bug #411652) > > > > > > I think someone deserves a serious thwacking... > > > > Maybe the maintainer for making non-binNMU-safe packages ? > > That is so much bullshit. Whoever uploaded the binNMU uploaded broken > packages. That would be the buildd. You are aware that buildd-built packages aren't usually tested before upload? -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote: > binNMUs are done without the bug-report. (It would be rather > pointless, since the maintainer himself cannot schedule binNMUs on > Debian's buildds.) This sounds inaccurate. binNMUs should still be in response to bugs wherever applicable, but they should close them unversioned since the BTS tracks source versions. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 05:59:33PM +, Sune Vuorela wrote: > On 2007-02-22, Steve Greenland <[EMAIL PROTECTED]> wrote: > > On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: > >> > (This problem was reported in bug #411652) > >> > > >> > I think someone deserves a serious thwacking... > >> > >> Maybe the maintainer for making non-binNMU-safe packages ? > > > > That is so much bullshit. > > if the topic was something more 'gently' than 'serious thwacking', then > yes. I maintain that anyone that uploads a package that is uninstallable *at the time of upload* needs something more than gentle encouragement. To upload someone else's package and render it uninstallable is even more annoying. To do that without ever even filing a bug, let alone posting info to the BTS about it, is even more so. I don't know what the difference between a regular NMU and a binNMU on all archs is, in terms of packaging practices. (Obviously Arch: all never gets built with the latter, which is the instant problem). I still don't even know who did that, or why -- since it was apparently built everywhere -- it wasn't done as a regular NMU. Having said that, I would have sent a polite message in private to the person that made the uploads. Only there is no record of that in the package or the QA system. I have repeatedly stated that I don't mind if people NMU my packages *as long as they follow the guidelines*. Here are some of the things from http://www.debian.org/doc/developers-reference that the person that uploaded this package didn't follow: * 5.10.2.1 (on binNMUs): "You have to make sure that your binary-only NMU doesn't render the uninstallable. This could happen when a source package generates arch-dependent and arch-independent packages that depend on each other via $(Source-Version)." (Which is exactly what happened here) * The upload violated policy section 4.4, in that the maintainer name and the email address of the *person* uploading the version do not appear in the changelog. Since this was a binNMU that effectively seems to have hit all archs, it seems that the regular NMU requirements should apply, too (Devref sec 5.11.1): * Make sure that the bug being fixed is in the BTS * Wait for maintainer reaction * Take responsibility for bugs you've introduced (now *I* have to produce a new upload, and I don't even know if I need to tighten some build-deps in control, because nobody told me what the original problem was) So yes, I'm ticked. Some unknown developer broke my package, violated policy, never told me what the problem was, and isn't taking responsibility to fix it. If you break something, you fix it. Not make someone else spend time figuring out what changed, why, by whom, and fix it. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
> 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> 2. For all in bacula-foo packages that are arch:all replace any
> occurence of
> Depends: bacula-foo (= ${Source-Version})
> with Depends: bacula-foo (= ${source:Version})
> 3. (optional, but clarify things) For all in bacula-foo packages that
> are arch:any replace any occurence of
> Depends: bacula-foo (= ${Binary-Version})
Something is missing here... I suspect:
| with Depends: bacula-foo (= ${binary:Version})
... but feel free to correct me.
pgpOEGlJcgPoZ.pgp
Description: PGP signature
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:28:32PM +0100, Wouter Verhelst wrote: > On Thu, Feb 22, 2007 at 11:53:23AM -0600, Steve Greenland wrote: > > On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: > > > > I think someone deserves a serious thwacking... > > > > > > Maybe the maintainer for making non-binNMU-safe packages ? > > > > That is so much bullshit. Whoever uploaded the binNMU uploaded broken > > packages. > > That would be the buildd. You are aware that buildd-built packages > aren't usually tested before upload? Yes. I wasn't aware that buildds ever modify the changelog or do binNMUs though. Aren't buildds simply there to build the existing sources on other platforms? Surely some human was involved here? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 11:53:23AM -0600, Steve Greenland <[EMAIL PROTECTED]> wrote: > On 22-Feb-07, 11:00 (CST), Sune Vuorela <[EMAIL PROTECTED]> wrote: > > > (This problem was reported in bug #411652) > > > > > > I think someone deserves a serious thwacking... > > > > Maybe the maintainer for making non-binNMU-safe packages ? > > That is so much bullshit. Whoever uploaded the binNMU uploaded broken > packages. No excuses. End of story. > > Now, it may be that the bacula package could be improved to generate > better results for a binNMU. The proper way to do that is to submit > bugs, preferably with patches, so that the bacula maintainer can fix > the source packages. Broken uploads are Not The Right Thing. Aren't binNMUs autobuilded ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 12:32:58PM -0600, John Goerzen wrote: > Yes. I wasn't aware that buildds ever modify the changelog or do > binNMUs though. Aren't buildds simply there to build the existing > sources on other platforms? Automatic bin-NMU support was added, I believe within the last year. The release team uses it extensively. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote:
> Hello,
> A binNMU does not show up in the pts, since there are no source
> changes.
Hmm, I wonder if it would be possible for it to show up? Since there
are .changes files with binNMUs, and presumably also migration to
testing statuses?
> > Does anybody know what is going on here?
>
> http://lists.debian.org/debian-release/2007/02/msg00647.html
That seems to explain it (I think). Though I am still confused about
why a binNMU is being used even though it is being rebuilt across all
archs.
> The bug is that a binNMU for bacula was scheduled although it is not
> binNMU-able. Usually checking is done whether the package would break
> before triggereing the rebuilt. Looks like this was missed this time.
OK, that makes sense. No worries then.
> If your next sourceful upload would fix this it would make the
> release-team's work easier. The fix is simple:
I will upload in about 1 hour.
> 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> 2. For all in bacula-foo packages that are arch:all replace any
> occurence of
> Depends: bacula-foo (= ${Source-Version})
> with Depends: bacula-foo (= ${source:Version})
> 3. (optional, but clarify things) For all in bacula-foo packages that
> are arch:any replace any
> occurence of
> Depends: bacula-foo (= ${Binary-Version})
>
> Untested (For testing just set the version number to 1.38.11-7+b1 in
> debian/changelog and rebuild with dpkg-buildpackage -b), I'll not have
> time for a tested patch today or tomorrow but I can probably come up
> with one on the weekend if you have not had time to resolve this then.
Do I need to update the MySQL build-deps though? It sounds like I
should, from reading the message you linked to, but I'm not certain
about that.
-- John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
Frans Pop <[EMAIL PROTECTED]> wrote:
> On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
[...]
>> 3. (optional, but clarify things) For all in bacula-foo packages that
>> are arch:any replace any occurence of
>> Depends: bacula-foo (= ${Binary-Version})
> Something is missing here... I suspect:
> | with Depends: bacula-foo (= ${binary:Version})
> ... but feel free to correct me.
Indeed, thank you.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:31:46PM +0100, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
> > 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> > 2. For all in bacula-foo packages that are arch:all replace any
> > occurence of
> > Depends: bacula-foo (= ${Source-Version})
> > with Depends: bacula-foo (= ${source:Version})
> > 3. (optional, but clarify things) For all in bacula-foo packages that
> > are arch:any replace any occurence of
> > Depends: bacula-foo (= ${Binary-Version})
>
> Something is missing here... I suspect:
> | with Depends: bacula-foo (= ${binary:Version})
That would be
bacula-foo (>= ${source:Version}), bacula-foo (<< ${source:Version}.1~)
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
* John Goerzen: > sid seems to contain bacula 1.38.11-7+b1, a binary-only NMU for i386, > which breaks bacula-console and various other packages due to broken > deps. The changelog file is signed only "buildd_i386-saens". > packages.qa.debian.org doesn't know about 1.38.11-7+b1. Here's the build log: http://buildd.debian.org/fetch.cgi?&pkg=bacula&ver=1.38.11-7%2Bb1&arch=i386&stamp=1171847294&file=log All official autobuilders are supposed to post their logs to buildd.debian.org, AFAIK. The problem seems to be that Architecture: all packages weren't rebuilt. They refer to exact package versions in their dependencies, which cannot be fulfilled by the binNMUed packages. > I think someone deserves a serious thwacking... they obviously didn't > even try to install the result of the NMU, filed no bug about it, etc. Binary-only NMUs are a necessary evil. The implementation kind of sucks, but I'm not sure how a better approach would look like. It's not just the dependencies problem, it's also quite confusing that you've got a source package which builds different binary package versions on different architectures (but their are other ways to achieve that). For instance, this pretty much rules out precise tracking based on binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote: >> binNMUs are done without the bug-report. (It would be rather >> pointless, since the maintainer himself cannot schedule binNMUs on >> Debian's buildds.) > This sounds inaccurate. binNMUs should still be in response to bugs wherever > applicable, but they should close them unversioned since the BTS tracks > source versions. My point was rather that binNMUs need to be handled differently than normal ones since there is a) no patch to apply and b the maintainer has nothing to fix. Especially the normal "I did a NMU with the atttached patch" bug reports are useless. Tracking binNMUs in the BTS is not useful, the BTS is mainly for reaching the maintainer, having bug-reports like this does not work: * Dear maintainer, this package needs a binNMU for the libbar translation. We'll schedule one. Please do nothing. or * We just triggered a rebuild of package bar. No patch was applied. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
John Goerzen <[EMAIL PROTECTED]> wrote: > On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote: [...] >> If your next sourceful upload would fix this it would make the >> release-team's work easier. The fix is simple: > I will upload in about 1 hour. Lovely. [...] > Do I need to update the MySQL build-deps though? It sounds like I > should, from reading the message you linked to, but I'm not certain > about that. I cannot hurt. But OTOH the release team thought /this/ issue required no source changes to fix, i.e. the buildds shouldn't be using the faulty mysql versions anymore. ;-) cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:31:46PM +0100, Frans Pop wrote:
> On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
> > 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> > 2. For all in bacula-foo packages that are arch:all replace any
> > occurence of
> > Depends: bacula-foo (= ${Source-Version})
> > with Depends: bacula-foo (= ${source:Version})
> > 3. (optional, but clarify things) For all in bacula-foo packages that
> > are arch:any replace any occurence of
> > Depends: bacula-foo (= ${Binary-Version})
>
> Something is missing here... I suspect:
> | with Depends: bacula-foo (= ${binary:Version})
>
> ... but feel free to correct me.
I think I am understanding what is going on here, but I think it is
incomplete.
There are these situations in bacula:
1) Arch all deps on arch all with the same version
2) Arch any deps on arch all with the same version
3) Arch all deps on arch any with the same version
I think that the above handle cases 1 and 2, but not case 3. Actually I
don't think it's possible to make case 3 binNMU-safe, or am I missing
something?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 22, 2007 at 07:31:46PM +0100, Frans Pop <[EMAIL PROTECTED]> wrote:
>> On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
>> > 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
>> > 2. For all in bacula-foo packages that are arch:all replace any
>> > occurence of
>> > Depends: bacula-foo (= ${Source-Version})
>> > with Depends: bacula-foo (= ${source:Version})
>> > 3. (optional, but clarify things) For all in bacula-foo packages that
>> > are arch:any replace any occurence of
>> > Depends: bacula-foo (= ${Binary-Version})
>> Something is missing here... I suspect:
>> | with Depends: bacula-foo (= ${binary:Version})
> That would be
> bacula-foo (>= ${source:Version}), bacula-foo (<< ${source:Version}.1~)
I do not get that, what is the benefit compared to (= ${binary:Version})
besides being impossible to read?
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: found and fixed some more
Processing commands for [EMAIL PROTECTED]: > # found these ones earlier and all have been fixed already, > # forgot to add them to this bug. Just for the record. > block 322762 with 406370 Bug#322762: /usr/doc still exists (transition tracking bug) Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 322837 322838 322839 328297 338060 338227 338238 351740 352893 352894 353569 355341 359358 359359 359361 359362 359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 359399 359400 359401 359403 359405 359406 359407 359408 359409 359410 359411 359412 359413 359414 359417 359418 359419 359420 359421 359422 359423 359424 359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 359559 359560 359561 359562 359563 359564 359566 359567 359568 359569 359570 359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 359581 359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 359592 359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 359603 359604 359605 359606 359607 359608 359609 359610 359611 359612 378646 378647 378648 378649 378650 Blocking bugs of 322762 added: 406370 > block 322762 with 406985 Bug#322762: /usr/doc still exists (transition tracking bug) Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 322837 322838 322839 328297 338060 338227 338238 351740 352893 352894 353569 355341 359358 359359 359361 359362 359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 359399 359400 359401 359403 359405 359406 359407 359408 359409 359410 359411 359412 359413 359414 359417 359418 359419 359420 359421 359422 359423 359424 359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 359559 359560 359561 359562 359563 359564 359566 359567 359568 359569 359570 359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 359581 359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 359592 359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 359603 359604 359605 359606 359607 359608 359609 359610 359611 359612 378646 378647 3786
I *love* goodbye-microsoft.com
... so I thought I'd take the liberty of registering "goodbye-apple.com" and "goodbye-osx.com" in order to protect the namespace. I'll gladly transfer them over to the first DD to code up something similar for that platform(s). :-) Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412009: ITP: bitbake -- build system used for embedded Linux distributions
Package: wnpp Severity: wishlist Owner: Jan Luebbe <[EMAIL PROTECTED]> * Package name: bitbake Version : 1.6.6 Upstream Author : the bitbake project * URL : http://developer.berlios.de/projects/bitbake/ * License : GPL, MIT/X Programming Lang: Python Description : build system used for embedded Linux distributions BitBake is a simple tool for the execution of tasks. It is derived from Portage, which is the package management system used by the Gentoo Linux distribution. It is most commonly used to build packages, as it can easily use its rudimentary inheritence to abstract common operations, such as fetching sources, unpacking them, patching them, compiling them, and so on. It is the basis of the OpenEmbedded project, which is being used for OpenZaurus, Familiar and a number of other Linux distributions. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-polaris Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 07:57:07PM +0100, Andreas Metzler <[EMAIL PROTECTED]>
wrote:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 22, 2007 at 07:31:46PM +0100, Frans Pop <[EMAIL PROTECTED]>
> > wrote:
> >> On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
> >> > 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> >> > 2. For all in bacula-foo packages that are arch:all replace any
> >> > occurence of
> >> > Depends: bacula-foo (= ${Source-Version})
> >> > with Depends: bacula-foo (= ${source:Version})
> >> > 3. (optional, but clarify things) For all in bacula-foo packages that
> >> > are arch:any replace any occurence of
> >> > Depends: bacula-foo (= ${Binary-Version})
>
> >> Something is missing here... I suspect:
> >> | with Depends: bacula-foo (= ${binary:Version})
>
> > That would be
> > bacula-foo (>= ${source:Version}), bacula-foo (<< ${source:Version}.1~)
>
> I do not get that, what is the benefit compared to (= ${binary:Version})
arch: all packages are *not* rebuilt, so their dependency won't ever get
updated, which means the dependency will be stuck to the original
${binary:Version}, which is... ${source:Version}.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 12:57:52PM -0600, John Goerzen <[EMAIL PROTECTED]>
wrote:
> On Thu, Feb 22, 2007 at 07:31:46PM +0100, Frans Pop wrote:
> > On Thursday 22 February 2007 19:26, Andreas Metzler wrote:
> > > 1. Add a Build-dependency on dpkg-dev (>=1.13.19)
> > > 2. For all in bacula-foo packages that are arch:all replace any
> > > occurence of
> > > Depends: bacula-foo (= ${Source-Version})
> > > with Depends: bacula-foo (= ${source:Version})
> > > 3. (optional, but clarify things) For all in bacula-foo packages that
> > > are arch:any replace any occurence of
> > > Depends: bacula-foo (= ${Binary-Version})
> >
> > Something is missing here... I suspect:
> > | with Depends: bacula-foo (= ${binary:Version})
> >
> > ... but feel free to correct me.
>
> I think I am understanding what is going on here, but I think it is
> incomplete.
>
> There are these situations in bacula:
>
> 1) Arch all deps on arch all with the same version
> 2) Arch any deps on arch all with the same version
> 3) Arch all deps on arch any with the same version
>
> I think that the above handle cases 1 and 2, but not case 3. Actually I
> don't think it's possible to make case 3 binNMU-safe, or am I missing
> something?
Case 3 is handled by the dependency rul I gave in another subthread.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
announcing edos.debian.net
Hello, I am happy to announce the availability of daily runs of edos-debcheck. The results can be accessed here: http://edos.debian.net/edos-debcheck/ A first version was set up during the QA meeting in Extremadura, but I came only recently around to implement some missing features. Fabio Mancinelli from the EDOS project had helped with the first version. * edos-debcheck: This tool checks installability of packages inside a given distribution. That is, it checks whether there exists a subset of the distribution containing a given package, and such hat all dependencies and conflicts of the subset are satisfied. An important point is that "deep" dependency and conflict chains are tested correctly. For instance, if you have A depends on B1, B2 B1 depends on C1 B2 depends on C2 C1 depends on E1 C2 depends on E2 E1 conflicts with E2 then A would be recognized as not installable. Disjunctive dependencies are handeled correctly, also in conjunction with "deep" dependencies and conlicts. This tool is also available in debian in the package of the same name. * The results shown on the web page: For each distribution in the configuration, for each of its architectures, and for a given date two numbers are given : "n (m)", where - n is the number of non-installable packages - m is the number of non-installable packages having their architecture set to some specific architecture (that is, different from "all"). Clicking on the numbers gives a detailed list, with explanations why the packages are not installable. In these lists, packages with architecture=all are indicated on grey background. There are summary columns showing packages that are not installable in some or in every achitecture of a distribution, and diffs between successive runs. * The special case of architecture=all: The reason why architecture=all packages are singled out is that there usually is a good technical excuse why they are not installable. For example, one might have packages Package A Architectures: a, b, c Package A-common Architecture: all Depends: A In this case A-common is not installable on architectures different from a, b, c, but it wouldn't make much sense to specify this in the architecture field of A-common. * Addition of more distros/architectures: If you want more distros or architectures added to this service please drop me a note. * Thanks a lot: to the ftbfs.de team, in particular to Martin Zobel-Helas, for hosting us and for their help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 12:32:58PM -0600, John Goerzen wrote: > On Thu, Feb 22, 2007 at 07:28:32PM +0100, Wouter Verhelst wrote: > > On Thu, Feb 22, 2007 at 11:53:23AM -0600, Steve Greenland wrote: > > > That is so much bullshit. Whoever uploaded the binNMU uploaded broken > > > packages. > > > > That would be the buildd. You are aware that buildd-built packages > > aren't usually tested before upload? > > Yes. I wasn't aware that buildds ever modify the changelog or do > binNMUs though. Aren't buildds simply there to build the existing > sources on other platforms? Surely some human was involved here? wanna-build and buildd have been modified a while back to be able to do binNMU's. The only human involvement is when a given package is marked in the database as 'requires a binNMU', and when the buildd admin later signs the package, as usual. If the package then fails to install, that is indeed a problem; but not something our current processes can handle before the fact. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
Steinar H. Gunderson wrote: > On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote: >> binNMUs are done without the bug-report. (It would be rather >> pointless, since the maintainer himself cannot schedule binNMUs on >> Debian's buildds.) > > This sounds inaccurate. binNMUs should still be in response to bugs wherever > applicable, but they should close them unversioned since the BTS tracks > source versions. Though there won't be any bugs *filed* if only binNMUs are needed to fix it as they should be closed manually anyway... A package not being binNMUable is also a bug that should be fixed ofcourse... and which is RC after being binNMUed ;-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Where did Bacula 1.38.11-7+b1 come from?
On Fri, Feb 23, 2007 at 12:13:07AM +0100, Wouter Verhelst wrote: > > binNMUs though. Aren't buildds simply there to build the existing > > sources on other platforms? Surely some human was involved here? > > wanna-build and buildd have been modified a while back to be able to do > binNMU's. The only human involvement is when a given package is marked > in the database as 'requires a binNMU', and when the buildd admin later > signs the package, as usual. Would it be possible to record the name of the human that marked the package in debian/changelog? That would be a big help, I think (and hopefully avoid a discussion on debian-devel next time it happens) Probably requiring more work, but I wonder if it would be possible for the buildd -- or perhaps katie -- to verify that binNMUs don't render previously-installable packages uninstallable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, 2007-02-22 at 19:51:17 +0100, Florian Weimer wrote: > Binary-only NMUs are a necessary evil. The implementation kind of > sucks, but I'm not sure how a better approach would look like. It's > not just the dependencies problem, it's also quite confusing that > you've got a source package which builds different binary package > versions on different architectures (but their are other ways to > achieve that). For instance, this pretty much rules out precise > tracking based on binary packages. The resulting .changes will get a field like this: Source: bacula (1.38.11-7) which can be used to track back from which source this binary originated. Or are you referring to something different? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Feb 23, 2007
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 358 (new: 17) Total number of packages offered up for adoption: 83 (new: 1) Total number of packages requested help for: 42 (new: 4) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: camas (#411674), orphaned 2 days ago Description: A versatile WebMail system for the Caudium WebServer Installations reported by Popcon: 2 caudium (#411675), orphaned 2 days ago Description: An extensible WWW server written in Pike Reverse Depends: camas caudium caudium-modules caudium-pixsl caudium-ultralog libroxen-123session libroxen-adbanner libroxen-asis libroxen-calculator libroxen-calendar (68 more omitted) Installations reported by Popcon: 41 dbengine (#411819), orphaned 2 days ago Description: A plug 'n play Web interface for mySQL and PostgreSQL Installations reported by Popcon: 46 emms (#411422), orphaned 4 days ago Description: The Emacs MultiMedia Syste Installations reported by Popcon: 71 linux-igd (#411875), orphaned yesterday Description: Linux UPnP Internet Gateway Device Installations reported by Popcon: 48 nettle (#411677), orphaned 2 days ago Description: low level cryptographic library Reverse Depends: chiark-utils-bin libnettle-dev nettle-bin pike7.6-core Installations reported by Popcon: 184 pexts (#411678), orphaned 2 days ago Description: Pike modules Installations reported by Popcon: 6 pike-public.network.pcap (#411679), orphaned 2 days ago Description: Pike interface module for the pcap library Reverse Depends: pike-public.network.pcap Installations reported by Popcon: 6 pike-public.parser.xml2 (#411680), orphaned 2 days ago Description: libxml2-based XML parser module for Pike Reverse Depends: pike-public.parser.xml2 Installations reported by Popcon: 7 pike-public.protocols.syslog (#411682), orphaned 2 days ago Description: Pike module implementing the Syslog protocol Reverse Depends: pike-public.protocols.syslog Installations reported by Popcon: 4 pike-public.tools.configfiles (#411683), orphaned 2 days ago Description: Pike module for accessing ini-style configurations Reverse Depends: pike-public.tools.configfiles Installations reported by Popcon: 5 pike7.6 (#411684), orphaned 2 days ago Description: Recommended meta package for Pike 7.6 Reverse Depends: caudium caudium-dev caudium-perl libroxen-floatingcode libroxen-form libroxen-randomfile libroxen-xmlrpc-common libroxen-xmlutils pike7.6 pike7.6-bzip2 (28 more omitted) Installations reported by Popcon: 138 pike7.7 (#411685), orphaned 2 days ago Description: Recommended meta package for Pike 7.7 Installations reported by Popcon: 3 pmk (#411686), orphaned 2 days ago Description: utility to configure software sources Installations reported by Popcon: 11 prolog-el (#411424), orphaned 4 days ago Description: Emacs major mode for editing Prolog code Installations reported by Popcon: 104 s48-refman (#411423), orphaned 4 days ago Description: An unofficial reference manual for Scheme48 Installations reported by Popcon: 18 scheme48 (#411425), orphaned 4 days ago Description: A simple, modular, and lightweight Scheme implementation Reverse Depends: cmuscheme48-el Installations reported by Popcon: 64 341 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: devscripts (#411591), offered 3 days ago Description: Scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build darcs-buildpackage debian-builder debnest devscripts-el equivs git-buildpackage jablicator svn-buildpackage thinkpad-source (1 more omitted) Installations reported by Popcon: 5604 82 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] rt2400 (#411791), requested 2 days ago Description: RT2400 wireless network drivers Installations reported by Popcon: 74 [NEW] rt2500 (#411788), requested 2 days ago Description: RT2500 wireless network drivers Installations reported by Popcon: 334 [NEW] rt2570 (#411790), requested 2 days ago Description: RT2570 wireless network
