upload debian package error

[xiangfu]

Hi
I try to upload xburst-tools[1], I have two warning and one error.
my question is 
1. the version number must 1.0.0(like that). can I use 2009.06(something like 
that to be a version)
2. I am not a maintainer. but I want to be this package's maintainer.
   can I add my name and email to the control file
3. what am I got do with last warining.

maybe I ignore some help page because My English is not very good.
So give me some advice or direct. 

thanks for the help.


W: xburst-tools source: source-nmu-has-incorrect-version-number 2009.06
E: xburst-tools source: no-maintainer-field
W: xburst-tools source: configure-generated-file-in-source config.log

[1]http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=xburst-tools
-- 
Best Regards
Xiangfu Liu

jabber : xiangf...@gmail.com
skype  : xiangfu.z


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

Re: ia32-libs depends on ia32-apt-get ?

[Goswin von Brederlow]

Steve Langasek  writes:

> On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote:
>> Look at perl for example:
>
>> Package: perl-base
>> Provides: perlapi-5.10.0
>
>> I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
>> perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
>> matching ABI can then easily depend on the right package.
>
>> The dh_perl helper could add the dependency automatically allowing a
>> binNMU to transition many packages.
>
> Do you intend to do the same for python, which has no such "API" provides?
> Or are you only proposing a workaround for perl?

Yes. No.

I was using perl as example because it verry nearly already is doing
this with its perlapi-5.10.0 provide.

I imagine dh_python / dh_pycentral / dh_pysupport will be able to
autodetect the need for a dependency on the python ABI automatically
as well.

>> > Also, what are the immediate practical use cases for cross-arch depends on
>> > extensible interpreters such as python and perl?  Wine doesn't need this,
>> > nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
>> > requiring that class of dependencies to be deferred by a release cycle?
>
>> Say you have:
>
>> Package: foo
>> Architecture: amd64
>> Depends: perl
>
>> Package: bar
>> Architecture: i386
>> Depends: perl
>
>> Package: libbaz-perl
>> Architecture: amd64
>> Depends: perl
>
>> Package: libbat-perl
>> Architecture: i386
>> Depends: perl
>
> This is a hypothetical.  I asked for evidence of a *practical* impact.

You really need me to go through the rdpends of interpreters and find
an example of 2 arch:any packages that depend on one? Ok, here we go:

Package: skyped
Architecture: i386
Depends: python (>= 2.5), python-gnutls, python-skype (>= 0.9.28.7)
Description: Daemon to control Skype remotely

Package: totem
Architecture: amd64
Depends: python, python-support (>= 0.90.0)
Description: A simple media player for the GNOME desktop based on GStreamer

So installing skyped would require a 32bit python and 32bit totem
prior to a release cycle.

>> 4) Using Depends: perl [same]
>>This would allos foo and bar to be both installed but only the
>>right one of libbaz-perl and libbat-perl. But that takes a release
>>cycle to introduce the new syntax.
>
> But if it's unproven that anyone *needs* this, there's no reason to worry
> about the delay for implementing this corner case.

See above.

>>Note that you also need perl to break libbaz-perl and libbat-perl
>>versions prior to the ones with "Depends: perl [same]" or yet
>>another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
>>suffers from the same problem.
>
> The need for flag days for interpreters is identified as a limitation of
> this design, and is actually a point that's currently under review.
>
>> > Handling of -dev packages is defined as *out of scope* for this
>> > specification.  I fail to see how it's broken to confine the initial scope
>> > to those elements that impact the package management tools, to avoid 
>> > getting
>> > bogged down in irrelevant discussions about filesystem layouts.
>
>> The problem is in the dependencies and actually not restricted to just
>> -dev packages. Transitional/Meta packages suffer from this in
>> general. For the sake of an example lets say you have the following
>> packages (xlibs-dev being a real example):
>
> You know xlibs-dev is no longer in the archive, right?
>
> -dev metapackages don't make a whole lot of sense except on a transitional
> basis.  While there may be some things that still need to be tightened up
> here, if one of the outcomes is that -dev metapackages have to be made arch:
> any, I don't think that's too onerous.

Not just -dev metapackages, any meta/transitional packages can run
into this. xlibs-dev is just the package where I noticed the issue
first.

>> Source: foo
>> Build-Depends: xlibs-dev, bar
>
>> Package: xlibs-dev
>> Architecture: all
>> Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...
>
>> Package: libice-dev
>> Architecture: any
>> Multi-Arch: same
>
>> Package: bar
>> Architecture: any
>> Multi-Arch: foreign
>> Depends: baz
>
>> Package: baz
>> Architecture: any
>
>> You assume:
>
>> | Dependencies, Build-Dependencies, and Recommends within an existing
>> | architecture foo will continue to remain closed over the set of
>> | packages declaring either Architecture: foo or Architecture: all.
>
> This is a statement of the implications for the archive, and is an
> expression of the existing archive requirements.  It says nothing about how
> build-dependency fields are to be interpreted on a build system.
>
>> Say you are building on amd64 and libice-dev:i386, bar:i386 and
>> baz:i386 is installed.
>
>> 1) The 'Multi-Arch: foreign' breaks your assumption.
>>Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just
>>fine. You assumption would indicate you don't consider that a
>>satisfaction of the Build-Depends.
>
> 

Re: ia32-libs transition

[Goswin von Brederlow]

Aneurin Price  writes:

> On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlow wrote:
>> Aneurin Price  writes:
>>
>>> Hi,
>>>
>>> I've just spent over an hour writing and rewriting this mail, and determined
>>> that I can't think of a single constructive thing to say.
>
> Not wanting to leave it at that, I've spent a couple of hours today trying to
> pin down some specifics. Unfortunately I've not had much success. Purging
> everything related to 32bit compatibility and reinstalling doesn't ever seem 
> to
> have exactly the same effect - so far I've seen numerous problems, but none of
> them reproducibly, and many of them making no sense at all - eg how in the 
> world
> did I lose /usr/bin/dpkg-deb at one point? No clue. The apt segfault went away

That would require you to hit ctrl-C in the preinst between a mv and a
ln command. Or on remove between dpkg removing the package and running
postrm where the diversion is undone. In both cases you would have a
half-installed package due to your ctrl-c-ing.

> after setting Cache-Limit to 50331648 - but why did it only start doing that
> after a couple of goes? Couldn't say.

That makes 4 people having hit that libapt bug.

> I suspect that all of my problems are secondary damage rooted in a problem I 
> had
> the first time I tried the update: installing ia32-apt-get requires a ton of
> entropy to generate a private key (why? beats me). Unfortunately, my system
> didn't seem to be able to generate sufficient randomness even after an evening
> of use, so eventually I ^Cd it just so that at least the dpkg database lock
> would be released. I'm aware that this isn't a good idea, but I didn't feel 
> that
> I had a great deal of choice - plus I've never had a partial package install 
> be
> such a headache to clean up before. Curiously, in my later repeats of the
> process it never took more than a couple of minutes to generate enough 
> entropy,
> and usually it was less than a minute, so I'm not sure why it had such a 
> problem
> the first time.

I verry rarely have enough random bits for gpg to create a key. Even
after hours of uptime without using gpg. Other things eat up enough to
keep the pool small. But I never had it block for hours waiting for
more. Usualy continious quickly. Do you use ssl for mail and had a
fair amount of mail traffic? I heart that that eats up random bits
like crazy.

> Or maybe that, once cleaned up, wasn't the end of the world after all. Another
> possibility is that I didn't realise until I'd read the other thread that you
> need to use apt-get to complete the process, so I just used aptitude the first
> couple of goes, as I usually do.

You only need "apt-get update". The rest works in aptitude or synaptic.

>>> So I'll just ask a couple of questions instead:
>>>
>>> Is there any way of preventing this kind of major breakage in the future?
>>> I don't think many people expect that upgrading one package will FUBAR
>>> the packaging system.
>>>
>>> Is there any chance of Wine becoming functional on amd64 in the forseeable
>>> future?
>>
>> # apt-get install ia32-wine
>
> Except that it's really:
> apt-get update
> apt-get upgrade
> apt-get update
> apt-get install ia32-wine
>
> Rather than:
> aptitude update
> aptitude install wine
>
> At least that's what I assume. I can't get past the second apt-get update
> without something breaking.

With version 19 (on mentors.debian.net) you can now also do

aptitude install ia32-apt-get
aptitude update
aptitude install ia32-wine

You only need one round of update after ia32-apt-get. ia32-wine
depends on all the libraries it needs and pulls them it. It doesn't
need an upgrade of ia32-libs before it is installable.

> This entire direction is a dead end. Having these extra package databases and
> dpkg-diversions only works in a very narrow set of circumstances. It's only a
> workable solution if you assume that everyone:
>
> * Uses apt-get and nothing else
> * Doesn't care about having other package-related tools like apt-file fully
> functional

apt-file needs to be patched for multiarch so it can cope with
multiple Contents-$ARCH files eventually. If you do that now it will
function more and more as libraries are converted to multiarch even if
ia32-apt-get is still used to install them. Remember that packages can
convert to multiarch prior to dpkg/apt/aptitute/synaptic/... being
multiarch capable.

> * Doesn't care about packages not being shown 'correctly' in eg.
> aptitude/apt-cache search, at least until the magic setup process is complete.

"correctly"? Inbetween installing ia32-apt-get and running update for
the first time after that there is small window where some index files
will be unavailable. I'm not aware though that that affects how
packages are shown in aptitude or apt-cache. I use apt-cache quite a
lot and it displays things just fine for me.

> * Reads the documentation and knows that they have to complete a multi-step
> process.
> * Is actually happy to do so
> * Is always 

ITP: scim-bridge-el -- SCIM-Bridge client for GNU Emacs

[Takaya Yamashita]

Package: wnpp
Owner: Takaya Yamashita 
Severity: wishlist

* Package name: scim-bridge-el
  Version : 0.7.4-1
  Upstream Author : S. Irie
* URL or Web page : http://www11.atwiki.jp/s-irie/pages/12.html
* License : GPL2
  Description : SCIM-Bridge client for GNU Emacs

 The Smart Common Input Method platform (SCIM) is an input
 method (IM) platform containing support for more than thirty
 languages (CJK and many European languages) for POSIX-style
 operating systems including Linux and BSD.
 This program is SCIM-Bridge client for GNU Emacs. It is, however,
 not part of official SCIM-Bridge.

---
Takaya Yamashita
tak...@debian.or.jp
tyamash...@mikilab.doshisha.ac.jp


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

Re: Bug#534507: ITP: kalternatives -- graphical alternatives system configuration tool

[Guillem Jover]

Hi!

On Tue, 2009-06-30 at 12:32:23 +0200, Pino Toscano wrote:
> Few days ago, I had a nice talk with Guillem, and he told me that dpkg 
> developers are working for cleaning up update-alternatives' code, and 
> planning 
> to convert it to C (along with provide a dpkg library); since the previous 
> are 
> either happening or planned to be soon, I will avoid to rewrite the parser 
> twice, but wait for the dpkg library and help testing it, which is what 
> kalternatives will use (when it is ready, of course).
> 
> Would it be acceptable for now?

Sure, as discussed, as long as this is only temporary until we provide
a better interface, it seems wasted effort having to rewrite it twice.

thanks,
guillem


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

Bug#535242: ITP: architect -- Power Architect, is a cross-platform, open-source data modeling tool

[Murilo Habermann Torquato]

Package: wnpp
Severity: wishlist
Owner: Murilo Habermann Torquato 

  Package name: architect
  Version : 0.9.13
  Upstream Author : SQL Power Group Inc 
  URL : http://code.google.com/p/power-architect/
  License : GPL
  Programming Lang: Java
  Description : Power Architect, is a cross-platform, open-source data 
modeling tool

A user-friendly data modeling tool created by data warehouse designers, and has 
many unique features geared
specifically for the data warehouse architect. It allows users to 
reverse-engineer existing databases, perform data profiling on
source databases, and auto-generate ETL metadata.



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

Re: ia32-libs transition

[Goswin von Brederlow]

Yannick  writes:

> Maybe all of this should go to experimental (is there a problem with wine 
> depending on experimental packages for amd64?) but thank you Goswin for your 
> work.
>
> Yannick

The problem was that libc6-i386 broke all 32bit support in unstable
making all 32bit packages uninstallable. So something had to be done
for unstable. I would have prefered doing this in experimental first
too. Esspecially seeing how the libc6-i386 screwed up the transition
on its first try and is still buggy (breaks wine).

The choices where
1) rewrite the old ia32-libs + ia32-libs-gtk for the new libc6-i386
or
2) make ia32-apt-get take over (slightly prematurely in hindsight)

According to popcon ~60 people had the previous ia32-apt-get
installed so I didn't expect that much of an outrage about it. Now it
shows 120 people.


Anyway, what is done is done. I uploaded a new version to mentors. If
anyone cares to try it out:

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=ia32-libs-tools

http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools/

MfG
Goswin


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

Re: [Fwd: Delivery Status Notification (Failure)]

[Steve Langasek]

On Tue, Jun 30, 2009 at 11:17:54PM +0200, Luk Claes wrote:

> Below the content of a bounce I got when replying to a wanna-build
> request... blacklisting domains seems to be accepted as the ones in
> control of its mailservers should be able to fix possible issues, but
> blacklisting all mail based on the country part of a domain??!

> I guess it's another sign that we already lost against spammers?

Looks to me like a sign that we have a DM who should fix his mail
configuration, or else be declared MIA.

>  Original Message 
> Subject: Delivery Status Notification (Failure)
> Date: 30 Jun 2009 23:05:42 +0200
> From: Mail Delivery System 
> To: l...@debian.org
> 
> The following message to  was undeliverable.
> The reason for the problem:
> 5.1.0 - Unknown address error 550-'5.7.0 ... Your
> country has been blacklisted due to its serious SPAM problems'
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 

-- 
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: RFC round 3: DEP-3: Patch Tagging Guidelines

[Charles Plessy]

Bonjour Raphaël,

Thank you for the feedback. It made me understood that the format can be even
simplified. First of all, let me clarify that I do not aim at describing the
format of Debian control files, but the proposed format for DEP5, which I
propose for DEP3 as well since it is simple and does not require prior
experience of Debian control files.

In the informal discussions about DEP5, a popular request was to be allowed to
use free-form plain comments. I think that I read such a request in the DEP3
discussion as well. With this goal in mind, I propose that anything that is not
in a field is a comment. Then there is no need to define embedded comments, and
the empty lines above the first field can be ignored as comments and do not
need to be specified. The only drawback is that a comment must not contain
lines that look like starting a new field. In my experience with
debian/copyright files, this is not a problem.

If everything that is not a field is a comment, then there is no need to
specify a signal for end of header (lines with spaces only), and if lines with
spaces only are allowed, then there is no need anymore for escaping empty lines
in field bodies with dot characters, which prettifies the field bodies and
simplifies the format. In the case of DEP3, spurious fields could appear if the
patch itself is parsed. Nevertheless, this can be solved by specifying that the
patch header is extracted by the parser in a way that depends on the format of
the patch, and that only the extracted patch header is fully compliant with the
pseudo RFC-822 format described below. This also has the advantage of moving
out the dpatch-specific contorsions from the definition of the format.


This would give:

Fields are logical elements composed of a field name, followed by a colon,
followed by a field body, and terminated by a line feed character.

 - A field name is composed of printable characters, except colons.

 - The field body is composed of any character. Leading spaces of the body are
   ignored. To avoid problems with multi-line values, any line feed character
   must be escaped by following it by a space. The line that contains that space
   is called a continuation line.

 - Lines that are not continuation lines and do not start a new field are plain
   comments.


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: ia32-libs depends on ia32-apt-get ?

[Steve Langasek]

On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote:
> > Patches implementing what?  I don't see any public discussion of an agreed
> > design for the package manager.

> Patches for dpkg to accept the Multi-Arch field as a tristate of Yes,
> No or missing and for packages to set that field. It's been
> yes/no/missing in all the mails about multiarch for years and suddnely
> you changed the string.

Based on feedback from Guillem as dpkg maintainer (among others).  It does
no good to have a spec that's stable for years if it gains no traction with
the maintainers of the packages where it has to be implemented.

> >> made the whole thing need a full release cycle for a transition due to
> >> DEBIAN/control format changes

> > You appear to be referring to
> > .
> > What do you propose as an alternative that would let us achieve multiarch
> > sooner?  Multiarch has already failed to get traction for more than two

> Look at perl for example:

> Package: perl-base
> Provides: perlapi-5.10.0

> I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
> perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
> matching ABI can then easily depend on the right package.

> The dh_perl helper could add the dependency automatically allowing a
> binNMU to transition many packages.

Do you intend to do the same for python, which has no such "API" provides?
Or are you only proposing a workaround for perl?

> > Also, what are the immediate practical use cases for cross-arch depends on
> > extensible interpreters such as python and perl?  Wine doesn't need this,
> > nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
> > requiring that class of dependencies to be deferred by a release cycle?

> Say you have:

> Package: foo
> Architecture: amd64
> Depends: perl

> Package: bar
> Architecture: i386
> Depends: perl

> Package: libbaz-perl
> Architecture: amd64
> Depends: perl

> Package: libbat-perl
> Architecture: i386
> Depends: perl

This is a hypothetical.  I asked for evidence of a *practical* impact.

> 4) Using Depends: perl [same]
>This would allos foo and bar to be both installed but only the
>right one of libbaz-perl and libbat-perl. But that takes a release
>cycle to introduce the new syntax.

But if it's unproven that anyone *needs* this, there's no reason to worry
about the delay for implementing this corner case.

>Note that you also need perl to break libbaz-perl and libbat-perl
>versions prior to the ones with "Depends: perl [same]" or yet
>another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
>suffers from the same problem.

The need for flag days for interpreters is identified as a limitation of
this design, and is actually a point that's currently under review.

> > Handling of -dev packages is defined as *out of scope* for this
> > specification.  I fail to see how it's broken to confine the initial scope
> > to those elements that impact the package management tools, to avoid getting
> > bogged down in irrelevant discussions about filesystem layouts.

> The problem is in the dependencies and actually not restricted to just
> -dev packages. Transitional/Meta packages suffer from this in
> general. For the sake of an example lets say you have the following
> packages (xlibs-dev being a real example):

You know xlibs-dev is no longer in the archive, right?

-dev metapackages don't make a whole lot of sense except on a transitional
basis.  While there may be some things that still need to be tightened up
here, if one of the outcomes is that -dev metapackages have to be made arch:
any, I don't think that's too onerous.

> Source: foo
> Build-Depends: xlibs-dev, bar

> Package: xlibs-dev
> Architecture: all
> Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...

> Package: libice-dev
> Architecture: any
> Multi-Arch: same

> Package: bar
> Architecture: any
> Multi-Arch: foreign
> Depends: baz

> Package: baz
> Architecture: any

> You assume:

> | Dependencies, Build-Dependencies, and Recommends within an existing
> | architecture foo will continue to remain closed over the set of
> | packages declaring either Architecture: foo or Architecture: all.

This is a statement of the implications for the archive, and is an
expression of the existing archive requirements.  It says nothing about how
build-dependency fields are to be interpreted on a build system.

> Say you are building on amd64 and libice-dev:i386, bar:i386 and
> baz:i386 is installed.

> 1) The 'Multi-Arch: foreign' breaks your assumption.
>Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just
>fine. You assumption would indicate you don't consider that a
>satisfaction of the Build-Depends.

Per the above, your conclusion here is invalid.  It satisfies the
build-depends, it's just not sufficient from an archive perspect

Bug#535233: ITP: collectl -- Initial package request

[Simmons, Christopher]

Package: collectl
Version: 3.3.4
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

*** Please type your report below this line *** 
I wish to work on creating a debian package for collectl-3.3.4

License: GPL, ARTISTIC

-- System Information:
Debian Release: 5.0.1
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: ia32-libs transition

[Aneurin Price]

On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlow wrote:
> Aneurin Price  writes:
>
>> Hi,
>>
>> I've just spent over an hour writing and rewriting this mail, and determined
>> that I can't think of a single constructive thing to say.

Not wanting to leave it at that, I've spent a couple of hours today trying to
pin down some specifics. Unfortunately I've not had much success. Purging
everything related to 32bit compatibility and reinstalling doesn't ever seem to
have exactly the same effect - so far I've seen numerous problems, but none of
them reproducibly, and many of them making no sense at all - eg how in the world
did I lose /usr/bin/dpkg-deb at one point? No clue. The apt segfault went away
after setting Cache-Limit to 50331648 - but why did it only start doing that
after a couple of goes? Couldn't say.

I suspect that all of my problems are secondary damage rooted in a problem I had
the first time I tried the update: installing ia32-apt-get requires a ton of
entropy to generate a private key (why? beats me). Unfortunately, my system
didn't seem to be able to generate sufficient randomness even after an evening
of use, so eventually I ^Cd it just so that at least the dpkg database lock
would be released. I'm aware that this isn't a good idea, but I didn't feel that
I had a great deal of choice - plus I've never had a partial package install be
such a headache to clean up before. Curiously, in my later repeats of the
process it never took more than a couple of minutes to generate enough entropy,
and usually it was less than a minute, so I'm not sure why it had such a problem
the first time.

Or maybe that, once cleaned up, wasn't the end of the world after all. Another
possibility is that I didn't realise until I'd read the other thread that you
need to use apt-get to complete the process, so I just used aptitude the first
couple of goes, as I usually do.

>>
>> So I'll just ask a couple of questions instead:
>>
>> Is there any way of preventing this kind of major breakage in the future?
>> I don't think many people expect that upgrading one package will FUBAR
>> the packaging system.
>>
>> Is there any chance of Wine becoming functional on amd64 in the forseeable
>> future?
>
> # apt-get install ia32-wine

Except that it's really:
apt-get update
apt-get upgrade
apt-get update
apt-get install ia32-wine

Rather than:
aptitude update
aptitude install wine

At least that's what I assume. I can't get past the second apt-get update
without something breaking.

> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following extra packages will be installed:
>  ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl
>  ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane
>  ia32-wine-bin ia32-wine-utils
> Suggested packages:
>  wine-doc binfmt-support ttf-mscorefonts-installer winbind avscan klamav
>  clamav
> Recommended packages:
>  ttf-liberation
> The following NEW packages will be installed:
>  ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl
>  ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane
>  ia32-wine ia32-wine-bin ia32-wine-utils
> 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded.
> Need to get 11.0MB of archives.
> After this operation, 51.4MB of additional disk space will be used.
> Do you want to continue [Y/n]? y
> ...
>
> % winemine
>
> Have fun. Works both with sid and experimental wine. Provided you have
> a lib32ncurses5 and lib32readline5 with the lib32 transition completed
> that is. Bug the respective maintainers for that one.
>
>> Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and
>> 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting
>> populace? Reading them in the process of trying to unfuck my system made me
>> feel more than slightly ill.
>
> Since my package was sponsored I would assume at least one other
> person looked over it. You are the first to mention illness. I can't
> change what it does. But do you have suggestion to improve how it does
> things in preinst/postinst/postrm?
>

To be honest, I say we take off and nuke the entire site from orbit.
You can't just hack together a quick shell script for something that major. It's
far too brittle.

> Latest source is on svn.debian.org pkg-ia32-libs:
> http://svn.debian.org/wsvn/pkg-ia32-libs/trunk/ia32-libs-tools/#_trunk_ia32-libs-tools_
>

This entire direction is a dead end. Having these extra package databases and
dpkg-diversions only works in a very narrow set of circumstances. It's only a
workable solution if you assume that everyone:

* Uses apt-get and nothing else
* Doesn't care about having other package-related tools like apt-file fully
functional
* Doesn't care about packages not being shown 'correctly' in eg.
aptitude/apt-cache search, at least until the magic setup process is complete.
* Reads the documentation and knows that they have to c

Bug#535224: ITP: libnetdude -- framework to netdude program

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: libnetdude
  Version : 0.11
  Upstream Author : Christian Kreibich 
* URL : http://netdude.sourceforge.net
* License : specific
  Description : framework to netdude program

 libnetdude is the base of the netdude program. It is the core of the framework
 and the place where the packet manipulations are performed. It allows you to
 implement trace file manipulations at a much higher level of abstraction than
 code written directly on top of the pcap library. It also provides a
 command-line interface that directly lets you script all packet-mangling
 capabilities provided by the set of plugins you have installed. Libnetdude's
 features include:
 
 * Convenient abstractions for trace files, trace parts & areas, packets,
   filters, and packet iterators.
 * Ability to edit arbitrarily large traces (subject to the large-file size
   limit on your OS). Traces are navigated using timestamps and fractional
   offsets.
 * Ability to insert and delete packets.
 * Flexible plugin architecture: Protocol plugins allow interpretation of
   arbitrary protocol data. Feature plugins provide helpful building blocks
   (like anonymizers, statistical analyzers, demultiplexers, etc.) in a reusable
   fashion.
 * Structured packet data. Raw packet data is interpreted as much as the
   installed protocol plugins permit it to. No need to write your own protocol
   analyzer any more.
 * Familiar tcpdump output: libnetdude can associate a tcpdump process with each
   trace file, providing tcpdump's familiar output for individual packets. The
   GUI application is making extensive use of this.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

[Fwd: Delivery Status Notification (Failure)]

[Luk Claes]

Hi

Below the content of a bounce I got when replying to a wanna-build
request... blacklisting domains seems to be accepted as the ones in
control of its mailservers should be able to fix possible issues, but
blacklisting all mail based on the country part of a domain??!

I guess it's another sign that we already lost against spammers?

Cheers

Luk

 Original Message 
Subject: Delivery Status Notification (Failure)
Date: 30 Jun 2009 23:05:42 +0200
From: Mail Delivery System 
To: l...@debian.org

The following message to  was undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 550-'5.7.0 ... Your
country has been blacklisted due to its serious SPAM problems'


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

Re: ia32-libs transition

[Joerg Jaspert]

>>> Will you do security support and regular uploads for it too? Or just a
>>> one shot upload? Will you stand against ftp-masters whish to remove
>>> it?
>> You are actively working with all you can do to not only let us hate it
>> but actually consider removing it completly. Good job.
> Not being a DD, my thoughts may be meaningless here; but as an amd64 Debian 
> user, I think I should speak in defence of Goswin.

> Waiting for multi-arch, Goswin's system permits me to use wine (and chromium 
> browser) on my 64bits Debian.

A simple chroot will permit you to use this. And is a much saner thing
than anything we have seen until now.

> If I understand well, ia32-libs was not acceptable in its state for ftp-
> masters. I think that having all the ia32-* packages would not be acceptable 
> either.

ia32-libs has a much larger history than the small one known here.

> The right thing would be to have multi-arch, but it will come when it's 
> ready (that's not a bad thing).

Not having m-a now isnt a good reason to willingly produce a known
broken thing.


-- 
bye, Joerg
 if klecker.d.o died, I swear to god, I'm going to migrate to gentoo.


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

Re: Multiarch

[Steve Langasek]

On Tue, Jun 30, 2009 at 07:36:03PM +0200, Goswin von Brederlow wrote:
> Thanks for clarifying that. Didn't sound like that before.

> Do you have any minutes of the meeting you could include in the
> debian wiki?

The spec is the synthesis of what was discussed during the meeting.  The
live minutes can also be found on gobby.ubuntu.com
(fountations-karmic-multiarch-support), but I don't expect there to be
anything of interest there.

> It probably wouldn't hurt to put the proposal there too and update it
> as more details are cleared up?

Yes, it would.  We don't need to have two copies of the spec in two
different wikis.  The current URL is already referenced in other places;
please just link to this page from wiki.debian.org/multiarch (if you think
it's appropriate), and when things are finalized we can move it to a more
permanent, less wiki-y location.

-- 
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: ia32-libs transition

[Yannick]

Joerg Jaspert wrote:

> On 11797 March 1977, Goswin von Brederlow wrote:
> 
>> Will you do security support and regular uploads for it too? Or just a
>> one shot upload? Will you stand against ftp-masters whish to remove
>> it?
> 
> You are actively working with all you can do to not only let us hate it
> but actually consider removing it completly. Good job.

Not being a DD, my thoughts may be meaningless here; but as an amd64 Debian 
user, I think I should speak in defence of Goswin.

If I understand well, ia32-libs was not acceptable in its state for ftp-
masters. I think that having all the ia32-* packages would not be acceptable 
either.

The right thing would be to have multi-arch, but it will come when it's 
ready (that's not a bad thing).

Waiting for multi-arch, Goswin's system permits me to use wine (and chromium 
browser) on my 64bits Debian.

Of course, Goswin made mistakes as ia32-apt-get does not warn the user about 
the need of pining i386 packages and try to install converted binary ones. 
But his propositions to limit the conversion to library packages may solve 
the issue.

Maybe all of this should go to experimental (is there a problem with wine 
depending on experimental packages for amd64?) but thank you Goswin for your 
work.

Yannick





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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Emilio Pozuelo Monfort]

Neil Williams wrote:
> On Tue, 30 Jun 2009 14:30:41 +0200
> Ludovic Brenta  wrote:
>> - I will prominently mark the package as deprecated and discourage
>> new packages from using it. As part of this I will move the package
>> to main/oldlibs.
> 
> A note in the description is one way but are there other steps you
> would use to implement this discouragement?

You could hide the public APIs around some

#ifdef GTK_EXTRA_I_KNOW_I_SHOULDT_BE_USING_THIS_CODE
...
#endif

You would need to fix the (four) build-rdepends so that they don't FTBFS though.

Emilio



signature.asc
Description: OpenPGP digital signature

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Josselin Mouette]

Le mardi 30 juin 2009 à 19:44 +0100, Neil Williams a écrit :
> The main point is that using gtk+extra2 in an application makes it very
> difficult to migrate that package to GTK+3.0 so I really don't want new
> applications to use gtk+extra2.

They should be migrated to use the widgets that already exist. GTK+ now
has an icon view widget, and I think the spreadsheet and chart widgets
can be found in libgoffice.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: ia32-libs transition

[Joerg Jaspert]

On 11797 March 1977, Goswin von Brederlow wrote:

> Will you do security support and regular uploads for it too? Or just a
> one shot upload? Will you stand against ftp-masters whish to remove
> it?

You are actively working with all you can do to not only let us hate it
but actually consider removing it completly. Good job.

-- 
bye, Joerg
Free Beer is such a good thing and Free Speech too. Debian is about the
both.


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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Neil Williams]

On Tue, 30 Jun 2009 14:30:41 +0200
Ludovic Brenta  wrote:

> > Yes, but that will also mean package using gtk-extra2 will not be
> > able to link to gtk3, which is what Neil was saying IIUC.
> 
> OK, not a big deal for as long as GTK+2 remains in Debian.

The main point is that using gtk+extra2 in an application makes it very
difficult to migrate that package to GTK+3.0 so I really don't want new
applications to use gtk+extra2. oldlibs does sound like a good idea -
life around gtk+extra2 is always quiet. I can only hope that moving to
oldlibs is *enough* to dissuade anyone from writing new code against it.

> > Hopefully not as long as with gtk1.2 though, so that's
> > why trying to build your packages with the preprocessor defines is
> > good.
> 
> As Neil explained, building gtk+extra with the preprocessor defines
> triggers _lots_ of warnings about usage of deprecated symbols and
> fixing them is a _lot_ of work, so I won't bother.

:-)

If the widgets you need in gtkada are some of the ones causing those
warnings, you're going to have to deal with those.
 
> - I will adopt the package gtk+extra and maintain it in Debian for as
> long as GTK+2 is in Debian and libgtkada2 needs it.

OK. Thanks for taking it on.

> - I will not update the package to use GTK+3.
> - I will prominently mark the package as deprecated and discourage
> new packages from using it. As part of this I will move the package
> to main/oldlibs.

A note in the description is one way but are there other steps you
would use to implement this discouragement?

> - I will inform GtkAda's upstream about the pending removal of GTK+2
> which will happen in the future, probably after June 2010; this gives
> them one year to reimplement the GtkAda widgets that presently use gtk
> +extra with GTK+3.

I wish them good luck. :-)

Not only would gtkada need to port the gtk+extra2 widgets but *then*
port the rest of gtkada to GTK+3.0. This is the hurdle, because the use
of gtk+extra2 makes it harder than necessary to migrate the rest of a
package to GTK+3.0.

> - When a new upstream version of GtkAda removes the dependency on gtk
> +extra or GTK+2 disappears from Debian, I will ask for removal of the
> package.
> 
> OK?

Yes, that's fine by me. Feel free to use / retitle the existing bug
report for removal of gtk+extra2 dependency filed against gtkada.
 
> PS. I trimmed the CC: list since I think everyone on this thread
> monitors debian-devel by now.

OK. (I'm subscribed to -devel too. Sorry for the extra CC's, I wasn't
sure who was subscribed.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpapzs9puUJW.pgp
Description: PGP signature

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Emilio Pozuelo Monfort]

Ludovic Brenta wrote:
> OK, I think that explains it.  Here is what I propose:
> 
> - I will adopt the package gtk+extra and maintain it in Debian for as long as
> GTK+2 is in Debian and libgtkada2 needs it.
> - I will not update the package to use GTK+3.
> - I will prominently mark the package as deprecated and discourage new 
> packages
> from using it. As part of this I will move the package to main/oldlibs.
> - I will inform GtkAda's upstream about the pending removal of GTK+2 which 
> will
> happen in the future, probably after June 2010; this gives them one year to
> reimplement the GtkAda widgets that presently use gtk+extra with GTK+3.
> - When a new upstream version of GtkAda removes the dependency on gtk+extra or
> GTK+2 disappears from Debian, I will ask for removal of the package.
> 
> OK?

Sounds good to me.

Best,
Emilio



signature.asc
Description: OpenPGP digital signature

Bug#535206: ITP: libpcapnav -- wrapper to libpcap

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: libpcapnav
  Version : 0.8
  Upstream Author : Christian Kreibich 
* URL : http://netdude.sourceforge.net
* License : specific
  Description : wrapper to libpcap

libpcap wrapper library that allows navigation to arbitrary packets in a
tcpdump trace file between reads, using timestamps or percentage offsets.

It was originally based on Vern Paxson's tcpslice tool.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
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: ia32-libs depends on ia32-apt-get ?

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le mardi 30 juin 2009 à 18:52 +0200, Goswin von Brederlow a écrit :
>> Please stop confusing ia32-apt-get with multiarch. It clearly is a
>> kludge to keep 32bit binaries working till there is multiarch. It is
>> not ment as a replacement.
>
> No, it is not a kludge. It is a horrible pile of trash.
>
> ia32-libs, in the state it was before you broke it, was a kludge. One
> that we can live with until multiarch is ready.

ftp-master disagreed.

> Now if you could just revert the changes in ia32-libs and spend the time
> you are currently wasting on ia32-apt-get helping with multiarch, that
> would be more helpful.
>
> Thanks,

I didn't change anything in ia32-libs. It was replaced completly. So
just checkout ia32-libs from svn, increase the version and upload. But
then you have to maintain it and do security support for it too.

MfG
Goswin


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

Re: ia32-libs transition

[Goswin von Brederlow]

Didier 'OdyX' Raboud  writes:

> Goswin von Brederlow wrote:
>
>> Aneurin Price  writes:
>> 
>>> Hi,
>>>
>>> I've just spent over an hour writing and rewriting this mail, and
>>> determined that I can't think of a single constructive thing to say.
>>>
>>> So I'll just ask a couple of questions instead:
>>>
>>> Is there any way of preventing this kind of major breakage in the future?
>>> I don't think many people expect that upgrading one package will FUBAR
>>> the packaging system.
>>>
>>> Is there any chance of Wine becoming functional on amd64 in the
>>> forseeable future?
>> 
>> # apt-get install ia32-wine
>> (...)
>> 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded.
>> Need to get 11.0MB of archives.
>> After this operation, 51.4MB of additional disk space will be used.
>> Do you want to continue [Y/n]? y
>> ...
>> 
>> % winemine
>> 
>> Have fun. Works both with sid and experimental wine. Provided you have
>> a lib32ncurses5 and lib32readline5 with the lib32 transition completed
>> that is. Bug the respective maintainers for that one.
>
> Hi Goswin, 
>
> Sorry, but that's plain false. The package ia32-wine is non-existant.
>
> # apt-get install ia32-wine
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Couldn't find package ia32-wine
>
> But the package "wine" is and here is what I get :
>
> # apt-get install wine
> (...) works
>
> $ winemine
> (does not work)
>
> Regards, 
>
> OdyX

Small addition. The reason that wine breaks there is that libc6-i386
is missing a Breaks:  and wine is missing a
Pre-Depends: libc6-i386 (>= 2.9-18). The existing wine packages (if
they are to be kept) need to to the lib32 link -> directory
transition. Just one more SNAFU of libc6, not my fault.

MfG
Goswin


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

Re: Multiarch

[Goswin von Brederlow]

Steve Langasek  writes:

> On Mon, Jun 29, 2009 at 09:02:05PM +0100, Matthew Johnson wrote:
>> I've also CC'd Hector and Steve who are listed as owners on that
>> document because whatever we do to get multiarch working (and I have no
>> strong views on the right way to do it) we should definitely not do it
>> differently to Ubuntu.
>
> Since there seems to be some confusion on this point, let me clarify that
> there is no proposal for Ubuntu to diverge from Debian in implementing
> multiarch.  A session on multiarch was held at UDS because it was
> convenient for a face-to-face discussion of *Debian* package management.
> Most of the people involved in the discussion were Debian developers,
> including both a dpkg comaintainer (Guillem) and an apt comaintainer
> (Michael).  While the specification resides in the Ubuntu wiki, I'm
> anticipating that the implementation will be driven directly in Debian
> first, thanks in large part to Guillem's interest.  And indeed, Ubuntu is
> largely at Guillem's mercy, since no one in Ubuntu has committed any
> resources to the dpkg implementation. :)
>
> We also have a follow-up round table scheduled at DebConf, to take this
> further:
>
>   https://penta.debconf.org/penta/submission/dc9/event/395

Thanks for clarifying that. Didn't sound like that before.

Do you have any minutes of the meeting you could include in the
debian wiki?

It probably wouldn't hurt to put the proposal there too and update it
as more details are cleared up?

MfG
Goswin


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

Re: ia32-libs transition

[Goswin von Brederlow]

Jonas Meurer  writes:

> On 30/06/2009 Goswin von Brederlow wrote:
>> > Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and
>> > 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting
>> > populace? Reading them in the process of trying to unfuck my system made me
>> > feel more than slightly ill.
>> 
>> Since my package was sponsored I would assume at least one other
>> person looked over it. You are the first to mention illness. I can't
>> change what it does. But do you have suggestion to improve how it does
>> things in preinst/postinst/postrm?
>
> it seems like the whole ia32 transition is a major illness.
>
> apt-get now installs random packages from i386 over the ones from amd64 in
> case that the version from i386 is superior. that just happened for
> initscripts sysvinit sysvinit-utils and rar on my system.
>
> why the heck does ia32-apt-get replace amd64 packages with i386 ones at
> all? is this an attempt to slowly migrate amd64 systems to i386 ones?
>
> greetings,
>  jonas

Because you didn't read the NEWS. Given the number of people that
don't read NEWS or have generally been surprised of ia32-apt-get
introducing 32bit packages to the system the next upload of
ia32-apt-get will be more explicit about this and only activate after
the user confirmed its use.

Actualy some constructive discussion on irc about this problem has
revealed a possible solution. Binary packages, those that don't get an
ia32- prefix, can easily be filtered out of the Packages files
preventing any replacement of 64bit packages with 32bit. That also
prevents things like skype to be listed though. So I intend to add a
debconf question:

  Do you want to
  [ ] abort installing ia32-apt-get
  [ ] only allow 32bit libraries
  [ ] allow 32bit libraries and binaries
  (DANGER: see docs about pining)

or something of that sort.


Will that satisfy you?

MfG
Goswin


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

Re: ia32-libs depends on ia32-apt-get ?

[Mark Brown]

On Tue, Jun 30, 2009 at 06:56:11PM +0200, Goswin von Brederlow wrote:
> Mark Brown  writes:

> > Then bring that up and try to move the discussion forward (as now seems
> > to be happening).  The approach that's currently being pused seems like
> > a blind alley.

> People really do seem to confuse this. ia32-apt-get is not an
> alternative to multiarch. Never has been, never will be.

It looks awfully like a bodged version of multiarch - doing what you're
doing and installing i386 packages on amd64 appears to be one of the
biggest use cases for multiarch, after all.


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

Re: ia32-libs depends on ia32-apt-get ?

[Josselin Mouette]

Le mardi 30 juin 2009 à 18:52 +0200, Goswin von Brederlow a écrit :
> Please stop confusing ia32-apt-get with multiarch. It clearly is a
> kludge to keep 32bit binaries working till there is multiarch. It is
> not ment as a replacement.

No, it is not a kludge. It is a horrible pile of trash.

ia32-libs, in the state it was before you broke it, was a kludge. One
that we can live with until multiarch is ready.

Now if you could just revert the changes in ia32-libs and spend the time
you are currently wasting on ia32-apt-get helping with multiarch, that
would be more helpful.

Thanks,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: ia32-libs transition

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le mardi 30 juin 2009 à 01:55 +0100, Aneurin Price a écrit :
>> Is there any way of preventing this kind of major breakage in the future?
>> I don't think many people expect that upgrading one package will FUBAR
>> the packaging system.
>
> Report a critical bug against the package. Arrange so that it can never
> migrate to testing.
>
>> Is there any chance of Wine becoming functional on amd64 in the forseeable
>> future?
>
> Yes: hijack the ia32-libs package.

Will you do security support and regular uploads for it too? Or just a
one shot upload? Will you stand against ftp-masters whish to remove
it?

If so then do join the ia32-libs team on alioth and make an
upload. I'm sure Bdale and Frederick have nothing against it. But then
you need to do the work too, not just the talk.

MfG
Goswin




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

Re: ia32-libs transition

[Goswin von Brederlow]

Didier 'OdyX' Raboud  writes:

> Goswin von Brederlow wrote:
>
>> Aneurin Price  writes:
>> 
>>> Hi,
>>>
>>> I've just spent over an hour writing and rewriting this mail, and
>>> determined that I can't think of a single constructive thing to say.
>>>
>>> So I'll just ask a couple of questions instead:
>>>
>>> Is there any way of preventing this kind of major breakage in the future?
>>> I don't think many people expect that upgrading one package will FUBAR
>>> the packaging system.
>>>
>>> Is there any chance of Wine becoming functional on amd64 in the
>>> forseeable future?
>> 
>> # apt-get install ia32-wine
>> (...)
>> 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded.
>> Need to get 11.0MB of archives.
>> After this operation, 51.4MB of additional disk space will be used.
>> Do you want to continue [Y/n]? y
>> ...
>> 
>> % winemine
>> 
>> Have fun. Works both with sid and experimental wine. Provided you have
>> a lib32ncurses5 and lib32readline5 with the lib32 transition completed
>> that is. Bug the respective maintainers for that one.
>
> Hi Goswin, 
>
> Sorry, but that's plain false. The package ia32-wine is non-existant.
>
> # apt-get install ia32-wine
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Couldn't find package ia32-wine

Ia32-wine is only available when ia32-apt-get is installed. I assumed
you already had that. What exactly will happen with wine or how
exactly it will do the trick to be installable out of the box isn't
fixed yet. It is possible the same 2 stage install as ia32-libs will
be used or something better.

> But the package "wine" is and here is what I get :
>
> # apt-get install wine
> (...) works
>
> $ winemine
> (does not work)

That will install the wine_..._amd64.deb that is in unstable but
missing in experimental for the latest version. Depending on the
solution it might disapear in unstable or be repalced by a Meta
package of one form or another.

>From talking to the wine maintainer I know that in the not to distant
future wine will support the win64 API so you can run 64bit windows
programs. So the actualy outcome might be that you have 3 packages:
wine, ia32-wine and wine64. Where wine would pull in ia32-wine and
wine64 and an contain a wrapper so "wine foo.exe" calls the right one.

You will have to see how wine will turn out.

MfG
Goswin


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

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Tue, 30 Jun 2009, Charles Plessy wrote:
> -The meta-information would be stored in a set of RFC-2822 compliant
> -fields. Those fields should start on the first non-empty line (after
> -having stripped whitespace characters at the start and end of lines).
> +The meta-information would be stored in a set of fields with a syntax
> +similar to the RFC 2822 or Debian control files. More precisely:

You remove the sentence that says where those fields should start. You
should put it back IMO. We allow for empty lines before the fields
(particulary for the dpatch case, I find it nicer to be able to leave
one empty line after the shebang).

> +Fields are logical elements composed of a field name, followed by a colon 
> (":"),
> +followed by a field body, and terminated by a "line feed" character followed 
> by
> +any character except "space".

You should mention the optional (but usal) space(s) after the colon. It's
not part of the field body AFAIK. And you can remove the "any character
except space" because a line with spaces only can also terminate a field
(it also terminates the whole set of fields however):

Field: body
 continuation line
 
something else



> A field name is composed of printable characters,
> +except "colon". A field body is composed of any character except "line feed"
> +unless when it is followed with a space, in which case the space is ignored. 
> As
> +a special exception, in the sequence of "line feed", "space", "dot" (.), 
> "line
> +feed", "space", the spaces are ignored and the dot is replaced by a space.

That description of the field body is not very clear and easy to
understand. Maybe it should simply explain how single-line values
and multi-lines values are encoded ?

Maybe:

The field body is composed of any character. To avoid problems with
multi-line values, any line feed character must be followed by a space.
The line that follows is called a continuation line. Furthermore empty
lines are replaced by a single dot character.


> +Lines that do not belong to a field body and do not start a new field are 
> plain
> +comments.

This looks wrong. Free form comments are meant to be after the set of
fields. We can't allow arbitrary data in the middle and assume they are
comments. Embedded comments are allowed in debian/control but they must
start with "#".

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: ia32-libs depends on ia32-apt-get ?

[Goswin von Brederlow]

Mark Brown  writes:

> On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote:
>> Mark Brown  writes:
>
>> > There seems to be at least some crossover between the people who were
>> > looking at multiarch and the people doing this stuff.
>
>> But not the people blocking the inclusion of patches for multiarch
>> already present in the BTS.
>
> Then bring that up and try to move the discussion forward (as now seems
> to be happening).  The approach that's currently being pused seems like
> a blind alley.

People really do seem to confuse this. ia32-apt-get is not an
alternative to multiarch. Never has been, never will be.

It is the ugly hack that keeps existing things running till mutliarch
fixes the problem.


The only thing ia32-apt-get is supposed to fix is ia32-libs and
ia32-libs-gtk unmaintainability and security bugs.

MfG
Goswin


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

Re: ia32-libs depends on ia32-apt-get ?

[Goswin von Brederlow]

Steve Langasek  writes:

> On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote:
>> Raphael Hertzog  writes:
>
>> > There is work going on recently. Steve Langasek drafted a plan that he
>> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
>> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
>> > reality inside Debian but I don't know of any timeframe.
>
>> > https://wiki.ubuntu.com/MultiarchSpec
>
>> They messed up some finer details, broke the existing patches,
>
> Patches implementing what?  I don't see any public discussion of an agreed
> design for the package manager.

Patches for dpkg to accept the Multi-Arch field as a tristate of Yes,
No or missing and for packages to set that field. It's been
yes/no/missing in all the mails about multiarch for years and suddnely
you changed the string.

> (Nor is there one for the MultiarchSpec, but that's only because Guillem and
> I are still hammering out some of the details that we don't yet agree on; so
> a public announcement is a little bit premature.)

So you do that in a dark corner ignoring any other people that worked
on multiarch before? You are only 2 people, you only have 4 eyes (I
assume). You are bound to miss something that a larger group would
spot.

>> made the whole thing need a full release cycle for a transition due to
>> DEBIAN/control format changes
>
> You appear to be referring to
> .
> What do you propose as an alternative that would let us achieve multiarch
> sooner?  Multiarch has already failed to get traction for more than two

Look at perl for example:

Package: perl-base
Provides: perlapi-5.10.0

I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
matching ABI can then easily depend on the right package.

The dh_perl helper could add the dependency automatically allowing a
binNMU to transition many packages.

> release cycles, and I don't see that your ia32-apt-get kludges are doing
> anything to get us there sooner.

Please stop confusing ia32-apt-get with multiarch. It clearly is a
kludge to keep 32bit binaries working till there is multiarch. It is
not ment as a replacement.

> Also, what are the immediate practical use cases for cross-arch depends on
> extensible interpreters such as python and perl?  Wine doesn't need this,
> nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
> requiring that class of dependencies to be deferred by a release cycle?

Say you have:

Package: foo
Architecture: amd64
Depends: perl

Package: bar
Architecture: i386
Depends: perl

Package: libbaz-perl
Architecture: amd64
Depends: perl

Package: libbat-perl
Architecture: i386
Depends: perl

Foo and Bar are binary packages that in some way use perl as a simple
interpreter. Libbaz-perl and libbat-perl on the other hand are
bindings for perl to use 2 C libraries libbaz and libbat.

Now with your proposal you have a few options:

1) perl has no Multi-Arch field
   Eigther foo can be installed or bar. But never both.

2) perl has Multi-Arch: same
   Now perl:i386 and perl:amd64 are flagged as coinstallable. Not
   supported.

3) perl has Multi-Arch: foreign
   Now foo and bar can be installed but so can libbaz-perl and
   libbat-perl. One of the libs will be broken.

4) Using Depends: perl [same]
   This would allos foo and bar to be both installed but only the
   right one of libbaz-perl and libbat-perl. But that takes a release
   cycle to introduce the new syntax.
   Note that you also need perl to break libbaz-perl and libbat-perl
   versions prior to the ones with "Depends: perl [same]" or yet
   another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
   suffers from the same problem.

>> and have a broken plan for -dev packages.
>
> Handling of -dev packages is defined as *out of scope* for this
> specification.  I fail to see how it's broken to confine the initial scope
> to those elements that impact the package management tools, to avoid getting
> bogged down in irrelevant discussions about filesystem layouts.

Actually the filesystem layout for -dev packages is no problem at
all. We already have /usr/include/$(DEB_HOST_GNU_TYPE) for include
files (where needed) and /usr/lib/$(DEB_HOST_GNU_TYPE) for the *.so
links. That part might be work but not a problem.

The problem is in the dependencies and actually not restricted to just
-dev packages. Transitional/Meta packages suffer from this in
general. For the sake of an example lets say you have the following
packages (xlibs-dev being a real example):

Source: foo
Build-Depends: xlibs-dev, bar

Package: xlibs-dev
Architecture: all
Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...

Package: libice-dev
Architecture: any
Multi-Arch: same

Package: bar
Architecture: any
Multi-Arch: foreign
Depends: baz

Package: ba

Sad news

[Kapil Hari Paranjape]

Hello,

Eitan Gurari, who created the TeX4HT system for converting from
TeX/LaTeX to different forms of hypertext, has passed away.

 http://www.cse.ohio-state.edu/news/news102.shtml

This is indeed sad news. The TeX user community and more generally
people who worked on preparing technical documents for the web will
surely mourn this loss of an outstanding and original contributor.
As a distributor of his software for the community, Debian will
too.

Regards,

Kapil.
--


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

Re: Bug#535143: ITP: gnome-do-docklets -- Dock applets for GNOME Do's "Docky" interface.

[brian m. carlson]

On Tue, Jun 30, 2009 at 02:37:51PM +1000, Christopher James Halse Rogers wrote:
> * Package name: gnome-do-docklets
>   Version : 0.8.2
>   Upstream Author : Jason Smith 
> * URL : http://do.davebsd.org/

This should be .

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Charles Plessy]

Le Tue, Jun 30, 2009 at 08:49:21AM +0200, Raphael Hertzog a écrit :
> On Tue, 30 Jun 2009, Charles Plessy wrote:
> > * “The meta-information would be stored in a set of RFC-2822 compliant 
> > fields.”
> > 
> > RFC-2822 distinguishes between “unstructured” and “structured” fields. The
> > ‘Description’ field you propose is not unstructured, since the first line 
> > has a
> > special role, but is not structured in the RFC-2822 way, since that would 
> > mean
> > for instance that things between parenthesis are comments. Moreover, having 
> > a
> > special role for the first CRLF sign is not consistant with the folding 
> > rules
> > of the RFC. Given that in addition RFC-2822 is non-free and therefore can 
> > not
> > be distributed in the Debian operating system, I think that it would be 
> > safer
> > to write “in the spirit of the RFC-2822” of even “in the spirit of the 
> > Debian
> > control files”, and write black on white what parsers should expect. Then we
> > can point to DEP3 in DEP5 ;) 
> 
> I prefer discussing a real patch here.

Maybe something like this?

Index: dep3.mdwn
===
--- dep3.mdwn   (revision 69)
+++ dep3.mdwn   (working copy)
@@ -47,10 +47,19 @@
 
 Structure
 -
-The meta-information would be stored in a set of RFC-2822 compliant
-fields. Those fields should start on the first non-empty line (after
-having stripped whitespace characters at the start and end of lines).
+The meta-information would be stored in a set of fields with a syntax
+similar to the RFC 2822 or Debian control files. More precisely:
 
+Fields are logical elements composed of a field name, followed by a colon 
(":"),
+followed by a field body, and terminated by a "line feed" character followed by
+any character except "space". A field name is composed of printable characters,
+except "colon". A field body is composed of any character except "line feed"
+unless when it is followed with a space, in which case the space is ignored. As
+a special exception, in the sequence of "line feed", "space", "dot" (.), "line
+feed", "space", the spaces are ignored and the dot is replaced by a space.
+Lines that do not belong to a field body and do not start a new field are plain
+comments.
+
 For patch-systems like dpatch that require the patch to be a standalone
 script, the shebang line is ignored and it is possible to put those fields
 in comments. The line should then follow the format "`# `". For



Cheers,

-- 
Charles


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

Re: ia32-libs transition

[Jonas Meurer]

On 30/06/2009 Goswin von Brederlow wrote:
> > Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and
> > 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting
> > populace? Reading them in the process of trying to unfuck my system made me
> > feel more than slightly ill.
> 
> Since my package was sponsored I would assume at least one other
> person looked over it. You are the first to mention illness. I can't
> change what it does. But do you have suggestion to improve how it does
> things in preinst/postinst/postrm?

it seems like the whole ia32 transition is a major illness.

apt-get now installs random packages from i386 over the ones from amd64 in
case that the version from i386 is superior. that just happened for
initscripts sysvinit sysvinit-utils and rar on my system.

why the heck does ia32-apt-get replace amd64 packages with i386 ones at
all? is this an attempt to slowly migrate amd64 systems to i386 ones?

greetings,
 jonas


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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Ludovic Brenta]

Selon Emilio Pozuelo Monfort :
> Ludovic Brenta wrote:
>> So, my understanting was correct then: gtk-extra2 will FTBFS only when
>> you remove GTK+2 from Debian, not when you introduce GTK+3.
> 
> Yes, but that will also mean package using gtk-extra2 will not be able to
> link to gtk3, which is what Neil was saying IIUC.

OK, not a big deal for as long as GTK+2 remains in Debian.

>> Joss, can you tell me
>> whether you intend for there to be a transition period when both GTK+2
>> and GTK+3 are in Debian?
> 
> Sure there will be.

Great.

> Hopefully not as long as with gtk1.2 though, so that's
> why trying to build your packages with the preprocessor defines is good.

As Neil explained, building gtk+extra with the preprocessor defines triggers
_lots_ of warnings about usage of deprecated symbols and fixing them is a
_lot_ of work, so I won't bother.

>> My intention is neither to take over maintenance of
>> gtk-extra nor to remove functionality from GtkAda; rather to try and give
>> a clear roadmap for upstream to plan the necessary changes, i.e.
>> reimplementing some of GtkAda's widgets with GTK+3 instead of gtk-extra.
> 
> GTK+3 will be released around March 2010 or so. When GTK+2 will be removed
> we don't really know, but don't wait till the last moment or it may be too
> late :)

OK, I think that explains it.  Here is what I propose:

- I will adopt the package gtk+extra and maintain it in Debian for as long as
GTK+2 is in Debian and libgtkada2 needs it.
- I will not update the package to use GTK+3.
- I will prominently mark the package as deprecated and discourage new packages
from using it. As part of this I will move the package to main/oldlibs.
- I will inform GtkAda's upstream about the pending removal of GTK+2 which will
happen in the future, probably after June 2010; this gives them one year to
reimplement the GtkAda widgets that presently use gtk+extra with GTK+3.
- When a new upstream version of GtkAda removes the dependency on gtk+extra or
GTK+2 disappears from Debian, I will ask for removal of the package.

OK?

PS. I trimmed the CC: list since I think everyone on this thread monitors
debian-devel by now.

-- 
Ludovic Brenta.


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

Re: ia32-libs transition

[Bernd Zeimetz]

Josselin Mouette wrote:
> Le mardi 30 juin 2009 à 01:55 +0100, Aneurin Price a écrit :
>> Is there any way of preventing this kind of major breakage in the future?
>> I don't think many people expect that upgrading one package will FUBAR
>> the packaging system.
> 
> Report a critical bug against the package. Arrange so that it can never
> migrate to testing.
> 
>> Is there any chance of Wine becoming functional on amd64 in the forseeable
>> future?
> 
> Yes: hijack the ia32-libs package.
> 

please do so.


-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Bug#534507: ITP: kalternatives -- graphical alternatives system configuration tool

[Pino Toscano]

Hello,

> I've skimmed over the sources, and it seems kalternatives is reading
> and writting directly to the alternatives db (under
> /var/lib/dpkg/alternatives/). The db should be considered internal,
> and we reserve the right to change its layout in the future.
>
> There's been recent changes to update-alternatives to make it more
> friendly and usable by front-ends (specifically the --get/set-selections
> and --query options), could you consider rewritting it using those?
> If the interface is inadequate or too limited we can always extend/fix
> it.
>
> Another option would be to wait a bit, the future plans are to
> rewrite it in C and move part of the db handling to a shared library.

Few days ago, I had a nice talk with Guillem, and he told me that dpkg 
developers are working for cleaning up update-alternatives' code, and planning 
to convert it to C (along with provide a dpkg library); since the previous are 
either happening or planned to be soon, I will avoid to rewrite the parser 
twice, but wait for the dpkg library and help testing it, which is what 
kalternatives will use (when it is ready, of course).

Would it be acceptable for now?
-- 
Pino Toscano


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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Emilio Pozuelo Monfort]

Ludovic Brenta wrote:
> So, my understanting was correct then: gtk-extra2 will FTBFS only when you
> remove GTK+2 from Debian, not when you introduce GTK+3.

Yes, but that will also mean package using gtk-extra2 will not be able to link
to gtk3, which is what Neil was saying IIUC.

> Joss, can you tell me
> whether you intend for there to be a transition period when both GTK+2 and
> GTK+3 are in Debian?

Sure there will be. Hopefully not as long as with gtk1.2 though, so that's why
trying to build your packages with the preprocessor defines is good.

> My intention is neither to take over maintenance of
> gtk-extra nor to remove functionality from GtkAda; rather to try and give a
> clear roadmap for upstream to plan the necessary changes, i.e. reimplementing
> some of GtkAda's widgets with GTK+3 instead of gtk-extra.

GTK+3 will be released around March 2010 or so. When GTK+2 will be removed we
don't really know, but don't wait till the last moment or it may be too late :)

Emilio



signature.asc
Description: OpenPGP digital signature

Re: ia32-libs depends on ia32-apt-get ?

[Mark Brown]

On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote:
> Mark Brown  writes:

> > There seems to be at least some crossover between the people who were
> > looking at multiarch and the people doing this stuff.

> But not the people blocking the inclusion of patches for multiarch
> already present in the BTS.

Then bring that up and try to move the discussion forward (as now seems
to be happening).  The approach that's currently being pused seems like
a blind alley.


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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Ludovic Brenta]

Selon Josselin Mouette :
> Le lundi 29 juin 2009 à 23:30 +0100, Neil Williams a écrit :
> > On Mon, 29 Jun 2009 23:19:45 +0100
> > Neil Williams  wrote:
> > 
> > > gtk+extra2 will FTBFS as soon as the functions that will be removed in
> > > GTK+3.0 become deprecated in GTK+2.0. GTK+2.0 doesn't have to be
> > > removed from Debian for gtk+extra2 to break. Yes, that isn't how
> > > things *should* work and it isn't how other packages *do* work but
> > > gtkextra has been dead upstream for such a long time that bitrot has
> > > all but ensured that this will be the result.
> > 
> > Let me clarify that a bit.
> > 
> > As soon as you take Josselin's advice for preparing the rest of gtkada
> > for GTK3.0, you'll discover that nothing in gtkextra has been prepared
> > for what is *currently* deprecated in GTK+2.0. Fixing that will mean
> > completing the migration of gtk-extra2 through to current GTK+2.0 as
> > well as implementing the transition in gtkada. This is why I cannot
> > implement Josselin's advice in quicklist - it shows up the breakage in
> > gtk-extra2.
> 
> I think you misunderstood my email. What is currently deprecated in GTK+
> 2.0 *is* what will disappear in GTK+ 3.0. But deprecated doesn’t mean
> the functions will disappear. All the current GTK+ 2.0 API will remain
> available until we remove gtk+2.0 from the archive, even deprecated
> functions.

So, my understanting was correct then: gtk-extra2 will FTBFS only when you
remove GTK+2 from Debian, not when you introduce GTK+3.  Joss, can you tell me
whether you intend for there to be a transition period when both GTK+2 and
GTK+3 are in Debian?  My intention is neither to take over maintenance of
gtk-extra nor to remove functionality from GtkAda; rather to try and give a
clear roadmap for upstream to plan the necessary changes, i.e. reimplementing
some of GtkAda's widgets with GTK+3 instead of gtk-extra.

-- 
Ludovic Brenta.


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

Re: Multiarch (Was: Re: ia32-libs depends on ia32-apt-get)

[Steve Langasek]

On Mon, Jun 29, 2009 at 09:02:05PM +0100, Matthew Johnson wrote:
> I've also CC'd Hector and Steve who are listed as owners on that
> document because whatever we do to get multiarch working (and I have no
> strong views on the right way to do it) we should definitely not do it
> differently to Ubuntu.

Since there seems to be some confusion on this point, let me clarify that
there is no proposal for Ubuntu to diverge from Debian in implementing
multiarch.  A session on multiarch was held at UDS because it was
convenient for a face-to-face discussion of *Debian* package management.
Most of the people involved in the discussion were Debian developers,
including both a dpkg comaintainer (Guillem) and an apt comaintainer
(Michael).  While the specification resides in the Ubuntu wiki, I'm
anticipating that the implementation will be driven directly in Debian
first, thanks in large part to Guillem's interest.  And indeed, Ubuntu is
largely at Guillem's mercy, since no one in Ubuntu has committed any
resources to the dpkg implementation. :)

We also have a follow-up round table scheduled at DebConf, to take this
further:

  https://penta.debconf.org/penta/submission/dc9/event/395

-- 
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: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim

[Josselin Mouette]

Le lundi 29 juin 2009 à 23:30 +0100, Neil Williams a écrit :
> On Mon, 29 Jun 2009 23:19:45 +0100
> Neil Williams  wrote:
> 
> > gtk+extra2 will FTBFS as soon as the functions that will be removed in
> > GTK+3.0 become deprecated in GTK+2.0. GTK+2.0 doesn't have to be
> > removed from Debian for gtk+extra2 to break. Yes, that isn't how
> > things *should* work and it isn't how other packages *do* work but
> > gtkextra has been dead upstream for such a long time that bitrot has
> > all but ensured that this will be the result.
> 
> Let me clarify that a bit.
> 
> As soon as you take Josselin's advice for preparing the rest of gtkada
> for GTK3.0, you'll discover that nothing in gtkextra has been prepared
> for what is *currently* deprecated in GTK+2.0. Fixing that will mean
> completing the migration of gtk-extra2 through to current GTK+2.0 as
> well as implementing the transition in gtkada. This is why I cannot
> implement Josselin's advice in quicklist - it shows up the breakage in
> gtk-extra2.

I think you misunderstood my email. What is currently deprecated in GTK+
2.0 *is* what will disappear in GTK+ 3.0. But deprecated doesn’t mean
the functions will disappear. All the current GTK+ 2.0 API will remain
available until we remove gtk+2.0 from the archive, even deprecated
functions.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: ia32-libs transition

[Josselin Mouette]

Le mardi 30 juin 2009 à 01:55 +0100, Aneurin Price a écrit :
> Is there any way of preventing this kind of major breakage in the future?
> I don't think many people expect that upgrading one package will FUBAR
> the packaging system.

Report a critical bug against the package. Arrange so that it can never
migrate to testing.

> Is there any chance of Wine becoming functional on amd64 in the forseeable
> future?

Yes: hijack the ia32-libs package.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: ia32-libs transition

[Didier 'OdyX' Raboud]

Goswin von Brederlow wrote:

> Aneurin Price  writes:
> 
>> Hi,
>>
>> I've just spent over an hour writing and rewriting this mail, and
>> determined that I can't think of a single constructive thing to say.
>>
>> So I'll just ask a couple of questions instead:
>>
>> Is there any way of preventing this kind of major breakage in the future?
>> I don't think many people expect that upgrading one package will FUBAR
>> the packaging system.
>>
>> Is there any chance of Wine becoming functional on amd64 in the
>> forseeable future?
> 
> # apt-get install ia32-wine
> (...)
> 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded.
> Need to get 11.0MB of archives.
> After this operation, 51.4MB of additional disk space will be used.
> Do you want to continue [Y/n]? y
> ...
> 
> % winemine
> 
> Have fun. Works both with sid and experimental wine. Provided you have
> a lib32ncurses5 and lib32readline5 with the lib32 transition completed
> that is. Bug the respective maintainers for that one.

Hi Goswin, 

Sorry, but that's plain false. The package ia32-wine is non-existant.

# apt-get install ia32-wine
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package ia32-wine

But the package "wine" is and here is what I get :

# apt-get install wine
(...) works

$ winemine
(does not work)

Regards, 

OdyX





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

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Lucas Nussbaum]

On 29/06/09 at 22:53 +0200, Raphael Hertzog wrote:
> Lucas Nussbaum suggested to replace "Bug-" with "" while
> Sean Finney suggested that the latter could be an alias for the former. I
> explained that I initially selected "Bug-" because it enables simple
> parsing without encoding a list of known vendors and/or fields. Ubuntu is 
> using
> "" currently but they have stated that breaking that compatibility
> should not be a concern.
> Sub-thread: http://lists.debian.org/debian-devel/2009/06/msg00461.html

While I'm fine with Bug-, I don't think that having a list of
known vendors is a good idea: some upstreams might use their own
bugtracker (like Trac), so having a full list seems impossible.

> After this round, if we don't have any important changes, I'll probably
> announce the format to debian-devel-announce. Should I use this opportunity to
> ask for more review or simply suggest people to start using the format?

I think it would be fine to suggest to use the format.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: ia32-libs depends on ia32-apt-get ?

[Didier 'OdyX' Raboud]

Goswin von Brederlow wrote:

> Didier 'OdyX' Raboud  writes:
>> I would largely prefer if ia32-* in its actual shape would be released in
>> experimental (where, with this level of touching the base of Debian
>> repositories handling, it should sit) and version 2.7 uploaded back in
>> Sid...
> 
> Conflicts with libc6-i386.
> 
>> Regards,
> 
> MfG
> Goswin

Hi Goswin, 

As I see the thing, libc6-i386 Conflicts with everything shipping things in 
/emul/.

What about fixing "just that" in a 1:2.8 upload to unstable ? You could then 
upload your actual "18" series in experimental (2:19 then) where it should 
obviously sit ?

Regards, 

OdyX



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