Bug#698030: debian-policy: document micro binary packages (udebs).

[Charles Plessy]

Package: debian-policy
Severity: wishlist

Le Sat, Jan 12, 2013 at 06:27:37PM -0800, Russ Allbery a écrit :
> 
> We already talk about udeb in various places (shlibs, for instance).  This
> isn't a new problem.

Hi Russ and everybody,

actually the only section of the Policy that currently contains the string
'udeb' is 8.6.4.2 about the shlibs system (plus some occurences in introductory
parts earlier in the chapter 8).  No bug in our list mention "udeb" either.

I therefore am filing this new bug so that the discussion (started in
697433#67) can be recorded in a separate place.  However, as noted by Russ it
is a larger effort, and I have no plan to start to work on it in the short
term.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


--
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/20130113051322.ga3...@falafel.plessy.net

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Guillem Jover]

On Sat, 2013-01-12 at 15:29:13 +0900, Charles Plessy wrote:
> here is a new version trying to addres Simon's and Guillem's comments.

> @@ -2671,6 +2671,7 @@ Package: libc6
> Description 
> (mandatory)
> Homepage
> Built-Using
> +id="f-Package-Type">Package-Type
>   
> 
>  
> @@ -2751,6 +2752,7 @@ Package: libc6
>   Vcs-Browser, 
> Vcs-Git, et al.id="f-Standards-Version">Standards-Version (recommend
>   Build-Depends et 
> al
> + Package-List 
> (recommended)
>   Checksums-Sha1
>   and Checksums-Sha256 (mandatory)
>   Files (mandatory)
> @@ -3801,6 +3803,34 @@ Checksums-Sha256:
> 
>   
> 
> +
> +   
> + Package-List
> +
> + 
> +   Multiline field listing all the packages that can be built from
> +   the source package, considering every architecture.  The first 
> line
> +   of the field value is empty.  Each one of the next lines describes
> +   one binary package, by listing its name, type, section and 
> priority
> +   separated by spaces.  Fifth and subsequent space-separated items
> +   may be present and parsers must allow them.  See the
> +   Package-Type field for a list of
> +   package types.
> + 
> +   
> +
> +   
> + Package-Type
> +
> + 
> +   Simple field containing a word indicating the type of package:
> +   deb for binary packages and udeb for micro 
> binary
> +   packages.  Other types not defined here may be indicated.  In
> +   source package control files, the Package-Type field
> +   should be omitted instead of giving it a value of deb, as
> +   this value is assumed for paragraphs lacking this field.
> + 
> +   
>

Seconded.

Thanks,
Guillem


signature.asc
Description: Digital signature

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Jonathan Nieder]

Russ Allbery wrote:

> In response to the other follow-up, I don't think this is the right place
> (or bug) to discuss udeb package behavior or what portions of Policy they
> comply with.

Surely it is relevant to people reading policy that it does not comply with
them all (or in other words that they are out of policy scope), no?
Advertising udeb as a valid package-type for policy-compliant packages
gives the opposite impression.

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:

>> In response to the other follow-up, I don't think this is the right
>> place (or bug) to discuss udeb package behavior or what portions of
>> Policy they comply with.

> Surely it is relevant to people reading policy that it does not comply
> with them all (or in other words that they are out of policy scope), no?

Sure.  But it's not directly relevant to the problem we're trying to
solve.  Or, put another way, it's broader than just this section.  I want
to be sure we don't get sidetracked into that larger effort while
addressing missing documentation for standard fields.

> Advertising udeb as a valid package-type for policy-compliant packages
> gives the opposite impression.

We already talk about udeb in various places (shlibs, for instance).  This
isn't a new problem.

I don't see an open bug about udebs in general off-hand.  If I'm not
missing something, it certainly seems reasonable to open one.

-- 
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/876231x1eu@windlord.stanford.edu

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Russ Allbery]

Charles Plessy  writes:

> here is a new version trying to addres Simon's and Guillem's comments.

Seconded.

In response to the other follow-up, I don't think this is the right place
(or bug) to discuss udeb package behavior or what portions of Policy they
comply with.

-- 
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/87vcb1x2he@windlord.stanford.edu

Bug#698020: ITP: python-xdo -- python library for simulating X11 keyboard/mouse input (libxdo bindings)

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: python-xdo
  Version : 0.1
  Upstream Author : Daniel Kahn Gillmor 
* URL : git://lair.fifthhorseman.net/~dkg/python-xdo
* License : BSD
  Programming Lang: C, Python
  Description : python library for simulating X11 keyboard/mouse input 
(libxdo bindings)

 python's xdo module lets you programmatically simulate keyboard input
 and mouse activity, move and resize windows, etc.  It does this using
 libxdo, which uses X11's XTEST extension and other Xlib functions.


-- 
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/20130112231415.584.87883.report...@alice.fifthhorseman.net

Bug#698015: ITP: python-pbkdf2 -- Python RSA PKCS#5 v2.0 module

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: python-pbkdf2
  Version : 1.3
  Upstream Author : Dwayne C. Litzenberger 
* URL : https://www.dlitz.net/software/python-pbkdf2/
* License : Expat
  Programming Lang: Python
  Description : Python RSA PKCS#5 v2.0 module

 This module implements the password-based key derivation
 function, PBKDF2, specified in RSA PKCS#5 v2.0.
 .
 PKCS#5 v2.0 Password-Based Key Derivation is a key derivation
 function which is part of the RSA Public Key Cryptography
 Standards series. The provided implementation takes a password
 or a passphrase and a salt value (and optionally a iteration
 count, a digest module, and a MAC module) and provides a file-like
 object from which an arbitrarly-sized key can be read.


-- 
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/20130112211937.9442.54861.reportbug@Aspire-1410

Bug#698013: ITP: ITP:rasterbator-ng -- Create rasterized versions of images

[Steven Anderson]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: ITP:rasterbator-ng
Version: 0.1
Upstream Author: [Tobias Jakobs http://code.google.com/p/rasterbator-ng/]
License: [GPL]
Description: [Create rasterized versions of images]


-- 
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/1358022101.24582.0.ca...@twoface.mooncitylabs.org

Re: [cut-team] Time to merge back ubuntu improvements!

[Svante Signell]

On Sat, 2013-01-12 at 17:14 +, Adam D. Barratt wrote:
> On 12.01.2013 16:11, Svante Signell wrote:
> > Or to say it differently:
> > experimental being really for new stuff
> > unstable unfrozen always:
> > - stable+1 if no freeze
> > - stable+2 if in freeze
> > - and stable+1=unstable at the freeze time.
> 
> This is similar to what used to happen before the testing suite existed 
> - unstable was copied to "frozen" and that was beaten in to shape until 
> it was suitable for release. "testing" was designed and implemented by 
> the Release Manager of the time to try and avoid the issues created by 
> that situation.
> 
> Please do some research on why things exist before suggesting getting 
> rid of them, particularly in favour of thing they replaced. (The 
> debian-devel post explaining the introduction of testing really isn't 
> that difficult to find.)

Of course there was a reason for introducing testing. And I did not
propose it to go away either. It should stay for packages marked as
being part of unstable at freeze time. Probably a separate repo for
frozen unstable is needed.





-- 
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/1358013304.4363.136.ca...@amd64.my.own.domain

Re: [cut-team] Time to merge back ubuntu improvements!

[Adam D. Barratt]

On 12.01.2013 16:11, Svante Signell wrote:

Or to say it differently:
experimental being really for new stuff
unstable unfrozen always:
- stable+1 if no freeze
- stable+2 if in freeze
- and stable+1=unstable at the freeze time.


This is similar to what used to happen before the testing suite existed 
- unstable was copied to "frozen" and that was beaten in to shape until 
it was suitable for release. "testing" was designed and implemented by 
the Release Manager of the time to try and avoid the issues created by 
that situation.


Please do some research on why things exist before suggesting getting 
rid of them, particularly in favour of thing they replaced. (The 
debian-devel post explaining the introduction of testing really isn't 
that difficult to find.)


Regards,

Adam


--
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/ce3bc1b76c50cf1a3c8437cfb5044...@mail.adsl.funky-badger.org

Re: [cut-team] Time to merge back ubuntu improvements!

[Svante Signell]

On Sat, 2013-01-12 at 15:50 +0100, Thomas Preud'homme wrote:
> Le samedi 12 janvier 2013 15:21:24, Jonas Smedegaard a écrit :
> > 
> > I recommend instead of redefining logic of unstable, branch off new
> > suites with new logic.
> > 
> > ...and then back to that issue of "maintainers should concentrate on the
> > release" again: I do sincerely worry that additional suites _will_
> > affect how many of us developers will concentrate on getting the release
> > out.
> 
> It would also probably affect how many users would test unstable which would 
> undermine the efficiency of the transition from unstable to testing since 
> bugs 
> in unstable are more likely to not be noticed.

I don't see the problem here. Unstable stay unstable and unfrozen, or
stable+2 as Thomas Goirand wrote. The packages going into testing are
from unstable before the freeze (stable+2) and from the old unstable
(stable+1) after the freeze.

Or to say it differently:
experimental being really for new stuff
unstable unfrozen always:
- stable+1 if no freeze
- stable+2 if in freeze
- and stable+1=unstable at the freeze time.


-- 
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/1358007101.4363.123.ca...@amd64.my.own.domain

Re: [cut-team] Time to merge back ubuntu improvements!

[Thomas Goirand]

On 01/12/2013 08:59 PM, Svante Signell wrote:
> On Fri, 2013-01-11 at 16:05 +0100, Stefano Zacchiroli wrote:
>> Doesn't this diminish significantly the advantages of CUT? Back in the
>> days of the CUT discussion, one of the main "issues" associated to
>> testing is that it stops rolling during freezes.
> As unstable does! As a user of testing and unstable I think it is very
> unfortunate that packages in unstable practically stop rolling and no
> new (or bug-fixed, except RC) packages are uploaded.

Yeah! I also find it disturbing that we are supposed to upload new stuff to
Experimental. Then during the freeze, there's no distinction at all between
stuff we upload to Experimental because of the freeze, and stuff we upload
to Experimental because we don't consider them ready for Unstable.

> but I assume very many of them are idling
> until the next stable is released. Some are forced to stop by the
> freeze.

Yes. That is annoying, I agree.

> Additionally, not everybody is able to solve all kinds of RC
> bugs.
>
> Is there a way to solve this problem? For example, when the freeze
> happens, packages in unstable are marked as presumptive packages in the
> new stable release. Then these packages are branched off to something
> that could be called pre-testing or whatever, and sid goes on as before
> the freeze.

Or we make it so that stable+2 (currently Jessie) exists right after the
freeze. SID would then be the staging area for packages and library
transitions for the unfrozen stable+2 (currently Jessie), during the freeze,
instead of stable+1 (currently Wheezy) when not frozen. We would upload
to t-p-u if we need updates to stable+1 (currently Wheezy).

I'm not proposing this change to happen (now or later), just barely listing
what would be possible to solve the problem. I'm not even sure that's the
path we should take, and that depends a lot on the view of both the
release team and the ftp team, and the security team, whom might just
object the lack of manpower to actually implement these changes (and yet
even manage transitions in stable+2 during the freeze of stable+1).
Because if we take that path, it means that during the freeze, we'd have 1
more flavor of Debian to take care of (eg: stable, stable+1, stable+2 and
SID).

If there was a choice to make (which isn't even the case), I'd personally
prefer having a longer support for the old-stable distribution.

On 01/12/2013 10:21 PM, Jonas Smedegaard wrote:
>
> ...and then back to that issue of "maintainers should concentrate on the 
> release" again: I do sincerely worry that additional suites _will_ 
> affect how many of us developers will concentrate on getting the release 
> out.

Me as well. But how can we know in advance what effect it will have?

Cheers,

Thomas


-- 
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/50f17970.5060...@debian.org

Re: [cut-team] Time to merge back ubuntu improvements!

[Thomas Preud'homme]

Le samedi 12 janvier 2013 15:21:24, Jonas Smedegaard a écrit :
> 
> I recommend instead of redefining logic of unstable, branch off new
> suites with new logic.
> 
> ...and then back to that issue of "maintainers should concentrate on the
> release" again: I do sincerely worry that additional suites _will_
> affect how many of us developers will concentrate on getting the release
> out.

It would also probably affect how many users would test unstable which would 
undermine the efficiency of the transition from unstable to testing since bugs 
in unstable are more likely to not be noticed.

Thomas


signature.asc
Description: This is a digitally signed message part.

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Guillem Jover]

On Sat, 2013-01-12 at 09:07:19 +, Neil Williams wrote:
> On Sat, 12 Jan 2013 15:29:13 +0900
> Charles Plessy  wrote:
> > By the way, isn't "Package-Type: udeb" completely redundant with "Section:
> > debian-installer" ?
> 
> Different purposes.

Right. Where using Section in general should be considered fragile, we
switched away from it for base for a reason too.

> udeb is a file format, allowed to break ftp-master checks which would
> reject a deb from the same upload. Section, if it's anything at all
> nowadays, is an arbitrary label within the generated Packages file. The
> Package-Type field determines that file format when dpkg-deb builds the
> file, so is far more important than Section.

Unfortunately that's not true, as Package-Type does not get exported
to the binary package control file. See #452273 and #575059 for a
longish and painful discussion of the issue. I guess dak uses some
kind of heuristic to catalogue them.

> If anything is redundant, it's Section - and not just when it is set
> to debian-installer, every where. (If we finally decide to drop
> Section, can we also merge Priority: extra and Priority: optional too?
> That would be saying goodbye to a raft of override bugs / checks).

Now that you mention this, it makes me think that switching from Section
to Package-Type, in addition to all other advantages I listed on those
bug reports, would actually reduce space at the same time (7 bytes).

  Section: debian-installer
  Package-Type: udeb

But then, I don't think I've got the motivation to try to properly
integrate udeb support in dpkg proper again, given the previous
experience...

Thanks,
Guillem


-- 
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/20130112142143.ga2...@gaara.hadrons.org

Re: [cut-team] Time to merge back ubuntu improvements!

[Jonas Smedegaard]

Quoting Svante Signell (2013-01-12 13:59:02)
> On Fri, 2013-01-11 at 16:05 +0100, Stefano Zacchiroli wrote:
> > [ dropping -www, setting Mail-Followup-To: cut-team ]
> > 
> > On Thu, Jan 10, 2013 at 04:06:00PM -0500, Michael Gilbert wrote:
> > > On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote:
> > > > On 01/05/2013 01:28 AM, alberto fuentes wrote:
> > > >> The few people on the list seems happy with it. If this is 
> > > >> working well, it needs a little more love on debian.org and a 
> > > >> 'testing-cut' link in the repos pointing to latest cut, so it 
> > > >> can be set on sources.list and forgotten
> > > >
> > > > Yes, we need to advertize more about CUT. CC-ing 
> > > > debian-www@lists.d.o in the hope the www team can link to CUT 
> > > > install instructions from our home page.
> > > 
> > > I probably should have already sent a message a while ago on this, 
> > > but yes the monthly snapshots have been put on hiatus during the 
> > > freeze. The official d-i betas and release candidates are 
> > > recommended now so that they get sufficient testing and feedback 
> > > before the release.
> > 
> > Doesn't this diminish significantly the advantages of CUT? Back in 
> > the days of the CUT discussion, one of the main "issues" associated 
> > to testing is that it stops rolling during freezes.
> 
> As unstable does! As a user of testing and unstable I think it is very 
> unfortunate that packages in unstable practically stop rolling and no 
> new (or bug-fixed, except RC) packages are uploaded. Only backported 
> packages fixing the RC bugs in unstable are updated to get them into 
> testing (and eventually stable). Of course the maintainers should 
> concentrate on the release, but I assume very many of them are idling 
> until the next stable is released. Some are forced to stop by the 
> freeze. Additionally, not everybody is able to solve all kinds of RC 
> bugs.
> 
> Is there a way to solve this problem? For example, when the freeze 
> happens, packages in unstable are marked as presumptive packages in 
> the new stable release. Then these packages are branched off to 
> something that could be called pre-testing or whatever, and sid goes 
> on as before the freeze.
> 
> Unfortunately experimental does not solve this issue, I think it could 
> remain as a staging area for packages that can break things if they 
> were uploaded to unstable directly.

Ignoring that issue of "maintainers should concentrate on the release" 
for a moment, the purpose of "unstable" really is "packages considered 
stable enough to potentially be part of next stable release", and 
"testing" is "packages proven stable enough interacting with each other 
for at least 10 days".

Reason unstable slows down suring freeze is that otherwise above logic 
would change during freeze: There would not be the normal transition 
period of 10 days only among packages all of them targeted next stable 
release, followed by a staging area of only packages that have all had 
that initial 10 days.

I recommend instead of redefining logic of unstable, branch off new 
suites with new logic.

...and then back to that issue of "maintainers should concentrate on the 
release" again: I do sincerely worry that additional suites _will_ 
affect how many of us developers will concentrate on getting the release 
out.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: [cut-team] Time to merge back ubuntu improvements!

[Svante Signell]

On Fri, 2013-01-11 at 16:05 +0100, Stefano Zacchiroli wrote:
> [ dropping -www, setting Mail-Followup-To: cut-team ]
> 
> On Thu, Jan 10, 2013 at 04:06:00PM -0500, Michael Gilbert wrote:
> > On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote:
> > > On 01/05/2013 01:28 AM, alberto fuentes wrote:
> > >> The few people on the list seems happy with it. If this is working
> > >> well, it needs a little more love on debian.org and a  'testing-cut'
> > >> link in the repos pointing to latest cut, so it can be set on
> > >> sources.list and forgotten
> > >
> > > Yes, we need to advertize more about CUT. CC-ing debian-www@lists.d.o
> > > in the hope the www team can link to CUT install instructions from
> > > our home page.
> > 
> > I probably should have already sent a message a while ago on this, but
> > yes the monthly snapshots have been put on hiatus during the freeze.
> > The official d-i betas and release candidates are recommended now so
> > that they get sufficient testing and feedback before the release.
> 
> Doesn't this diminish significantly the advantages of CUT? Back in the
> days of the CUT discussion, one of the main "issues" associated to
> testing is that it stops rolling during freezes.

As unstable does! As a user of testing and unstable I think it is very
unfortunate that packages in unstable practically stop rolling and no
new (or bug-fixed, except RC) packages are uploaded. Only backported
packages fixing the RC bugs in unstable are updated to get them into
testing (and eventually stable). Of course the maintainers should
concentrate on the release, but I assume very many of them are idling
until the next stable is released. Some are forced to stop by the
freeze. Additionally, not everybody is able to solve all kinds of RC
bugs.

Is there a way to solve this problem? For example, when the freeze
happens, packages in unstable are marked as presumptive packages in the
new stable release. Then these packages are branched off to something
that could be called pre-testing or whatever, and sid goes on as before
the freeze. 

Unfortunately experimental does not solve this issue, I think it could
remain as a staging area for packages that can break things if they were
uploaded to unstable directly.

Just my 5c.


-- 
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/1357995542.4363.103.ca...@amd64.my.own.domain

Re: Packages with Depends, Recommends and Suggests on fuse-utils (in unstable)

[Salvatore Bonaccorso]

Hi Julien

On Sat, Jan 12, 2013 at 01:15:26PM +0100, Julien Cristau wrote:
> On Sat, Jan 12, 2013 at 11:39:45 +0100, Salvatore Bonaccorso wrote:
> 
> > Hi
> > 
> > As per dev-ref 7.1.1 about mass-bugfilling I'm writing first to
> > debian-devel.
> > 
> > In unstable fuse-utils transitional package was dropped, and this now
> > makes some packages uninstallable. Some Depends, Recommends or
> > Suggests still fuse-utils. Wheezy is not affected as it still contains
> > the fuse-utils transitional package.
> > 
> > I would fill the bugreports for packages with Depends and Recommends
> > on fuse-utils with severity serious. The one with Suggests to
> > fuse-utils with severity important.
> > 
> Nah, just file one serious bug against src:fuse for failing to build
> fuse-utils.

Yes this was also suggested by Ansgar, to let the src:fuse package
reintroduce the fuse-utils transitional package.

Thanks for the comment!

Regards,
Salvatore


--
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/20130112122212.GB9311@elende

Re: Packages with Depends, Recommends and Suggests on fuse-utils (in unstable)

[Salvatore Bonaccorso]

Hi

Cc'in explicitly Daniel Baumann (maintaner of fuse package)

On Sat, Jan 12, 2013 at 11:39:45AM +0100, Salvatore Bonaccorso wrote:
> As per dev-ref 7.1.1 about mass-bugfilling I'm writing first to
> debian-devel.
> 
> In unstable fuse-utils transitional package was dropped, and this now
> makes some packages uninstallable. Some Depends, Recommends or
> Suggests still fuse-utils. Wheezy is not affected as it still contains
> the fuse-utils transitional package.
> 
> I would fill the bugreports for packages with Depends and Recommends
> on fuse-utils with severity serious. The one with Suggests to
> fuse-utils with severity important.

Ansgar suggested on #debian-release to reintroduce the fuse-utils
transitional package in unstable until after the wheezy release. This
would be better in the the regard only one package needs an instant
fix (src:fuse).

Regards,
Salvatore


-- 
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/20130112122036.GA9311@elende

Re: Packages with Depends, Recommends and Suggests on fuse-utils (in unstable)

[Julien Cristau]

On Sat, Jan 12, 2013 at 11:39:45 +0100, Salvatore Bonaccorso wrote:

> Hi
> 
> As per dev-ref 7.1.1 about mass-bugfilling I'm writing first to
> debian-devel.
> 
> In unstable fuse-utils transitional package was dropped, and this now
> makes some packages uninstallable. Some Depends, Recommends or
> Suggests still fuse-utils. Wheezy is not affected as it still contains
> the fuse-utils transitional package.
> 
> I would fill the bugreports for packages with Depends and Recommends
> on fuse-utils with severity serious. The one with Suggests to
> fuse-utils with severity important.
> 
Nah, just file one serious bug against src:fuse for failing to build
fuse-utils.

Cheers,
Julien


signature.asc
Description: Digital signature

Packages with Depends, Recommends and Suggests on fuse-utils (in unstable)

[Salvatore Bonaccorso]

Hi

As per dev-ref 7.1.1 about mass-bugfilling I'm writing first to
debian-devel.

In unstable fuse-utils transitional package was dropped, and this now
makes some packages uninstallable. Some Depends, Recommends or
Suggests still fuse-utils. Wheezy is not affected as it still contains
the fuse-utils transitional package.

I would fill the bugreports for packages with Depends and Recommends
on fuse-utils with severity serious. The one with Suggests to
fuse-utils with severity important.

Attached is the dd-list for all three lists.

Regards,
Salvatore
Bernd Schubert 
   unionfs-fuse

Chris Lamb 
   mtpfs

Dario Minnucci 
   djmount

Debian LTSP Maintainers 
   ltspfs

Debian VSquare Team 
   fuse-umfuse-ext2
   fuse-umfuse-fat
   fuse-umfuse-iso9660

Dmitry E. Oboukhov 
   mhddfs

Filippo Giunchedi 
   fuse-umfuse-ext2 (U)
   fuse-umfuse-fat (U)
   fuse-umfuse-iso9660 (U)

Guido Trotter 
   fuse-umfuse-ext2 (U)
   fuse-umfuse-fat (U)
   fuse-umfuse-iso9660 (U)

Hendrik Sattler 
   obexfs

Julien Lavergne 
   ifuse

Louis Zuckerman 
   glusterfs (U)

Ludovico Gardenghi 
   fuse-umfuse-fat (U)

Ludovico Gardenghi 
   fuse-umfuse-ext2 (U)
   fuse-umfuse-iso9660 (U)

Matthias Albert 
   glusterfs (U)

Nick Andrik 
   acetoneiso

Patrick Matthäi 
   glusterfs

Sebastien Delafond 
   wikipediafs

Vagrant Cascadian 
   ltspfs (U)

Laszlo Boszormenyi (GCS) 
   ceph

Mario Izquierdo (mariodebian) 
   tcos

Michal Suchanek 
   httpfs2

NIIBE Yutaka 
   gfarm2fs

Osamu Tatebe 
   gfarm2fs (U)

Sage Weil 
   ceph (U)

Vincent Danjean 
   owfs

Bastian Kleineidam 
   libpam-mount

Re: Packages with incomplete .md5sum files

[Wouter Verhelst]

On Thu, Jan 10, 2013 at 02:13:46PM -0500, Michael Gilbert wrote:
> On Thu, Jan 10, 2013 at 3:21 AM, Andreas Beckmann wrote:
> > Excluding shipped files from .md5sums looks seriously wrong for files
> > in /usr and at least questionable in /var/lib.
> 
> What is so "serious" about that?

In itself it may not be a huge problem, but it's usually a good
indicator of another, more serious, bug.

> Please no more rc mbf's.

Would you rather we shipped packages that we know are broken, but that
we don't want to fix because we want "no more rc mbf's"?

I question that logic.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
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/20130112103157.gi25...@grep.be

Re: Bug#697433: Is the Package-List field necessary for uploads ?

[Neil Williams]

On Sat, 12 Jan 2013 15:29:13 +0900
Charles Plessy  wrote:

> here is a new version trying to addres Simon's and Guillem's comments.
> 
> By the way, isn't "Package-Type: udeb" completely redundant with "Section:
> debian-installer" ?

Different purposes.

udeb is a file format, allowed to break ftp-master checks which would
reject a deb from the same upload. Section, if it's anything at all
nowadays, is an arbitrary label within the generated Packages file. The
Package-Type field determines that file format when dpkg-deb builds the
file, so is far more important than Section.

If anything is redundant, it's Section - and not just when it is set
to debian-installer, every where. (If we finally decide to drop
Section, can we also merge Priority: extra and Priority: optional too?
That would be saying goodbye to a raft of override bugs / checks).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgplbOEqBDxwQ.pgp
Description: PGP signature