Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow]

Russ Allbery  writes:

> David Kalnischkies  writes:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery  wrote:
>
>>> Actually, why would that be the behavior?  Why would dpkg --purge foo
>>> not just remove foo for all architectures for which it's installed, and
>>> require that if you want to remove only a specific architecture you
>>> then use the expanded syntax?
>
>> We (as in APT team and dpkg team) had a lot of discussions about that,
>> see for starters (there a properly more in between the 10 months…)
>> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
>> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html
>
>> In short, i think the biggest counter is that it feels unintuitive to
>> install a library (in native arch) with e.g. "apt-get install libfoo"
>> while you have to be specific at removal to avoid nuking 'unrelated'
>> packages with "apt-get remove libfoo".
>
> Ah, hm... I suppose that's a good point, although honestly I wouldn't mind
> having apt-get remove libfoo remove all instances of libfoo that are
> installed.  I think that would be quite reasonable behavior, and don't
> find it particularly unintuitive.
>
> I agree that it's asymmetric.  apt-get install libfoo means libfoo:native,
> but apt-get remove libfoo means libfoo:*.  And asymmetric is bad, all
> things being equal.  But I think this may be one place where asymmetric is
> still the right thing to do; I would argue that it means you're
> implementing the most common operation in both cases.  apt-get install
> libfoo generally means "give me a native libfoo" since non-native libfoo
> is going to be an unusual case, and apt-get remove libfoo generally means
> "I have no more interest in libfoo, make it go away."  I think that people
> who want to get rid of one architecture of libfoo but keep the other are
> already going to be thinking about architectures, and it's natural to ask
> them to qualify their request.

In another thread we discussed the problem with plugins (e.g. input
methods for chinese/japanese) and LD_PRELOAD (e.g. fakeroot) using
stuff. For those packages it would be great if

apt-get install plugin

would install all architectures of the package (for various values of
all :). This would add asymetry in that apt-get install libfoo would
sometimes mean libfoo:native and sometimes libfoo:*. Having apt-get
install libfoo:* for anything M-A:same would make it more symetric in
that case.

"apt-get install libfoo" generaly means "please upgrade libfoo to the
latest version". That should be "apt-get upgrade libfoo" which doesn't
yet exists. Libraries should be pulled in from binaries and not
installed manually so I wouldn't give that case much weight.

Instead concentrate on the more usefull cases:

apt-get install plugin binary libfoo-dev bindings-for-some-interpreter

Plugins will be M-A:same and depend on something M-A:same. They will
have some other indication (to be implemented) that they are
plugins. Libfoo-dev will be M-A:same. Binaries will be M-A:foreign.
Bindings will be M-A:same but depends on something M-A:allowed.

Now think what would be most usefull for those cases.

MfG
Goswin


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

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Goswin von Brederlow]

Serafeim Zanikolas  writes:

> hi Goswin,
>
> On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote [edited]:
>> One thing though: Can I add my own local fragments? Is there a fragment
>> dir in /etc for that?
>
> you can, and they should also go to /usr/share/reconf-inetd (as long as the
> filenames don't conflict with any other packages' fragments [0])
>
> reconf-inetd doesn't care about the origin of fragments in
> /usr/share/reconf-inetd. of course, if you copy a fragment there manually, the
> dpkg trigger will not be activated, so you'll have to run reconf-inetd by hand
>
> btw I've in the meantime uploaded a new revision to unstable.
>
> also, FWIW my FOSDEM DEP9-related talk is now online [1]
>
> cheers,
> sez

Putting local config into /usr/share is wrong though.

Another question: How do I disable a fragment? In udev I can create a
rule file with the same name as one in /lib/udev to disable it. [If it
was covered I'm sorry, Fosdem talks aren't downloaded yet.]

MfG
Goswin


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

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Bernd Zeimetz]

On 02/16/2012 12:22 AM, Serafeim Zanikolas wrote:
> hi Goswin,
> 
> On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote [edited]:
>> One thing though: Can I add my own local fragments? Is there a fragment
>> dir in /etc for that?
> 
> you can, and they should also go to /usr/share/reconf-inetd (as long as the
> filenames don't conflict with any other packages' fragments [0])

No, /usr/share should not be topuched by local stuff. Have a look at
initramfs-tools - the defaults are shipped in /usr/share and whatever
you want to add goes to /etc/initramfs-tools - that is a sane and
obvious way to handle such things.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f3cc8b6.8050...@bzed.de

Re: Bug#655999: [bugs.debian.org] Reporting documentation - "What package does your bug report belong to?" points to user support groups

[Wouter Verhelst]

On Wed, Feb 15, 2012 at 11:12:28AM -0500, Filipus Klutiero wrote:
> Hum, interesting. I am aware that the ITS deals with errors in the
> package given, like when the user does a typo, but I'm not aware
> that one can "knowingly report against an unknown package". Could
> you explain how they would do that?

You report against package 'general'.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216091452.gj25...@grep.be

Re: Source package names for R libraries (and Perl, Python, Java, …).

[Wouter Verhelst]

On Wed, Feb 15, 2012 at 09:29:13PM +0100, Joachim Breitner wrote:
> Maybe the best we can do is to set good precedence for the next 100
> programming languages to come. Looking at some examples I find:
>   * Haskell: Almost exclusively haskell-foo
>   * OCaml: A mix of ocaml-foo, ocamlfoo and some foo (even generic
> names such as why or calendar).
>   * Perl: Mostly libfoo-perl
>   * Lisp: Mostly cl-foo
>   * Ruby: Some libfoo-ruby, some ruby-foo
>   * Javascript: Mostly non-generic upstream names, node-foo for node
> components.
>   * Java: About have are non-generic upstream names, other half are
> libfoo-java
> Counting ruby for both, there the vote is 4 to 3 between lang-foo and
> libfoo-lang.

Except that the reason you find ruby in both is that it's transitioning
from libfoo-ruby to ruby-foo. So it's 4 to 2, really.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216092211.gk25...@grep.be

Re: Bug#655999: [bugs.debian.org] Reporting documentation - "What package does your bug report belong to?" points to user support groups

[Jonathan Nieder]

Wouter Verhelst wrote:
> On Wed, Feb 15, 2012 at 11:12:28AM -0500, Filipus Klutiero wrote:

>> Hum, interesting. I am aware that the ITS deals with errors in the
>> package given, like when the user does a typo, but I'm not aware
>> that one can "knowingly report against an unknown package". Could
>> you explain how they would do that?
>
> You report against package 'general'.

Don't you mean "base", "installation-reports", or "upgrade-reports"?


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

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Serafeim Zanikolas]

On Thu, Feb 16, 2012 at 09:41:40AM +0100, Goswin von Brederlow wrote [edited]:
[..]
> Putting local config into /usr/share is wrong though.

the answer to all local policy questions is: like you always did; you edit
inetd.conf.

/usr/share/reconf-inetd fragments are input to a *maintainer* tool. you can
abuse it for local policy, but then you're on your own

> Another question: How do I disable a fragment? In udev I can create a
> rule file with the same name as one in /lib/udev to disable it. [If it
> was covered I'm sorry, Fosdem talks aren't downloaded yet.]

as a local sysadmin, you don't disable a reconf-inetd fragment; you disable an
inetd.conf entry by preceding it "with exactly one hash character (`#')"
(quote from the last paragraph of Policy 11.2).

reconf-inetd will not change user-disabled inetd.conf entries. this behaviour
is documented and tested in scenaria 1-12 in [0]

once again: DEP9 does not change the way sysadmins configure inetd

cheers,
sez

ps. you won't find any such answers in my fosdem talk; the talk is more about
how to replace a tool that impacts many maintainers, most of which won't
give any feedback until you've done all the work

[0] 
http://anonscm.debian.org/gitweb/?p=collab-maint/reconf-inetd.git;a=blob;f=features/no-action.feature


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

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Serafeim Zanikolas]

On Thu, Feb 16, 2012 at 10:13:26AM +0100, Bernd Zeimetz wrote:
> On 02/16/2012 12:22 AM, Serafeim Zanikolas wrote:
> > hi Goswin,
> > 
> > On Wed, Feb 15, 2012 at 02:27:48PM +0100, Goswin von Brederlow wrote 
> > [edited]:
> >> One thing though: Can I add my own local fragments? Is there a fragment
> >> dir in /etc for that?
> > 
> > you can, and they should also go to /usr/share/reconf-inetd (as long as the
> > filenames don't conflict with any other packages' fragments [0])
> 
> No, /usr/share should not be topuched by local stuff. Have a look at

agreed. I've clarified in my follow up to Goswin.

cheers,
sez


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

Bug#660091: ITP: eliom -- Web framework that can generate client and server parts from the same code

[Pierre Chambart]

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

Package name: eliom
Version: 2.0.2
Upstream Author: ocsigen team 
URL: http://ocsigen.org
License: LGPL
Description: Eliom is a web framework for ocsigenserver written in OCaml.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f3ce30f.5030...@crans.org

Re: Bug#655999: [bugs.debian.org] Reporting documentation - "What package does your bug report belong to?" points to user support groups

[Josip Rodin]

On Wed, Feb 15, 2012 at 11:12:28AM -0500, Filipus Klutiero wrote:
> Ah, OK. If the request is going to be "Why am I experiencing problem
> foo?", then it makes sense on debian-user. In that case, the problem
> is just phrasing (in the current phrasing, the user is already at
> the step of reporting a bug).

People arrive thinking about bugs but they don't necessarily have a clear
idea in their mind about what the exact bug is, so encouraging some
generic diagnostic discussion should be more helpful than bouncing their
bug report from one maintainer to another.

> >In any case, we do have support for tracking unknown packages in the bug
> >tracking system, and a few people (used to) volunteer to look after it.
> >So if the prospective reporter doesn't get help from debian-user, they
> >can still file such a bug report.
> 
> Hum, interesting. I am aware that the ITS deals with errors in the
> package given, like when the user does a typo, but I'm not aware
> that one can "knowingly report against an unknown package". Could
> you explain how they would do that?

Whenever you type something in the Package: line that can't be matched
to an existing package name, it falls through into and is forwarded to
unknown-package@qa.d.o

-- 
 2. That which causes joy or happiness.


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

Re: Source package names for R libraries (and Perl, Python, Java, …).

[Piotr Ożarowski]

[Paul Wise, 2012-02-16]
> How about a lintian complaint at info/pedantic level called
> source-package-name-doesnt-match-binary-package that triggers on
> single-binary source packages and where the binary name doesnt look
> like a versioned library package?

Please don't. There are developers (like me) who prefer source package
names to be as close as possible to upstream's name.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216115934.gk28...@piotro.eu

Re: Source package names for R libraries (and Perl, Python, Java, …).

[Jakub Wilk]

* Piotr Ożarowski , 2012-02-16, 12:59:
How about a lintian complaint at info/pedantic level called 
source-package-name-doesnt-match-binary-package that triggers on 
single-binary source packages and where the binary name doesnt look 
like a versioned library package?
Please don't. There are developers (like me) who prefer source package 
names to be as close as possible to upstream's name.


Right. Such tag wouldn't match existing practice[0] in the Python world, 
where some[1] upstreams take care of making their project names globally 
unique.


It would be also incompatible with policy for packaging extensions for 
XUL based applications[2].



[0] That said, I'm not sure how widespread this practice is.

[1] My gut feeling is s/some/most/, though again, I didn't do any 
research to justify such claim.


[2] https://wiki.debian.org/Mozilla/ExtensionsPolicy

--
Jakub Wilk


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

Re: Multiarch file overlap summary and proposal

[David Kalnischkies]

On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow  wrote:
> Russ Allbery  writes:
>> David Kalnischkies  writes:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery  wrote:
>>
 Actually, why would that be the behavior?  Why would dpkg --purge foo
 not just remove foo for all architectures for which it's installed, and
 require that if you want to remove only a specific architecture you
 then use the expanded syntax?
>>
>>> We (as in APT team and dpkg team) had a lot of discussions about that,
>>> see for starters (there a properly more in between the 10 months…)
>>> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
>>> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html
>>
>>> In short, i think the biggest counter is that it feels unintuitive to
>>> install a library (in native arch) with e.g. "apt-get install libfoo"
>>> while you have to be specific at removal to avoid nuking 'unrelated'
>>> packages with "apt-get remove libfoo".
>>
>> Ah, hm... I suppose that's a good point, although honestly I wouldn't mind
>> having apt-get remove libfoo remove all instances of libfoo that are
>> installed.  I think that would be quite reasonable behavior, and don't
>> find it particularly unintuitive.
>>
>> I agree that it's asymmetric.  apt-get install libfoo means libfoo:native,
>> but apt-get remove libfoo means libfoo:*.  And asymmetric is bad, all
>> things being equal.  But I think this may be one place where asymmetric is
>> still the right thing to do; I would argue that it means you're
>> implementing the most common operation in both cases.  apt-get install
>> libfoo generally means "give me a native libfoo" since non-native libfoo
>> is going to be an unusual case, and apt-get remove libfoo generally means
>> "I have no more interest in libfoo, make it go away."  I think that people
>> who want to get rid of one architecture of libfoo but keep the other are
>> already going to be thinking about architectures, and it's natural to ask
>> them to qualify their request.
>
> In another thread we discussed the problem with plugins (e.g. input
> methods for chinese/japanese) and LD_PRELOAD (e.g. fakeroot) using
> stuff. For those packages it would be great if
>
>    apt-get install plugin
>
> would install all architectures of the package (for various values of
> all :). This would add asymetry in that apt-get install libfoo would
> sometimes mean libfoo:native and sometimes libfoo:*. Having apt-get
> install libfoo:* for anything M-A:same would make it more symetric in
> that case.
>
> "apt-get install libfoo" generaly means "please upgrade libfoo to the
> latest version". That should be "apt-get upgrade libfoo" which doesn't
> yet exists. Libraries should be pulled in from binaries and not
> installed manually so I wouldn't give that case much weight.

But M-A:same will end-up on dev-packages as well, and these are quiet
likely to be installed manually. And in the end are libraries more often
installed by hand then they are removed - think e.g. of the binary
distribution of certain applications (aka mostly games).
I need libfoo for my new amd64 game so i install it. Later i remove the
game and remember to remove libfoo with it also. I just forgot that i have
a i386 game i play from time to time which requires libfoo:i386 which is
killed by that, too. That i haven't packaged my games is misfortune, but
we are talking about real-world usage here…

Also, in some distant future we might be able to co-install binaries.
It's easy to think of M-A:same just as libraries but i personally think that
this is an unnecessary mental limitation and just exists because it is
currently the (mostly imaginative) case.

And it seems like you assume apt-get and co are only used by humans.
In fact i think it is at least equally common used in scripts, usually with -y
to e.g. remove obsolete packages. I can't wait for the resulting shitstorm…

(btw, you know that 'apt-get purge foo+' is possible, right?
 Which behavior would you expect? The same as 'apt-get install foo' ?)


The "same-as" thing in the plugin thread just smells like poor-man's
conditional dependency - and it's trying to solve something which isn't
solvable on that level: Just because i have armel packages installed on my
system doesn't mean that i am going to execute an armel binary.
Cross-building for example will install libc6:armel for me, but i am still
not even close to be interested in libfakeroot:armel.
To get libfakeroot:armel on the system is the responsibility of whatever tool
helps the administrator to setup an foreign armel system on his host,
which is his brain if (s)he chooses to setup it by hand with apt-get.

It's comparable with the dependency grouping for xul-applications:
The user has a variety of usecases to choose from but all these usecases
include the same apt-get command. Which usecase is the most popular
is not really measurable and even if it would it changes over time, but the
behavior of the apt-* tools i

Bug#660122: ITP: obfsproxy -- pluggable transport proxy for Tor

[Peter Palfrader]

Package: wnpp
Severity: wishlist
Owner: Peter Palfrader 

Description: pluggable transport proxy for Tor
 obfsproxy is a tool that attempts to circumvent censorship, by
 transforming the Tor traffic between the client and the bridge. This way,
 censors, who usually monitor traffic between the client and the bridge, will
 see innocent-looking transformed traffic instead of the actual Tor traffic.
 .
 It is written in C and is compliant to the Tor pluggable transports
 specification, and its modular architecture allows it to support multiple
 pluggable transports.
Homepage: https://www.torproject.org/projects/obfsproxy
Vcs-Git: https://git.torproject.org/debian/obfsproxy.git
Vcs-Browser: https://gitweb.torproject.org/debian/obfsproxy.git

Cheers,



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120216162527.18394.16390.report...@valiant.palfrader.org

Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev

[Sylvestre Ledru]

Le mercredi 01 février 2012 à 19:43 -0600, Steve M. Robbins a écrit :
> 
> 
> > Unfortunately they were still not available for that at the time of
> > my last poking.  Diverging from upstream is not a good idea, so we
> > still have to live in a non perfect world...
> 
> I think we can no longer live in the status quo (see all the blockers
> of #631019), so something has to give.  Even if it is painful, perhaps
> Debian could pioneer something and pass patches back to upstream?
I asked upstream for their opinions on this subject.

Here is the answer:
"There are no current plans to change the parallel HDF5 library name to
another name. However, this has been a source of confusion over the years,
so I entered a bug report for it. (I don't know of any ramifications to
renaming the parallel library, but I think the best solution would
be for us to provide it with a different name.)"
(the bug report is not public).

As Julien suggested a few days ago on IRC, we could provide a patch for
this but I don't think it is a technical issue but more
organisation/politic issue for their users. 

We could try to make Debian move to the renaming of all MPI HDF5
libraries but this will be diverging a lot from upstream while
confusing our users (but I don't know if it would confuse less or more
than the current solution).

Sylvestre














--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1329409321.4035.121.ca...@pomegues.inria.fr

Re: Bug#660091: ITP: eliom -- Web framework that can generate client and server parts from the same code

[Thomas Koch]

Pierre Chambart:
> Package name: eliom
> Version: 2.0.2
> Upstream Author: ocsigen team 
> URL: http://ocsigen.org
> License: LGPL
> Description: Eliom is a web framework for ocsigenserver written in OCaml.

Please also provide a long description.

Regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202161917.18169.tho...@koch.ro

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

I was thinking more about this, and I was finally able to put a finger on
why I don't like package splitting as a solution.

We know from prior experience with splitting packages for large
arch-independent data that one of the more common mistakes that we'll make
is to move the wrong files: to put into the arch-independent package a
file that's actually arch-dependent.

Look at the failure mode when that happens with the sort of package that
we're talking about splitting out of m-a:same packages:

* The arch-independent package gets arch-dependent content that happens to
  match the architecture of the maintainer's build machine, since that's
  the only place the arch-independent package is built.  The maintainer
  will by definition not notice, since the content is right for their
  system.

* The maintainer is probably using a popular system type (usually either
  i386 or amd64), and everyone else on that system type will also not
  notice, so the bug can be latent for some time.

* Systems with the wrong architecture will get data files that have the
  wrong format or the wrong information.  This is usually not a case that
  the software is designed to detect, so the result is normally random
  segfaults or similar sorts of major bugs.  The failure case for header
  files is *particularly* bad: C software will generally compile fine with
  the wrong-sized data types and then, at *runtime*, happily pass the
  wrong data into the library, resulting in random segfaults and possibly
  even data corruption.  This won't happen until runtime, so could go
  undetected for long periods of time.

This is a particularly nasty failure mode due to how long it can stay
undetected and how much havoc it causes.

Now, compare to the failure mode with refcounting if the maintainer
doesn't realize that an arch-specific file can't be shared:

* Each arch-specific package will continue to get the appropriate files
  for that architecture.  Each package will still be usable and consistent
  independently, so users who don't care about multiarch won't ever see a
  problem.

* Users who want to co-install separate architectures will immediately
  encounter a dpkg error saying that the files aren't consistent.  This
  means they won't be able to co-install the packages, but dpkg will
  prevent any actual harm from happening.  The user will then report a bug
  and the maintainer will realize what happened and be able to find some
  way to fix it.

* Even better, we can automatically detect this error case by scanning the
  archive for architecture pairs that have non-matching overlapping files
  and deal with it proactively.

The refcounting failure mode behavior is just completely superior here.
And this *is* a mistake that we're going to make frequently; we know that
from past experience with splitting packages.  Note that this problem
often happens because, when the maintainer originally split the package,
there was nothing arch-specific in the file, but upstream made it
arch-specific later on and the maintainer didn't notice.  (It's very easy
to miss.)  This is particularly common with header files.

Note that arch-qualifying all of the files does not have the problems of
package splitting, but it's also a much more intrusive fix.

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


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

Bug#660138: ITP: 389-dsgw -- 389 Directory Server Gateway

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 

* Package name: 389-dsgw
  Version : 1.1.9
  Upstream Author : Red Hat, Inc.
* URL : http://directory.fedoraproject.org
* License : GPL-2, LGPL-2.1, MPL-1.1
  Programming Lang: C
  Description : 389 Directory Server Gateway

 389 Directory Server Gateway is a collection of 3 web applications
 that run on top of the Administration Server used by the Directory
 Server.  These 3 applications are:

 - phonebook:
   a simple phonebook application geared towards end users, with simple search
   screens and simple self-service management
 - orgchart:
   an organization chart viewer
 - gateway:
   a more advanced search interface that allows admins to create and edit user
   entries, and allows creation of templates for different types of user and
   group entries



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120216191928.16664.31004.reportbug@eldon.tyrell

running a program from debian/tmp

[David Roguin]

Hi,

I'm making changes to the evolution email client and I want to know if
there's an easy way to test the changes I am doing without installing
the generated .debs.

Thanks!

-- 
David


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAGaJj4+69=wqmwqhn15srpb2gnynbfh9xevmtvkx0tz_uwt...@mail.gmail.com

Bug#660140: ITP: tack -- terminfo action checker

[Samuel Bronson]

Package: wnpp
Owner: Samuel Bronson 
Severity: wishlist

* Package name: tack
  Version : 1.07
  Upstream Author : Thomas Dickey 
* URL or Web page : ftp://ftp.invisible-island.net/ncurses/
* License : GPL-2+
  Description : terminfo action checker

The 'tack' program is a diagnostic tool that is designed to create and
verify the correctness of terminfo's. This program can be used to
create new terminal descriptions that are not included in the standard
ncurses release.

It was in Debian before, but got orphaned and eventually dropped; see
.

--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



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

Bug#660141: ITP: php-mongo -- PHP to MongoDB interface

[Rajmund Zawislak]

Package: wnpp
Severity: wishlist
Owner: Rajmund Zawislak 

* Package name: php-mongo
  Version : 1.2.7
  Upstream Author : Kristina Chodorow, Derick Rethans
* URL : http://pecl.php.net/package/mongo
* License : Apache License
  Programming Lang: C
  Description : package provides an interface for communicating
 with the MongoDB database in PHP.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120216201340.3411.30524.reportbug@debian-sid.i

Re: running a program from debian/tmp

[Jonathan Yu]

For some value of easy... I think most people who work with Debian packages
on a regular basis use a chroot environment to build and install packages.

Several similar programs can be used for this: pbuilder (and the faster
copy-on-write variant, cowbuilder) and sbuild are the ones I've used in the
past. I'm sure there's many more. But it's not exactly an easy way of doing
it, since some initial setup is required (bootstrapping the Debian base
system environment)

On Thu, Feb 16, 2012 at 2:42 PM, David Roguin  wrote:

> Hi,
>
> I'm making changes to the evolution email client and I want to know if
> there's an easy way to test the changes I am doing without installing
> the generated .debs.
>
> Thanks!
>
> --
> David
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/CAGaJj4+69=wqmwqhn15srpb2gnynbfh9xevmtvkx0tz_uwt...@mail.gmail.com
>
>

Re: Multiarch file overlap summary and proposal

[Carsten Hey]

* David Kalnischkies [2012-02-16 03:59 +0100]:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery  wrote:
> >>>   it needs to find and remove foo:*

foo:all (or foo:any) instead of foo:* would save the need to quote it.

> > Actually, why would that be the behavior?  Why would dpkg --purge foo not
> > just remove foo for all architectures for which it's installed, and
> > require that if you want to remove only a specific architecture you then
> > use the expanded syntax?
>
> We (as in APT team and dpkg team) had a lot of discussions about that,
> see for starters (there a properly more in between the 10 months…)
> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html
>
> In short, i think the biggest counter is that it feels unintuitive to
> install a library (in native arch) with e.g. "apt-get install libfoo"
> while you have to be specific at removal to avoid nuking 'unrelated' packages
> with "apt-get remove libfoo".

I would expect this (especially if the package foo is not a library, but
I would also expect this for libraries):

 * apt-get install foo tries to install foo:native if possible, if it is
   not possible, it tries to install the package foo from an other
   architecture but ask before proceeding (as if additional dependencies
   are required to install a package).
 * apt-get remove foo removes all installed foo packages (on all
   architectures).


This summarises how apt without multi-arch handles this, the above would
make apt with multi-arch also behave so:

apt-get install foo
--->
  foo is not installed  foo is installed
apt-get remove foo
   <---

> > Note that this obviously requires that a binNMU not be considered a
> > different version of the package for this purpose.  But I think that too
> > makes sense.  A binNMU *isn't* a full new version of the package; it's a
> > new build of the same version.  We've historically been a bit sloppy about
> > this distinction, but I think it's a real distinction and a meaningful
> > one.
>
> Mhh. The current spec just forbids binNMU for M-A:same packages -
> the 'sync' happens on the exact binary version.
> Somewhere else in this multiarch-discussion was hinted that we could
> sync on the version in (optional) Source tag instead to allow binNMU.
> It's a bit too late (in my timezone) for me to do serious predictions on
> difficult-levels on changing this in APT but i guess its relatively easy.

> (the only problem i see is that i don't have ${source:Version} available
>  currently in the version structure, but we haven't even tried pushing
>  apt's abibreak to sid specifically as i feared "last-minute" changes…)

I'm not sure if you meant this with "Source tag", anyway, the 'Packages'
files miss the source version too, but this could be added as optional
field that would be used if it differs from the 'Version:' field.


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216221059.ga8...@furrball.stateful.de

Re: Multiarch file overlap summary and proposal

[Carsten Hey]

* Russ Allbery [2012-02-16 10:43 -0800]:
> * Users who want to co-install separate architectures will immediately
>   encounter a dpkg error saying that the files aren't consistent.  This
>   means they won't be able to co-install the packages, but dpkg will
>   prevent any actual harm from happening.  The user will then report a bug
>   and the maintainer will realize what happened and be able to find some
>   way to fix it.
>
> * Even better, we can automatically detect this error case by scanning the
>   archive for architecture pairs that have non-matching overlapping files
>   and deal with it proactively.

There are still files that differ that do not need to be fixed, for
example documentation that contains it's build date.

One way to address this is to use a new dpkg control file (placed in
/var/lib/dpkg/info) that lists files that dpkg considers to be equal
even if they differ.


Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216224340.gb8...@furrball.stateful.de

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

Carsten Hey  writes:
> * Russ Allbery [2012-02-16 10:43 -0800]:

>> * Users who want to co-install separate architectures will immediately
>>   encounter a dpkg error saying that the files aren't consistent.  This
>>   means they won't be able to co-install the packages, but dpkg will
>>   prevent any actual harm from happening.  The user will then report a bug
>>   and the maintainer will realize what happened and be able to find some
>>   way to fix it.

>> * Even better, we can automatically detect this error case by scanning the
>>   archive for architecture pairs that have non-matching overlapping files
>>   and deal with it proactively.

> There are still files that differ that do not need to be fixed, for
> example documentation that contains it's build date.

Every file that differs has to be fixed in the current multi-arch plan.
Documentation that contains its build date is going to need to be split
out into a separate -docs package.

I'm fine with splitting documentation; that has far fewer problems than
splitting other types of files, since documentation isn't tightly coupled
at a level that breaks software.

> One way to address this is to use a new dpkg control file (placed in
> /var/lib/dpkg/info) that lists files that dpkg considers to be equal
> even if they differ.

I don't think this is a good idea.  I don't think we should allow this
sort of inconsistency depending on what package is installed first.

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


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

Work-needing packages report for Feb 17, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 409 (new: 6)
Total number of packages offered up for adoption: 142 (new: 0)
Total number of packages requested help for: 57 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   scim-hangul (#659312), orphaned 6 days ago
 Description: Hangul Input Method Engine for SCIM
 Installations reported by Popcon: 57

   scim-pinyin (#659310), orphaned 6 days ago
 Description: smart pinyin IM engine for SCIM platform
 Installations reported by Popcon: 535

   scim-python (#659308), orphaned 6 days ago
 Description: Python input method framework for SCIM
 Reverse Depends: python-scim python-scim-dbg scim-python
   scim-python-englishwriter scim-python-xingma scim-tegaki
 Installations reported by Popcon: 54

   scim-tables (#659309), orphaned 6 days ago
 Description: generic tables IM engine module for SCIM platform
 Reverse Depends: scim-tables-additional scim-tables-ja
   scim-tables-ko scim-tables-zh task-kannada-desktop
   task-malayalam-desktop
 Installations reported by Popcon: 781

   scim-tegaki (#659313), orphaned 6 days ago
 Description: Tegaki input method for SCIM
 Installations reported by Popcon: 27

   scim-uim (#659311), orphaned 6 days ago
 Description: UIM IM engine module for SCIM platform
 Installations reported by Popcon: 118

403 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 142 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#646208), requested 117 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (177 more
   omitted)
 Installations reported by Popcon: 61313

   apt-xapian-index (#567955), requested 745 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 52510

   asymptote (#517342), requested 1084 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3036

   athcool (#278442), requested 2669 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 95

   balsa (#642906), requested 144 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg debreaper
 Installations reported by Popcon: 270

   bastille (#592137), requested 558 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 242

   boinc (#511243), requested 1134 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1859

   cardstories (#624100), requested 297 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 5

   chromium-browser (#583826), requested 627 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 10089

   cryptsetup (#600777), requested 484 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7556

   dctrl-tools (#448284), requested 1573 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   postgresql-server-dev-all simple-cdd (1 more omitted)
 Installations reported by Popcon: 14976

   debtags (#567954), requested 745 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2610

Re: Source package names for R libraries (and Perl, Python, Java, …).

[Paul Wise]

On Thu, Feb 16, 2012 at 7:59 PM, Piotr Ożarowski wrote:

> Please don't. There are developers (like me) who prefer source package
> names to be as close as possible to upstream's name.

As a pedantic/info level warning, you are of course free to ignore it.

-- 
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
Archive: 
http://lists.debian.org/caktje6fvkf3hkmyz5l+geh9nyqb2_8d1ptzbppq2ypbrk2b...@mail.gmail.com

Bug#660165: [new check] Source package names for R libraries (and others if appropriate).

[Charles Plessy]

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

Dear Lintian maintainers,

The correspondance between source and binary package names has been discussed
on the debian-devel mailing list recently.

  http://lists.debian.org/debian-devel/2012/02/msg00622.html

In particular, it has been proposed that, for source package producing a single
binary package, their names should be the same, and follow a naming scheme that
prevents possible clash with unrelated packages using the same name upstream.

Pros and cons have been reminded or identified in this discussion, and I would
like them to be easy to find for refreshing our memories in the future.
Policy, DEP and lintian have been proposed as a vector, and my conclusion is
that, for some subsets of packages, lintian is a good place.

To start, I propose the following new lintian tag, to be applied on packages in
the gnu-r section and any other sections for which there is a consensus.
Improvements on the wording are much welcome.

  source-and-binary-package-names-do-not-match
  
  Source packages in the gnu-r section that produce only one binary package
  should use the same name.
  
  This rule guarantees that there will be no name conflict even if the upstream
  names are generic and used in unrelated projects.  It also prevents having
  unrelated source and a binary packages with the same name in the Debian
  archive.
  
  Severity: normal, Certainty: certain

You may have noted that there is no patch attached...  While, if there is
agreement to create this new tag, I will try to implement it, everybody is most
welcome to be faster than me on this.

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
Archive: http://lists.debian.org/20120217011902.ga31...@falafel.plessy.net