[Jeff Licquia]
I will be ready.
Good.
Just so we're all on the same page, this is my understanding of the
needed discover 2 package renames:
discover2-udeb - discover-udeb
discover2-data-udeb - discover-data-udeb
Correct.
Unless I hear otherwise, I will upload discover 2 packages
On Mon, Mar 22, 2004 at 02:48:21AM -0500, David Nusinow wrote:
I've attached a patch to the d-i build system that'll
have to be applied when both uploads are made to unstable.
Now that Petter has uploaded the new disover version, this patch needs
to be applied. Since the svn archive no longer
Petter Reinholdtsen wrote:
I've uploaded discover1 and discover1-data to unstable. Everything
should be ready for you. :)
It's there. If I've screwed anything up, let me know.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
David Nusinow wrote:
Now that Petter has uploaded the new disover version, this patch needs
to be applied. Since the svn archive no longer allows anonymous access,
there's no way I can check to see that he did it, and I can no longer
raise him on IRC. Would someone please apply it? Thank you
I had a look at making hw-detect apt-install the proper discover deb
matching whatever version of discover is on the initrd. Not hard to
write the code, but it's hard for the code to do the right thing until
the new discover packages have entered testing. If hw-detect
apt-installs discover1 right
On Tue, Mar 23, 2004 at 08:07:43PM -0500, Joey Hess wrote:
I'll do this.
Awesome, thank you.
Don't you have an alioth account?
I do (dnusinow-guest) but I haven't been added to the access list for
debian-installer though.
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
On Tue, Mar 23, 2004 at 08:22:04PM -0500, Joey Hess wrote:
Can someone keep an eye on the discover package's progress to testing,
and remind us that we need to update hw-detect to install discover1 just
before it hits testing?
I'll keep an eye on it.
- David Nusinow
--
To UNSUBSCRIBE,
David Nusinow wrote:
I do (dnusinow-guest) but I haven't been added to the access list for
debian-installer though.
Well that was a silly oversight on my part. ;-)
--
see shy jo
signature.asc
Description: Digital signature
[David Nusinow]
Ok, everything looks good to me on the discover1 front. I haven't looked
at what's going on with discover2, but I'm sure you guys have it well in
hand.
I hope Jeff do the last minute changes (renaming the udeb), and
prepare an upload, yes.
Petter suggested a Tuesday upload
Petter Reinholdtsen wrote:
The discover1 packages in experimental are ready to into unstable.
The discover2 packages need to rename the udebs from discover2 to
discover. This should not trigger the NEW queue, as the old discover
packages used those names.
Jeff, can you verify that you are ready
On Tue, Mar 16, 2004 at 04:18:26PM +0100, Petter Reinholdtsen wrote:
[Ian Murdock]
That's correct. We can upload Discover 2 whenever you are ready to
do the transition. I actually don't have an up to date key in the
keyring, so Jeff Licquia will be uploading Discover 2 for us for
now.
[Petter Reinholdtsen]n
These are the package names including changes, if I got it right:
I got a minor issue wrong.
source discover2-data - discover-data (changed, new name exited)
binary discover-data (new source)
binary discover-data-udeb
Petter Reinholdtsen wrote:
So, Joey, should we rename the udebs and update the build scripts, to
avoid having inconsistent naming between the debs and the udebs?
Sure, I don't see a problem with that. Note that hw-detect will need an
update too.
--
see shy jo
signature.asc
Description:
On Sat, Mar 20, 2004 at 11:46:29PM +0100, Petter Reinholdtsen wrote:
type old name new namedelta
-
binary discover-udeb - discover1-udeb (NEW)
binary dicsover-data-udeb
On Sat, Mar 20, 2004 at 08:47:09PM -0500, David Nusinow wrote:
On Sat, Mar 20, 2004 at 11:46:29PM +0100, Petter Reinholdtsen wrote:
type old name new namedelta
-
binary discover-udeb
[Joey Hess]
Sure, I don't see a problem with that.
OK. Then we need another upload into experimental for discover1-udeb
and discover1-data-udeb to be cleared by the FTP-masters. I do not
think we need a new upload of discover2.
Note that hw-detect will need an update too.
Yes. The code to
On Tue, Mar 16, 2004 at 08:18:26PM +0100, Marco d'Itri wrote:
On Mar 16, Jeff Licquia [EMAIL PROTECTED] wrote:
- Which XFree86 driver works with my video card?
- How do I format PostScript to talk to my printer?
- What software do I need to install for my new scanner to work?
- What
[Gaudenz Steinlin]
As I and David are going to take over the maintainership of discover
1.5 we are interested in fixing the transition plan now.
If I understood you and David correctly, you wanted to go ahead with
the transition, but did not have time to do it yourself. I'm looking
into doing
On Tue, Mar 16, 2004 at 01:07:13PM +0100, Petter Reinholdtsen wrote:
[Gaudenz Steinlin]
As I and David are going to take over the maintainership of discover
1.5 we are interested in fixing the transition plan now.
If I understood you and David correctly, you wanted to go ahead with
the
[Gaudenz Steinlin]
This is Ok with me. I will be busy with real life until 4/15. I
really hope I find more time to work on d-i and discover afterwards.
I look forward to your return. :)
IIRC Branden agreed to an NMU by the debian-boot Team of discover2
if Progeny does not upload it. Ian
On Tue, Mar 16, 2004 at 02:05:46PM +0100, Petter Reinholdtsen wrote:
[Gaudenz Steinlin]
Looking at the subversion repository, I suspect there are some patches
missing compared to the packages in the debian archive. Do you known
if this is true?
I'm not sure if Ian merged everything. You can
[Petter Reinholdtsen]
Good. I am executing it then. I'll start by updating the alioth CVS,
and ask for people to review the changes. When this is done, I'll
upload a new version and wait for the ftp-masters to do their thing.
When the new discover1 package is in the archive, it should be
On Tue, Mar 16, 2004 at 02:40:07PM +0100, Petter Reinholdtsen wrote:
The alioth CVS for discover1 is updated with my changes. Please
review. If the changes are ok, I'll upload today.
Please hold off. I may not have time today to review them. Please wait
until I've done so before uploading.
[David Nusinow]
Why the conflicts at all? If the discover2 package is providing the
discover package (=2) then it should simply replace the old discover
package. Same for discover-data. discover-data and discover versions
would matter of course, but I don't understand why this couldn't be
[David Nusinow]
Please hold off. I may not have time today to review them. Please
wait until I've done so before uploading.
I'll try. :)
There's certaintly no rush now that beta3 is out. Thanks!
There is definitely a rush now. If the discover2 packages should have
any chance of making it
[Petter Reinholdtsen]
The alioth CVS for discover1 is updated with my changes. Please
review. If the changes are ok, I'll upload today.
The packages are available from
URL:http://www.skolelinux.no/~pere/discover1/.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Tue, 2004-03-16 at 08:21, Gaudenz Steinlin wrote:
Looking at the subversion repository, I suspect there are some patches
missing compared to the packages in the debian archive. Do you known
if this is true?
I'm not sure if Ian merged everything. You can find my latest packages on
[Jeff Bailey]
I'm curious, though. The new hotplug seems to have the goal of
replacing discover. It may make sense to use that instead of
discover2 on 2.6 based systems (since it's likely that everyone will
want it anyway)
I've experienced some problems with hotplug earlier, as it is using
[Ian Murdock]
That's correct. We can upload Discover 2 whenever you are ready to
do the transition. I actually don't have an up to date key in the
keyring, so Jeff Licquia will be uploading Discover 2 for us for
now.
Sounds good. I'll leave the uploading to Jeff, assuming it happens
fairly
On Tue, 2004-03-16 at 08:05, Petter Reinholdtsen wrote:
IIRC Branden agreed to an NMU by the debian-boot Team of discover2
if Progeny does not upload it. Ian Murduck then replied that he will
upload soon, but this has not happend since then. According to him
the maintainer of discover2
[David Nusinow]
Please hold off. I may not have time today to review them. Please
wait until I've done so before uploading. There's certaintly no rush
now that beta3 is out. Thanks!
I just realized that I could upload them to experimental instead of
unstable. This will put them in the NEW
What about uploading both discover1 and the new discover (2) to
experimental today, to get it into the NEW queue and on the todo list
for the ftp-masters? This way we know the packages are cleared by the
ftp-masters when we upload the packages into unstable.
These are the package names
On Tue, Mar 16, 2004 at 03:37:50PM +0100, Petter Reinholdtsen wrote:
[Jeff Bailey]
I'm curious, though. The new hotplug seems to have the goal of
replacing discover. It may make sense to use that instead of
discover2 on 2.6 based systems (since it's likely that everyone will
want it
Petter Reinholdtsen wrote:
The point with the changes it to replace the 'discover' debs in sid
with discover version 2. The udebs stay the same, so debian-installer
should not be affected by the move.
Except of course that it will need to be modified to apt-install an
appropriate version of
[Joey Hess]
Except of course that it will need to be modified to apt-install an
appropriate version of discover..
Perhaps, but probably not. I think we should keep discover version 2
out of testing until it is as good as discover 1. That mean the
version of discover in sarge can be used with
On Tue, 2004-03-16 at 06:37, Petter Reinholdtsen wrote:
Of course hotplug have a huge advantage using these maps directly, as
the kernel module maintainers in effect is maintaining their HW
database. :)
Note that the next version of discover-data will have this advantage
as well: We're
Petter Reinholdtsen wrote:
Perhaps, but probably not. I think we should keep discover version 2
out of testing until it is as good as discover 1. That mean the
version of discover in sarge can be used with d-i, right?
Hmm, this will make it harder to install unstable with d-i though.
--
[Marco d'Itri]
Petter, this is not a problem but a feature.
Oh. I didn't realise. Thanks for clearing that up.
Actually I consider discover broken by design because it needs a
proprietary database which must be updated for each driver added to
the kernel and for each new device supported
On Tue, Mar 16, 2004 at 03:37:50PM +0100, Petter Reinholdtsen wrote:
[Jeff Bailey]
I'm curious, though. The new hotplug seems to have the goal of
replacing discover. It may make sense to use that instead of
discover2 on 2.6 based systems (since it's likely that everyone will
want
[Joey Hess]
Hmm, this will make it harder to install unstable with d-i though.
Why?
'discover' in unstable will be discover version 2, and it work about
the same as discover version 1.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Tue, Mar 16, 2004 at 06:59:01PM +0100, Marco d'Itri wrote:
I've experienced some problems with hotplug earlier, as it is
using the info in /lib/modules/version/modules.*map directly.
If more than one module claim to support a given PCI id, it seem
to pick any one of them. The
On Mar 16, Petter Reinholdtsen [EMAIL PROTECTED] wrote:
Actually I consider discover broken by design because it needs a
proprietary database which must be updated for each driver added to
the kernel and for each new device supported by each driver.
What do you mean by proprietary database
[Marco d'Itri]
Belonging, or pertaining, to a proprietor (Webster)
I meant something that is specific to a single program, feel free to
choose a more suitable word.
Right. Here it is mostly used as another word for non-free, and I did
not see how the discover database was non-free.
BTW, I'd
On Mar 16, Jeff Bailey [EMAIL PROTECTED] wrote:
How difficult is this blacklisting to do? Is filing bugs against the
hotplug package sufficient?
Yes, the name of the module has to be added to /etc/hotplug/blacklist.
Please provide a detailed explanation of why the blacklisting is needed
in the
Marco d'Itri wrote:
Petter, this is not a problem but a feature. Actually I consider
discover broken by design because it needs a proprietary database which
must be updated for each driver added to the kernel and for each new
device supported by each driver.
I'm finding it a little difficult to
On Mar 16, Jeff Licquia [EMAIL PROTECTED] wrote:
- Which XFree86 driver works with my video card?
- How do I format PostScript to talk to my printer?
- What software do I need to install for my new scanner to work?
- What package contains the special tweak utilities for my laptop?
-
On Tue, Mar 16, 2004 at 08:18:26PM +0100, Marco d'Itri wrote:
I'm not saying that there is no use for discover, but that hotplug is
more suitable to manage loading of kernel drivers (i.e. just about
everything which appears in /sys/).
By looking at this, can we assume that it's uncontested
On Mar 16, Jeff Bailey [EMAIL PROTECTED] wrote:
I'm not saying that there is no use for discover, but that hotplug is
more suitable to manage loading of kernel drivers (i.e. just about
everything which appears in /sys/).
By looking at this, can we assume that it's uncontested that discover
Petter Reinholdtsen wrote:
Perhaps, but probably not. I think we should keep discover version 2
out of testing until it is as good as discover 1. That mean the
version of discover in sarge can be used with d-i, right?
If unstable has packages named discover2 and discover1, and testing has
[Joey Hess]
If unstable has packages named discover2 and discover1, and testing
has only a package named discover, you will be unable to upate the
discover package in testing.
Both testing and unstable will have a package named discover. In
testing, it will be version 1, and in unstable it
Petter Reinholdtsen wrote:
[Joey Hess]
If unstable has packages named discover2 and discover1, and testing
has only a package named discover, you will be unable to upate the
discover package in testing.
Both testing and unstable will have a package named discover. In
testing, it will
[please keep cc'ing debian-boot, discover-workers and David Nusinow]
Hi
I see 3 different ways how the transition from discover 1 to discover 2
in Debian could be handled. All of them need coordination between
progeny (probably the maintainer of the new discover 2 packages) and
debian-boot
On Thu, Dec 18, 2003 at 06:18:28PM +0100, Gaudenz Steinlin wrote:
[please keep cc'ing debian-boot, discover-workers and David Nusinow]
No need to cc me, I'm subscribed to -boot, thanks :-)
1. Alternative:
This is basically branden's proposal, see this mail[1] for more details
a) rename
53 matches
Mail list logo
