Re: Distribution and support for Debian-502-i386-netinst

[Ian Campbell]

On Sat, 2011-12-03 at 19:35 +, Philipp Kern wrote:
> On 2011-12-03, Marc Haber  wrote:
> > On Fri, 2 Dec 2011 18:58:55 + (UTC), Philipp Kern
> > wrote:
> >>On 2011-12-02, Marc Haber  wrote:
> >>> I also support this and think it is a really good idea. But please
> >>> keep x.y.z-1 around and easily accessible when x.y.z is released.
> >>You can jigdo any old CD image.
> > How do I do this for a past point release, such as, 6.0.1, for
> > example?
> 
> You use jigdo?  Try it, it works.

In my experience jigdo does not work for a CD release of a previous
point release because some of the packages referenced by the jigdo are
removed from the mirrors i.e. those which have been updated.

These are not official Debian images but check out the comments on
http://community.citrix.com/display/xs/Debian+Lenny for lots of reports
of things not being available any more -- this happens every time there
is a point release.

Ian.

-- 
Ian Campbell


Having no talent is no longer enough.
-- Gore Vidal


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1323002315.7376.68.ca...@dagon.hellion.org.uk

New sections

[Joerg Jaspert]

Hi

following the 3 bugs I close with this mail I just created new sections
in our 3 archives. That is,

introspection, which is for "GObject introspection data" (or whatever
   other subsystem is doing something similar to it in the
   future)

education, which is for education related tools that don't fit better
   into any other section

metapackages, which is for metapackages so that apt can do special
  handling on them.


For the introspection I also did move packages matching "gir1\.2-.*"
over, as specified in the bug (visible with next dinstall). education
and metapackages are left empty, maintainers who want to move their
packages over are free to follow the usual procedures of it, though you
can just give us regex patterns if you want to move more than one
package at once.

-- 
bye, Joerg
[And yes, sections should die, lalala, bla, imagine the usual blubb
 coming up on that already done, so skip it :) ]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iplw8px9@lennier.ganneff.de

Re: Distribution and support for Debian-502-i386-netinst

[George Danchev]

On Sun, 04 Dec 2011 12:38:35 +, Ian Campbell  
wrote:

On Sat, 2011-12-03 at 19:35 +, Philipp Kern wrote:

On 2011-12-03, Marc Haber  wrote:
> On Fri, 2 Dec 2011 18:58:55 + (UTC), Philipp Kern
> wrote:
>>On 2011-12-02, Marc Haber  wrote:
>>> I also support this and think it is a really good idea. But 
please
>>> keep x.y.z-1 around and easily accessible when x.y.z is 
released.

>>You can jigdo any old CD image.
> How do I do this for a past point release, such as, 6.0.1, for
> example?

You use jigdo?  Try it, it works.


In my experience jigdo does not work for a CD release of a previous
point release because some of the packages referenced by the jigdo 
are

removed from the mirrors i.e. those which have been updated.


Actually jigdo has a mechanism to fallback to a certain server for 
packages

it can not download from the given mirror. That is:
zcat debian-502-i386-netinst.jigdo
...
[Servers]
Debian=http://us.cdimage.debian.org/cdimage/snapshot/Debian/ --try-last

apparently this 'try-last' repo does not store historical packages long 
enough
for any reason. In that case the unfinished image can still be mounted 
loopback
and re-used, but this time the snapshot.debian.org mirror could be 
given as a mirror

to finally finish the image.

$ zgrep -i generated debian-502-i386-netinst.jigdo
Info='Generated on Mon, 29 Jun 2009 13:07:10 +0200'

Then you navigate the required dated URL at:
http://snapshot.debian.org/archive/debian/

which is the case of debian-502 should be something like:
http://snapshot.debian.org/archive/debian/20090629T101044Z/

(yes, this is not very convenient)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/eff01ea8209d4fa42ff6f988e1a09...@spnet.net

Re: Donation

[VieuxGeek DuSystem]

Thats note a spam she want give a donation.
 Le 3 déc. 2011 22:04, "Andreas Moog"  a écrit :

> On 12/03/2011 09:52 PM, Daniel Martí wrote:
> > Scam in french, asking for money. Is there any way to avoid spam in this
> > list?
>
> For starters, by not including a fullquote of the SPAM. Then by
> following http://www.debian.org/MailingLists/index.html#ads
>
> Cheers, Andreas
>
>

Re: Bug#650975: r8168: does not belong in a stable release

[Patrick Matthäi]

Am 04.12.2011 19:41, schrieb Julien Cristau:
> Source: r8168
> Severity: serious
> 
> (x-debbugs-cc to pmatthaei and debian-release)
> 
> Hi,

Hey, thanks for submitting!

> 
> I've been blocking this package from entering testing, but as Patrick
> Matthäi questions that choice I'm filing this bug for the record.
> 
> It is my opinion, as a member of the release team, that we shouldn't
> ship this package in stable.
> 
> This driver duplicates functionality available in the r8169 module in
> the standard linux kernel, which is going to create a support burden,

From my point of view, there are this pros and cons for the driver:

Pros:
- It is free
- It is a working driver (mainline r8169 also covers those NICs, but it
is not working for years with specific NICs)
- Our users with such a crippled NIC could install this *alternative*
driver from our archive

Cons:
- Overlapping PCIIDs with r8169
- People simple switch to r8168 without reporting bugs (decreased
bugfixing on r8169)


Sure r8169 should be fixed in upstream, so that there is only one driver
and everyone is happy, but when it is fixed? Tomorrow or 2015? Who
knows. If someone has got a patch I would be happy to test it :)

For the time where it isn't fixed we (IMHO) should ship the driver with
our release(s) until r8169 is fixed or r8168 is in mainline (who knows..)

> the ITP was NAKed by the kernel maintainers, and apparently you agreed
> in <4ebfcf49.5070...@abeckmann.de> to not let this enter wheezy.

I just want to note:
It is my personal motivation that we should release it (but there is
much time until the next release, so the situation could change), not
the motivation of Andreas Beckmann, I am doing it on my own.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Re: FTBFS bugs against binary packages

[Goswin von Brederlow]

Wolodja Wentland  writes:

> Hello,
>
> we are seeing an increasing number of users in #debian-next asking about FTBFS
> bugs that are reported by apt-listbugs during upgrades. Most of those users
> are not familiar with acronyms such as FTBFS or if these bugs apply to their
> setup.
>
> The underlying problem seems to be that a subset of FTBFS bugs are reported
> against binary and not source packages, which is something we might want to
> address. I think it is better to make sure that FTBFS bugs are reported
> against source packages rather than "fixing" apt-listbugs, but I am not
> entirely sure what the best approach is.
>
> It is certainly important to spread the word, but implementing such
> consistency checks in reportbug/mass-bugs/... might make sense.

I think reportbug should make it simpler to select the source package
when reporting bugs or include FTBFS as option in one of its menues
(severity or tags?) and automatically use the source package then.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehwkovzx.fsf@frosties.localnet

New sections and frontend behaviour [Was: Re: New sections]

[Goswin von Brederlow]

Joerg Jaspert  writes:

> metapackages, which is for metapackages so that apt can do special
>   handling on them.

On IRC Joerg mentioned that transitional packages could/should also go
to the metapackages section.

The reasoning being that both metapackages and transitional packages
should have their dependencies marked as non-automatic so they don't get
removed when the top package is removed.

I think mixing the two types of packages would be a mistake as one wants
quite a different behaviour from them:

metapackages: keep them installed
transitional: remove after upgrade once nothing depends on it

So maybe there should be a "transitional" section to keep the two types
of packages apart. If there are seconds to this please someone open a
bug about it.



Personally I'm also not quite sure about the validity of marking all
dependencies of metapackages non-automatic. As mentioned in the
bugreport what happens if I want to remove gnome and install something
else? Then I have to manually remove all the dependencies of gnome.

I think dependencies of metapackages should be left as automatic but
frontends should ask wether to turn them all to non-automatic when the
meta package is selected for removal. So at removal time one would get
the choice of keeping all/some or removing them all. This could also
only ask if the metapackage was non-automatic.

Transitional packages on the other hand should just be removed with
their dependencies set to the same state the transitional package was in
(automatic -> leave them alone, non-automatic -> set them
non-automatic).

MfG
Goswin

PS: shouldn't frontends use the Tag: role::metapackage, special::meta?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ty5ghs3h.fsf@frosties.localnet

Re: New sections

[Russ Allbery]

Joerg Jaspert  writes:

> metapackages, which is for metapackages so that apt can do special
>   handling on them.

Should this section also get transitional packages, or should those stay
in oldlibs?  I'm guessing the latter, but they're technically also
metapackages.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uskhs18@windlord.stanford.edu