Re: Missing licenses in upstream source files

[Ben Hutchings]

On Wed, 2009-03-18 at 14:20 +0100, Dominik Smatana wrote:
> Hello,
> 
> there are missing licenses in some source files in upstream project
> I'm packaging for Debian.
> 
> There is just license in the "main" source file.
> 
> Is it fine?
> 
> Or should I edit these files and add missing licenses (copy & paste
> from "main" file)?

If you think the licencing of those files is not clear then you should
ask the copyright holder or upstream maintainer to make it clear rather
than making your own guess.

Ben.



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

Re: group nvram

[Sam Hartman]

I'd like to chime in with the general concern that the proposal to
remove a bunch of groups from udev seems under-baked and that the
current groups have value.

I definitely would like to see the tss (tpm) group remain along with
the kvm and fuse groups.  I think scanner is important as well.

I can understand the argument for getting rid of nvram.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Grid tasks

[Noah Meyerhans]

On Mon, Mar 16, 2009 at 02:28:08PM +0100, Steffen Moeller wrote:
> > Would there be support for creating a grid task, and splitting it this way?
> > 
> > Currently the packages are in the new queue. Should I wait until they
> > actually reach unstable before creating the task? Are there any other
> > obvious candidate packages?
> 
> I don't think that there is such a thing like "the Grid". We should wait a 
> bit longer to
> see how the world evolves around the concepts associated with grids (X.509 
> certificates,
> virtual organisations, ...). To me, mere computations are what may initially 
> drive us, but
> there should be more to come.

I'm not sure about that.  There's a whole lot of inertia behind things
like the Open Science Grid (http://www.opensciencegrid.org/).  My site,
with a Debian-based Condor cluster, is considering joining it right now.
If we can make it easier for people to build clusters that can easily be
added to such a grid, we should.

Additionally, I'd argue that "The Grid" could pretty easily refer to a
site-local grid.  A workstation joined to a local cluster doesn't really
need to care about whether it's part of something larger or not.

noah
(who should probably go sign up for debian-science at this point...)



signature.asc
Description: Digital signature

Re: User and groups justification (was Re: group nvram)

[Bastien ROUCARIES]

On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello  wrote:
> Hi there!
>
> On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
>> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
>>  wrote:
>>> BTW instead of arguing about group and something like this could we
>>> create a wiki page on debian wiki about justification of group.
>>> Therefore purpose of every system group will documented. With exemple
>>> of security concern.
>>
>> Done under http://wiki.debian.org/SystemGroups Please contribute
>
> Do you know that a similar document is already installed on any Debian
> system (provided by the base-passwd package)?

I forget :S

>  /usr/share/doc/base-passwd/user-and-groups.html
>  /usr/share/doc/base-passwd/user-and-groups.txt.gz
>
> I would prefer any new information to be added there instead, since the
> files above are available offline as well.

Does not forbid to add to wiki in order to ease writing :) I agree we
should sync the offline file.

> Thx, bye,
> Gismo / Luca
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Marco d'Itri]

On Mar 18, Bastien ROUCARIES  wrote:

> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
No, I want to give access to the raw scanner device only to its own
driver-daemon.
I do not know if SCSI scanners already work this way or not.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

User and groups justification (was Re: group nvram)

[Luca Capello]

Hi there!

On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
>  wrote:
>> BTW instead of arguing about group and something like this could we
>> create a wiki page on debian wiki about justification of group.
>> Therefore purpose of every system group will documented. With exemple
>> of security concern.
>
> Done under http://wiki.debian.org/SystemGroups Please contribute

Do you know that a similar document is already installed on any Debian
system (provided by the base-passwd package)?

  /usr/share/doc/base-passwd/user-and-groups.html
  /usr/share/doc/base-passwd/user-and-groups.txt.gz

I would prefer any new information to be added there instead, since the
files above are available offline as well.

Thx, bye,
Gismo / Luca


pgpfvqJnViYXv.pgp
Description: PGP signature

Re: group nvram

[Julien BLACHE]

Bernd Zeimetz  wrote:

Hi,

>> Yes, SCSI scanners still exist, and they're still used through
>> /dev/sgX. Actually, all high-volume, high-speed scanners are
>> SCSI. Some have a USB interface too, but it's slower.
>
> I also know some fancy damn expensive scanners with firewire, but I doubt
> they're supported in sane - unfortunately.

True. There's not been a lot of interest for the FireWire
scanners. Though I do believe those scanners actually do SCSI over
FireWire, but never checked that out. That'd be the most sensible
thing to do. That can be verified pretty easily, if the scanner uses
SCSI commands (or encapsulation) on its USB interface, you can bet the
FireWire interface just does SCSI.

I wish I had time to try that out when I had access to an A3 Epson
scanner with USB & FireWire.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Raphael Hertzog]

On Wed, 18 Mar 2009, Matthias Klose wrote:
> > I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> > describe parent relationship, and create a new tool to query those
> > meta-information) but I wonder what impact you expect it would have
> > on the decision of exporting DEB_VENDOR in the build environment.
> > 
> > Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> > so that no external tool is required ?
> > 
> > ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> > # Ubuntu or derivative
> > endif
> 
> what about a command is_derivative  which could be used instead?
> This wouldn't hard-code any specific vendor names.

I don't see your point. In the example above $(DEB_VENDORS) is created by
dpkg-buildpackage (so not hardcoded) and Ubuntu is the parameter of the
"is_derivative_of()" logical function.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

Matthias Klose  writes:
> Manoj Srivastava schrieb:

>>  A) Provide a way to specify project wide defaults for env variables
>>  B) Allow a site admin to selectively override these, and provide site
>> wide defaults
>>  C) Allow a package to set some flags that would otherwise break the
>> package, overriding site and/or project defaults as needed
>>  D) Allow the user to specify and override any of the above.

> E) Provide a way to specify project wide defaults and override any of
> the above.  This is much needed to for rebuild checks ignoring package
> specific work arounds. Currently workarounds tend to live forever, and
> there is no way to automatically override those.

Wouldn't the user override work for you in this case?  If you're doing
archive-wide test builds overriding any package settings, that seems to me
to be exactly the same case as a user overriding all package settings to
force a particular set of build flags and you could do this with the same
mechanism.

-- 
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

Re: group nvram

[Bernd Zeimetz]

Julien BLACHE wrote:
> m...@linux.it (Marco d'Itri) wrote:
> 
> Hi,
> 
>> This is the complete list of groups which I'd rather stop using:
> 
>> scanner (do SCSI scanners still exist? how are they used?)
> 
> Yes, SCSI scanners still exist, and they're still used through
> /dev/sgX. Actually, all high-volume, high-speed scanners are
> SCSI. Some have a USB interface too, but it's slower.

I also know some fancy damn expensive scanners with firewire, but I doubt
they're supported in sane - unfortunately.

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Matthias Klose]

Raphael Hertzog schrieb:
> On Wed, 18 Mar 2009, Loïc Minier wrote:
>>  If you implement conditional behavior in your rules, typically based on
>>  lsb_release -is output:
>>  if vendor is Ubuntu:
>> foo
>>  elif vendor is Debian:
>> bar
>>  you face a problem when you meet:
>>  else:
>>
>>  What behavior should one use here?
> 
> Debian should always be the "else" because it's the default case. It
> ensures that the lack of DEB_VENDOR results in correct package and
> also that any unknown derivatives get the Debian behaviour.
> 
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant… this explains
> your other remark:
> 
>>  Instead, I think it would be nice if we could express some inheritance
>>  concept so that you can have conditional behavior in rules based on
>>  either "this distribution and its derivatives" or "only for this exact
>>  distribution" and logical combinations such as "derivatives of Foo
>>  except derivatives of Bar".
> 
> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe parent relationship, and create a new tool to query those
> meta-information) but I wonder what impact you expect it would have
> on the decision of exporting DEB_VENDOR in the build environment.
> 
> Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> so that no external tool is required ?
> 
> ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> # Ubuntu or derivative
> endif

what about a command is_derivative  which could be used instead?
This wouldn't hard-code any specific vendor names.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
 wrote:
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
>  wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
>>> On Mar 18, Steve Langasek  wrote:
>>>
 A peek at the source says it uses /proc/acpi/ibm/light.
>>> Other people told me that they believe that nowadays all modern
>>> thinkpads use a kernel driver.
>>>
>>> This is the complete list of groups which I'd rather stop using:
>>>
>>>    fuse (I have no idea about how FUSE works)
>>
>> This group is important, fuse could lead to local dos.
>>
>>>    kvm (what are the security implications of access to /dev/kvm?)
>>
>> Idem local dos due to pinned memory
>>
>>>    nvram
>>>    rdma (infiniband devices)
>
> about this group:
> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216
>
> Having 0666 permissions would not necessarily be a bad idea, but the
> consensus among other distributions is to limit RDMA access to an
> "rdma" group so that administrators have some control over who gets
> direct hardware access (even though in theory it is safe for anyone,
> there is the possibility of untrusted users consuming network
> bandwidth at least). Also, RDMA often requires increasing the amount
> of locked memory allowed in /etc/security/limits.conf, and doing that
> by group "rdma" is convenient as well.
>
>
>>>    scanner (do SCSI scanners still exist? how are they used?)
>>
>> scanner is also used for usb device.
>>
>>>    tss (TPM devices, do select users have a need to access them?)
>>
>>
>> BTW why do you hate this group? They are here in order to give fine
>> gained privilege, that is the basis of good security.
>>
>>> The other major reason to do this is that non-standard groups which are
>>> not in /etc/groups break some systems which use LDAP.
>>
>> Add this group to standard ldap. Acces to harware should be limited by
>> policy, and group is a good policy. And a catch all group
>> coulddolocaldos is not really a good policy.
>
> BTW instead of arguing about group and something like this could we
> create a wiki page on debian wiki about justification of group.
> Therefore purpose of every system group will documented. With exemple
> of security concern.

Done under http://wiki.debian.org/SystemGroups Please contribute

> Regards
>
> Bastien
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Matthias Klose]

Manoj Srivastava schrieb:
> On Mon, Mar 16 2009, Raphael Hertzog wrote:
> 
>> On Sun, 15 Mar 2009, Bill Allombert wrote:
>>> There is no documented semantic for CFLAGS et. al. in Debian policy. While 
>>> some Makefile handle it in a certain way, this is not mandatory in
>>> any way. For example some configure scripts append options to CFLAGS while
>>> other will not change it if it is defined.
>> This is precisely what I want to change. We should provide a reasonable
>> way for the user/admin to give default flags and for the packager to
>> override/extend the default set of flags.
> 
> So here are what I think we need, based on the most common use
>  cases:
> 
>  A) Provide a way to specify project wide defaults for env variables
>  B) Allow a site admin to selectively override these, and provide site
> wide defaults
>  C) Allow a package to set some flags that would otherwise break the
> package, overriding site and/or project defaults as needed
>  D) Allow the user to specify and override any of the above.

E) Provide a way to specify project wide defaults and override any of the above.
This is much needed to for rebuild checks ignoring package specific work
arounds. Currently workarounds tend to live forever, and there is no way to
automatically override those.

> I do not see any reason to limit ourselves to one tool to set
>  the env variables, especially since it prevents the package maintainer
>  from distinguishing between the project wide defaults anduser set
>  values, and has no easy way  for a site to set site wide values. Hey, I
>  might like hardening flags the project does not  cater to when I
>  rebuild the archive on my buildd -- and the snippet approach allows for
>  it.

maybe, but for E) a package should honour these overwrite flags.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: removing unmaintained (unused?) X input drivers

[Frank Lin PIAT]

On Wed, 2009-03-18 at 21:51 +0900, Paul Wise wrote:
> On Wed, Mar 18, 2009 at 8:18 PM, Julien Cristau  wrote:
> 
> > the following X input drivers will be removed from the archive soon
> > unless someone steps up to maintain them (both upstream and in Debian).
> > If you use one of these, now is the time to make yourself known.
> 
> Should debian-user and forums.debian.net be notified about this?

In case this can help striking people's minds:

magellan-- Driver for Magellan SpaceMouse input devices.

calcomp -- Driver for Calcomp Drawing Board II & III graphics
   http://linux.die.net/man/4/calcomp

digitaledge -- Driver for DigitalEdge graphics tablets.

dmc -- Driver for DMC FIT-10 input devices.
   http://linux.die.net/man/4/dmc

elo2300 -- Driver for ELOGraphics 2300 TouchScreen

dynapro -- Driver for Dynapro input devices.
   http://linux.die.net/man/4/dynapro

jamstudio   -- Driver for JamStudio graphics tablets.
   http://linux.die.net/man/4/js_x

magictouch  -- Driver for MagicTouch input devices.
   http://linux.die.net/man/4/magictouch

palmax  -- Driver for Palmax touchscreens.
   http://linux.die.net/man/4/palmax

spaceorb-- Driver for SpaceOrb input devices.

tek4957 -- Driver for Tektronix 4957 graphics tablets.
   http://linux.die.net/man/4/tek4957

ur98-- Driver for UR98 input devices.
   http://linux.die.net/man/4/ur98

summa   -- Driver for Summa graphics tablets.

microtouch  -- Driver for MicroTouch input devices.
   http://linux.die.net/man/4/microtouch


Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
 wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
>> On Mar 18, Steve Langasek  wrote:
>>
>>> A peek at the source says it uses /proc/acpi/ibm/light.
>> Other people told me that they believe that nowadays all modern
>> thinkpads use a kernel driver.
>>
>> This is the complete list of groups which I'd rather stop using:
>>
>>    fuse (I have no idea about how FUSE works)
>
> This group is important, fuse could lead to local dos.
>
>>    kvm (what are the security implications of access to /dev/kvm?)
>
> Idem local dos due to pinned memory
>
>>    nvram
>>    rdma (infiniband devices)

about this group:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216

Having 0666 permissions would not necessarily be a bad idea, but the
consensus among other distributions is to limit RDMA access to an
"rdma" group so that administrators have some control over who gets
direct hardware access (even though in theory it is safe for anyone,
there is the possibility of untrusted users consuming network
bandwidth at least). Also, RDMA often requires increasing the amount
of locked memory allowed in /etc/security/limits.conf, and doing that
by group "rdma" is convenient as well.


>>    scanner (do SCSI scanners still exist? how are they used?)
>
> scanner is also used for usb device.
>
>>    tss (TPM devices, do select users have a need to access them?)
>
>
> BTW why do you hate this group? They are here in order to give fine
> gained privilege, that is the basis of good security.
>
>> The other major reason to do this is that non-standard groups which are
>> not in /etc/groups break some systems which use LDAP.
>
> Add this group to standard ldap. Acces to harware should be limited by
> policy, and group is a good policy. And a catch all group
> coulddolocaldos is not really a good policy.

BTW instead of arguing about group and something like this could we
create a wiki page on debian wiki about justification of group.
Therefore purpose of every system group will documented. With exemple
of security concern.

Regards

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

Raphael Hertzog  writes:

> I can understand you were not happy with the way the change was done but
> saying dpkg-bp is broken is strong (and wrong). If you really believed
> that a major mistake was done at that time, you could have complained
> louder and you could have asked for a tech-ctte ruling. We also offered
> to retract the change to the release team but they did not deem it
> necessary.

Well, I tried to bring it up at the time, but it seemed clear that you
felt strongly that it was the right way forward and there were only a few
who objected (although I suspect that's because not that many people
realized at the time all of the implications).  I suppose I could have
appealed it to the tech-ctte, but that seemed unnecessarily
confrontational given that the actual negative effect on the archive at
the moment was relatively minor.  Most of my concern was over packages
starting to rely on this behavior of dpkg-buildpackage, thus making it
difficult to use a different solution.

At the time, I didn't think of the makefile fragment idea that Manoj has
proposed.  If I had thought of that, I would have pushed that, since I
think it addresses the core goal in a much cleaner fashion.  At the time,
I had no good alternative solution.

I thought at the time about making a bigger deal about it, but I didn't
really want to just start a flamewar and it seemed like a poor way to
thank you for all of the other work that you were doing on
dpkg-buildpackage.

At the time, I think it was more important to worry about finishing the
lenny work.  I'm very glad that you've re-raised the discussion, and I
really appreciate you doing so.  Hopefully we can find a solution that
makes everyone happy for squeeze.

-- 
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

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

Manoj Srivastava  writes:

> Also, any upstream Makefile that sets CFLAGS (don't most ones
>  that use automake do that?) will also be not affected, unless even more
>  hackery is done. At this point, what dpkg does to these variables not
>  enough to justify any such effort.

Most packages that use Automake also use Autoconf, and Autoconf picks up
CFLAGS from the environment at the time configure is run, so most Automake
packages would pick up an environmental default.  However, I expect many
packages are shielded at present by use of the default Policy-recommended
explicit setting of CFLAGS.  I know nearly all of mine (that care about
CFLAGS at all) are.  The main exception are Perl modules, for which I've
mostly switched to debhelper v7 rule minimization.

When this change was originally made in dpkg-buildpackage, it broke
several packages that didn't have this shield.  I'm not sure if there was
a common way in which those packages are fixed or how many of them went
back to setting CFLAGS explicitly.

> On Wed, Mar 18 2009, Raphael Hertzog wrote:
>> While I agree that the distinction is blurred because in the rules files
>> you don't know where the env var comes from, I don't agree that it's a
>> deficiency.

> A missing feature is a deficiency. How critical a deficiency it
>  is is a matter of opinion, and we  apparently differ.

And for what it's worth, I agree with Manoj here.

-- 
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

Re: group nvram

[Henrique de Moraes Holschuh]

On Tue, 17 Mar 2009, Bernd Zeimetz wrote:
> Please do not as it will allow users which need to access Thinkpad-specific
> devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
> hole in my opinion.

Which are?  If you mean people running tpb, tpb is as far as I know,
completely obsolete on anything that can run thinkpad-acpi.

I am honestely curious about it, and I can *do* something about it easily if
there is some functionality missing from thinkpad-acpi that is commonly used
on thinkpads that will run Debian Squeeze.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Henrique de Moraes Holschuh]

On Wed, 18 Mar 2009, Marco d'Itri wrote:
> On Mar 18, Steve Langasek  wrote:
> > A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.

A driver which I happen to be the maintainer of ;-)

The driver supports every real thinkpad made in the last ten years,
including the more common numbered series models still in use (770, 600,
570).  Almost-thinkpads (like the thinkpad-sl and the i-series) are unlikely
to have a compatible nvram layout anyway, so they don't count.

I *do* know of people still using the model 240, and those cannot use the
ACPI-based driver at all.  But these people usually do NOT run Debian,
either.

However, if you remove group nvram, please don't go with kmem.  Go with
root.  While PeeCee CMOS-style NVRAM writes can soft-brick a box (you
debrick it by clearing the nvram and redoing all your BIOS config), AFAIK
kmem access lets you install rootkits or read sensitive data like encryption
keys.

By using the root group for /dev/nvram, you avoid the trap of people adding
users to the kmem group without knowing the consequences.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Julien BLACHE]

Bastien ROUCARIES  wrote:

Hi,

>>    scanner (do SCSI scanners still exist? how are they used?)
>
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?

Marco is specifically referring to the generic SCSI scanners support
in the basic udev rules. That can be migrated to libsane.

The scanner group is not going away anytime soon.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Julien BLACHE]

m...@linux.it (Marco d'Itri) wrote:

Hi,

> This is the complete list of groups which I'd rather stop using:

> scanner (do SCSI scanners still exist? how are they used?)

Yes, SCSI scanners still exist, and they're still used through
/dev/sgX. Actually, all high-volume, high-speed scanners are
SCSI. Some have a USB interface too, but it's slower.

You can pull that from udev if you wish, as support for SCSI scanners
has been added upstream to the udev rules and I can backport that to
unstable.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Bernd Zeimetz]

Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:

> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?

Ack. That's what it the group is used for at one of our customers.

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520318: RFH: wireshark

[Joost Yervante Damad]

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

The current maintainer (Frederic) is very busy, I helped out for some time, 
but can't really give this quite big package the care it needs either lately.

The package already lives in collab-maint svn, it would be great if some more 
people could help out.

Upstream is very helpful. 

This package is involved in security updates regularly so some notions of 
handling security issues and C are needed.

Thanks, 

Joost Yervante Damad



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
> On Mar 18, Steve Langasek  wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd rather stop using:
>
>    fuse (I have no idea about how FUSE works)
>    kvm (what are the security implications of access to /dev/kvm?)
>    nvram
>    rdma (infiniband devices)
>    scanner (do SCSI scanners still exist? how are they used?)

Scanner is useful, imagine I work in a company working on a secret
project. One of the computer has a scanner. Do you wnat to give
scanning right to the internship student ?

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

Hello,

On Wed, 18 Mar 2009, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more widespread usage.
> 
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable. 

It does set the dpkg-architecture related variables since 2001, so that's
not true.

> We cannot standardize on the "env variable proposal" because such proposal has
> never be made. Instead dpkg-buildpackage was broken in Lenny, and should be
> fixed ASAP. 

I can understand you were not happy with the way the change was done but
saying dpkg-bp is broken is strong (and wrong). If you really believed that
a major mistake was done at that time, you could have complained louder
and you could have asked for a tech-ctte ruling. We also offered
to retract the change to the release team but they did not deem it
necessary.

> Now we have packages that do not build correctly with
> dpkg-buildpackage, others that do not build correctly with debian/rules 
> binary,
> and all handle env var differently.  

Hence why I started this discussion, I'm not happy with the situation
either.

I also know that several maintainers object to adding a Makefile snippet
so if we ever want to have a chance to standardize something in policy, we
need to find a reasonable compromise like the one I tried to
propose in http://lists.debian.org/debian-devel/2009/03/msg00920.html

While I prefer the env var approach, I'm not opposed to the Makefile
snippet approach, but I know that others are and I really want that we
find some path out of this situation because the objectives behind all this
are desirable.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
> On Mar 18, Steve Langasek  wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd rather stop using:
>
>    fuse (I have no idea about how FUSE works)

This group is important, fuse could lead to local dos.

>    kvm (what are the security implications of access to /dev/kvm?)

Idem local dos due to pinned memory

>    nvram
>    rdma (infiniband devices)
>    scanner (do SCSI scanners still exist? how are they used?)

scanner is also used for usb device.

>    tss (TPM devices, do select users have a need to access them?)


BTW why do you hate this group? They are here in order to give fine
gained privilege, that is the basis of good security.

> The other major reason to do this is that non-standard groups which are
> not in /etc/groups break some systems which use LDAP.

Add this group to standard ldap. Acces to harware should be limited by
policy, and group is a good policy. And a catch all group
coulddolocaldos is not really a good policy.

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Luca Niccoli]

2009/3/18 Marco d'Itri :

> This is the complete list of groups which I'd rather stop using:
>
>    fuse (I have no idea about how FUSE works)

Neither do I, I see FUSE helper binary is set suid, and executable
only for fuse members, but there could be more AFAIK. It would be a
good idea not to mess it up, and wait for someone who actually knows
it...

>    kvm (what are the security implications of access to /dev/kvm?)

Locking large amounts of memory that can't be swapped out to disk.

Cheers,
Luca


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Roger Leigh]

On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more widespread usage.
> 
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable. 
> 
> We cannot standardize on the "env variable proposal" because such proposal
> has never be made. Instead dpkg-buildpackage was broken in Lenny, and should
> be fixed ASAP. Now we have packages that do not build correctly with
> dpkg-buildpackage, others that do not build correctly with debian/rules
> binary, and all handle env var differently.  

Exactly.

dpkg-buildpackage setting environment variables is broken.  Using make
to set site/distro/user-specific options makes more sense.  Not only is
it more flexible and extensible, it will also work no matter how one
builds the package since make will handle it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Marco d'Itri]

On Mar 18, Steve Langasek  wrote:

> A peek at the source says it uses /proc/acpi/ibm/light.
Other people told me that they believe that nowadays all modern
thinkpads use a kernel driver.

This is the complete list of groups which I'd rather stop using:

fuse (I have no idea about how FUSE works)
kvm (what are the security implications of access to /dev/kvm?)
nvram
rdma (infiniband devices)
scanner (do SCSI scanners still exist? how are they used?)
tss (TPM devices, do select users have a need to access them?)

The other major reason to do this is that non-standard groups which are
not in /etc/groups break some systems which use LDAP.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Clint Adams]

On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable. 
> 
> We cannot standardize on the "env variable proposal" because such proposal has
> never be made. Instead dpkg-buildpackage was broken in Lenny, and should be
> fixed ASAP. Now we have packages that do not build correctly with
> dpkg-buildpackage, others that do not build correctly with debian/rules 
> binary,
> and all handle env var differently.  

I concur.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Bill Allombert]

On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> So according to your rule that policy should standardize "common practice"
> and not mandate something completely new, the env variable proposal is in
> more widespread usage.

For ten years, the "common practice" was that dpkg-buildpackage did not set
any variable. 

We cannot standardize on the "env variable proposal" because such proposal has
never be made. Instead dpkg-buildpackage was broken in Lenny, and should be
fixed ASAP. Now we have packages that do not build correctly with
dpkg-buildpackage, others that do not build correctly with debian/rules binary,
and all handle env var differently.  

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Steve Langasek]

On Wed, Mar 18, 2009 at 05:37:49PM +0100, Bernd Zeimetz wrote:
> > But I'm not aware of any reason that users need to access /dev/nvram,
> > generally.  The only tool I know of that uses this interface is
> > hotkey-setup, which runs a daemon as root to handle polling the nvram state,
> > so the group permissions don't matter.

> What way use other programs like pidging-blinklight these days?
> I remember that /dev/nvram was needed to get a blinking keyboard light years
> ago... not sure what the current way is.

A peek at the source says it uses /proc/acpi/ibm/light.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520282: ITP: metatheme-gilouche -- Gilouche Theme created by openSUSE

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode 

* Package name: metatheme-gilouche
  Version : 11.1.2
  Upstream Author : Jakub Steiner 
* URL : http://forgeftp.novell.com/opensuse-art/
* License : GPL-2+
  Programming Lang: SVG, XML, gtkrc
  Description : Gilouche Theme created by openSUSE

Please see below for description, and the VCS information. This package
replaces industrial-icon-theme (currently in contrib). Because the version
of tango-icon-theme in sid is in main now, metatheme-gilouche can go to
main as well.

The package also contains a openSUSE start-here logo, which should maybe
removed (as it looks a bit wrong on Debian).

-- debian/control (excerpt):
Source: metatheme-gilouche
VCS-Git: git://git.debian.org/collab-maint/metatheme-gilouche.git
VCS-Browser: http://git.debian.org/?p=collab-maint/metatheme-gilouche.git

Package: gilouche-theme
Conflicts: industrial-icon-theme
Replaces: industrial-icon-theme
Depends: ${misc:Depends}, tango-icon-theme
Architecture: all
Description: Gilouche Theme created by openSUSE
 This theme is the default one used in openSUSE. This package provides the
 complete theme, consisting of icons, and Metacity and GTK+ themes.
 .
 The icon theme was previously known as openSUSE Industrial, but has been
 renamed to Gilouche as well.


-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juli...@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/


signature.asc
Description: Digital signature

Re: group nvram

[Bernd Zeimetz]

Steve Langasek wrote:
> It's certainly far *more* insecure to add users to the kmem group than to
> the nvram group.

Definitely.

> But I'm not aware of any reason that users need to access /dev/nvram,
> generally.  The only tool I know of that uses this interface is
> hotkey-setup, which runs a daemon as root to handle polling the nvram state,
> so the group permissions don't matter.

What way use other programs like pidging-blinklight these days?
I remember that /dev/nvram was needed to get a blinking keyboard light years
ago... not sure what the current way is.



-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#466550: Pristine source from upstream VCS repository

[Manoj Srivastava]

On Wed, Mar 18 2009, Steve Langasek wrote:

> On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
>> >> Given that we already have a tool that can download upstream
>> >>  sources, with or without mangling, and can be used by facilities
>> >>  outside of the unpacked Debian source package to determine if there was
>> >>  new versions and to download unmangled versions, is there any need to
>> >>  retain the get-orig-source target at all?
>
>> > I have get-orig-source targets that verify the upstream detached gpg
>> > signatures before repacking the tarballs.  Is there a way to do that with
>> > uscan?
>
>> There is no limit on what your user specified script can
>>  do. Given a version number, you can still download the hash and test
>>  it. No sweat.
>
> So I have to duplicate information (the upstream URL) between the watch file
> and the script?  Seems like it's better to just continue using
> get-orig-source then.

For the smallish subset of packages that have upstream hash, and
 do download and check it, and who do not otherwise have to specify a
 URL (I mean, the url for the tarball and the hash can not be the same,
 neh?), yup, some duplication ensues. The common case is unaffected, I
 think. 

>> >> I mean, this seldom implemented target is duplicating an existing and
>> >> widely used facility in Debian; and removing the target from the policy
>> >> will advance the laudable goal of stripping the policy of cruft.
>
>> > Well, I doubt more people are using uscan mangling than are using
>> > get-orig-source, really; so I don't think that facility is "widely used".
>
>> There are far many more watch files in packages than there are
>>  get-orig-source targets in rules files, so yes, uscan is far more
>>  widely used. As I said elsewhere in this thread, mangling is not widely
>>  enough automated to say anything one way or the other about practices
>>  followed. 
>
> It certainly is possible to say which of the two possible processes for
> mangling is more prevalent by examining the archive.
>
> $ cd /srv/lintian.debian.org/laboratory/source
> $ find . -mindepth 3 -maxdepth 3 -name rules | xargs grep -l get-orig-source 
> | wc -l
> 752
> $
>
> There are many more watch files than that, of course, but how many of them
> include non-default actions?  I'm pretty confident that it doesn't approach
> 5% of the archive, even without subjecting gluck to a script to parse all
> the watch files to check this.

How many of the get-orig-source targets follow written policy
 and get the latest upstream sources?

>> I would not be against a recommendation in policy to implement
>>  direct-from-vcs  upstream tarballs to be created vbia get-orig-source,
>>  and everyone else just use debian/watch and debian/urepack files.
>
> The (as-yet-unrealized) benefit of having this defined in policy is to
> give developers other than the maintainer a simple, standard way to
> grab the new upstream source of a package.  Doesn't "try debian/rules
> get-orig-source, and if that doesn't exist, try uscan instead" fall
> short of "simple"?

While this is subjective, I think this is simple enough,
 especially for the user base that is wanting sources not from
 the Debian archive. Most users who can't follow "Do a, if that fails,
 do B" would be satisfied with apt-get source, I would think.

Anyway, since get-orig-source is an optional target, you
 _have_to  try uscan, and if that fails, get-orig-source, and changing
 this will ijpact 95% or so of the debian/rules, and for what benefit?
 (more on this below)

> (This is basically the status quo, so it's not a tragedy if we don't
> correct it - but if we're going to amend policy here anyway, surely it
> would be good for the outcome to be a policy definition that meets
> this standard.)
>
> On Fri, Mar 13, 2009 at 10:38:35AM -0500, Manoj Srivastava wrote:
>
>> Let me make a case here for the get-the-latest work flow, but
>>  before I do so, I would like to state that the relative popularity of
>>  the work-flow ought not to be relevant when making policy: technical
>>  policy should not get in the way of even a minority work-flow without
>>  sound and compelling reasons to select one method or the other (usually
>>  this clause gets called in for integration issues).
>
> Popularity speaks to whether developers find it useful.  We shouldn't
> be codifying requirements into Policy if it doesn't actually benefit
> us to standardize on them.  But if there is a benefit from having all
> packages behave the same way - "integration issues", as you say - that
> should be weighed against incompatible minority workflows.
>
> I certainly do think that the inclusion of get-orig-source in Policy
> serves no purpose *but* to provide a consistent interface that
> developers can rely on.  So while we should try to minimize the
> disruption of maintainers' existing workflows, if this belongs in
> Policy at all (which

Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava]

On Wed, Mar 18 2009, Raphael Hertzog wrote:

> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>> 
>> Modulo debhelper, cdbs, et.al can help.
>
> Debhelper can't help. Only CDBS can (as its design is precisely based on
> included Makefiles).
>
>> And will be mostly useless. dpkg can set these variables until
>>  it is blue in the face, and it has zero effect on my packages  until I
>>  change my rules file. Or change upstream Makefiles to pay attention to
>>  the cflags set in the env. This is a major change for some of my
>>  packages, and without them the dpkg proposal does nothing.
>
> That's true for a lot of packages but not all packages. It also means that
> there is some usage of this approach in the archive (otherwise if all
> packages ignored the environment variables, there would never have been
> packages that FTBFS when this change was introduced in Lenny).

Any package that follows policy §4.9 examples to set CFLAGS
 based on DEB_BUILD_OPTIONS will be immune to CFLAGS et al set in the
 environment.

Also, any upstream Makefile that sets CFLAGS (don't most ones
 that use automake do that?) will also be not affected, unless even more
 hackery is done. At this point, what dpkg does to these variables not
 enough to justify any such effort.

> So according to your rule that policy should standardize "common
> practice" and not mandate something completely new, the env variable
> proposal is in more widespread usage.

That was not my rule, just a misunderstanding of what I
 said. The rules is that policy
  a) standardizes practices needed for integration, and no more.
  b) when it must add stuff, policy tries to add the best, and minimal,
 solution. 
 c) Often the viability of s solution is not clear until it has been put
into practice, and the kinks ironed out.

This does not mean shoddy practices will be enshrined in policy.

> (Note that I don't find this rule particularly useful and that's why I
> didn't mention it before but since you ask about points where you are
> biased I thought it could be worth telling) 

An incorrect rendering of the rule does not help, sorry.



>> Also, the dpkg proposal  blurs the distinction between the site
>>  wide policy and project defaults, as far as the user or the package
>>  maintainer is concerned. This is a deficiency.
>
> While I agree that the distinction is blurred because in the rules files
> you don't know where the env var comes from, I don't agree that it's a
> deficiency.

A missing feature is a deficiency. How critical a deficiency it
 is is a matter of opinion, and we  apparently differ.

> The rules files receives a value and should use it. It doesn't need to
> know whether it's the site-wide default or the distribution default. 
>
>> Yup. The major differences are:
>>  With the dpkg proposal:
>>  Bad:
>>  o) people must always use dpkg to build packages, or the packages come
>> out different
>
> If the policy document the fact that the rules files need some input
> variables, then it's not a big deal: if you really care about being able
> to call debian/rules directly you can always adapt your rules files
> accordingly like I suggested at the end of this mail:
> http://lists.debian.org/debian-devel/2009/03/msg00920.html


> We could even write such a Makefile that mimics more closely what
> dpkg-buildpackage does for people that care about it. But I don't
> really want to impose a Makefile snippet to everybody.


Frankly, dpkg does very little: All it does is to discard the
 policy suggestion (which I think is a bad idea) and only sets FLAGS to
   -g -O0 or -g -O2

I do not think that this is much of an assistance, if this is as
 far as dpkg goes.

Setting CPPFLAGS, COPTS, CWARNS, CFLAGS, CMACHINE (and things
 for other languages) might be better, but trivially just setting CFLAGS
 to select between -O0 and -O2 is not enough to justify mangling build
 systems to 


>>  o) The user or the package maintainer can no longer tell the difference
>> between site policy and project policy
>
> The user is intelligent, he can read the output of dpkg-buildpackage that
> tells him where the data comes from (or he can read the doc and the
> configuration file). In any case, it's comparable to having to
> read a Makefile snippet.

With the makefile snippet, the Makefile can tell the difference,
 and there is a standard method to tell what variables are set in the
 site config.

> For the package maintainer, why should he care ? The variable is
> provided in a manner where he can or can't override it, but that's all
> that matters.

Because it gives the option to override one or the other -- a
 generic default that is 

Re: [Fwd: Re: Bug#520236: Please package minicomputer for Debian]

[Martin Michlmayr]

* Michal Čihař  [2009-03-18 13:20]:
> > those as wishes, not as RFP.
> > For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
> > 
> > Can I change it? How?
> 
> At least this bug has been already fixed.

I fixed all of them as they came in.

-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Fwd: Re: Bug#520236: Please package minicomputer for Debian]

[Holger Levsen]

Hi,

On Mittwoch, 18. März 2009, Grammostola Rosea wrote:
> I reported approximately 6 bugs, which where actually RFP. I reported
> those as wishes, not as RFP.
> Can I change it? How?

see http://www.debian.org/Bugs/Developer


regards,
Holger


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

Bug#520273: RFA: apt-listbugs -- Lists critical bugs before each apt installation

[Junichi Uekawa]

Package: wnpp
Severity: normal

I'd like to look for someone who can look after apt-listbugs.
Upstream maintenance is required; knowledge of ruby or the Debian BTS
is a plus.


Package: apt-listbugs
Priority: optional
Section: admin
Installed-Size: 436
Maintainer: Junichi Uekawa 
Architecture: all
Version: 0.0.95
Depends: ruby (>= 1.8), libruby1.8 (>= 1.8.5), libdpkg-ruby1.8 (>= 0.3.2), apt, 
libzlib-ruby1.8, libgettext-ruby1.8, libxml-parser-ruby1.8, 
libhttp-access2-ruby1.8 (>= 2.0.6)
Suggests: reportbug, debianutils (>= 2.0) | www-browser | w3m
Filename: pool/main/a/apt-listbugs/apt-listbugs_0.0.95_all.deb
Size: 91424
MD5sum: e0d3f9e9c72352183c5a40debafe0f9c
SHA1: df75681c403169166854908e69bcc1846ffb58ec
SHA256: 133dc67097dfa7b3f6e325b620e48a9f1dae5a87cbc16998b7baea1c773c9fd5
Description: Lists critical bugs before each apt installation
 apt-listbugs is a tool which retrieves bug reports from the Debian Bug
 Tracking System and lists them. Especially, it is intended to be invoked
 before each upgrade/installation by apt in order to check whether the
 upgrade/installation is safe.
 .
 Many developers and users prefer the unstable version of Debian for its new
 features and packages.  apt, the usual upgrade tool, can break your system by
 installing a buggy package.
 .
 apt-listbugs lists critical bug reports from the Debian Bug Tracking System.
 Run it before apt to see if an upgrade or installation is known to be unsafe.
Tag: admin::package-management, implemented-in::ruby, interface::commandline, 
protocol::http, role::program, scope::utility, suite::debian, works-with::bugs, 
works-with::software:package




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Transition of initscripts to new order / sequence number

[Jan Wagner]

Hi there,

while thinking about how to solve #508189, where I need to change the position 
of the initscript in bootorder, I thought it would not sufficient to change 
only the call of dh_installinit in the rules file.

If an user changed the symlinks, I guess I will break his changes. How should 
we handle this? Is there any best practise and/or policy how we should deal 
with it? I think it's not usefull just to override the changes by the local 
sysadmin.

Thanks for your hints, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
--END GEEK CODE BLOCK--


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

Bug#520271: RFA: ecasound -- command-line Multi-track sound recorder

[Junichi Uekawa]

Package: wnpp
Severity: normal


There has been new upstream release of this package.  I just haven't
had the time to maintain this package properly.

Package: ecasound
Priority: extra
Section: sound
Installed-Size: 3676
Maintainer: Junichi Uekawa 
Architecture: amd64
Source: ecasound2.2
Version: 2.5.2-3
Replaces: ecasound2.2 (<< 2.3.2-1), libecasound7, libecasound7c102
Provides: ecasound, ladspa-host
Depends: libasound2 (>> 1.0.16), libaudiofile0 (>= 0.2.3-4), libc6 (>= 2.7-1), 
libflac8, libgcc1 (>= 1:4.1.1), libjack0 (>= 0.109.2), libncurses5 (>= 
5.6+20071006-3), libogg0 (>= 1.0rc3), libreadline5 (>= 5.2), libsamplerate0, 
libsndfile1, libstdc++6 (>= 4.2.1), python-ecasound2.2 (= 2.5.2-3), python
Suggests: mp3-encoder, mpg321 | mp3-decoder, vorbis-tools, swh-plugins | 
ladspa-plugin, timidity, mikmod
Filename: pool/main/e/ecasound2.2/ecasound_2.5.2-3_amd64.deb
Size: 1688376
MD5sum: 34cc75110944cefe909ed61a8854e764
SHA1: d6a3f4b715e8c055851eb7bae7f9203f6c8c0277
SHA256: dea3613f8ca2a319c09d432d6c45c47e03fade19965ee3ecebb1ffed55ec5a6d
Description: Multitrack-capable audio recorder and effect processor
 Ecasound is a software package designed for multitrack audio
 processing. It can be used for simple tasks like audio playback,
 recording and format conversions, as well as for multitrack effect
 processing, mixing, recording and signal recycling. Ecasound supports
 a wide range of audio inputs, outputs and effect algorithms.
 Effects and audio objects can be combined in various ways, and their
 parameters can be controlled by operator objects like oscillators
 and MIDI-CCs. As most functionality is located in shared libraries,
 creating alternative user-interfaces is easy. A versatile console mode
 interface is included in the package.
Tag: interface::text-mode, role::program, scope::application, sound::mixer, 
sound::player, uitoolkit::ncurses, use::editing, works-with::audio




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520269: RFA: ladspa-sdk -- sample tools for linux-audio-dev plugin architecture

[Junichi Uekawa]

Package: wnpp
Severity: normal

I'm looking for someone to pick this package up.  I think there has
been a new upstream release since the last packaged version.


Package: ladspa-sdk
Priority: optional
Section: sound
Installed-Size: 240
Maintainer: Junichi Uekawa 
Architecture: amd64
Version: 1.1-6
Provides: ladspa-host, ladspa-plugin, ladspa-sdk-dev
Depends: libc6 (>= 2.5), libgcc1 (>= 1:4.1.2), libstdc++6 (>= 4.1.2)
Conflicts: ladspa-sdk-dev
Filename: pool/main/l/ladspa-sdk/ladspa-sdk_1.1-6_amd64.deb
Size: 40980
MD5sum: 48b497b90968bd2abe50abb5e089c6d7
SHA1: 1c7c59d1ecaa92f5b66c17383a3bde6f3565f301
SHA256: 3bdd29008122d48ccef2ccab8aab387dddb93d0a394d71996f638d9f74c68c59
Description: sample tools for linux-audio-dev plugin architecture
 LADSPA is a free standard specification for audio effect plugins.
 .
 Contains sample plugins, and analyseplugin, listplugin, applyplugin
 programs, and the ladspa.h, the LADSPA specification.
 .
 Please build-depend on this package if you need ladspa.h
Tag: devel::examples, devel::library, role::devel-lib, works-with::audio




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520268: RFA: rarpd -- Reverse Address Resolution Protocol daemon

[Junichi Uekawa]

Package: wnpp
Severity: normal

I'd like someone to pick this package up. I used to use this to get
sparc machines installed via netboot. I don't do that anymore.

Package: rarpd
Priority: extra
Section: net
Installed-Size: 104
Maintainer: Junichi Uekawa 
Architecture: amd64
Version: 0.981107-7.1
Depends: libc6 (>= 2.7-1)
Suggests: update-cluster
Filename: pool/main/r/rarpd/rarpd_0.981107-7.1_amd64.deb
Size: 10616
MD5sum: 65c7b798c6ff55b53a4fb2b4cc575969
SHA1: 6971bffa677e828322f8255880b350e634ee43bf
SHA256: 050130008ee01b37824d03bc0175a0f157ee2af489b11662fbf2dda883b96a07
Description: Reverse Address Resolution Protocol daemon
 RARP is a protocol which allows individual devices on an IP network to
 get their own IP addresses from the RARP server.
 You need this daemon only if you have on your LAN machines like
 diskless Sun boxes.
 With kernels up to 2.2 you have the option of using the integrated RARP
 support instead of this daemon.
Tag: admin::configuring, interface::daemon, network::configuration, 
network::server, protocol::ip, role::program, use::configuring



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520270: RFA: ecamegapedal -- an audio effects pedal application

[Junichi Uekawa]

Package: wnpp
Severity: normal

I would like to give up maintaining this package.
Probably someone who takes up ecasound.

Package: ecamegapedal
Priority: optional
Section: sound
Installed-Size: 2032
Maintainer: Junichi Uekawa 
Architecture: amd64
Version: 0.4.4-7
Depends: libasound2 (>> 1.0.14), libaudiofile0 (>= 0.2.3-4), libc6 (>= 2.5-5), 
libflac8, libgcc1 (>= 1:4.2-20070516), libjack0 (>= 0.103.0), libogg0 (>= 
1.1.3), libqt3-mt (>= 3:3.3.7), libsamplerate0, libsndfile1, libstdc++6 (>= 
4.2-20070516)
Filename: pool/main/e/ecamegapedal/ecamegapedal_0.4.4-7_amd64.deb
Size: 791316
MD5sum: da47635aca23b69401a18480aa4ca33d
SHA1: 8fa865227cc1143398bccc5595c3360fffaf853e
SHA256: a1a63299d6417e3fa053dcb04508c3dcd8782b880e1f6044cf1d8452a32c68ab
Description: an audio effects pedal application
 Using ecasound libraries, this program provides a real-time effects
 pedal simulated in an X screen.
 .
 It can read from the audio device, and output to an audio device in
 real time, or can process wave files. It can work very flexibly.
 .
 For more complex interface, see ecawave, and qtecawave.
 For command-line addicts, this is not the way to go,
 go for ecasound.
 .
 It can apply any ladspa plugin to the audio data.
Tag: interface::x11, role::program, scope::application, uitoolkit::qt, 
use::editing, works-with::audio, x11::application




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Loïc Minier]

On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> >  if vendor is Ubuntu:
> > foo
> >  elif vendor is Debian:
> > bar
> >  you face a problem when you meet:
> >  else:
> > 
> >  What behavior should one use here?
> 
> Debian should always be the "else" because it's the default case. It
> ensures that the lack of DEB_VENDOR results in correct package and
> also that any unknown derivatives get the Debian behaviour.

 [ There are two difference things here: I agree that if no vendor is
 set, Debian should be assumed but I don't think the choice of Debian's
 behavior for unknown vendors is the right one, I think I'd personally
 prefer erroring out to raise the issue, but that's only if there's a
 sane way to handle that properly, which could be your DEB_VENDORS
 proposal. ]

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Packaging a library when upstream does not build a .so

[Adeodato Simó]

* Enrico Zini [Wed, 18 Mar 2009 11:42:58 +]:

> On Tue, Mar 17, 2009 at 03:03:22PM +, Simon Huggins wrote:

> > Is there a reason you need this now and can't wait until you've managed
> > to argue for the shared library from upstream and cajoule them into
> > producing a .so?
> > I had an upstream that wasn't very confident with soname changes and
> > went through a long process explaining that and the benefits but
> > ultimately it was worth it.

> Upstream will not be able to tackle shared libraries before an
> unpredictable amount of time, which could easily exceed one year or two.
> I am trying to help by sending him an up-to-date version of my libtool
> patch after every release, and making myself available for any other
> help that would be needed.  However, he is not evil; he has other much
> more urgent things to work on.

> In the meantime, should I:

>  - not package the library, which is however very useful, and needed by
>other software that I have written and want to package
>  - package the library only as a -dev built with -fPIC (but no one has
>endorsed that option so far)
>  - package a debian-only shared library, taking advantage of the fact
>that API and ABI are rather stable, and have been for a year.  In
>that case, I need to figure out the best way to do it.

I think you should go for #3, package a shared library with a Debian
specific SONAME.

My preference would be for libfoo.so.0d, libfoo.so.1d, ... (package
names libfoo0d, libfoo1d, ...), but it’s probably not worth your time to
investigate how to achieve that with libtool, so libfoo-0d.so.0,
libfoo-1d.so.0, etc., also sound appropriate and easily achieved with
the -release option for libtool as Roger Leigh hinted (keeping
-version-info always at 0:0:0). Package names would be libfoo-0d-0,
libfoo-1d-0, ...

HTH,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Loïc Minier]

On Wed, Mar 18, 2009, Emilio Pozuelo Monfort wrote:
> There is a good use case for this that doesn't require a conditional, which is
> passing --with-package-name=$(DEB_VENDOR) to configure for packages that have
> this option (e.g. the GStreamer stack, that right now checks
> lsb_release -si output.

 Good point; that's similar to when the "exactly this vendor" check
 makes sense

> It doesn't solve your concerns but perhaps you could do some common
> action or apply the Debian logic for anything else (which would be the
> same as not looking at DEB_VENDOR at all).

 Applying the Debian logic is not good enough for e.g. derivatives of
 Ubuntu as they want to fork the Ubuntu behavior and patches etc.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Conheça o Projeto Renda Familiar

[Lucélia Oliveira]

Quer ter independência financeira? Quer ter uma boa fonte de renda
alternativa? Está procurando emprego?
 
Conheça o Projeto Renda Familiar, um trabalho criado para promover e
restaurar o poder de compra das pessoas, através de um trabalho moderno,
dinâmico e eficaz.
 
Link do projeto: http://www.projetorendafamiliar.com.br/luceliarv
 
Estrategicamente elaborado, o Projeto Renda Familiar, tem sua força na
duplicação e captação de novos associados, ou seja, é você quem indica um
novo usuário para o projeto. Assim, você ganha por cada pessoa que se
efetivar em sua rede.
 
Teste gratuitamente por 30 dias e nos deixe mostrar tudo o que temos para
te oferecer e o que iremos fazer por você.
 
Nós te ajudaremos a construir sua rede sem que você precise fazer nada, a
não ser o cadastro g.r.á.t.i.s. é claro. 
 
Sua página será ativada imediatamente após o seu cadastro e você poderá
iniciar suas indicações e acumular creditos.
 
Acesse: http://www.projetorendafamiliar.com.br/luceliarv
 
E escolha test drive, não mensalidade.
 
Atenciosamente,


Lucélia Oliveira
Participante do Projeto Renda Familiar
Rio Verde - GO

Se você não quiser mais receber e-mails desta Lista, utilize o link
http://rendaefamilia.mkt9.com/admin/sair.php?id=1565|389|0&uid=123737971749355100

Re: DEB_VENDOR and forks

[Loïc Minier]

On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant…

 Yes, that's exactly the issue I'm raising

> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe parent relationship, and create a new tool to query those
> meta-information) but I wonder what impact you expect it would have
> on the decision of exporting DEB_VENDOR in the build environment.

 Well I just want this issue to be considered near the initial
 introduction of DEB_VENDOR.

> Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> so that no external tool is required ?
> 
> ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> # Ubuntu or derivative
> endif

 That would be a possible implementation which I wouldn't mind using;
 albeit the name of the field isn't too obvious but I don't have any
 good idea.  I think I'd be fine with either an external tool or
 environment vars, but in any case the handling of specific vendor and
 inherited vendors should be similar IMO.


 Thanks!

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Raphael Hertzog]

On Wed, 18 Mar 2009, Loïc Minier wrote:
>  If you implement conditional behavior in your rules, typically based on
>  lsb_release -is output:
>  if vendor is Ubuntu:
> foo
>  elif vendor is Debian:
> bar
>  you face a problem when you meet:
>  else:
> 
>  What behavior should one use here?

Debian should always be the "else" because it's the default case. It
ensures that the lack of DEB_VENDOR results in correct package and
also that any unknown derivatives get the Debian behaviour.

Of course an Ubuntu derivative could be surprised if they get
a Debian-variant of a package instead of an Ubuntu-variant… this explains
your other remark:

>  Instead, I think it would be nice if we could express some inheritance
>  concept so that you can have conditional behavior in rules based on
>  either "this distribution and its derivatives" or "only for this exact
>  distribution" and logical combinations such as "derivatives of Foo
>  except derivatives of Bar".

I see how we can solve it (add new fields in /etc/dpkg/origins/* to
describe parent relationship, and create a new tool to query those
meta-information) but I wonder what impact you expect it would have
on the decision of exporting DEB_VENDOR in the build environment.

Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
so that no external tool is required ?

ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
# Ubuntu or derivative
endif

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Missing licenses in upstream source files

[Dominik Smatana]

Hello,

there are missing licenses in some source files in upstream project
I'm packaging for Debian.

There is just license in the "main" source file.

Is it fine?

Or should I edit these files and add missing licenses (copy & paste
from "main" file)?

Thanks for advice.

Dominik Smatana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: removing unmaintained (unused?) X input drivers

[Paul Wise]

On Wed, Mar 18, 2009 at 8:18 PM, Julien Cristau  wrote:

> the following X input drivers will be removed from the archive soon
> unless someone steps up to maintain them (both upstream and in Debian).
> If you use one of these, now is the time to make yourself known.

Should debian-user and forums.debian.net be notified about this?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Fwd: Re: Bug#520236: Please package minicomputer for Debian]

[schoappied]

Grammostola Rosea wrote:

Hi,

I reported approximately 6 bugs, which where actually RFP. I reported 
those as wishes, not as RFP.

For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241

Can I change it? How?

\r



On Wed, Mar 18, 2009 at 11:34:37AM +0100, rosea wrote:
  

Package: minicomputer
Severity: wishlist



Whoa. Could you please read http://www.debian.org/devel/wnpp/ (look for
"RFP") before submitting any more of these? The batch of bugs you're
filing are all going into a state where they need to be fixed up by
hand, at the moment ...

  

I think it's already done:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Fwd: Re: Bug#520236: Please package minicomputer for Debian]

[Michal Čihař]

Hi

Dne Wed, 18 Mar 2009 12:40:42 +0100
Grammostola Rosea  napsal(a):

> I reported approximately 6 bugs, which where actually RFP. I reported 
> those as wishes, not as RFP.
> For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
> 
> Can I change it? How?

At least this bug has been already fixed.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

[Fwd: Re: Bug#520236: Please package minicomputer for Debian]

[Grammostola Rosea]

Hi,

I reported approximately 6 bugs, which where actually RFP. I reported 
those as wishes, not as RFP.

For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241

Can I change it? How?

\r
--- Begin Message ---
On Wed, Mar 18, 2009 at 11:34:37AM +0100, rosea wrote:
> Package: minicomputer
> Severity: wishlist

Whoa. Could you please read http://www.debian.org/devel/wnpp/ (look for
"RFP") before submitting any more of these? The batch of bugs you're
filing are all going into a state where they need to be fixed up by
hand, at the moment ...

-- 
Colin Watson   [cjwat...@debian.org]

--- End Message ---

Re: A hack to alleviate transitions in Britney; now what?

[Adeodato Simó]

* Adeodato Simó [Tue, 17 Mar 2009 18:25:10 +0100]:

> * Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]:

> > > Removing GNOME from testing because something depends on libfrufru1 isn't
> > > a win for testing's usability.

> > It would only last until it is able to migrate without breaking anything. I
> > think this is just a matter of deciding which way is "less broken", i.e.
> > broken because some packages are removed, or broken because you have
> > multiple versions of the same libraries. IMHO the latter approach breaks
> > testing more than the former, because it is a matter of availability vs
> > duplicates (and if something goes wrong: installability).

> If you can’t see how keeping another library around is more useful for
> user than breaking half of their systems, I’d appreciate if you could
> think if over again.

I’m very sorry, Raphael, I didn’t want to be harsh: please accept my
apologies. Removing packages is certainly an option when they are not
fixed, or unmaintained, or candidates for removal from unstable.

But removing maintained and fixed and useful packages to make a
transition does not particularly help our users: new users of testing
won’t be able to install the package, and old users will end up (in the
best case) with the two SONAMEs of the library installed [in the worst
case, they won’t be able to upgrade].

So, in keeping the old library around is what apt & co. is going to
suggest to these users, I would say it’s appropriate to use it as a
temporary solution to alleviate precisely that problem.

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEB_VENDOR and forks

[Emilio Pozuelo Monfort]

Loïc Minier wrote:
> On Wed, Mar 18, 2009, Raphael Hertzog wrote:
>> I also included DEB_VENDOR in the set of variables. This variable is not
>> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
>> to become more used in the future for things like this:
>> - enable additional patch/features depending on the vendor (while still
>>   sharing a common source package for better cooperation)
>> - special purpose derivative could change the behaviour of helpers like
>>   debhelper/CDBS based on this value (for example to strip doc for
>>   Emdebian, to extract debug infos in .ddeb, ...)
> 
>  While I appreciate the effort of providing DEB_VENDOR, I'd like to
>  raise a design issue with this approach which we'd best fix now.
> 
>  If you implement conditional behavior in your rules, typically based on
>  lsb_release -is output:
>  if vendor is Ubuntu:
> foo
>  elif vendor is Debian:
> bar
>  you face a problem when you meet:
>  else:
> 
>  What behavior should one use here?

There is a good use case for this that doesn't require a conditional, which is
passing --with-package-name=$(DEB_VENDOR) to configure for packages that have
this option (e.g. the GStreamer stack, that right now checks lsb_release -si 
output.

It doesn't solve your concerns but perhaps you could do some common action or
apply the Debian logic for anything else (which would be the same as not looking
at DEB_VENDOR at all).

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Packaging a library when upstream does not build a .so

[Enrico Zini]

On Tue, Mar 17, 2009 at 03:03:22PM +, Simon Huggins wrote:

> Is there a reason you need this now and can't wait until you've managed
> to argue for the shared library from upstream and cajoule them into
> producing a .so?
> I had an upstream that wasn't very confident with soname changes and
> went through a long process explaining that and the benefits but
> ultimately it was worth it.

Upstream will not be able to tackle shared libraries before an
unpredictable amount of time, which could easily exceed one year or two.
I am trying to help by sending him an up-to-date version of my libtool
patch after every release, and making myself available for any other
help that would be needed.  However, he is not evil; he has other much
more urgent things to work on.

In the meantime, should I:

 - not package the library, which is however very useful, and needed by
   other software that I have written and want to package
 - package the library only as a -dev built with -fPIC (but no one has
   endorsed that option so far)
 - package a debian-only shared library, taking advantage of the fact
   that API and ABI are rather stable, and have been for a year.  In
   that case, I need to figure out the best way to do it.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

removing unmaintained (unused?) X input drivers

[Julien Cristau]

Hi,

the following X input drivers will be removed from the archive soon
unless someone steps up to maintain them (both upstream and in Debian).
If you use one of these, now is the time to make yourself known.

magellan
calcomp
digitaledge
dmc
elo2300
dynapro
jamstudio
magictouch
palmax
spaceorb
tek4957
ur98
summa
microtouch
(package names are xserver-xorg-input-$driver)

See http://lists.x.org/archives/xorg-devel/2009-February/000186.html

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

DEB_VENDOR and forks

[Loïc Minier]

On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> I also included DEB_VENDOR in the set of variables. This variable is not
> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
> to become more used in the future for things like this:
> - enable additional patch/features depending on the vendor (while still
>   sharing a common source package for better cooperation)
> - special purpose derivative could change the behaviour of helpers like
>   debhelper/CDBS based on this value (for example to strip doc for
>   Emdebian, to extract debug infos in .ddeb, ...)

 While I appreciate the effort of providing DEB_VENDOR, I'd like to
 raise a design issue with this approach which we'd best fix now.

 If you implement conditional behavior in your rules, typically based on
 lsb_release -is output:
 if vendor is Ubuntu:
foo
 elif vendor is Debian:
bar
 you face a problem when you meet:
 else:

 What behavior should one use here?

 I think changing the build based on lsb_release or DEB_VENDOR output in
 their current form is going to mean more work for derivatives and
 surprize breakages downstream (typically not for Debian and Ubuntu).

 Instead, I think it would be nice if we could express some inheritance
 concept so that you can have conditional behavior in rules based on
 either "this distribution and its derivatives" or "only for this exact
 distribution" and logical combinations such as "derivatives of Foo
 except derivatives of Bar".

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Wed, 18 Mar 2009 19:13:03 +0900
Charles Plessy  wrote:

> Le Wed, Mar 18, 2009 at 07:25:40AM +, Neil Williams a écrit :
> > 
> > Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
> > using debhelper calls and uploading TDebs each time they would
> > currently upload any package that contains /usr/share/locale/LC_*/ etc.
> > Those TDebs are, effectively, +t0 - only updates by translators start
> > the +t1 sequence.
> > 
> > Maintainer uploads:
> > foo_1.2.3-4_amd64.deb
> > foo-tdeb_1.2.3-4_all.tdeb
> > foo-bar_1.2.3-4_amd64.deb
> > foo_1.2.3-4.diff.gz
> > foo_1.2.3.orig.tar.gz
> > foo_1.2.3-4.dsc
> > foo_1.2.3-4_amd64.changes
> 
> Hi Neil,
> 
> how do you coordinate your action with the project of using the source format
> '3.0 (quilt)' by default in Squeeze +1?

Why should 3.0 be any more difficult than 1.0 or anything that follows?
(Not that I have any particular desire to use 3.0 or quilt myself.) 3.0
has to deal with incorporating patches and changes from the BTS, so
+t1.diff.gz is no different. In Squeeze+1, the changes are restricted
to debian/po or po/ for native Debian packages so there is no need to
do anything with 3.0 until Squeeze+2.

What matters is that the maintainer gets the +t1.diff.gz and applies it
onto the source package prior to the next upload. It's no different to
how the same maintainer would handle a patch or new translations
file sent to the BTS. I'm quite sure various tools and scriptage will
be devised to help with different workflow patterns before Squeeze+2.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpQnfJp71RjA.pgp
Description: PGP signature

Re: DEP-4: The TDeb specification.

[Charles Plessy]

Le Wed, Mar 18, 2009 at 07:25:40AM +, Neil Williams a écrit :
> 
> Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
> using debhelper calls and uploading TDebs each time they would
> currently upload any package that contains /usr/share/locale/LC_*/ etc.
> Those TDebs are, effectively, +t0 - only updates by translators start
> the +t1 sequence.
> 
> Maintainer uploads:
> foo_1.2.3-4_amd64.deb
> foo-tdeb_1.2.3-4_all.tdeb
> foo-bar_1.2.3-4_amd64.deb
> foo_1.2.3-4.diff.gz
> foo_1.2.3.orig.tar.gz
> foo_1.2.3-4.dsc
> foo_1.2.3-4_amd64.changes

Hi Neil,

how do you coordinate your action with the project of using the source format
'3.0 (quilt)' by default in Squeeze +1?

Have a nice day,

-- 
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

Re: Environment variables, debian/rules and dpkg-buildpackage

[Goswin von Brederlow]

Raphael Hertzog  writes:

> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>> 
>> Modulo debhelper, cdbs, et.al can help.
>
> Debhelper can't help. Only CDBS can (as its design is precisely based on
> included Makefiles).

With the magic

%:
dh $@

debhelper could help.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

On Tue, 17 Mar 2009, Manoj Srivastava wrote:
> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> > It seems to me that you are indeed close, but with the exception of
> > this required include in all our debian/rules, which will be a PITA to
> > achieve.
> 
> Modulo debhelper, cdbs, et.al can help.

Debhelper can't help. Only CDBS can (as its design is precisely based on
included Makefiles).

> And will be mostly useless. dpkg can set these variables until
>  it is blue in the face, and it has zero effect on my packages  until I
>  change my rules file. Or change upstream Makefiles to pay attention to
>  the cflags set in the env. This is a major change for some of my
>  packages, and without them the dpkg proposal does nothing.

That's true for a lot of packages but not all packages. It also means that
there is some usage of this approach in the archive (otherwise if all
packages ignored the environment variables, there would never have been
packages that FTBFS when this change was introduced in Lenny).

So according to your rule that policy should standardize "common practice"
and not mandate something completely new, the env variable proposal is in
more widespread usage.

(Note that I don't find this rule particularly useful and that's why I
didn't mention it before but since you ask about points where you are
biased I thought it could be worth telling) 

> See, I think we need have package opt-in in any case.

Not in all cases. CDBS could also be updated to cope with the env var
and debhelper 7 packages using rules.tiny could also make use of it
without a modification.

> Also, the dpkg proposal  blurs the distinction between the site
>  wide policy and project defaults, as far as the user or the package
>  maintainer is concerned. This is a deficiency.

While I agree that the distinction is blurred because in the rules files
you don't know where the env var comes from, I don't agree that it's a
deficiency.

The rules files receives a value and should use it. It doesn't need to
know whether it's the site-wide default or the distribution default. 

> Yup. The major differences are:
>  With the dpkg proposal:
>  Bad:
>  o) people must always use dpkg to build packages, or the packages come
> out different

If the policy document the fact that the rules files need some input
variables, then it's not a big deal: if you really care about being able
to call debian/rules directly you can always adapt your rules files
accordingly like I suggested at the end of this mail:
http://lists.debian.org/debian-devel/2009/03/msg00920.html

We could even write such a Makefile that mimics more closely what
dpkg-buildpackage does for people that care about it. But I don't
really want to impose a Makefile snippet to everybody.

>  o) The user or the package maintainer can no longer tell the difference
> between site policy and project policy

The user is intelligent, he can read the output of dpkg-buildpackage that
tells him where the data comes from (or he can read the doc and the
configuration file). In any case, it's comparable to having to
read a Makefile snippet.

For the package maintainer, why should he care ? The variable is provided
in a manner where he can or can't override it, but that's all that
matters.

>  o) The environment variables are set even if the package is not ready
> for them,

We already took that hit. It's not an issue.

>  o) rules file still need to be modified to take advantage of the
> variables set -- none of my rules files will be affected by any
> settings in dpkg right now.

The fact that your rules files need change doesn't meant that all need it.

>  With the Make snippets proposal:
>  Bad:
>  o) Every package has to change (but,every package has to change anyway,
> since currently dpkg can set the variables till it is blue in the
> face and nothing will take effect in my packages)
>  Good:
>  o) the person building the package is not constrained to using dpkg;
>  o) The site admin can add on to the variables set on that site, and is
> not constrained by what dpkg handles
>  o) the process is opt in, and packages opt in to using the new
> mechanism when they are ready.
>  o) The end user can override project, site, or package policies,
> individually, or in any combination
> 
> If I am biased (likely), please tel me where I have gone wrong
>  above. 

If the policy documents the environment that needs to be setup, nobody is
forced to use dpkg-buildpackage to do it. But it's probably more
convenient to use a helper compared to manually setting the expected
variable.

dpkg-buildpackages should be considered like a helper and I'm available to
fix any problem that makes it painful to use (if you find its usage too
much constraining).

I would like to point out that we speak mainly of CFLAGS and al. but that
I also included DEB_VENDOR in the set of variables. This variable is not
used currently (as I just in

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Hector Oron  writes:

> Hello Goswin et al,
>
>   IMHO, the things you are talking about are quite nice. They way it
> works sounds to me a little complex, that it is very close to the idea
> of crosscompiling, as the *right way*, as opposed to accumulate dirty
> hacks and workarrounds that it is what most embedded distros do out
> there. As from my point of view, getting people confused is also not a
> good idea, as what you talk about seems to be much like cross
> compiling, you should face the troubles we face when cross compiling
> the *right way*.

I verry much unifies cross-compiling and biarch. That is true. The
similarity was recognised and planed in.

>  As a first step, I would recommend to take a deep though and let
> community and Debian workflow as is (most of the better systems used
> for safety-critical are well proben in time, that helps on having a
> better MTBF -- why break what we have proben for many years?)

It has been though of for years now. At some point there has to be
some acting. The idea, the concept and even a basic implementation has
been around from before sarge and there have been no fundamental
changes in years despide repeated deep thinking about it.

> After some rest and thoughts on paper and ink I would recommend to do
> some cross compiling work, try to bootstrap a minimal set of packages
> for armel (it would be appreciated in emdebian), and you'll find lots
> of tools need to be polished and therefore lots of common and uncommon
> packages. What all this is about is very nice, but needs lots of work,
> if you want to do it the *right way*. Once you realize what one
> architecture implies, then you'll find what an overhead is to think on
> common libcs, oses and arches, plus vendors, it just becomes somehow
> insane.

Which all boils down to DEB_HOST_GNU_TYPE=x86_64-linux-gnu being
unique.

Note that for cross-compiling for multiple architectures on the same
system the GNU tripplet must already be unique or the toolchain,
libraries and headers collide. So this "insanity" is something
inherint in having millions of ABIs for an arch or for uclibc and not
something multiarch creates. That "insanity" also does not affect any
existing Debian arch.

>  So, if you like to do wacky ideas[1], I invite you to emdebian land
> and let Debian distro follow their flow.

And I see that they struggle and use dpkg-cross and curse and if you
go back in the thread you see that at least some from the emdebian
camp voiced their wish to replace the dpkg-cross hack with multiarch.

And that it needs a lot of work is not really true. What it needs most
is cooperation. The willingness from maintainers to accept patches and
from Debian in general to accept the multiarch dirs. Packages can be
patched for multiarch as needed and those that need it will do the
work. Need is a great motivater in that respect. So we just have to
light the way and get things started.

> (Please do not interpret me as I am telling what you have to do or
> anything else, i am trying to be as much friendly as I can)

No offense taken.

> Friendly regards,
>   Hector Oron
>
> [1] http://wiki.debian.org/EmdebianWackyIdeas
> -- 
>  Héctor Orón

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#466550: Pristine source from upstream VCS repository

[Steve Langasek]

On Mon, Mar 16, 2009 at 11:38:50AM -0500, Manoj Srivastava wrote:

> I am opposed to bloating the policy with dictum that are
>  unnecessary, but I see your point about the API. The API is essentially
>  the watch file, and we already specify that in the policy. DEHS (as
>  mentioned in policy) uses that file;p there is no need to add stuff
>  into policy that we already have.

Hrm, but in fact what Policy has to say about watch files can hardly be
considered a useful API.  It only says that a file named debian/watch may
exist, but says nothing about what it's supposed to look like.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#466550: Pristine source from upstream VCS repository

[Steve Langasek]

On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
> >> Given that we already have a tool that can download upstream
> >>  sources, with or without mangling, and can be used by facilities
> >>  outside of the unpacked Debian source package to determine if there was
> >>  new versions and to download unmangled versions, is there any need to
> >>  retain the get-orig-source target at all?

> > I have get-orig-source targets that verify the upstream detached gpg
> > signatures before repacking the tarballs.  Is there a way to do that with
> > uscan?

> There is no limit on what your user specified script can
>  do. Given a version number, you can still download the hash and test
>  it. No sweat.

So I have to duplicate information (the upstream URL) between the watch file
and the script?  Seems like it's better to just continue using
get-orig-source then.

> >> I mean, this seldom implemented target is duplicating an existing and
> >> widely used facility in Debian; and removing the target from the policy
> >> will advance the laudable goal of stripping the policy of cruft.

> > Well, I doubt more people are using uscan mangling than are using
> > get-orig-source, really; so I don't think that facility is "widely used".

> There are far many more watch files in packages than there are
>  get-orig-source targets in rules files, so yes, uscan is far more
>  widely used. As I said elsewhere in this thread, mangling is not widely
>  enough automated to say anything one way or the other about practices
>  followed. 

It certainly is possible to say which of the two possible processes for
mangling is more prevalent by examining the archive.

$ cd /srv/lintian.debian.org/laboratory/source
$ find . -mindepth 3 -maxdepth 3 -name rules | xargs grep -l get-orig-source | 
wc -l
752
$

There are many more watch files than that, of course, but how many of them
include non-default actions?  I'm pretty confident that it doesn't approach
5% of the archive, even without subjecting gluck to a script to parse all
the watch files to check this.

> I would not be against a recommendation in policy to implement
>  direct-from-vcs  upstream tarballs to be created vbia get-orig-source,
>  and everyone else just use debian/watch and debian/urepack files.

The (as-yet-unrealized) benefit of having this defined in policy is to give
developers other than the maintainer a simple, standard way to grab the new
upstream source of a package.  Doesn't "try debian/rules get-orig-source,
and if that doesn't exist, try uscan instead" fall short of "simple"?

(This is basically the status quo, so it's not a tragedy if we don't correct
it - but if we're going to amend policy here anyway, surely it would be good
for the outcome to be a policy definition that meets this standard.)

On Fri, Mar 13, 2009 at 10:38:35AM -0500, Manoj Srivastava wrote:

> Let me make a case here for the get-the-latest work flow, but
>  before I do so, I would like to state that the relative popularity of
>  the work-flow ought not to be relevant when making policy: technical
>  policy should not get in the way of even a minority work-flow without
>  sound and compelling reasons to select one method or the other (usually
>  this clause gets called in for integration issues).

Popularity speaks to whether developers find it useful.  We shouldn't be
codifying requirements into Policy if it doesn't actually benefit us to
standardize on them.  But if there is a benefit from having all packages
behave the same way - "integration issues", as you say - that should be
weighed against incompatible minority workflows.

I certainly do think that the inclusion of get-orig-source in Policy serves
no purpose *but* to provide a consistent interface that developers can rely
on.  So while we should try to minimize the disruption of maintainers'
existing workflows, if this belongs in Policy at all (which I believe
ultimately it does), then that trumps the fact that some packages will need
to change in order for their maintainers to continue using their preferred
workflow.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: group nvram

[Reinhard Tartler]

Stephen Gran  writes:

>> Users must not be in specific groups to access hardware, this is broken
>> and insecure.
>
> That's the first I've heard that argument - of course you don't give
> untrusted users access to hardware, but we've always managed access to
> devices with group membership (lp, dialout, etc).  Are you proposing
> that should change?

Well, since lp and dialout access cannot render your machine unbootable,
this is indeed possible with nvram, since you can overwrite critical
parts of your bios with it. Think of an malicious or buggy program
running under your user account doing nasty things.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Wed, 18 Mar 2009 00:26:30 -0500
Manoj Srivastava  wrote:

> On Tue, Mar 17 2009, Neil Williams wrote:
> 
> >>  Do you prevent mixing old and new .debs and .tdebs?
> >
> > Changes to translations use +t1.diff.gz etc.
> >
> >>  How do you merge data from a new package into the tdeb data?
> >
> > The real question is how to get apt to understand getting the
> > +t1.diff.gz when asked for apt-get source and for dpkg to expect to
> > unpack +t1.diff.gz etc.
> 
> Also, currently one may put up a new version of a package into
>  experimental or people.debian.org; and it carries with it the older
>  translations. If the translations are separated, then the people.d.o
>  package will be useful only for testing by the speakers of the original
>  langiage the debconf templates were written in.  This seems like a step
>  back

No, the initial TDeb will be generated by the maintainer, effectively
+t0, so the maintainer uploads the initial TDeb containing whatever
translations are currently supported, putting the TDeb wherever you
put the binary and .dsc. It is up to the maintainer to incorporate any
+t1.diff.gz containing updated or new translations that may exist
already into each new Debian version. The other repository could also
simply copy any existing TDeb that does already exist alongside the test
package. (Being Arch:all, the TDeb is only included in the maintainer
upload or subsequent translator updates, buildd's don't need to worry
about TDebs at all.)

If the new version has changed translated strings then those will only
available in English until the +t1 TDeb arrives anyway - that doesn't
change. (English is always the language in which the templates must be
written initially - en_US at that.) There remains the current advice
that changes to the templates should always seek translation updates
prior to the upload of the initial TDeb by the maintainer. If
maintainers implement a string freeze and wait for translation updates
before uploading, the chances of a +t1.diff.gz being required by time
of the next release by the maintainer are lower.

Just like the dependencies of a package in experimental, the TDeb is
still available and can be updated by translators, the +t1.diff.gz is
available to the maintainer to incorporate into any new version and
debian/rules needs to include support for generating the TDeb for each
new version.

Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
using debhelper calls and uploading TDebs each time they would
currently upload any package that contains /usr/share/locale/LC_*/ etc.
Those TDebs are, effectively, +t0 - only updates by translators start
the +t1 sequence.

Maintainer uploads:
foo_1.2.3-4_amd64.deb
foo-tdeb_1.2.3-4_all.tdeb
foo-bar_1.2.3-4_amd64.deb
foo_1.2.3-4.diff.gz
foo_1.2.3.orig.tar.gz
foo_1.2.3-4.dsc
foo_1.2.3-4_amd64.changes

The foo-tdeb package will be listed in the .changes anyway so existing
tools will simply add it to the list of files to be uploaded to
ftp-master or wherever. foo-tdeb_1.2.3-4_all.tdeb is, effectively,
foo-tdeb_1.2.3-4+t0_all.tdeb

Translator updates arrive:
foo-tdeb_1.2.3-4+t1_all.tdeb
foo_1.2.3-4+t1.diff.gz
foo_1.2.3-4+t1.dsc
foo_1.2.3-4+t1_all.changes

Maintainer makes a new release foo_1.2.3-5 which incorporates the TDeb
changes in a similar manner to how an NMU is included today. All files
matching foo*1.2.3-4* are removed by dak when the new version is
uploaded. The updated translations now exist in
foo-tdeb_1.2.3-5_all.tdeb - uploaded by the maintainer and there is no
+t1.diff.gz or +t1_all.tdeb until the package translations need to be
touched again.

The key point is that a +t1 revision can happen *during a release
freeze* without touching the source, without changing any of the
binaries. Once the release is out and unstable is accessible again, the
maintainer adds +t1.diff.gz to their next upload. Done.

(Interesting point, if the current Debian version has already migrated
to testing, the +t1 TDeb will also need to migrate with the +t1.diff.gz
as source. Whether the rules should change for a TDeb migration needs
to be decided - it could be that TDebs have a shorter time in unstable
if the relevant version of the package is already in testing or even
be allowed to migrate immediately. That's all for Squeeze+1.)

The system is quite similar to how an NMU is currently done - without
the problems of a source rebuild - and maintainers can handle the +t1
in much the same manner to fit into their workflow. Whether a changelog
entry is needed is undecided, it would be courteous but not necessarily
mandatory, especially if no bug exists to be closed.

What remains to be resolved is how best to fit that
"maintainer incorporates the changes from the TDeb" stage is handled so
that it doesn't disturb maintainer workflow too much. The changes will
only be in the po/ files and consist of simply unpacking the
+t1.diff.gz on top of your existing checkout (and committing any
changes if you use an RCS).

None of this