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

[Don Armstrong]

On Sun, 15 Mar 2009, Steve Langasek wrote:
> On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote:
> > Now, this has its own set of problems and caveats as well, since
> > if you don’t pay attention and take care of later cleanup, you end
> > up with packages in testing that do not belong to any source in
> > testing, which is bad.
> 
> Will there be reports produced on a regular basis of the stale
> libraries in testing, and their reverse-dependencies, so that people
> can easily pitch in to help with this later cleanup?

Even better would be to turn this report into a set of bugs filed
against the set of reverse dependencies which are made RC at the time
that the transition migrates.

[I'm personally slightly concerned about relaxing britney allowing
testing to get into unreleasable states; a flag to re-enable the old
behavoir late in release would probably be good.]


Don Armstrong

-- 
I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

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

[Steve Langasek]

On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote:

> [I'm personally slightly concerned about relaxing britney allowing
> testing to get into unreleasable states; a flag to re-enable the old
> behavoir late in release would probably be good.]

In practice, the release team has to do this at various points in the
release cycle anyway because the transitions become so entangled that
breaking something in testing, or removing a bunch of packages that we
intend to release with, are the only options.  This approach at least
ensures that testing will remain installable and (presumably) useful during
the rocky transitions, merely requiring a bit of cleanup of old packages.

-- 
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: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

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.

> You are conflating breakage that were reported with breakage that appeared
> but were not reported.
[…]
> Changing CFLAGS behind the back of the maintainers is potentially changing
> how the package is build in a undefined way. A package built in such way 
> should
> be assumed broken.

So you should assume that most Lenny packages are broken. I know the
difference but while I don't deny that some unused packages might be
affected by this, it's not my concern right now (those packages are
probably candidate for removal if nobody used them to detect that they are
not working anymore).

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

[Raphael Hertzog]

On Sun, 15 Mar 2009, Stephen Gran wrote:
> This one time, at band camp, Raphael Hertzog said:
> > Care to elaborate what kind of flexibility you need in this specific case ?
> 
> I don't.  I'm imagining that some of our downstreams may.

It's precisely one of our downstreams that pushed the
dpkg-buildpackage change (Ubuntu). I don't think most downstreams
care a lot about the exact implementation, but they clearly want
a way to alter defauld build flags at the distribution level.

This all started with:
https://wiki.ubuntu.com/DistCompilerFlags

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: Bug#466550: Pristine source from upstream VCS repository

[Reinhard Tartler]

Ben Finney  writes:

> Ben Hutchings  writes:
>
>> # Upstream homepage links to a file called puzzles.tar.gz which
>> # redirects to puzzles-r$version.tar.gz.  uscan can't check that.
>> # However, this is a nightly snapshot numbered according to the SVN
>> # revision number, so we can extract the version number from its web
>> # view.
>> version=3
>> opts="filenamemangle=s/.*\?rev=(\d+).*/sgt-puzzles_$1.orig.tar.gz/,downloadurlmangl...@.*\?rev=(\d+)@http://www.chiark.greenend.org.uk/~sgtatham/puzzles/puzzles-r$1.tar.gz@";
>>  \
>> http://svn.tartarus.org/sgt/puzzles/ /sgt\?rev=(\d+)\&view=rev
>> 
>> OK, so it's not exactly pretty...
>
> It also fails in those instances where “available from a VCS” does
> not mean “available as a working tree of files via HTTP”. Some VCS
> repositories make *only* the revision data available, for various
> reasons.

For ffmpeg (and mplayer AFAIUI), upstream provides only revision data,
and is heavily using svn:externals, which forced me doing horrible
things like this:

http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/get-orig-source.sh;hb=HEAD
http://git.debian.org/?p=pkg-multimedia/mplayer.git;a=blob;f=debian/get-orig-source.sh;hb=HEAD

Does someone manage to "port" that script to uscan? ;-)

-- 
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: toolame: remove from unstable, update in stable

[Fabian Greffrath]

Luk Claes schrieb:

It's ok, please mention the portability bugs on [0] and upload.


Unfortunately IANADD, so I cannot modify the wiki page on my own. The 
closed bugs are #504308 and #506193. Maybe someone can do me the favor 
 and add them on the wiki page once the package has been uploaded.


To which dist should I upload, stable or stable-proposed-updates? 
Which version number should I choose?


Mark Purcell schrieb:
> As the current twolame maintainer.
> I would be happy with this approach.

Great, thank you very much!

Fabian

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  greffr...@leat.ruhr-uni-bochum.de


--
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 Mon, Mar 16 2009, Ben Finney wrote:

> Manoj Srivastava  writes:
>
>> 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.
>
> Okay, now I'm officially confused. I don't see how the patch [0] I've
> submitted for this issue does not satisfy what you're saying.
>
> Ideally, I'd like to see you produce a patch for bug#466550 that
> demonstrates what you're saying, so I can see the difference. I can
> understand if that's too much effort though.

I can see how this discussion could have gotten confusing.

Use cases:
 A) Get upstream version from the Debian archive
 B) Get a specific version from upstream (perhaps to package, or to
verify the version in the debian archive)
 C) Get the latest version from upstream (usually to package it)
In cases B and C above, the upstream distribution can be a
 tarball or a VCS.

Let me see if I can capture the current status again. I am
 starting with a modified form of Kapil's statement early in the report:
1. Once pkg_ver.orig.tar.gz enters the Debian archive this is considered
   the authoritative Debian version from which all the binary Debian
   packages will be built (for that version of the package). A
   signature/checksum is used (in the upload and the Sources.gz file) so
   as to detect any "contamination". apt-get source is enough to get the
   latest Debian source from the archive (and wget for older sources)
2. Whenever upstream releases a new version, one needs to create a
   pkg_nver.orig.tar.gz for the newer version. In most cases this is merely a
   matter of downloading and renaming an upstream tar.gz. 
3. If re-packaging of upstream sources was required in order to create
   this .orig.tar.gz, then this should be documented in the copyright
   file (with some further explication in README.Debian-source
   perhaps). 
4. If upstream distributes tarballs, the "uscan" and "uupdate" programs
   are adequate and there is no significant need for a get-orig-source
   target. 
5. If the upstream distribution is in the form of a VCS, then uscan does
   not cater to it. This seems to be the case where get-orig-source can
   fill a need.



There are these three variables that govern the logic:
package in Debian already:   Yes/No
Upstream code Mangling Required: Yes/No
Upstream has  tarballs:  Yes/No
Version to Get:  Latest/Current

   In tabular/Karnaugh map form (X are the don't care states):
|--+-++--++--|
| Already  | Version | Has  tarballs | Only VCS  |
| Packaged | to get  | Mangle | Pristine | Mangle | Pristine |
|--+-++--++--|
| Yeslatest  | uscan  | uscan| GOS| GOS  |
| Yescurrent | uscan  | uscan| GOS| GOS  |
| No latest  | uscan  | uscan| GOS| GOS  |
| No current |   X|   X  |  X |  X   |
|--+-++--++--|
By logic minimization, the answer is clear :)

While the target was originally designed for cases where we had
 to mangle upstream sources, after this discussion and analysis I am
 coming to the conclusion that uscan has matured to cover all cases
 where upstream distributes a tarball; making the target obsolete. The
 places where we do not have an existing solution is if upstream
 distributes sources _only_ in a VCS.   

Now, your patch states:
--8<---cut here---start->8---
+   This target generates the original source archive for
+   the package, such that its contents exactly match the
+   original source archive used to generate the package
+   for Debian.

+   The commands for this target fetch the original source
+   package, corresponding to the Debian package version,
+   from a canonical archive site (for example, via FTP,
+   WWW, or a public VCS repository), do any necessary
rearrangement to turn it into the original source
+   archive file format, and leave it in the current
+   directory. See  for
+   policy details of the original source archive.
--8<---cut here---end--->8---

There are some places where I differ:
 a) You ask this target only refer to the version in the changelog, and
not the latest version
 b) You ask the file is left in the current directory, instead of ../
where uscan leaves it
 c) This patch makes  the target work for cases where uscan would be
enough -- watch files are useful for DEHS and the PTS and stuff, so
we want to recommend watch files anyway, duplicating uscan in a
targe

Lenny security hardening features

[Danny Richards]

Hi,

It is written here <
http://wiki.debian.org/NewInLenny#head-6e41dc18abd5f3c10b59000dabaf1f6b2ab7cad8
>
that "some packages" in Lenny were built with GCC hardening features.

Is there any documentation about:
  1. Which packages were built this way ?
  2. Which features were used ?

Thanks,
Danny.

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

[Felipe Sateler]

Raphael Hertzog wrote:

> Note that I'm not asking to mandate the tool. I would like to mandate the
> fact that packages can rely on some environment variables being set to
> some values.

Note that packages will not necessarily pickup the environment variables.
autoconf using packages will probably do automatically, but other build-systems
still require the maintainer to pick up the changes from the environment and
passing them to the build command (eg, scons doesn't have any standard way for
that, its up to the package to define a variable). So you don't actually
guarantee that all packages use the default flags.

-- 

  Felipe Sateler


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

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
>> Say you have acrobat reader installed which depend on ia32-libs-gtk.
>> You also have libgtk2.0 (i386) installed with a newer version that
>> breaks acrobat reader (like it did last year). Then acrobat reader
>> will use the newer libgtk and break despide the dependencies all being
>> correct.
>
> How is it any different from acrobat on i386 breaking when you upgrade
> GTK+ the same way?

Depends: ia32-libs-gtk (<= 2.6)

It does not depend on libgtk2.0-0 (i386) but installing libgtk2.0-0
(i386) would break it. That I would really like to avoid.

Also some libraries do have conffiles or binaries and will get into a
file conflict with or without the multiarch library path. They need a
Replaces/Conflicts line anyway. Chief among them libc6 (i386)
vs. libc6-i386.

MfG
Goswin


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

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Aurelien Jarno  writes:

> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
>> On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
>> > ]] Clint Adams 
>> 
>> > | It may be time to change packages installing files to
>> > | /emul/ia32-linux (which violates the FHS) to use
>> > | /usr/lib32 instead.
>> 
>> > Could we pretty please use the multiarch paths here if we start moving
>> > stuff around?  We're going to need to patch gcc/binutils if we're to
>> > compile stuff against those paths anyway.
>> 
>> What transitional issues is that going to cause us if and when multiarch
>> becomes generally available, if biarch packages start using the path now?
>> 
>
> Note that i386 libc on amd64 has used once the multiarch paths. This has
> been reverted to the current path, because there was no clear plans
> about a transition to multiarch. I think this still applies.

You couldn't compile anything for 32bit anymore.

> One of the goal of multiarch is to avoid having packages containing
> binaries of a different architecture than the one of the package (e.g.
> i386 binaries in an amd64 package), in order to make packages of
> different architecture co-installable. If we start to break this goal,
> we will have packages using the multiarch path, but not co-installable,
> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
> be co-installable.

Already broken for 2 stable releases.

> IMHO, we should have a clear transitional plan to multiarch before we
> start using multiarch path, in order to make sure we are not creating
> problems that has to be solved later.

libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo

or

libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs

Adding that will let dpkg know how to handle the transition just fine.

> OTOH, as soon as we have the toolchain fully supporting multiarch path
> support (there is a missing part in gcc, that was thought to be fixed
> binutils [1]), I am not opposed to switch the main glibc to the multiarch
> path.
>
> [1] I offered to write it, but I haven't found time yet, so a patch is
> welcome.

Binutils upstream has vetoed adding multiarch paths saying it is gccs
job. The BTS has a simple patch for gcc using the specs file to add
the multiarch dirs without loosing the biarch dirs.

Did you have anything more complex in mind to fix this?

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

[Goswin von Brederlow]

Raphael Hertzog  writes:

> On Fri, 13 Mar 2009, Manoj Srivastava wrote:
>>  3. dpkg-buildpackage is probably the wrong place to put this solution
>> in.
>
> Why?
>
>> The fact that dpkg-buildpackage's setting the variables is not
>>  easily configurable, and  presents to make as though it was set
>>  on the commandline, and thus making it hard for the *USER* to set the
>>  flag variables via env variables, is, in my opinion, a major bug.
>
> This is wrong. dpkg-buildpackage preserves the value set by the user if
> any. It simply sets default values to all those environment variables if
> they have none.

I think he ment that you can not know wether the setting comes from
dpkg-buildpackage or the user. If it comes from dpkg-buildpackage then
debian/rules should be free to override it as needed. If it comes from
the user then that is another story. At least that is my take on it.

MfG
Goswin


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

Re: Breaking /emul/ia32-linux for squeeze

[Steve Langasek]

On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
> Josselin Mouette  writes:

> > Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
> >> Say you have acrobat reader installed which depend on ia32-libs-gtk.
> >> You also have libgtk2.0 (i386) installed with a newer version that
> >> breaks acrobat reader (like it did last year). Then acrobat reader
> >> will use the newer libgtk and break despide the dependencies all being
> >> correct.

> > How is it any different from acrobat on i386 breaking when you upgrade
> > GTK+ the same way?

> Depends: ia32-libs-gtk (<= 2.6)

Where is the package that does this?

How does this package know, a priori, that the next version of libgtk2.0
will break it?  It's considered a bug if a library breaks its public
interfaces without changing soname; consequently it would also be a bug for
this package to second-guess libgtk.

> Also some libraries do have conffiles or binaries and will get into a
> file conflict with or without the multiarch library path. They need a
> Replaces/Conflicts line anyway. Chief among them libc6 (i386)
> vs. libc6-i386.

That's true, but not a reason to cause file conflicts for all the other
biarch packages out there.

-- 
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: Breaking /emul/ia32-linux for squeeze

[Aurelien Jarno]

Goswin von Brederlow a écrit :
> Aurelien Jarno  writes:
> 
>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
>>> On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
 ]] Clint Adams 
 | It may be time to change packages installing files to
 | /emul/ia32-linux (which violates the FHS) to use
 | /usr/lib32 instead.
 Could we pretty please use the multiarch paths here if we start moving
 stuff around?  We're going to need to patch gcc/binutils if we're to
 compile stuff against those paths anyway.
>>> What transitional issues is that going to cause us if and when multiarch
>>> becomes generally available, if biarch packages start using the path now?
>>>
>> Note that i386 libc on amd64 has used once the multiarch paths. This has
>> been reverted to the current path, because there was no clear plans
>> about a transition to multiarch. I think this still applies.
> 
> You couldn't compile anything for 32bit anymore.
> 
>> One of the goal of multiarch is to avoid having packages containing
>> binaries of a different architecture than the one of the package (e.g.
>> i386 binaries in an amd64 package), in order to make packages of
>> different architecture co-installable. If we start to break this goal,
>> we will have packages using the multiarch path, but not co-installable,
>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
>> be co-installable.
> 
> Already broken for 2 stable releases.

We are not using multiarch paths in Debian, so this has never happens.
When using standard /usr/lib paths, people are expecting that the paths
collide. When using multiarch they do not expect that, as it the goal of
multiarch.

>> IMHO, we should have a clear transitional plan to multiarch before we
>> start using multiarch path, in order to make sure we are not creating
>> problems that has to be solved later.
> 
> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo
> 
> or
> 
> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs
> 
> Adding that will let dpkg know how to handle the transition just fine.

Meaning we need to have that for each package previously available as a
biarch package. Seems to be complicated for no real gain.

Let me ask you a question: What would be the gain of using the multiarch
path for the biarch packages?

For me pushing that is the wrong way to get multiarch support in Debian.
If we want it, we need to move the main librairies to the multiarch
path. And it is something I proposed for glibc once we have proper gcc
support, and a stabilised glibc 2.9. This choice still needs to be
validated by other persons though (like the RM team).

Last but not least, what is really need to have multiarch support in
Debian is a proper support in dpkg. They are some code already done by
Tollef, they are some ideas floating around, but they are still some
design decisions to be taken, and nobody has a real patch that can be
applied to dpkg. People are pushing hard to have multiarch support, but
no one seems to care about actually writing code.

>> OTOH, as soon as we have the toolchain fully supporting multiarch path
>> support (there is a missing part in gcc, that was thought to be fixed
>> binutils [1]), I am not opposed to switch the main glibc to the multiarch
>> path.
>>
>> [1] I offered to write it, but I haven't found time yet, so a patch is
>> welcome.
> 
> Binutils upstream has vetoed adding multiarch paths saying it is gccs
> job. The BTS has a simple patch for gcc using the specs file to add
> the multiarch dirs without loosing the biarch dirs.
> 
> Did you have anything more complex in mind to fix this?

This patch looks a bit hackish and it has to be done for each
architecture. Mathias requested that something more automatic using
debian/multiarch.inc is done.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Processed: Re: Processed: Re: Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 519837 cups
Bug#519837: Debian 5.0 - Cups -Canon Pixma iP3500 installation printing failure
Bug reassigned from package `general' to `cups'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Processed: Re: Bug#519902: Dist-upgrade to lenny broke cvs and apt, cannot recover.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 519902 general
Bug#519902: Dist-upgrade to lenny broke cvs and apt, cannot recover.
Warning: Unknown package 'libc'
Bug reassigned from package `libc' to `general'.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Mass bugfiling in preparation for multiarch

[Goswin von Brederlow]

Hi,

over the weekend I did some work on multiarch again and did notice
some new and old problems when adding more libraries to my test set.

Given that the problems are quite easily detectable I'm considering
scanning all packages for their occurance and reporting bugs for them.
In detail I'm looking for the following situations violating 'Policy
8.2 Shared library support files':

1) Library packages that contain public binary ([/usr]/[s]bin/*)

Policy 8.2 says:

| If your package contains files whose names do not change with each
| change in the library shared object version, you must not put them in
| the shared library package. Otherwise, several versions of the shared
| library cannot be installed at the same time without filename clashes,
| making upgrades and transitions unnecessarily difficult.

Example: libc6 contains /usr/sbin/zic, /usr/bin/getent and several more

libc6 must be split into libc-bin and libc6 packages.


2) Library packages that contain conffiles

First Policy 8.2. If the conffiles are not named in a way that changes
with each soname change then this is a violation of a MUST directive.

Example: libc6 conatins /etc/gai.conf


Secondly even conffiles with unique names will be a problem for
multiarch. The library package would be installed from i386
and amd64 resulting in 2 debs with the same conffile.

Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf

For this I want to file bugs (on top of violations of the MUST
directive) requesting that either the conffile is split into a
seperate package (say you already have a libfoo and foo-bin package)
or made unique for the target:
/etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.


3) Library packages that contain shared files

Policy 8.2 goes on to say this about shared files:

| If the program or file is architecture independent, the
| recommendation is for it to be placed in a subdirectory of
| /usr/share instead, preferably under
| /usr/share/package-name. Following the package-name naming
| convention ensures that the file names change when the shared object
| version changes.

But the MUST directive of 8.2 still remains and packages not using a
/usr/share/package-name but something more generic are in violation.

Example: libasound2 contains /usr/share/alsa/alsa.conf
 libarts1c2a conatins /usr/share/man/man1/artsdsp.1.gz


Again for multiarch this becomes more complicated.
/usr/share/package-name will still cause a conflict between the i386
and amd64 flavour of a library package. For this I want to file bugs
(again on top of the violations of the MUST directive) requesting that
either the shared data is split out into libfoo-common packages or, in
case of verry small files, moved out of shared into the multiarch
library path: /usr/lib/x86_64-linux-gnu/package/.

Example: libdirectfb-1.0-0 contains /usr/share/directfb-1.0.1/cursor.dat



Any objections to this? Note that most will be violations of a MUST
directive of policy.

MfG
Goswin


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

Bug#509850: ITP : haskell-curl -- Haskell bindings to the libcurl URL transfer library

[Erik de Castro Lopo]

Package: wnpp
Followup-For: Bug #509850
Owner: Erik de Castro Lopo 


* Package name: haskell-curl
  Version : 1.3.4
  Upstream Author : Sigbjorn Finne 
* URL or Web page : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl
* License : BSD3
  Description : GHC 6 Haskell bindings to the libcurl URL transfer library

 libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP,
 HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. libcurl supports
 SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload,
 proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate,
 Kerberos4), file transfer resume, http proxy tunneling and more!





-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)



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

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

[Adeodato Simó]

* Steve Langasek [Sun, 15 Mar 2009 19:55:50 -0700]:

Hello, Steve.

> On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote:
> > Now, this has its own set of problems and caveats as well, since if you
> > don’t pay attention and take care of later cleanup, you end up with
> > packages in testing that do not belong to any source in testing, which
> > is bad.

> Will there be reports produced on a regular basis of the stale libraries in
> testing, and their reverse-dependencies, so that people can easily pitch in
> to help with this later cleanup?

There is a web page [1] that contains information about ongoing
transitions, including those that are in need on cleanup (libdvdread at
the moment). A list of packages is provided, and they are classified in
two groups: “Pending migration” (that is, they’ve been successfully
rebuilt in unstable), and “Not fixed in unstable”.

The first group is the responsibility of the Release Team, and they’re
most likely failing to migrate because of another transition (or, could
be, because of RC bugs, but in that case removal at some point would be
warranted).

The second group (which is empty in the case of libdvdread) are the ones
we can use help with. These will have RC bugs from day 0, and will be in
the list of transition blockers (http://snipr.com/transition-blockers).
Maybe once the transition is done, they should be moved to a separate
list, I don’t know. Thoughts?

Additionally, as I said in my original mail, the purpose of this is
mainly to break ties between transitions once they are ready, and by
definition a transition is not ready if still some packages are not
rebuilt in unstable. Meaning, there will be really few packages allowed
into this “second group”, if any, and removals from testing will be
preferred in that case.

Does this address your concerns?

  [1]: https://buildd.debian.org/transitions/summary.html
   (This page may move to release.debian.org eventually.)

* Don Armstrong [Mon, 16 Mar 2009 00:48:22 -0700]:

Hello, Don.

> On Sun, 15 Mar 2009, Steve Langasek wrote:
> > On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote:
> > > Now, this has its own set of problems and caveats as well, since
> > > if you don’t pay attention and take care of later cleanup, you end
> > > up with packages in testing that do not belong to any source in
> > > testing, which is bad.

> > Will there be reports produced on a regular basis of the stale
> > libraries in testing, and their reverse-dependencies, so that people
> > can easily pitch in to help with this later cleanup?

> Even better would be to turn this report into a set of bugs filed
> against the set of reverse dependencies which are made RC at the time
> that the transition migrates.

As said above, failures to build against the new library are RC from day
0, and the intention is not to do transitions while those are open,
other constraints permitting.

As for packages that are rebuilt in unstable but not migrated, I don’t
think RC bugs are approriate, since they’re not bugs in the package. We
have the above mentioned list, which I think should be enough (since I
don’t expect for those packages to remain without migrating for too long
periods of time).

> [I'm personally slightly concerned about relaxing britney allowing
> testing to get into unreleasable states; a flag to re-enable the old
> behavoir late in release would probably be good.]

In addition to what Steve explained about the inevitable necessity to
bend the rules for entangled transitions, let me clear up that this is
not any flag in britney that enables the behavior permanently or
globally. This applies to a transition on a case-by-case basis, with a
conscious decision and need for manual action. Also, it is my
expectation that the need for this will mostly disappear once we get
this first batch of transitions done.

Sounds good?

Thanks for your feedback,

-- 
- 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: Bug#466550: Pristine source from upstream VCS repository

[Stefano Zacchiroli]

On Sun, Mar 15, 2009 at 06:48:11PM -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?

My answer: yes, there is such a need.

What you are proving is that---at least for the use cases already
handled by uscan---there is no need for another _implementation_ of
that use cases.  Having a policy-prescribed debian/rules target name
that implements that is different.

In a sense, while uscan offers an implementation, the policy offer its
API. The two are complementary and I don't see why I should loose one
because of the other.

Also, having an API, offers exactly encapsulation, in the sense that
you can use uscan to implement it, but you are not forced to. What is
the problem with that? It is like *the* point I'm missing in this
whole discussion.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Steve Langasek  writes:

> On Mon, Mar 16, 2009 at 10:55:36AM +0100, Goswin von Brederlow wrote:
>> Josselin Mouette  writes:
>
>> > Le dimanche 15 mars 2009 à 01:30 +0100, Goswin von Brederlow a écrit :
>> >> Say you have acrobat reader installed which depend on ia32-libs-gtk.
>> >> You also have libgtk2.0 (i386) installed with a newer version that
>> >> breaks acrobat reader (like it did last year). Then acrobat reader
>> >> will use the newer libgtk and break despide the dependencies all being
>> >> correct.
>
>> > How is it any different from acrobat on i386 breaking when you upgrade
>> > GTK+ the same way?
>
>> Depends: ia32-libs-gtk (<= 2.6)
>
> Where is the package that does this?

Patched from marillats old package.

> How does this package know, a priori, that the next version of libgtk2.0
> will break it?  It's considered a bug if a library breaks its public
> interfaces without changing soname; consequently it would also be a bug for
> this package to second-guess libgtk.

I patched that in after the fact so I wouldn't accidentally upgrade
the system to a known broken combination. Since the acroread package
is locally build that was easier than patching libgtk to conflict with
acroread.

Anyway, my point was more the fact that it depends on *ia32-libs-gtk*
and *not* *libgtk2.0-0*. Acroread would break by something that is not
listed, directly or indirectly, as depends.

>> Also some libraries do have conffiles or binaries and will get into a
>> file conflict with or without the multiarch library path. They need a
>> Replaces/Conflicts line anyway. Chief among them libc6 (i386)
>> vs. libc6-i386.
>
> That's true, but not a reason to cause file conflicts for all the other
> biarch packages out there.

MfG
Goswin


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

Re: net-tools future

[Bjørn Mork]

Martín Ferrari  writes:

> Problematic tools:
>  * mii-tool: it could be dropped and replaced by a pointer to ethtool as
> it's not meant to be used automatically by scripts. On the other hand,
> it's distributed as a stand-alone tool [0] and we could do the same.

A couple of notes:

 mii-tool and ethtool use different driver interfaces which I'm pretty
 sure aren't completely overlapping for all drivers in the kernel

 mii-tool may not be meant for scripts, but I for one have used it in
 the past to force speed/duplex like this:

iface eth1 inet static
 address 10.122.226.9
 netmask 255.255.255.192
 up /sbin/mii-tool -F 100baseTx-FD eth1

 I'm pretty sure I'm not the only one...

 I fail to see the value of removing mii-tool.  I'd rather see just the
 non-working features removed in favour of an ethtool recommendation.



Bjørn



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

Re: Mass bugfiling in preparation for multiarch

[Josselin Mouette]

Le lundi 16 mars 2009 à 12:11 +0100, Goswin von Brederlow a écrit :
> Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf
> 
> For this I want to file bugs (on top of violations of the MUST
> directive) requesting that either the conffile is split into a
> seperate package (say you already have a libfoo and foo-bin package)
> or made unique for the target:
> /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.

Insane. This file must, of course, be moved to libgtk2.0-common instead.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

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

[Richard Atterer]

On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote:
> [I'm personally slightly concerned about relaxing britney allowing 
> testing to get into unreleasable states; a flag to re-enable the old 
> behavoir late in release would probably be good.]

Adeodato's proposal makes a lot of sense, but still I agree with the above. 
"Always in a releasable state" was a good design decision for testing, and 
this change will muddy the idea a bit further.

At the very least, there should be an auto-generated web page listing 
packages in testing that are currently unreleasable!


For a cleaner separation, testing could be split it two: The normal, 
releasable testing works according to the strict rules as before. A second, 
add-on repository (let's call it "mouldy";-) can realize Adeodato's idea: 
It is only intended to be added to sources.list _in addition to testing_, 
and contains out-of-date library packages and the programs which depend on 
them.

Rather than removing packages from testing to make way for a new 
transition, britney would move them over to "mouldy". This way, they would 
still be available. At the same time, the fact that they moved there is a 
clear sign to the respective maintainers that they need to do something to 
get their packages into a releasable state.

Once the problem is resolved, those packages which only indirectly depended 
on the library transition can be moved back from "mouldy" to testing 
without recompilation.

I can't say I'm too much of an expert with these issues, so there may be 
problems with this scheme. For example, it is possible that "mouldy" would 
end up containing everything and testing would be empty, which would buy 
you nothing. :)

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key: 888354F7
  | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC 8883 
54F7
  ¯ '` ¯


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

Re: Breaking /emul/ia32-linux for squeeze

[Simon Richter]

Hi,

On Fri, Mar 13, 2009 at 11:27:47PM -0700, Steve Langasek wrote:
> On Fri, Mar 13, 2009 at 05:57:32PM +0100, Simon Richter wrote:

> > That is actually beneficial if we wanted to merge both architectures into
> > one, which would IMO be the sanest thing to do,

> IMO that's not a sane thing to do at all.

Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
and s390/s390x. That would allow us to get rid of a lot of specianl cases,
including the hack for libc6-386.

   Simon


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

[Stefano Zacchiroli]

On Fri, Mar 13, 2009 at 09:04:30PM +0100, Raphael Hertzog wrote:
> * either we modify policy to mandate the set of environment variables that
>   dpkg-buildpackage sets

> In terms of efforts, the first solution is the easiest. But we aim
> at the _right_ solution so feel free to design something that makes
> the second solution viable.

FWIW I'd love to see the first solution implemented. My main reason,
as a maintainer of packages which mostly escape the autotools / C
language pattern, is to see written somewhere the intended semantics
in Debian of the various environment variable. That would offer an
explanation to maintainers about how to handle such variables even if
their upstreams are not using "standard" makefiles.

Regarding the objection of mandating dpkg-buildpackage as *the* tool
to build, it looks moot to me. The main point would be defining the
API and the intended meaning of variables. Then if it will happen that
dpkg-buildpackage sets them properly, let's be happy about that or
implement alternative tools.

Same goes for the configuration file objection: dpkg-buildpackage can
have one.

... and pretty please, do not choose a solution that will require
adding an "-include" to 15'000 thousands debian/rules; we will finish
doing that by Lenny+50, the earliest.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Splitting of the gnome-python* source packages - MBF

[Josselin Mouette]

Hi,

the gnome-python, gnome-python-desktop and gnome-python-extras packages
are collections of Python modules that are not necessarily related. It
was more and more requested to split them more logically, and this is
what I have done now that upstream plans are a bit clearer.

According to the changes in the binary packages, maintainers now need to
update their dependencies. The result of an automatic search of which
packages import which modules can be found on the wiki:
http://wiki.debian.org/GnomePythonSplitting
(I can provide the very ugly scripts to run on merkel to generate such
things on demand.)


1. GNOME-PYTHON

What is in unstable now:
  * python-gconf contains the gconf module
  * python-gnome2 contains the gnomevfs, gnome, gnome.ui,
gnomecanvas, and bonobo modules

What will change upstream:
  * It’s very likely that gnome-python is deprecated upstream when
GNOME 3.0 is released.
  * The gconf module will then probably move in a new source
package, as it is the only of these APIs that is not going away.

What changes to apply to Debian packages:
  * If your package only uses gconf and not the other modules, you
should switch it to only depend on python-gconf. It will
immediately reduce the list of library dependencies, and will
help reducing it further later on.
  * The python-gnome2 → python-gconf dependency will remain, so no
need to update the other packages.

I propose to file wishlist bugs on the packages that can move to using
python-gconf.

2. GNOME-PYTHON-DESKTOP

What is in unstable now:
  * Every module has been moved to its own package.
  * The python-gnome2-desktop package is now only a metapackage.

What will change upstream:
  * It’s likely that some modules will disappear (gnomeprint,
gtksourceview, nautilusburn), while most won’t.

What changes to apply to Debian packages:
  * To ease management of the multiple modules, the
python-gnome2-desktop metapackage is *going away* before the
squeeze release.
  * All packages must be updated to not depend on
python-gnome2-desktop but on the individual modules.

I propose to file important bugs on all packages depending on
python-gnome2-desktop, making them RC once the package is removed (not
until at least a few months, though).


3. GNOME-PYTHON-EXTRAS

What is happening in unstable:
  * egg.trayicon, gtkhtml2 and gtkmozembed each have their own
binary package (python-eggtrayicon, python-gtkhtml2,
python-gtkmozembed)
  * gksu 1.X is going away (nothing uses it anyway)
  * gda is going away, at least for a while
  * gtkspell will have its own binary package (currently in NEW)

What will change upstream:
  * It’s very hard to tell, these modules don’t seem to change much.
  * Most of them have better replacements, so other packages should
really get of these dependencies anyway.

What changes to apply to Debian packages:
  * To simplify the dependency tree, the dependencies of
python-gnome2-extras on python-eggtrayicon, python-gtkhtml2 and
python-gtkmozembed are going away, probably right after the
squeeze release.
  * Therefore, packages using these modules *must* be updated to use
the new binary package as dependency instead.

Bugs have already been filed for egg.trayicon, gtkhtml2 and gtkmozembed.
I propose to complete them with gtkspell bugs and to make them
important. They would become serious before the squeeze release.


LIST OF AFFECTED PACKAGES

Adam Cécile (Le_Vert) 
   exaile (U)

Nicolas FRANCOIS (Nekral) 
   virtaal

David Villa Alises 
   ows

Moray Allan 
   straw (U)

Tom Cato Amundsen 
   solfege

Michael Biebl 
   tracker

Adolfo González Blázquez 
   cameramonitor
   pyrenamer

Salvatore Bonaccorso 
   giplet

Joachim Breitner 
   infon-devel

Luca Bruno 
   freespeak

Luca Bruno 
   istanbul

Ross Burton 
   meld
   nautilus-python
   postr

Debian Bazaar Maintainers 
   bzr-gtk

Debian GNOME Maintainers 
   accerciser (U)
   deskbar-applet
   epiphany-extensions (U)
   gedit-plugins (U)
   gnome-games (U)
   hamster-applet (U)
   hotwire (U)
   meld (U)
   nautilus-python (U)
   ontv (U)
   update-manager

Debian OLPC 
   sugar
   sugar-toolkit
   sugar-web-activity

Cédric Delfosse 
   gaphor

Sebastian Dröge 
   gedit-plugins (U)
   gnome-games (U)
   ontv (U)
   service-discovery-applet

Decklin Foster 
   pygmy

Pedro Fragoso 
   hamster-applet

Gustavo Franco 
   gtimelog (U)

Romain Francoise 
   deskbar-applet (U)

François Févotte 
   exaile

Jeremy Guitton 
   ontv

Dafydd Harries 
   gtimelog (U)

Uwe Hermann 
   miro

Varun Hiremath 
   pychess

Philipp Kaluza 
   pida

Philipp Kern 
   timer-applet

Julian Andres Klode 
   gimmie

martin f. krafft 
   jppy (U)

Mario Lang 
   accerciser

Julien Lavergne 
   avant-window-navigator
   awn-extras-applets
   screenlets

Yann Leboulang

Re: Splitting of the gnome-python* source packages - MBF

[Adeodato Simó]

> Clement Lorteau 
>gtkvncviewer

I filed #518000 a while ago about this, heh. But the bug report needs
updating to say that python-gconf exists on its own, and that
gtkvncviewer should depend on that instead of python-gnome2.

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

Bug#519957: ITP: amap -- Next-generation tool for assisting network penetration testing

[Nima Talebi]

Package: wnpp
Severity: wishlist
Owner: Nima Talebi 

* Package name: amap
  Version : 5.2
  Upstream Author : van Hauser , Dj RevMoon 
* URL : http://freeworld.thc.org/thc-amap/
* License : GPL2
  Programming Lang: C
  Description : Next-generation tool for assisting network penetration 
testing

Amap is a next-generation tool for assistingnetwork penetration testing.  It
performs fast and reliable application protocol detection, independant on the
TCP/UDP port they are being bound to.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)



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

Re: Grid tasks

[Steffen Moeller]

Hi Chris,

Chris Walker wrote:
> I propose we (Debian-science) create two grid tasks packages:
> 
> Grid-client: This would contain the packages  a user workstation needs to
> submit jobs to the grid.
> 
> Grid-server: Packages for running a grid cluster. 
> 
> The globus packages recently proposed on debian-devel are obvious
> candidates. 
> 
> 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.

Candidates to look at are the Open Source cloud management infrastructure 
Eucalyptus,
UNICORE, even BOINC I would not like miss as there are several grid-savvy 
bridges built
towards and from it.

What we should possibly start with is a set of tags for the debtags initiative 
that is
grid-related.

Best,

Steffen


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

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Aurelien Jarno  writes:

> Goswin von Brederlow a écrit :
>> Aurelien Jarno  writes:
>> 
>>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
 On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
> ]] Clint Adams 
> | It may be time to change packages installing files to
> | /emul/ia32-linux (which violates the FHS) to use
> | /usr/lib32 instead.
> Could we pretty please use the multiarch paths here if we start moving
> stuff around?  We're going to need to patch gcc/binutils if we're to
> compile stuff against those paths anyway.
 What transitional issues is that going to cause us if and when multiarch
 becomes generally available, if biarch packages start using the path now?

>>> Note that i386 libc on amd64 has used once the multiarch paths. This has
>>> been reverted to the current path, because there was no clear plans
>>> about a transition to multiarch. I think this still applies.
>> 
>> You couldn't compile anything for 32bit anymore.
>> 
>>> One of the goal of multiarch is to avoid having packages containing
>>> binaries of a different architecture than the one of the package (e.g.
>>> i386 binaries in an amd64 package), in order to make packages of
>>> different architecture co-installable. If we start to break this goal,
>>> we will have packages using the multiarch path, but not co-installable,
>>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
>>> be co-installable.
>> 
>> Already broken for 2 stable releases.
>
> We are not using multiarch paths in Debian, so this has never happens.
> When using standard /usr/lib paths, people are expecting that the paths
> collide. When using multiarch they do not expect that, as it the goal of
> multiarch.

All biarch packages contain binary objects of a foreign architecture
(that is kind of the point of them). Some do contain binaries. Some
contain conffiles. One contains the dynamic loader. Prime example is
libc6 vs. libc6-i386/amd64.

Using the multiarch library path already and in biarch packages just
changes the number from 5 to 25 or thereabout.

Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
due to the dynamic linker and I believe every single biarch package
depends on the libc. So they will never be coinstallable. The question
is just how much Conflicts/Replaces are needed for the upgrade path.

>>> IMHO, we should have a clear transitional plan to multiarch before we
>>> start using multiarch path, in order to make sure we are not creating
>>> problems that has to be solved later.
>> 
>> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
>> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo
>> 
>> or
>> 
>> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
>> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs
>> 
>> Adding that will let dpkg know how to handle the transition just fine.
>
> Meaning we need to have that for each package previously available as a
> biarch package. Seems to be complicated for no real gain.
>
> Let me ask you a question: What would be the gain of using the multiarch
> path for the biarch packages?

Instead of violating the FHS we would follow a hopefully future FHS
while still violating the existing FHS. So nothing really.

I'm totaly fine with leaving the biarch packages where they are. I
would like some push behind using multiarch paths for native packages
though. Or rather I want them gone and replaced by ia32-apt-get.

> For me pushing that is the wrong way to get multiarch support in Debian.
> If we want it, we need to move the main librairies to the multiarch
> path. And it is something I proposed for glibc once we have proper gcc
> support, and a stabilised glibc 2.9. This choice still needs to be
> validated by other persons though (like the RM team).

Full ACK.

> Last but not least, what is really need to have multiarch support in
> Debian is a proper support in dpkg. They are some code already done by
> Tollef, they are some ideas floating around, but they are still some
> design decisions to be taken, and nobody has a real patch that can be
> applied to dpkg. People are pushing hard to have multiarch support, but
> no one seems to care about actually writing code.

Pre sarge we had a dpkg that could install multiarch just fine but
lacked some handholding when upgrading packages when they switched
between arch all/any. Bitrot and redesigns in dpkg have made the patch
kind of useless though and it needs to be rewritten.

As for design decisions the only ones I know are missing are all
cosmetic. They don't imapct the algorithm, just the look&feel:

1) How to specify an arch in sources.list?

Suggestion:
deb [arch=i386,amd64] http://ftp.debian.org sid main

2) How to specify a package including the architecture?

Suggestions:

Depends: foobar/i386
Conflicts: foobar [i386]
Replaces: i386-foobar
Suggests: foobar=amd64

apt-get install amd64/foobar

3) Where should dpkg put mai

Re: Breaking /emul/ia32-linux for squeeze

[Roger Leigh]

On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno  writes:
> 
> > Goswin von Brederlow a écrit :
> >> Aurelien Jarno  writes:
> >> 
> >>> One of the goal of multiarch is to avoid having packages containing
> >>> binaries of a different architecture than the one of the package (e.g.
> >>> i386 binaries in an amd64 package), in order to make packages of
> >>> different architecture co-installable. If we start to break this goal,
> >>> we will have packages using the multiarch path, but not co-installable,
> >>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
> >>> be co-installable.
> >> 
> >> Already broken for 2 stable releases.
> >
> > We are not using multiarch paths in Debian, so this has never happens.
> > When using standard /usr/lib paths, people are expecting that the paths
> > collide. When using multiarch they do not expect that, as it the goal of
> > multiarch.
> 
> All biarch packages contain binary objects of a foreign architecture
> (that is kind of the point of them). Some do contain binaries. Some
> contain conffiles. One contains the dynamic loader. Prime example is
> libc6 vs. libc6-i386/amd64.

Why can't we move the dynamic linker as well?  It's not hard-coded; it's
in the DT_INTERP section of the ELF binary.  If you have a multi-arch
/lib as well as /usr/lib, there's no reason why it's not possible to
move it (and obviously keep a symlink until everything is rebuilt).


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: Breaking /emul/ia32-linux for squeeze

[Steve Langasek]

On Mon, Mar 16, 2009 at 01:55:40PM +, Roger Leigh wrote:
> > > We are not using multiarch paths in Debian, so this has never happens.
> > > When using standard /usr/lib paths, people are expecting that the paths
> > > collide. When using multiarch they do not expect that, as it the goal of
> > > multiarch.

> > All biarch packages contain binary objects of a foreign architecture
> > (that is kind of the point of them). Some do contain binaries. Some
> > contain conffiles. One contains the dynamic loader. Prime example is
> > libc6 vs. libc6-i386/amd64.

> Why can't we move the dynamic linker as well?

Because contrary to all appearances in this thread, multiarch is not
intended to be an exercise in masochism.

-- 
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#519957: ITP: amap -- Next-generation tool for assisting network penetration testing

[Charles Plessy]

Le Mon, Mar 16, 2009 at 11:58:11PM +1100, Nima Talebi a écrit :
> 
> * Package name: amap
>   Version : 5.2
>   Upstream Author : van Hauser , Dj RevMoon 
> 
> * URL : http://freeworld.thc.org/thc-amap/
> * License : GPL2
>   Programming Lang: C
>   Description : Next-generation tool for assisting network penetration 
> testing
> 
> Amap is a next-generation tool for assistingnetwork penetration testing.  It
> performs fast and reliable application protocol detection, independant on the
> TCP/UDP port they are being bound to.

Dear Nima,

amap was included in Debian until Etch; maybe you can start your work from the
previous amap package:

http://archive.debian.org/debian/pool/main/a/amap/

We will have to discuss what to do with /usr/bin/amap, which is for the moment
used by the bioinformatic software from the package amap-align.

By the way, http://freeworld.thc.org/thc-amap/ does not seem to work.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: Breaking /emul/ia32-linux for squeeze

[Marco d'Itri]

On Mar 16, Simon Richter  wrote:

> Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
> and s390/s390x. That would allow us to get rid of a lot of specianl cases,
> including the hack for libc6-386.
I think it would be very helpful if somebody could summarize why a
multiarch system is useful, except for the obvious case of installing
proprietary i386 software on amd64 systems.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Breaking /emul/ia32-linux for squeeze

[Mike Hommey]

On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri  wrote:
> On Mar 16, Simon Richter  wrote:
> 
> > Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
> > and s390/s390x. That would allow us to get rid of a lot of specianl cases,
> > including the hack for libc6-386.
> I think it would be very helpful if somebody could summarize why a
> multiarch system is useful, except for the obvious case of installing
> proprietary i386 software on amd64 systems.

s/proprietary// ; there you have your obvious case.

Mike


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

Re: Breaking /emul/ia32-linux for squeeze

[David Bremner]

Mike Hommey wrote:

>On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri  wrote:
>> I think it would be very helpful if somebody could summarize why a
>> multiarch system is useful, except for the obvious case of installing
>> proprietary i386 software on amd64 systems.

>s/proprietary// ; there you have your obvious case.

To hopefully amplify Mike's point, I currently have a 32bit chroot to
run mozart-oz (needed for $WORK) on my amd64 desktop. I'm sure there
are many other examples. Setting up a chroot is a barrier for many
users (even if schroot and debootstrap make it fairly easy in practice
on Debian).  Of course all software should become 64bit clean
eventually, but here we are.  I suppose some motivated person could
survey all the software in the archive that is present on i386 but not
on amd64.

All the best

David




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

Re: Mass bugfiling in preparation for multiarch

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le lundi 16 mars 2009 à 12:11 +0100, Goswin von Brederlow a écrit :
>> Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf
>> 
>> For this I want to file bugs (on top of violations of the MUST
>> directive) requesting that either the conffile is split into a
>> seperate package (say you already have a libfoo and foo-bin package)
>> or made unique for the target:
>> /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.
>
> Insane. This file must, of course, be moved to libgtk2.0-common instead.

That depends on the contents of the file. In this example the file is
architecture independent so duplicating it per target is stupid.

In other cases there would be a list of available plugins for an
application. And for every target triplet the list of plugins can
differ. In those cases adding the triplet to either the dir or the
filename makes sense.

E.g. /etc/libfoo/plugins-x86_64-linux-gnu.d/

MfG
Goswin


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

Re: Breaking /emul/ia32-linux for squeeze

[Michael Poole]

m...@linux.it writes:

> On Mar 16, Simon Richter  wrote:
>
>> Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
>> and s390/s390x. That would allow us to get rid of a lot of specianl cases,
>> including the hack for libc6-386.
> I think it would be very helpful if somebody could summarize why a
> multiarch system is useful, except for the obvious case of installing
> proprietary i386 software on amd64 systems.

People who use those systems frequently could probably provide more
cases, but I know of three cases beyond running "qualified" or
"supported" 32-bit binaries on 64-bit systems):

- On platforms where the 32-bit mode is not so register-poor as i386,
  using 32-bit binaries can be significantly faster and less
  cache-disruptive than 64-bit binaries because they need less memory
  bandwidth.  Even on amd64 systems, some executables have this trait.

- Some users have code that does not function properly on systems with
  sizeof(int) != sizeof(void*).  Multiarch gives them a chance to
  migrate this code at their own pace.

- For environments with certain configuration management or regulatory
  requirements, qualifying new binaries is a considerable cost --
  having nothing to do with whether the software is "proprietary" --
  and multiarch makes it easier for them also to migrate at a pace
  that makes sense to them.

Michael Poole


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

Re: Breaking /emul/ia32-linux for squeeze

[Ian Campbell]

On Mon, 2009-03-16 at 14:36 +0100, Goswin von Brederlow wrote:
> 
> Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
> due to the dynamic linker

Really? I thought the i386 dynamic linker was /lib/ld-linux.so.2 and the
64 bit one was /lib/ld-linux-x86-64.so.2.

Ian.
-- 
Ian Campbell

Without love intelligence is dangerous;
without intelligence love is not enough.
-- Ashley Montagu


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

Re: generating man pages from docbook

[Marco d'Itri]

I never received an answer from the docbook-to-man maintainers, so
I switched to docbook-utils which works correctly but I found out is
uninstallable on four architectures. What should I do?
Maybe the jadetex dependency should be downgraded to Recommends since
it's only needed for some output formats anyway?

https://buildd.debian.org/build.php?pkg=module-init-tools

On Mar 04, md wrote:

> - Forwarded message from md -
> 
> To: pben...@uni-osnabrueck.de
> Cc: debian-xml-sgml-p...@lists.alioth.debian.org
> Subject: Escape backslashes in the man pages
> User-Agent: Mutt/1.5.19 (2009-01-05)
> 
> Please advise. What should I use to build this document?
> 
>Debian GNU/Linux">
>   DocBook">
>   SGML">
> ]>
> 
> - Forwarded message from Michal Marek  -
> 
> From: Michal Marek 
> To: Marco d'Itri 
> Cc: mit-de...@lists.printk.net
> Subject: Re: [Mit-devel] Escape backslashes in the man pages
> User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
> 
> Marco d'Itri napsal(a):
> > Escape backslashes in the man pages.
> >
> > --- a/doc/depmod.conf.sgml
> > +++ b/doc/depmod.conf.sgml
> > @@ -42,7 +42,7 @@
> >  
> >The format of depmod.conf and files under 
> > depmod.d is simple: one
> >command per line, with blank lines and lines starting with #
> > -  ignored (useful for adding comments).  A \ at the end of a line
> > +  ignored (useful for adding comments).  A \\ at the end of a line
> 
> Which conversion tool do you use to generate the manpages? docbook2man
> from docbook-utils correctly escapes the backslashes and applying your
> patch results in '' in the roff source.
> 
> Michal
> 
> 
> ___
> Mit-devel mailing list
> mit-de...@dmesg2.printk.net
> http://dmesg2.printk.net/cgi-bin/mailman/listinfo/mit-devel
> 
> - End forwarded message -
> 
> -- 
> ciao,
> Marco
> 
> - End forwarded message -
> 
> -- 
> ciao,
> Marco

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

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

> On Mar 16, Simon Richter  wrote:
>
>> Well, it would get i386/amd64 in line with sparc/sparc64, powerpc/powerpc64
>> and s390/s390x. That would allow us to get rid of a lot of specianl cases,
>> including the hack for libc6-386.

I don't see sparc/sparc64, powerpc/powerpc64, mips/mips64/mipsn32,
mipsel/mips64el/mipsn32el sparc/sparc64, powerpc/powerpc64, s390/s390x
or arm/armel/armebai as having solved the multiarch problem.

Except maybe s390x as the s390 port seems to want to drop 31 bit
support and go completly 64bit.

> I think it would be very helpful if somebody could summarize why a
> multiarch system is useful, except for the obvious case of installing
> proprietary i386 software on amd64 systems.
>
> -- 
> ciao,
> Marco

So I can have a 64bit mysql or postgres for my huge collection of
porn on my mipsel system.

So I can install a 32bit gcc on my amd64 as that eats half the ram
compared to the 64bit one while keeping a 64bit gzip as that runs 20%
faster.

So I can install wine on my amd64 without the maintainer having to
include a prebuild wine in the wine source.

So I can get rid of all the biarch packages that are quite ugly and
only work 75% right.

So I can install a linux iceweasel and flash plugin on freebsd.

So I can install and compile against 32bit uclibc packages on my amd64
and use the results on my i386 based netapp fileserver.

And then it should cover cross-compiling as well for all those that
want to build packages for their embedded arm boxes.

And as an extra gimmick it would allow upgrading a i386 lenny to amd64
squeeze.


Note that 7345 out of 16030 (46%) reported amd64 systems have
ia32-libs installed. 4453 (28%) also have ia32-libs-gtk installed.
So even just "proprietary i386 software on amd64" is a huge chunk of
debian user. And those numbers will more likely go up than down as
i386 users overcome their fear of updating to amd64.

MfG
Goswin


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

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Roger Leigh  writes:

> On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
>> Aurelien Jarno  writes:
>> 
>> > Goswin von Brederlow a écrit :
>> >> Aurelien Jarno  writes:
>> >> 
>> >>> One of the goal of multiarch is to avoid having packages containing
>> >>> binaries of a different architecture than the one of the package (e.g.
>> >>> i386 binaries in an amd64 package), in order to make packages of
>> >>> different architecture co-installable. If we start to break this goal,
>> >>> we will have packages using the multiarch path, but not co-installable,
>> >>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
>> >>> be co-installable.
>> >> 
>> >> Already broken for 2 stable releases.
>> >
>> > We are not using multiarch paths in Debian, so this has never happens.
>> > When using standard /usr/lib paths, people are expecting that the paths
>> > collide. When using multiarch they do not expect that, as it the goal of
>> > multiarch.
>> 
>> All biarch packages contain binary objects of a foreign architecture
>> (that is kind of the point of them). Some do contain binaries. Some
>> contain conffiles. One contains the dynamic loader. Prime example is
>> libc6 vs. libc6-i386/amd64.
>
> Why can't we move the dynamic linker as well?  It's not hard-coded; it's
> in the DT_INTERP section of the ELF binary.  If you have a multi-arch
> /lib as well as /usr/lib, there's no reason why it's not possible to
> move it (and obviously keep a symlink until everything is rebuilt).

We can not change the location of the interpreter recorded in the elf
without loosing all compatibility with other linux distributions.
Getting everyone to change might be possible eventually but that will
take more than 1 debian stable cycle.

That asside we need the link for compatibility during the
transition. And the link will collide just as badly as the file
does. So you have won nothing. And that is not just while everything
is being rebuild. It needs to be there during stable->new stable
upgrades too. So squeeze+1 is the first the link could disapear.

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

[Manoj Srivastava]

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.

In the non-snippet method proposed, there is no way for the
 package maintainer to override project defaults yet cater user set
 variable settings, since the information is lost.

Also, I think that just CFLAGS is probably too broad, I might
 want to override only some of the categories of flags (optimization,
 machine related, warning, debugging, etc) and not others; pulling
 warning and optimization out as separate subflags might be a good
 compromise.

All of this can be done with Makefile snippets, and do not allow
 you to mandate any set of tools, without which the environment set
 would be different. You can use dpkg-vuildpackage, $MAKE) -f
 deban/rules, write a wrapper Makefile that include ./debian/rules -- it
 all would just work.

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.

manoj
-- 
s = (char*)(long)retval; /* ouch */ Larry Wall in doio.c from the perl
source code
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Processed: Re: Processed: Re: Bug#519902: Dist-upgrade to lenny broke cvs and apt, cannot recover.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 519902 upgrade-reports
Bug#519902: Dist-upgrade to lenny broke cvs and apt, cannot recover.
Bug reassigned from package `general' to `upgrade-reports'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Breaking /emul/ia32-linux for squeeze

[Stephen Gran]

This one time, at band camp, Goswin von Brederlow said:
> 1) How to specify an arch in sources.list?

Don't.  Specify it in apt.conf

> Suggestion:
> deb [arch=i386,amd64] http://ftp.debian.org sid main

APT::Arches "i386,amd64"

Or something.

> 2) How to specify a package including the architecture?
> 
> Suggestions:
> 
> Depends: foobar/i386
> Conflicts: foobar [i386]
> Replaces: i386-foobar
> Suggests: foobar=amd64

Eww.  What's the matter with debs and the tools knowing a package is
i386, and making the assumption that all it's dependencies are i386?
Put another way, I can't think of a valid use for an amd64 binary
depending on a ppc32 binary.

> apt-get install amd64/foobar

Fine.  Or maybe --arch amd64.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: generating man pages from docbook

[Hilmar Preusse]

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

Hi,

> I never received an answer from the docbook-to-man maintainers, so
> I switched to docbook-utils which works correctly but I found out is
> uninstallable on four architectures. What should I do?
> 
Hmm, weird. jadetex is architecture all and haven't changed for a
while. Could you find out, why it can't be installed?

> https://buildd.debian.org/build.php?pkg=module-init-tools
> 
Checking for source dependency conflicts...
  /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install 
debhelper quilt docbook-utils
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  docbook-utils: Depends: jadetex but it is not going to be installed
E: Broken packages

H.
-- 
Psychoanalysis is that mental illness for which it regards itself a therapy.
-- Karl Kraus
  http://www.hilmar-preusse.de.vu/


-- 
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 Mon, Mar 16 2009, Stefano Zacchiroli wrote:


> In a sense, while uscan offers an implementation, the policy offer its
> API. The two are complementary and I don't see why I should loose one
> because of the other.
>
> Also, having an API, offers exactly encapsulation, in the sense that
> you can use uscan to implement it, but you are not forced to. What is
> the problem with that? It is like *the* point I'm missing in this
> whole discussion.

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.

manoj
-- 
You get what you pay for. Gabriel Biel
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

[Manoj Srivastava]

On Mon, Mar 16 2009, Raphael Hertzog wrote:

> On Mon, 16 Mar 2009, Bdale Garbee wrote:
>> 
>> > I think he ment that you can not know wether the setting comes from
>> > dpkg-buildpackage or the user. If it comes from dpkg-buildpackage then
>> > debian/rules should be free to override it as needed. If it comes from
>> > the user then that is another story. At least that is my take on it.
>> 
>> This is a great point.  It must be possible to craft a rules file that 
>> overrides 
>> system or distribution wide defaults and which can be over-ridden by an 
>> individual 
>> building the package.
>
> I don't see why it's needed, it's the job of the rules file to adjust the
> flags if there's a reason to deviate (like using -O0 instead of -O2 for
> some arch with compiler problems) but in general the package should not
> override completely the default flags but just complete them and/or
> adjust/fix them if needed.

But while overriding the project wide default makes sense,
 overriding the human doing hte building does not.

>
> However, if the caller really wish that his build options prevail in
> all cases, he can use "make -e" (and dpkg-buildpackage has the -R
> option that let him call "debian/rules" as "make -e -f debian/rules"
> instead).

We do not want to override *EVERYTHING* in the Makefile, just
 the CFLAGS.  This blunt instrument of the -e flag is not a good
 solution. 

> If necessary we can add a new option --force-flags to dpkg-bp or similar
> to make this even easier.

Making a bad solution easy is not a good thing either.

>> That seems to require the ability for the code in a rules file to
>> distinguish between things in the environment because they're defaults
>> and things in the environment that are attempting to override defaults.
>
> Apparently there's no way to know from where the variable value come in
> make. That's true for environment variables like for command line
> variables.
> (at least according to my lookup of info make)

Err, I think you need to get more conversant with Make. Yes,
 there is no way to know whether or not the environment variables were
 set by dpkg or the user; but it is itrivial to make it so that the
 project wide defaults can be overridden by the site wide stuff, and
 each being overridden by the package at will. We can even make it so
 that the package can tell which one set the value, and override only
 the project wide one and not the site variable.

> So if we really want the rules files to be able to know, we have to
> add yet another requirement to create this information. This is not
> desirable IMO.

Given how trivial it is, I think it is eminently desirable. It
 is just that dpkg is not the right place for such subtleties.

manoj
-- 
Though many hands make light work, too many cooks spoil the broth.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
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 Mon, 16 Mar 2009, Manoj Srivastava wrote:
> In the non-snippet method proposed, there is no way for the
>  package maintainer to override project defaults yet cater user set
>  variable settings, since the information is lost.

You're not trying very hard to look from both sides: whether the default
value comes from the environment or from an included Makefile, in both
cases the user can override it with command-line arguments.

Granted it means that dpkg-buildpackage would have to pass user-overriden
flags on the command line instead of using the environment, but that can
be done if people really want this possibility.

So the policy would mandate a set of variables that could be communicated
either via the environment or via the command-line depending on how
authoritative the user wants to be.

That would be fine for me too.

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: generating man pages from docbook

[Marco d'Itri]

On Mar 16, Hilmar Preusse  wrote:

> Hmm, weird. jadetex is architecture all and haven't changed for a
> while. Could you find out, why it can't be installed?
I hoped that somebody here would tell me...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: generating man pages from docbook

[Norbert Preining]

On Mo, 16 Mär 2009, Marco d'Itri wrote:
> On Mar 16, Hilmar Preusse  wrote:
> > Hmm, weird. jadetex is architecture all and haven't changed for a
> > while. Could you find out, why it can't be installed?
> I hoped that somebody here would tell me...

Aehm sorry I lost this track completely. Can someone bring me on top
what I should look into?

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
DRAFFAN (n.)
An infuriating person who always manages to look much more dashing
that anyone else by turning up unshaven and hangover at a formal
party.
--- Douglas Adams, The Meaning of Liff


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

Re: generating man pages from docbook

[Adeodato Simó]

* Norbert Preining [Mon, 16 Mar 2009 18:24:15 +0100]:

> On Mo, 16 Mär 2009, Marco d'Itri wrote:
> > On Mar 16, Hilmar Preusse  wrote:
> > > Hmm, weird. jadetex is architecture all and haven't changed for a
> > > while. Could you find out, why it can't be installed?
> > I hoped that somebody here would tell me...

> Aehm sorry I lost this track completely. Can someone bring me on top
> what I should look into?

jadetex is uninstallable on arches where texlive-bin is not available
yet rebuilt against libpoppler4. Which is only s390, which is waiting
for an upload.

I’ve given back module-init-tools and set dep-waits as appropriate.

-- 
- 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: generating man pages from docbook

[Norbert Preining]

On Mo, 16 Mär 2009, Adeodato Simó wrote:
> jadetex is uninstallable on arches where texlive-bin is not available
> yet rebuilt against libpoppler4. Which is only s390, which is waiting
> for an upload.

Ok, I can live with that. If there are more fundamental problems with
s390 please ask again. 

But that is probably a libpoppler problem not being compiled, thus a
texlive problem not being compiled. Sorry, poppler *is* a pain.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
BURLINGJOBB
A seventeenth-century crime by which excrement is thrown into the
street from a ground-floor window.
--- Douglas Adams, The Meaning of Liff


-- 
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 Mon, 16 Mar 2009, Manoj Srivastava wrote:
> > However, if the caller really wish that his build options prevail in
> > all cases, he can use "make -e" (and dpkg-buildpackage has the -R
> > option that let him call "debian/rules" as "make -e -f debian/rules"
> > instead).
> 
> We do not want to override *EVERYTHING* in the Makefile, just
>  the CFLAGS.  This blunt instrument of the -e flag is not a good
>  solution. 

Then he can add the required parameter on the command line instead
of using the environment.

make -f debian/rules CFLAGS="..." 

You don't seem to grasp the fact that mandating some variables to be
preset doesn't forbid us to rely on Makefile features if we chose to.

> > Apparently there's no way to know from where the variable value come in
> > make. That's true for environment variables like for command line
> > variables.
> > (at least according to my lookup of info make)
> 
> Err, I think you need to get more conversant with Make. Yes,
>  there is no way to know whether or not the environment variables were
>  set by dpkg or the user; but it is itrivial to make it so that the
>  project wide defaults can be overridden by the site wide stuff, and
>  each being overridden by the package at will. We can even make it so
>  that the package can tell which one set the value, and override only
>  the project wide one and not the site variable.

It is trivial to do with whatever solution we retain. The problematic part
that I pointed out is "how to know in the rules file if the CFLAGS value
comes from the command-line, from the environment or from the makefile
itself".

Do you have a solution to that ? If no, then there was no point in
suggesting me to get more conversant with Make. If yes, show it to
me.

Suppose you have "FOO ?= bar" in the Makefile, write me the rest of the
Makefile so that I have this:
$ FOO=foo make
FOO was set in the environment
$ make FOO=foo
FOO was set on the command-line
$ make
FOO was set in the Makefile

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

[Manoj Srivastava]

On Mon, Mar 16 2009, Raphael Hertzog wrote:

> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> In the non-snippet method proposed, there is no way for the
>>  package maintainer to override project defaults yet cater user set
>>  variable settings, since the information is lost.
>
> You're not trying very hard to look from both sides: whether the default
> value comes from the environment or from an included Makefile, in both
> cases the user can override it with command-line arguments.
>
> Granted it means that dpkg-buildpackage would have to pass user-overriden
> flags on the command line instead of using the environment, but that can
> be done if people really want this possibility.
>
> So the policy would mandate a set of variables that could be communicated
> either via the environment or via the command-line depending on how
> authoritative the user wants to be.
>
> That would be fine for me too.

That still fails on two points:
 a) Not using dpkg would mean different build environments
 b) there is no way for a site or buildd admin to provide site wide
defaults that override dpkg ones but the user can override

Also, a dding new project wide builkd defaults is tied to dpkg
 development and releases (which is not really a great idea either


manoj
-- 
"...a most excellent barbarian ... Genghis Kahn!" _Bill And Ted's
Excellent Adventure_
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

[James Vega]

On Mon, Mar 16, 2009 at 06:37:40PM +0100, Raphael Hertzog wrote:
> Suppose you have "FOO ?= bar" in the Makefile, write me the rest of the
> Makefile so that I have this:
> $ FOO=foo make
> FOO was set in the environment
> $ make FOO=foo
> FOO was set on the command-line
> $ make
> FOO was set in the Makefile

$ cat Makefile
FOO ?= bar
all:
ifeq "$(origin FOO)" "command line"
$(info "FOO was set on the command-line")
endif
ifeq "$(origin FOO)" "environment"
$(info "FOO was set in the environment")
endif
ifeq "$(origin FOO)" "file"
$(info "FOO was set in the Makefile")
endif

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

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

[Raphael Geissert]

Steve Langasek wrote:

> On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote:
> 
>> [I'm personally slightly concerned about relaxing britney allowing
>> testing to get into unreleasable states; a flag to re-enable the old
>> behavoir late in release would probably be good.]
> 
> In practice, the release team has to do this at various points in the
> release cycle anyway because the transitions become so entangled that
> breaking something in testing, or removing a bunch of packages that we
> intend to release with, are the only options.  This approach at least
> ensures that testing will remain installable and (presumably) useful
> during the rocky transitions, merely requiring a bit of cleanup of old
> packages.
> 

Wouldn't it be better to remove the packages from testing? this way if the
library and other packages are ready to go they could easily migrate
without any special hack, if my understanding of the situation is correct.
This change would not affect users of the removed packages, because unless
the new library conflicts the old one, no package would break on installed
systems.
This schema is more or less what Richard Atterer is proposing, but instead
of solving the transition on the archive, it would be happening on the
user's machines.

What do you think?

Whatever happens, thanks for your work! :)

Cheers,
Raphael Geissert



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

Re: toolame: remove from unstable, update in stable

[Cyril Brulebois]

Fabian Greffrath  (16/03/2009):
> Unfortunately IANADD, so I cannot modify the wiki page on my own.

Yes, you can!

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Bill Allombert]

On Mon, Mar 16, 2009 at 09:14:32AM +0100, Raphael Hertzog wrote:
> On Sun, 15 Mar 2009, Stephen Gran wrote:
> > This one time, at band camp, Raphael Hertzog said:
> > > Care to elaborate what kind of flexibility you need in this specific case 
> > > ?
> > 
> > I don't.  I'm imagining that some of our downstreams may.
> 
> It's precisely one of our downstreams that pushed the
> dpkg-buildpackage change (Ubuntu). I don't think most downstreams
> care a lot about the exact implementation, but they clearly want
> a way to alter defauld build flags at the distribution level.

I do not see a need for dpkg-buildpackage to set CFLAGS etc. in the environment
*by default*. What is needed instead is a policy spelling how a package should
react when a particular variable is set in the environment. If the variable
is unset the package should be built the default way.

This would still allow downstream to set them (and objectively, nothing has
ever prevented downstream to set them in the first place).

At this point it seems clear to me that:
1) dpkg-buildpackage should be changed not to set CFLAGS etc. by default.
2) we need to document how packages are supposed to behave should CFLAGS etc.
be set in the environment at build-time
3) dpkg-buildpackage should provide a configurable way to set CFLAGS etc. to
some values if this is considered useful.

dpkg-buildpackage setting CFLAGS per default is both useless and harmful.
On the other hand, this proposal still allow downstream to use
dpkg-buildpackage in the same way as with lenny, and preserve the same level of
functionality

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

Bug#519993: ITP: wbar -- a light and fast launch bar

[Krzysztof Burghardt]

Package: wnpp
Severity: wishlist
Owner: Krzysztof Burghardt 

* Package name: wbar
  Version : 1.3.3
  Upstream Author : Rodolfo Granata 
* URL : http://code.google.com/p/wbar/
* License : GPL
  Programming Lang: C++
  Description : a light and fast launch bar

wbar is a quick launch bar. Its fast, light and cool eye-candy.
..
Initially developed for Fluxbox, then tested on WindowMaker, Xfce,
Gnome, etc.
..
It can run on top of desktops such as xfdesktop or nautilus with
the -above-desk switch.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



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

> You're not trying very hard to look from both sides: whether the default
> value comes from the environment or from an included Makefile, in both
> cases the user can override it with command-line arguments.
>
> Granted it means that dpkg-buildpackage would have to pass
> user-overriden flags on the command line instead of using the
> environment, but that can be done if people really want this
> possibility.

I think it's clearly mandatory to implement a hierarchy of settings:

* Debian defaults
* Local distribution overrides
* Local package overrides
* User settings

where each overrides the previous ones.

Personally, I'd rather see this done via an included make fragment.  I
think the logic in debian/rules is simpler in that case, and I don't agree
with the argument that it's that much harder to implement than relying on
environment variables.  In practice, huge numbers of Debian packages
already unconditionally set CFLAGS in debian/rules and hence override any
environment variable settings.  All those packages are going to have to be
modified anyway.  I don't see a way of meaningfully deploying this change
without modifying most of the archive.

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

[Manoj Srivastava]

On Mon, Mar 16 2009, Raphael Hertzog wrote:

> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> > However, if the caller really wish that his build options prevail in
>> > all cases, he can use "make -e" (and dpkg-buildpackage has the -R
>> > option that let him call "debian/rules" as "make -e -f debian/rules"
>> > instead).
>> 
>> We do not want to override *EVERYTHING* in the Makefile, just
>>  the CFLAGS.  This blunt instrument of the -e flag is not a good
>>  solution. 
>
> Then he can add the required parameter on the command line instead
> of using the environment.
>
> make -f debian/rules CFLAGS="..." 
>
> You don't seem to grasp the fact that mandating some variables to be
> preset doesn't forbid us to rely on Makefile features if we chose to.

Heh. I never thought I would be lectured on the use of make. Cute.

And you are missing the point that making people type stuff on
 the command line for site specific stuff looses out to being able to
 edit a conffile instead. 

dpkg might suffice if we were not wanting the ability to set
 site wide build defaults a la gentoo use flags -- but it seems silly to
 give up on that i we are designing a solution now.

>> > Apparently there's no way to know from where the variable value come in
>> > make. That's true for environment variables like for command line
>> > variables.
>> > (at least according to my lookup of info make)
>> 
>> Err, I think you need to get more conversant with Make. Yes,
>>  there is no way to know whether or not the environment variables were
>>  set by dpkg or the user; but it is itrivial to make it so that the
>>  project wide defaults can be overridden by the site wide stuff, and
>>  each being overridden by the package at will. We can even make it so
>>  that the package can tell which one set the value, and override only
>>  the project wide one and not the site variable.
>
> It is trivial to do with whatever solution we retain. The problematic part
> that I pointed out is "how to know in the rules file if the CFLAGS value
> comes from the command-line, from the environment or from the makefile
> itself".

> Do you have a solution to that ? If no, then there was no point in

Of course I do. 


> suggesting me to get more conversant with Make. If yes, show it to
> me.

*Sigh*. 

--8<---cut here---start->8---
File: make.info,  Node: Origin Function,  Next: Flavor Function,  Prev:
Eval Function,  Up: Functions 
--8<---cut here---end--->8---

This is precisely what the origin function is for.


Also, you might not need it with the snippet example:

--8<---cut here---start->8---
default_foo := BAR
site_foo := baz  # by default, this is empty -- set by site admin

ifndef (,$(strip $(site_foo)))
 foo = $(site_foo)
else
 foo = $(default_foo)
endif
--8<---cut here---end--->8---

Now the variable foo is set, but we can tell it was set in a
 makefile, and set by default or the site admin. And make a decision in
 the rules file based on that. (Note the use of := versus = above; the
 difference is significant, really).

We can also tell if a variable was set in the environment, or
 the command line -- but the whole include makefile snippet means we do
 not have to replicate what dpkg does on the command line if we do not
 want to use  that single point of entry.


> Suppose you have "FOO ?= bar" in the Makefile, write me the rest of the
> Makefile so that I have this:
> $ FOO=foo make
> FOO was set in the environment
> $ make FOO=foo
> FOO was set on the command-line
> $ make
> FOO was set in the Makefile

Goodness me.

manoj
-- 
The world is coming to an end ... SAVE YOUR BUFFERS!!!
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: generating man pages from docbook

[Hilmar Preusse]

On 16.03.09 Adeodato Simó (d...@net.com.org.es) wrote:
> * Norbert Preining [Mon, 16 Mar 2009 18:24:15 +0100]:
> > On Mo, 16 Mär 2009, Marco d'Itri wrote:
> > > On Mar 16, Hilmar Preusse  wrote:

Hi,

> > > > Hmm, weird. jadetex is architecture all and haven't changed for a
> > > > while. Could you find out, why it can't be installed?
> > > I hoped that somebody here would tell me...
> 
> > Aehm sorry I lost this track completely. Can someone bring me on top
> > what I should look into?
> 
> jadetex is uninstallable on arches where texlive-bin is not available
> yet rebuilt against libpoppler4. Which is only s390, which is waiting
> for an upload.
> 
...however in the moment it seems not to be fault of poppler not to
be available. I guess the only thing we can do is waiting.

H.
-- 
Whatever doesn't succeed in two months and a half in California will
never succeed.
-- Rev. Henry Durant, founder of the University of California
  http://www.hilmar-preusse.de.vu/


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

Re: Bug#518494: ITP: pythm -- media players (e.g. mpd, gstreamer, mplayer) GUI frontend

[Yaroslav Halchenko]

I am sorry Luca that I have missed your email. Looking at it now I
realize that it came at the hottest time -- I was about to submit my
PhD dissertation, so my mind was fully occupied with other things ;)


> On Fri, 06 Mar 2009 16:25:16 +0100, Yaroslav Halchenko wrote:
> > * Package name: pythm
> >   Version : 0.5.5-dmr (fork developed by Dylan)
> >   Upstream Author : Matthias Hans , Dylan Reilly 
> > , and others ;)
> > * URL : http://github.com/negi/pythm/tree/master
> What are the advantages of this one WRT the original project [1]?  Is

original project is dead (or at least stale for quite a while) as
far I can see that.

besides a variety of cosmetic/UI changes, this fork brings
gstreamer backend which might be a preferable one for FR (hence it is
the default one iirc)

> there any chance that development on the original project will continue?
there is always some degree of chance for anything. 
But I can probably say that it is very unlikely
If it does continue, I don't see any reason why our fork should not be
considered for merge ;)

> In this case, I would say that the fork should not be packaged with the
> original name.
yeah -- I had such doubts as well; but atm there is no original pythm
development, and not sure if it would ever come back.

There is though another fork by Paul TT. We adopted some of his changes
(GUI) but not all.

To summarize -- I would stick with pythm name until original author does
not come up and claim his trademark ;)

> > Pythm (Python + Rhythm) is a media player frontend, designed to
> > control gstreamer, mplayer or mpd with one GUI on mobile devices such
> > as OpenMoko's FreeRunner.
>  ^
> Do you mind maintaining your package under the pkg-fso umbrella [2],
> which is the team behind any Debian effort for Openmoko devices?
not at all... and actually that is what I was asking for in the other
recent email. I will apply for membership within pkg-fso on alioth, so I
could upload.

Cheers
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




signature.asc
Description: Digital signature

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

[Manoj Srivastava]

On Mon, Mar 16 2009, Russ Allbery wrote:

> Raphael Hertzog  writes:
>
>> You're not trying very hard to look from both sides: whether the default
>> value comes from the environment or from an included Makefile, in both
>> cases the user can override it with command-line arguments.
>>
>> Granted it means that dpkg-buildpackage would have to pass
>> user-overriden flags on the command line instead of using the
>> environment, but that can be done if people really want this
>> possibility.
>
> I think it's clearly mandatory to implement a hierarchy of settings:
>
> * Debian defaults
> * Local distribution overrides
> * Local package overrides
> * User settings
>
> where each overrides the previous ones.

We can do better than that with the Make snippets.

Say, as an user, I think my admin is nuts, and I want o
 override his setting, and revert to the project wide default, for all
 packages I build on this machine. Easy (just set site_foo in the env,
 call debian/rules with -e).

Or, as an admin, I want to always override the project wide
 settings (hey, I like hardening flags), but on some machines I have
 taken time out to set up site wide defaults -- and I do not want to
 over ride those. Again, easy to do with the example snippet I posted.

All kinds of flexibility become ours once we embrace toe
 sour^H^H^Hsnippets, I mean.

> Personally, I'd rather see this done via an included make fragment.  I
> think the logic in debian/rules is simpler in that case, and I don't
> agree with the argument that it's that much harder to implement than
> relying on environment variables.  In practice, huge numbers of Debian
> packages already unconditionally set CFLAGS in debian/rules and hence
> override any environment variable settings.  All those packages are
> going to have to be modified anyway.  I don't see a way of
> meaningfully deploying this change without modifying most of the
> archive.

The advantage of the snippet approach is where packages might
 break if the builtin defaults are changed will not be broken by the
 snippet approach, since the change is opt-in.

manoj
-- 
It is a city built of bones, and daubed with flesh and blood, in which
old age and death, pride and hypocrisy are the inhabitants. 150
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

DebianWiki migrated

[Frank Lin PIAT]

Hi all,

Wiki engine migrated


The DebianWiki team is pleased to announce that the wiki is now running
moinmoin 1.7, which brings many new features (see [1] and [2]).

The syntax on how to make links and use attachments have changed in
moinmoin 1.6, see:
 http://wiki.debian.org/HelpOnMoinWikiSyntax
 http://wiki.debian.org/HelpOnEditing

Also, the GUI editor is now disabled, because moinmoin 1.7 use an old 
version of fckeditor which would have been a security problem. We are
working to find a solution.


Hosting sponsor
===

The wiki is hosted on a new machine. The hardware and bandwith are 
sponsored by Dembach Goo Informatics [3].


Secure https access
===

You can now use https to securely sign into the wiki.

When you publish an URL (in mailing list, bug reports...), we recommend
that you do not post https URL (to avoid "untrusted" SSL certificates
problems)


Misc Hints and Tips
===

* The wiki.debian.org/Teams/${team} is a good place to get new
  contributors...
  A "News" section is a good idea (with links to "Bits
  from $FooBar team" and some interesting threads on the mailing
  list, like squeeze road-map)

* If you link to your wiki page from some Debian material (alioth,
  documentation, package...), then add the page to the category
  "CategoryPermaLink" so we can prevent 404s, also make sure use
  use http link (i.e not https).

* Subscribe to the pages that matters to you, so you are notified
  of contributions.


Thanks to the DDs that handled the hard work migrating the wiki (pabs,
luca and zobel).


... Stay tuned for more bits from DebianWiki, regarding the theme (CSS)
and License.

Franklin

[1] http://moinmo.in/MoinMoinRelease1.6
[2] http://moinmo.in/MoinMoinRelease1.7
[3] http://www.dg-i.net/


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

> I think it's clearly mandatory to implement a hierarchy of settings:
> 
> * Debian defaults
> * Local distribution overrides
> * Local package overrides
> * User settings
> 
> where each overrides the previous ones.

I think we all mostly agree on that. I see only two remarks:
- the package can either fully override the default settings or
  filter the provided build options: i.e. add/remove/replace build
  options. (and I think that the "filter" option should be the recommended
  approach)
- the user should also be able to provide a default build option that the
  package can override in case the user wants to trust the
  maintainer's opinion on what build options are sane or not for this
  specific package (it might allow him to have a better success rate if you
  want to recompile lots of packages with some options that are known to
  not work in some cases)
  
Do we want that hierarchy set in stone in policy or do we simply
want to define how the rules file is supposed to retrieve the relevant
build options ?

What would the policy change look like if we select the Makefile snippet
approach ?

> In practice, huge numbers of Debian packages already unconditionally set
> CFLAGS in debian/rules and hence override any environment variable
> settings.  All those packages are going to have to be modified anyway.
> I don't see a way of meaningfully deploying this change without
> modifying most of the archive.

It would be nice to have figures here.

Note that we have packages switching to debhelper 7 rules files as
simple as /usr/share/doc/debhelper/examples/rules.tiny so the number of
packages explicitely setting CFLAGS might drop.

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

[Raphael Hertzog]

On Mon, 16 Mar 2009, Manoj Srivastava wrote:
> The advantage of the snippet approach is where packages might
>  break if the builtin defaults are changed will not be broken by the
>  snippet approach, since the change is opt-in.

Once a package relies on values provided by a Makefile snippet, it might
also break when the values provided by the snippet change. Otherwise we
lose the advantage of facilitating distribution-wide changes of default
build options.

I don't see how you reconcile everything.

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: DebianWiki migrated

[Frank Lin PIAT]

On Mon, 2009-03-16 at 21:29 +0100, Frank Lin PIAT wrote:
> 
> Wiki engine migrated
> 

I completely forgot to thanks and give credits to Valessio Brito for his
DebianWiki logo.

 http://wiki.debian.org/htdocs/WikiDebianLogo_B.png

This is now fixed.

Regards,

Franklin


-- 
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 Mon, 16 Mar 2009, Manoj Srivastava wrote:
> And you are missing the point that making people type stuff on
>  the command line for site specific stuff looses out to being able to
>  edit a conffile instead. 

Who said the command line was for site-specific stuff?

In my proposition the hierarchy could be something like this:
- distribution default (encoded in dpkg-buildpackage or in a /etc/dpkg/origins/ 
file)
- site-specific (/etc/dpkg/dpkg-buildpackage.conf)
- package specific (inside debian/rules)
- user specific (command line options)

In my opinion, the origin of the variable is not important, the only
important part is to specifiy in policy how the value is communicated to
the rules file.

> > Do you have a solution to that ? If no, then there was no point in
> 
> Of course I do. 
> This is precisely what the origin function is for.

Then it would have been nice to point it out directly instead of making
fun of me while I made it clear that I have read the whole section about
variables (where there was no reference to this origin 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: Breaking /emul/ia32-linux for squeeze

[Tollef Fog Heen]

]] Stephen Gran 

| Put another way, I can't think of a valid use for an amd64 binary
| depending on a ppc32 binary.

Package: foo
Depends: sed

(sed is Essential: yes, but I think you get the point.)

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


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

Re: Mass bugfiling in preparation for multiarch

[Aurelien Jarno]

On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote:
> Hi,
> 
> over the weekend I did some work on multiarch again and did notice
> some new and old problems when adding more libraries to my test set.
> 
> Given that the problems are quite easily detectable I'm considering
> scanning all packages for their occurance and reporting bugs for them.
> In detail I'm looking for the following situations violating 'Policy
> 8.2 Shared library support files':
> 

[snip]

> Any objections to this? Note that most will be violations of a MUST
> directive of policy.
> 

If you want to get some more multiarch ennemies, this is clearly the
way to go.

The alternate method is to post a list to debian-devel, and when we have 
a basic multiarch support, you may start thinking about filling bugs.
Not before.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Breaking /emul/ia32-linux for squeeze

[Aurelien Jarno]

On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno  writes:
> 
> > Goswin von Brederlow a écrit :
> >> Aurelien Jarno  writes:
> >> 
> >>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
>  On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
> > ]] Clint Adams 
> > | It may be time to change packages installing files to
> > | /emul/ia32-linux (which violates the FHS) to use
> > | /usr/lib32 instead.
> > Could we pretty please use the multiarch paths here if we start moving
> > stuff around?  We're going to need to patch gcc/binutils if we're to
> > compile stuff against those paths anyway.
>  What transitional issues is that going to cause us if and when multiarch
>  becomes generally available, if biarch packages start using the path now?
> 
> >>> Note that i386 libc on amd64 has used once the multiarch paths. This has
> >>> been reverted to the current path, because there was no clear plans
> >>> about a transition to multiarch. I think this still applies.
> >> 
> >> You couldn't compile anything for 32bit anymore.
> >> 
> >>> One of the goal of multiarch is to avoid having packages containing
> >>> binaries of a different architecture than the one of the package (e.g.
> >>> i386 binaries in an amd64 package), in order to make packages of
> >>> different architecture co-installable. If we start to break this goal,
> >>> we will have packages using the multiarch path, but not co-installable,
> >>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
> >>> be co-installable.
> >> 
> >> Already broken for 2 stable releases.
> >
> > We are not using multiarch paths in Debian, so this has never happens.
> > When using standard /usr/lib paths, people are expecting that the paths
> > collide. When using multiarch they do not expect that, as it the goal of
> > multiarch.
> 
> All biarch packages contain binary objects of a foreign architecture
> (that is kind of the point of them). Some do contain binaries. Some
> contain conffiles. One contains the dynamic loader. Prime example is
> libc6 vs. libc6-i386/amd64.
> 
> Using the multiarch library path already and in biarch packages just
> changes the number from 5 to 25 or thereabout.
> 
> Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
> due to the dynamic linker and I believe every single biarch package
> depends on the libc. So they will never be coinstallable. The question
> is just how much Conflicts/Replaces are needed for the upgrade path.
> 
> >>> IMHO, we should have a clear transitional plan to multiarch before we
> >>> start using multiarch path, in order to make sure we are not creating
> >>> problems that has to be solved later.
> >> 
> >> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
> >> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo
> >> 
> >> or
> >> 
> >> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
> >> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs
> >> 
> >> Adding that will let dpkg know how to handle the transition just fine.
> >
> > Meaning we need to have that for each package previously available as a
> > biarch package. Seems to be complicated for no real gain.
> >
> > Let me ask you a question: What would be the gain of using the multiarch
> > path for the biarch packages?
> 
> Instead of violating the FHS we would follow a hopefully future FHS
> while still violating the existing FHS. So nothing really.
> 
> I'm totaly fine with leaving the biarch packages where they are. I
> would like some push behind using multiarch paths for native packages
> though. Or rather I want them gone and replaced by ia32-apt-get.
> 
> > For me pushing that is the wrong way to get multiarch support in Debian.
> > If we want it, we need to move the main librairies to the multiarch
> > path. And it is something I proposed for glibc once we have proper gcc
> > support, and a stabilised glibc 2.9. This choice still needs to be
> > validated by other persons though (like the RM team).
> 
> Full ACK.
> 
> > Last but not least, what is really need to have multiarch support in
> > Debian is a proper support in dpkg. They are some code already done by
> > Tollef, they are some ideas floating around, but they are still some
> > design decisions to be taken, and nobody has a real patch that can be
> > applied to dpkg. People are pushing hard to have multiarch support, but
> > no one seems to care about actually writing code.
> 
> Pre sarge we had a dpkg that could install multiarch just fine but
> lacked some handholding when upgrading packages when they switched
> between arch all/any. Bitrot and redesigns in dpkg have made the patch
> kind of useless though and it needs to be rewritten.
> 
> As for design decisions the only ones I know are missing are all
> cosmetic. They don't imapct the algorithm, just the look&feel:
> 
> 1) How to specify an arch in sources.list?
> 
> Suggestio

Re: Breaking /emul/ia32-linux for squeeze

[Stephen Gran]

This one time, at band camp, Tollef Fog Heen said:
> ]] Stephen Gran 
> 
> | Put another way, I can't think of a valid use for an amd64 binary
> | depending on a ppc32 binary.
> 
> Package: foo
> Depends: sed
> 
> (sed is Essential: yes, but I think you get the point.)

I don't see what the architecture of sed has to do with it in that
example.  My main point was that I don't see why a binary of one
architecture will need to explicitly depend on a binary of another
architecture *and the architecure of that second binary matters*.  Sorry
if that last point wasn't clear.  Of course there will be shell scripts
and so on that will execute whatever binary happens to be first in PATH,
but that's not an explicit architecture relationship that calls for the
sort of grotesquery mentioned.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

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

[Russ Allbery]

Raphael Hertzog  writes:

> I think we all mostly agree on that. I see only two remarks:
> - the package can either fully override the default settings or
>   filter the provided build options: i.e. add/remove/replace build
>   options. (and I think that the "filter" option should be the recommended
>   approach)

Yes.

> - the user should also be able to provide a default build option that the
>   package can override in case the user wants to trust the
>   maintainer's opinion on what build options are sane or not for this
>   specific package (it might allow him to have a better success rate if you
>   want to recompile lots of packages with some options that are known to
>   not work in some cases)

I don't think this is particularly important at a level of granularity
less than the system configuration level (in other words, having the user
do this by changing a conffile would be fine with me).  I base this on my
experience as a user overriding compilation flags long before I'd ever
used Linux, where if need be I'll just cut and paste what the package
currently uses and change it slightly when building regular packages.
This is pretty much par for the course for overriding configuration like
that.

> Do we want that hierarchy set in stone in policy or do we simply want to
> define how the rules file is supposed to retrieve the relevant build
> options ?

I think we should say something about the hierarchy of options in Policy
at least as non-normative text as an explanation for what on earth we're
trying to accomplish, so that ten years from now we can figure out what we
were thinking.

> What would the policy change look like if we select the Makefile snippet
> approach ?

Roughly:

All packages should add:

include /etc/dpkg-dev/build-options.mk

to their debian/rules file.  This file will set the following options:

CFLAGS
LDFLAGS
...

Packages should use those settings by default (with appropriate changes or
propagation into other variables as needed by the build system of the
package -- insert explanation of what each of them means here), but the
package may override or change those settings if they're not appropriate
for this particular package.

Users when building a package may override both the defaults and
debian/rules by setting the appropriate variable on the make command line
with, for example:

make -f debian/rules CFLAGS=blah

Not in Policy: dpkg-buildpackage could certainly have a useful option for
doing the last, and I think that would be a worthwhile feature.

> It would be nice to have figures here.

I don't have time to write the code myself, but it should be fairly
trivial to find most packages that set CFLAGS explicitly by looking at the
rules file in the Lintian lab on gluck.  You'll miss more complex makefile
include systems, but you'll get most of the cases.

> Note that we have packages switching to debhelper 7 rules files as
> simple as /usr/share/doc/debhelper/examples/rules.tiny so the number of
> packages explicitely setting CFLAGS might drop.

Yes, agreed.

Note that all CDBS packages can easily switch to whatever we want,
including makefile snippets, with a rev to CDBS.  debhelper 7 with minimal
rules will probably need to add the include file directly, since debhelper
isn't in as good of a position to force the makefile inclusion.  (There
are ways in which it could, but they all seem very ugly to me.)

-- 
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: Breaking /emul/ia32-linux for squeeze

[Marco d'Itri]

On Mar 16, Mike Hommey  wrote:

> > I think it would be very helpful if somebody could summarize why a
> > multiarch system is useful, except for the obvious case of installing
> > proprietary i386 software on amd64 systems.
> s/proprietary// ; there you have your obvious case.
Not really, because then the most logical solution would be to fix the
few packages which are not 64 bits clean yet.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Steve Langasek]

On Mon, Mar 16, 2009 at 12:17:28PM -0600, Raphael Geissert wrote:
> Steve Langasek wrote:

> > On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote:

> >> [I'm personally slightly concerned about relaxing britney allowing
> >> testing to get into unreleasable states; a flag to re-enable the old
> >> behavoir late in release would probably be good.]

> > In practice, the release team has to do this at various points in the
> > release cycle anyway because the transitions become so entangled that
> > breaking something in testing, or removing a bunch of packages that we
> > intend to release with, are the only options.  This approach at least
> > ensures that testing will remain installable and (presumably) useful
> > during the rocky transitions, merely requiring a bit of cleanup of old
> > packages.

> Wouldn't it be better to remove the packages from testing? this way if the
> library and other packages are ready to go they could easily migrate
> without any special hack, if my understanding of the situation is correct.

In some cases, if you want a completely consistent testing you have to
remove dozens of source packages for the benefit of one "extra" binary
package that's built from the same source as something important.

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

-- 
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: Breaking /emul/ia32-linux for squeeze

[Mike Hommey]

On Mon, Mar 16, 2009 at 10:45:32PM +0100, Marco d'Itri wrote:
> On Mar 16, Mike Hommey  wrote:
> 
> > > I think it would be very helpful if somebody could summarize why a
> > > multiarch system is useful, except for the obvious case of installing
> > > proprietary i386 software on amd64 systems.
> > s/proprietary// ; there you have your obvious case.
> Not really, because then the most logical solution would be to fix the
> few packages which are not 64 bits clean yet.

64-bits cleanness is not the sole reason to run 32 bits applications on
64 bits systems.

Mike


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

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

[Don Armstrong]

On Mon, 16 Mar 2009, Adeodato Simó wrote:
> As said above, failures to build against the new library are RC from
> day 0, and the intention is not to do transitions while those are
> open, other constraints permitting.

Cool.
 
> As for packages that are rebuilt in unstable but not migrated, I
> don’t think RC bugs are approriate, since they’re not bugs in the
> package.

Right; I really only meant the cases in which someone has to do
something to clean up the transition. (For things that only the RMs
can do, it doesn't really make a difference to me how it's tracked,
though bugs in the BTS against an appropriate psuedopckage using the
'affects'[1] mechanism to indicate which packages have a problem would
help other people besides the RMs know what was going on.)

> In addition to what Steve explained about the inevitable necessity
> to bend the rules for entangled transitions, let me clear up that
> this is not any flag in britney that enables the behavior
> permanently or globally. This applies to a transition on a
> case-by-case basis, with a conscious decision and need for manual
> action. Also, it is my expectation that the need for this will
> mostly disappear once we get this first batch of transitions done.

That's good enough for me. I didn't understand that it involved manual
action.


Don Armstrong

1: This isn't working 100% yet; I hope to have an announcement about
it and summary shortly.
-- 
Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: net-tools future

[Ben Hutchings]

On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote:
> Martín Ferrari  writes:
> 
> > Problematic tools:
> >  * mii-tool: it could be dropped and replaced by a pointer to ethtool as
> > it's not meant to be used automatically by scripts. On the other hand,
> > it's distributed as a stand-alone tool [0] and we could do the same.
> 
> A couple of notes:
> 
>  mii-tool and ethtool use different driver interfaces which I'm pretty
>  sure aren't completely overlapping for all drivers in the kernel
> 
>  mii-tool may not be meant for scripts, but I for one have used it in
>  the past to force speed/duplex like this:
> 
> iface eth1 inet static
>  address 10.122.226.9
>  netmask 255.255.255.192
>  up /sbin/mii-tool -F 100baseTx-FD eth1
> 
>  I'm pretty sure I'm not the only one...

You can do this with ethtool now, and more cleanly:

link-speed 100
link-duplex full

>  I fail to see the value of removing mii-tool.  I'd rather see just the
>  non-working features removed in favour of an ethtool recommendation.
 
It doesn't recognise 1G and 10G links, so its speed reporting is broken.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: DebianWiki migrated

[Bernd Zeimetz]

Frank Lin PIAT wrote:
> Hi all,
> 
> Wiki engine migrated
> 

Thanks for the work!

> Also, the GUI editor is now disabled, because moinmoin 1.7 use an old 
> version of fckeditor which would have been a security problem. We are
> working to find a solution.

If I remember right, the GUI editor messed up several pages, so it was
recommended not to use it (and I always hated it with a passion), so the
question is if it is really needed to have it enabled again.

Cheers,

Bernd

-- 
 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: Mass bugfiling in preparation for multiarch

[Russ Allbery]

Aurelien Jarno  writes:

> If you want to get some more multiarch ennemies, this is clearly the way
> to go.
>
> The alternate method is to post a list to debian-devel, and when we have
> a basic multiarch support, you may start thinking about filling bugs.
> Not before.

Well, regardless of the benefits for multiarch, library packages
containing binaries that don't change names with different SONAMEs violate
a Policy must at present.  So either they're RC bugs or Policy is wrong
about the severity.

It's a theoretical problem in libc6 in particular since the chances of
libc6 changing SONAMEs again is low and there would be a lot of other work
to have to do to deal with that apart from the binaries in /usr/bin, but
the situation for other libraries is much more concrete.  I've already
filed an RC bug about this in one other package that I ran into.  I think
such bugs are fair game regardless of whether or not we're trying to
implement multiarch (with the normal caveats about mass bug filing).

If the file does change with SONAME, that's a different matter, and that
part depends more on our multiarch direction.

-- 
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: DebianWiki migrated

[Frank Lin PIAT]

On Mon, 2009-03-16 at 23:33 +0100, Bernd Zeimetz wrote:
> Frank Lin PIAT wrote:
> > Hi all,
> > 
> > Wiki engine migrated
> > 
> 
> Thanks for the work!
> 
> > Also, the GUI editor is now disabled, because moinmoin 1.7 use an old 
> > version of fckeditor which would have been a security problem. We are
> > working to find a solution.
> 
> If I remember right, the GUI editor messed up several pages, so it was
> recommended not to use it (and I always hated it with a passion)

Quite a few users choose moinmoin because it have a gui editor.

> so the question is if it is really needed to have it enabled again.

Finding bugs and fixing bugs... that's the game.

Franklin


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

Re: net-tools future

[Guus Sliepen]

On Sun, Mar 15, 2009 at 06:41:14PM +, Ben Hutchings wrote:

> >  * nameif: can be replaced by "ip link", not sure if it's worth the
> > effort (does anybody actually use it?)
> 
> Never heard of it, and it seems redundant with udev now.  There's also
> ifrename.

I think udev can now do everything ifrename can do, and if installations
without udev are unsupported by Debian then this tool can go away as well.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Mass bugfiling in preparation for multiarch

[Aurelien Jarno]

On Mon, Mar 16, 2009 at 03:40:53PM -0700, Russ Allbery wrote:
> Aurelien Jarno  writes:
> 
> > If you want to get some more multiarch ennemies, this is clearly the way
> > to go.
> >
> > The alternate method is to post a list to debian-devel, and when we have
> > a basic multiarch support, you may start thinking about filling bugs.
> > Not before.
> 
> Well, regardless of the benefits for multiarch, library packages
> containing binaries that don't change names with different SONAMEs violate
> a Policy must at present.  So either they're RC bugs or Policy is wrong
> about the severity.
> 
> It's a theoretical problem in libc6 in particular since the chances of
> libc6 changing SONAMEs again is low and there would be a lot of other work
> to have to do to deal with that apart from the binaries in /usr/bin, but
> the situation for other libraries is much more concrete.  I've already
> filed an RC bug about this in one other package that I ran into.  I think
> such bugs are fair game regardless of whether or not we're trying to
> implement multiarch (with the normal caveats about mass bug filing).
> 
> If the file does change with SONAME, that's a different matter, and that
> part depends more on our multiarch direction.
> 

Still mass filling bugs is not the solution here. As it see seems we like
policy and reference, let me quote the developer reference 7.2:

"Please use the programms dd-list and if appropriate whodepends (from
the package devscripts) to generate a list of all affected packages, and
include the output in your mail to ."

That's what I suggested.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: DebianWiki migrated

[Ben Finney]

Frank Lin PIAT  writes:

> Wiki engine migrated
> 
> 
> The DebianWiki team is pleased to announce that the wiki is now
> running moinmoin 1.7, which brings many new features (see [1] and
> [2]).

Thanks very much!

One of the new features announced in MoinMoin 1.7 is OpenID
authentication. Could this please be enabled on the Debian wiki?

-- 
 \  “An eye for an eye would make the whole world blind.” —Mahatma |
  `\Gandhi |
_o__)  |
Ben Finney


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

libcairo has two different versions in Lenny?

[Michelle Konzack]

Fellow Developers,

last Friday I have downloaded the fist Debian install DVD fro Lenny  and
for some mintes trie to install a new Workstation and gotten this:

[ STDIN ]---
[r...@michelle1:~ ] apt-get install fvwm
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  fvwm: Depends: libgtk2.0-0 (>= 2.12.0) but it is not going to be installed
Depends: librsvg2-2 (>= 2.18.1) but it is not going to be installed
E: Broken packages

[r...@michelle1:~ ] apt-cache policy fvwm libgtk2.0-0 librsvg2-2
fvwm:
  Installed: (none)
  Candidate: 1:2.5.26-1
  Version table:
 1:2.5.26-1 0
900 ftp://ftp2.de.debian.org lenny/main Packages
libgtk2.0-0:
  Installed: (none)
  Candidate: 2.12.11-4
  Version table:
 2.12.11-4 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages
librsvg2-2:
  Installed: (none)
  Candidate: 2.22.2-2lenny1
  Version table:
 2.22.2-2lenny1 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages

[r...@michelle1:~ ] apt-get install fvwm libgtk2.0-0 librsvg2-2 libcairo2 
libpango1.0-0
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  libgtk2.0-0: Depends: libcairo2 (>= 1.6.4-6.1) but 1.4.10-1+lenny2 is to be 
installed
  libpango1.0-0: Depends: libcairo2 (>= 1.6.4-6.1) but 1.4.10-1+lenny2 is to be 
installed
E: Broken packages

[r...@michelle1:~ ] apt-cache policy fvwm libgtk2.0-0 librsvg2-2 libcairo2 
libpango1.0-0
fvwm:
  Installed: (none)
  Candidate: 1:2.5.26-1
  Version table:
 1:2.5.26-1 0
900 ftp://ftp2.de.debian.org lenny/main Packages
libgtk2.0-0:
  Installed: (none)
  Candidate: 2.12.11-4
  Version table:
 2.12.11-4 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages
librsvg2-2:
  Installed: (none)
  Candidate: 2.22.2-2lenny1
  Version table:
 2.22.2-2lenny1 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages
libcairo2:
  Installed: (none)
  Candidate: 1.4.10-1+lenny2
  Version table:
 1.6.4-7 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages
 1.4.10-1+lenny2 0
980 http://security.debian.org lenny/updates/main Packages
libpango1.0-0:
  Installed: (none)
  Candidate: 1.20.5-3
  Version table:
 1.20.5-3 0
920 cdrom://Lenny_DVD_1 lenny/main Packages
900 ftp://ftp2.de.debian.org lenny/main Packages



Can someone explain, WHY the SECURITY mirror has an outdated version  of
libcairo2 and blocking the installation (I have  manualy  installed  the
libcairo2, but it is  annoying  and  should  be  corrected  as  fast  as
possibel)


Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
 Michelle Konzack
   Apt. 917
   50, rue de Soultz
Jabber linux4miche...@jabber.ccc.de   67100 Strasbourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886Tel. FR: +33  6  61925193


signature.pgp
Description: Digital signature

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

[Raphael Geissert]

Steve Langasek wrote:

> On Mon, Mar 16, 2009 at 12:17:28PM -0600, Raphael Geissert wrote:
>> Wouldn't it be better to remove the packages from testing? this way if
>> the library and other packages are ready to go they could easily migrate
>> without any special hack, if my understanding of the situation is
>> correct.
> 
> In some cases, if you want a completely consistent testing you have to
> remove dozens of source packages for the benefit of one "extra" binary
> package that's built from the same source as something important.
> 
> 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).

Cheers,
Raphael Geissert



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

Stefano Zacchiroli wrote:
> 
> ... and pretty please, do not choose a solution that will require
> adding an "-include" to 15'000 thousands debian/rules; we will finish
> doing that by Lenny+50, the earliest.

It would take some time, yes; but packages using cdbs would only require a
binNMU once cdbs includes that file on its own.
IMO this is what looks like The Right Solution; are we willing to ignore it
just because it would take some time?

Anyway, any package that was last updated before dpkg-buildpackage started
to set the environment vars could easily be discarded, because it was never
affected by the ENV vars mess.

What other approach (which fulfils all the pros already mentioned by Manoj)
do you suggest?

Cheers,
Raphael Geissert



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

Bug#520043: ITP: enigform -- Iceweasel/Firefox extension to digitally sign HTTP requests

[Jonathan Wiltshire]

Package: wnpp
Severity: wishlist
Owner: Jonathan Wiltshire 

* Package name: enigform
  Version : 0.8.1
  Upstream Author : Artruro 'Buanzo' Busleiman 
* URL : http://enigform.mozdev.org/
* License : MPL
  Programming Lang: Javascript
  Description : Iceweasel/Firefox extension to digitally sign HTTP requests

Enigform is a Mozilla Firefox extension that provides the ability to digitally 
sign HTTP requests, even those generated via AJAX. It implements the mechanism 
described in the white paper "OpenPGP-based Identity and Data Authentication 
for HTTP", by Arturo Buanzo Busleiman. 

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



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

Bug#520045: ITP: libapache2-mod-openpgp -- Apache module to enhance HTTP with OpenPGP features

[Jonathan Wiltshire]

Package: wnpp
Severity: wishlist
Owner: Jonathan Wiltshire 

* Package name: libapache2-mod-openpgp
  Version : 0.5.0
  Upstream Author : Arturo 'Buanzo' Busleiman 
* URL : http://wiki.buanzo.org/index.php?n=Main.ModOpenpgp
* License : Apache 2.0
  Programming Lang: C, Python
  Description : Apache module to enhance HTTP with OpenPGP features

Mod_OpenPGP is an Apache module that serves as a companion for Firefox's 
extension "Enigform". Together, they enhance the HTTP protocol with OpenPGP 
Session Management (Initiation, Validation, Expiration, and Auto-Closing), 
Request Signing and Verification. 

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



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

Re: net-tools future

[Ben Hutchings]

On Mon, 2009-03-16 at 22:25 +, Ben Hutchings wrote:
> On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote:
[...]
> >  I fail to see the value of removing mii-tool.  I'd rather see just the
> >  non-working features removed in favour of an ethtool recommendation.
>  
> It doesn't recognise 1G and 10G links, so its speed reporting is broken.

I was mistaken - the Debian package has a patch to add 1G support.
Ethernet 10G PHYs have a much larger MDIO register set and there is no
standard for addressing these through ioctls (something else I'd like to
fix).  But I'll admit that they are rare as yet.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

group nvram

[Marco d'Itri]

Unless somebody will have persuasive objections I will change it to
group kmem in a future udev upgrade.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#520053: ITP: jkmeter -- Jkmeter is a horizontal or vertical audio bargraph level meter

[Jaromír Mikeš]

Package: wnpp
Severity: wishlist
Owner: "Jaromír Mikeš" 

* Package name: jkmeter
  Version : 0.4.0-1
  Upstream Author : Fons Adriaensen 
* URL : http://www.kokkinizita.net/linuxaudio/downloads/index.html
* License : GPL
  Programming Lang: C++
  Description : Jkmeter is a horizontal or vertical audio bargraph level 
meter

(Jkmeter is a horizontal or vertical bargraph level
meter based on the ideas of mastering guru Bob Katz.
See  and
follow the links on 'level practices'.
This is the type of meter you want for live recording,
mixing and mastering.)

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy
  APT policy: (500, 'hardy')
Architecture: i386 (i686)

Kernel: Linux 2.6.29-1-multimedia-686 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Re: Bug#520053: ITP: jkmeter -- Jkmeter is a horizontal or vertical audio bargraph level meter

[Ben Hutchings]

On Tue, 2009-03-17 at 03:31 +0100, Jaromír Mikeš wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Jaromír Mikeš" 
> 
> * Package name: jkmeter
>   Version : 0.4.0-1
>   Upstream Author : Fons Adriaensen 
> * URL : http://www.kokkinizita.net/linuxaudio/downloads/index.html
> * License : GPL
>   Programming Lang: C++
>   Description : Jkmeter is a horizontal or vertical audio bargraph level 
> meter

Please specify whether this is a standalone application or a GUI
component.  If it's standalone, which audio sources does it work with
(looks like JACK)?  If a GUI component, which toolkit does it work with?

> (Jkmeter is a horizontal or vertical bargraph level
> meter based on the ideas of mastering guru Bob Katz.
> See  and

404

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: DebianWiki migrated

[Paul Wise]

On Tue, Mar 17, 2009 at 8:18 AM, Ben Finney  wrote:

> One of the new features announced in MoinMoin 1.7 is OpenID
> authentication. Could this please be enabled on the Debian wiki?

That would likely make it much harder to fix  #385797 - Wiki does not
have a license.

I think once we've sorted that out, enabling OpenID will be a reasonable idea.

-- 
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: DebianWiki migrated

[Ben Finney]

Paul Wise  writes:

> On Tue, Mar 17, 2009 at 8:18 AM, Ben Finney  
> wrote:
> 
> > One of the new features announced in MoinMoin 1.7 is OpenID
> > authentication. Could this please be enabled on the Debian wiki?
> 
> That would likely make it much harder to fix #385797 - Wiki does not
> have a license.

I don't see how the use of a different authentication system
intersects with that bug at all. Can you elaborate what you think the
issue is?

-- 
 \“I have a microwave fireplace in my house. The other night I |
  `\   laid down in front of the fire for the evening in two minutes.” |
_o__)   —Steven Wright |
Ben Finney


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

Re: DebianWiki migrated

[Paul Wise]

On Tue, Mar 17, 2009 at 2:57 PM, Ben Finney  wrote:

> I don't see how the use of a different authentication system
> intersects with that bug at all. Can you elaborate what you think the
> issue is?

I'm making an uneducated guess that allowing editing by people we
cannot contact will be bad for licencing the wiki since we need to
contact people to be able to give pages a license. The current
authentication mechanism requires an email address so there is a
decent chance we'll be able to contact people for this purpose.
Unfortunately the address isn't validated with some kind of
challenge-response mechanism so much of this argument is bogus, my
hope is that most people will have a real, working email address in
their wiki account.

-- 
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: DebianWiki migrated

[Ben Finney]

Paul Wise  writes:

> I'm making an uneducated guess that allowing editing by people we
> cannot contact will be bad for licencing the wiki since we need to
> contact people to be able to give pages a license. The current
> authentication mechanism requires an email address so there is a
> decent chance we'll be able to contact people for this purpose.

No problem. Using OpenID for authentication doesn't prevent a
registration process that needs some other details. It even supports
it with “attribute exchange”, so that people can (if they choose to)
have the registration process re-use the email address they've already
got recorded with their OpenID provider.

-- 
 \  “Some subjects are so serious that one can only joke about |
  `\them.” —Niels Bohr |
_o__)  |
Ben Finney


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