Bug#659954: ITP: mono-upnp -- client/server libraries for UPnP

[Chow Loong Jin]

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 


* Package name: mono-upnp
  Version : 0.1.0
  Upstream Author : Alexander Kojevnikov 
* URL : http://www.github.com/mono/mono-upnp
* License : MIT/X11 (BSD like)
  Programming Lang: C#
  Description : client/server libraries for UPnP

Mono.Upnp is a set of client/server libraries for the Universal Plug 'n Play
specification, which can be found at http://www.upnp.org.

Mono.Upnp includes the following projects:
 - Mono.Ssdp: An implementation of the Simple Discovery Protocol.
 - Mono.Upnp: An implementation of the UPnP Device Architecture 1.1, Sections
2-6.
 - Mono.Upnp.GtkClient: An executable Gtk+ user interface for inspecting UPnP
   devices and services on the network.
 - Mono.Upnp.Dcp.MediaServer1: An implementation of the UPnP Audio/Video
   MediaServer1 Device Control Protocol.
 - Mono.Upnp.Dcp.MediaServer1.FileSystem: A MediaServer1 implementation which
   serves media from the filesystem.
 - Mono.Upnp.Dcp.MediaServer1.FileSystem.ConsoleServer: An executable console
   program which serves media from the filesystem.
 - Mono.Upnp.Dcp.MSMediaServerRegistrar1: An implementation of the Microsoft
   MSMediaServerRegistrar1 Device Control Protocol.



-- 
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/20120215092302.8751.91040.reportbug@localhost6.localdomain6

Re: DEP5: minor suggestions - FSF address etc.

[Jari Aalto]

2012-02-11 20:44 Charles Plessy :
| Le Sat, Feb 11, 2012 at 12:23:12PM +0200, Jari Aalto a écrit :
| http://dep.debian.net/deps/dep5/
|
| > (1) Use URL instead of real FSF address everywhere
|
| The examples contain license notices for the GNU GPL version 2, and in
| these there is no URL but the postal address. The current practice in
| Debian is to update if needed the postal address in the GPL notices
| version 1 and 2 (lintian tag old-fsf-address-in-copyright-file), but not
| to replace them by the URL of the latest GPL. I would prefer that the
| examples do make implicit suggestions to do so.

In my opinion, we should follow strictly how FSF recommends the GPL to be
presented. The use of postal addresses is no longer the FSF's current
postion.

.. and what a headache it all was when they moved their office. All License
texts had to be revised. That's a reason enough to stick to the FSF
recommended format that uses URL.

Jari


-- 
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/87ty2sjtqa@test20.cante.net

Re: DEP5: minor suggestions - FSF address etc.

[Jari Aalto]

2012-02-11 20:44 Charles Plessy :
| Le Sat, Feb 11, 2012 at 12:23:12PM +0200, Jari Aalto a écrit :
|> (2) No ending commas in years
|
| I would apply this change if it were supported by more people, but given
| that the object of DEP 5 is to record upstream license and copyright
| statements, and given that Upstreams write such statements using many
| different styles, I would prefer to not normalise the examples and give
| the impression that the copyright statements need to be normalised to be
| compliant with the machine-readable format.

I though that DEP5 was intended to use for Debian and not to record how
upstram chose to write their copyright statements.

I feel that Debian should focus on standards and therefore also present
those standards in DEP documents to the readers that follow the DEPs.

In this case, the FSF lawyers probably know how to write proper Copyright
statements, as they have instructed:



A copyright notice looks like this:
Copyright (C) year1, year2, year3 copyright-holder

The word ‘Copyright’ must always be in English, by international
convention.

...

You can use a range (‘2008-2010’) instead of listing individual years
(‘2008, 2009, 2010’) if and only if: 1) every year in the range,
inclusive, really is a “copyrightable” year that would be listed
individually; and 2) you make an explicit statement in a ‘README’ file
about this usage.

In addition, typographically, it's illogical to have ending-commas in
written text like that.

Jari



-- 
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/87pqdgjtdf@test20.cante.net

Bug#659964: ITP: proftmb -- per-residue prediction of bacterial transmembrane beta barrels

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

* Package name: proftmb
  Version : 1.1.7
  Upstream Author : Henry Bigelow 
* URL : http://rostlab.org/
* License : GPL
  Programming Lang: C++
  Description : per-residue prediction of bacterial transmembrane beta 
barrels

proftmb provides a four state (up-strand, down-strand, periplasmic loop, and
outer loop) per-residue prediction for the protein.



-- 
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/20120215112659.1320.23888.reportbug@debian-unstable.rostclust

Re: Multi-arch all-architecture plugins

[Goswin von Brederlow]

Ian Jackson  writes:

> Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> As you said these are usualy plugins that nothing depends on. So this
>> wouldn't help much. Also if there is a dependency than the rules for
>> m-a:same should be sufficient. If the package is something to depend on
>> then packages of all architectures should depend on it if they use
>> it. The plugin might only be used by amd64 packages and none of the i386
>> would depend on it and then installing only amd64 is perfectly fine.
>
> I don't think that's the case.  Consider something like fakeroot.  The
> fakeroot binary itself may be any architecture, because its function
> is to set up a socket and be a server for children and set an
> LD_PRELOAD and so forth.  But the libfakeroot.so must be available for
> all configured architectures so that the LD_PRELOAD works no matter
> what architecture(s') binaries end up running.

Ok, this is a 3rd class of packages with this problem. libfakeroot.so
isn't a plugin but due to LD_PRELOAD it has the same issues with
multiarch as plugins with no depends on them (e.g. input methods).

> So you would have:
>
>Package: fakeroot
>Multi-Arch: foreign
>Depends: libfakeroot
>
>Package: libfakeroot
>Multi-Arch: all
>
> and it would have to mean "install libfakeroot for all configured
> architectures".  If libfakeroot were m-a:same then it would mean
> "install libfakeroot for the arch whose fakeroot we picked" which is
> wrong.
>
>> I would concentrate on the case that nothing depends on it and the
>> solution while keeping the depending case in the back of my mind.
> ...
>> Another possible solution was to have a metapackage with wildcard
>> dependency:
>> 
>> Package: plugin-all
>> Depends: plugin:*
>
> So plugin would be m-a:allowed ?

No limitations on what plugin may be, doesn't factor into the equation
so far. For fakeroot it would be this:

Package: fakeroot 
Multi-Arch: foreign 
Depends: libfakeroot:*
 
Package: libfakeroot 
Multi-Arch: same
   
>> One thing to keep in mind is that the list of architectures for the
>> system might change (the admin adds another architecture) making any
>> such all-archs dependencies suddenly unfullfilled. But that is probably
>> unavoidable and apt-get -f install would fix it right up.
>
> Yes.  Something would have to be done then, certainly.
>
> Perhaps the right answer is not to consider configured architectures,
> but rather architectures for which any package is installed.
>
> Ie, as follows:
>
>  * Find the set of all architectures "foo" for which any package is
>present on the system
>
>  * Now for each
>
>  Package: plugin
>  Architecture: bar
>  Multi-Arch: all
>
>imagine a dependency
>
>  Depends: plugin:foo1, plugin:foo2, ...
>
> Should dpkg do this as well as apt ?
>
> Ian.

Good question. Apt certainly has to care. dpkg could ignore it and
assume frontends will do the right thing.

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/87d39gtgo0.fsf@frosties.localnet

Re: Multi-arch all-architecture plugins

[Goswin von Brederlow]

Peter Samuelson  writes:

> [Ian Jackson]
>> If you install on i386 your 2 binaries and libc6, you /do/ need the
>> i386 libfakeroot.  Otherwise if you say "fakeroot " it
>> won't work, no matter that /usr/bin/fakeroot is amd64.
>
> libfakeroot is something of a special case, indeed.  As a hack to my
> proposal, perhaps it can be 'M-A: same-as libc-dev'?  I know it's
> potentially useful beyond development, but in practice, it seems to be
> almost entirely used for development.

I don't think it is a special case as such. As Ian says: If you install
any i386 binary then you (potentially) need libfakeroot:i386. And the
common thing for binaries is libc6. Even static binaries depend on the
ld.so from libc6. I think we can ignore the case of libc6:i386 being
installed without any binary needing it.

>> Whereas if you have gimp installed you /either/ have the amd64 or the
>> i386 version, and all your gimp plugins need to be the same
>> architecture.
> [...]
>> And indeed the plugin itself need not have a multi-arch field because
>> it doesn't need to be coinstalled with other arches.
>
> Right, so gimp plugins aren't really an interesting case.

Except is gimp the only way to use gimp plugins? Isn't there another app
foo that also uses libgimp and its plugins? Then you could have
gimp:amd64, foo:i386.

>> > Package: libsasl2-modules
>> > Multi-Arch: same-as libsasl2-2
>> 
>> Would it matter if the list of sasl modules installed was different on
>> different architectures ?  Would that mean that i386 sasl-using
>> applications would have different sasl capabilities or would it cause
>> libsasl not to start up due to missing plugins ?
>
> The first.  It's similar to the PAM modules case.  Different apps would
> have different capabilities.  This doesn't _necessarily_ have security
> implications, like getting your PAM modules out of sync, but it's still
> something you would not do on purpose, and as such, best if we can
> prevent it with infrastructure.
>
> [Bernhard Link]
>> Would this also work with nss plugins? That might be a bit more
>> complicated as it would be libc6 on most architectures, but libc6.1
>> or libc0.1 on others.
>
> True.  It would probably need to use a virtual package, like
> 'glibc-2.13-1'.  This might not be a good solution, though, as
> apparently the NSS ABI has a wider span than the ABI promised by the
> glibc virtual package name.  Ideal (for my purposes here) would be if
> glibc could provide a virtual package indicating the NSS ABI, akin to
> 'perlapi-5.10.0'.
>
> Peter

I think that is unneccessary. Wouldn't the nss plugins already have all
the depends in place to ensure ABI compatibility for the non-multiarch
case? So all we need to add is to get them installed and the existing
depends/conflicts/breaks/... will make sure they are compatible.

So "Multi-Arch: same-as glibc-2.13-1" would be fine. Even "Multi-Arch:
libc" would be fine (if it is provided).

--[ Summary ]-

I think a few things have become clearer now and we have a few new
ideas.

1) 3 kinds of packages
   - plugins stuff depends on (already covered)
   - plugins without depends
   - LD_PRELOAD libraries
   The last two seem to provide identical challenges so lets treat them
   the same for now. From now on "plugins" means  the later two cases.

2) Plugins are used through some core library. If the core library is
   installed for some arch the plugin should be installed for the same
   arch. This is not neccessarily all the archs configured in dpkg.
   For LD_PRELOAD libraries the libc is a suitable stand-in for the core
   library.

Idea: 'same-as core-lib'

3) Admins might want to intentionally not install some plugin for some
   arch.

Idea: Something that works like Recommends and not like Depends.

4) Things can be configured to use different plugins on different
   architectures. Just because the core library is installed for an
   architecture does not always mean the plugin would be used.
   It could be nice for the maintainer to specify if this plugin is a
   configured-per-arch or always-all-archs case.

Idea: Some flag to switch between Recommends and Suggests semantic?

-

I like both the same-as and the Recommends idea. I don't like the idea
of using the M-A field for same-as. There could be plugins with M-A:same
as well as M-A:allowed semantic (e.g. a plugin enabling some scripting
support like perl for irssi), maybe even M-A:foreign.

I'm not sure if "Recommends: same-as:core-lib" or similar syntax would
be a good idea. It might be best to introduce a new field: "Same-as:
core-lib". This should also be backward compatible in that we do not
need to wait one release cycle before using Same-as.

The behaviour should be that when first installing core-lib for some
arch all the installed plugins are also installed for that arch. But
on upgrade missing plugins are not added.

Re: How to tell users that ia32-libs will go away

[Ben Hutchings]

On Wed, 2012-02-15 at 04:32 +0100, Goswin von Brederlow wrote:
> Ben Hutchings  writes:
[..]
> > Since dpkg will prefer to install packages from the native
> > architecture, I don't see any problem here.  I suppose I'm biased by
> > having actually tested this.
> >
> > Ben.
> 
> But it is only a preference, not a garanty. With aptitude even pining is
> just taken as advisement. So there will always be a risk of amd64
> packages getting pulled in before the user reboots into a 64bit
> kernel. As I said, not safe.
> 
> Are you sure you can get all the bugs fixed and the package and
> multiarch properly tested so wheezy can rely on it for something as
> essential as the kernel?

Since when do we require that all bugs are fixed?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#659984: ITP: starlink-libpal -- Position Astronomy Library

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org


* Package name: starlink-libpal
  Version : 0.1.0
  Upstream Author : Tim Jenness 
* URL : http://starlink.jach.hawaii.edu/starlink
* License : LGPLv2+
  Programming Language: C
  Description : Position Astronomy Library
 This library is a collection of code designed to aid in
 replacing the SLA library with code from NOVAS and SOFA.
 .
 Where possible the API is similar to the slalib
 except for the use of a "pal" prefix.

The goal of this package is to provide a modern alternative to the
slalib. Future versions of starlib-libast
 will be built using this library instead
of slalib 

This package is built in preparation to build saods9
.





-- 
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/4f3bc227.1040...@liska.ath.cx

Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow]

Ian Jackson  writes:

> Russ Allbery writes ("Multiarch file overlap summary and proposal (was: 
> Summary: dpkg shared / reference counted files and version match)"):
>> 5. Data files that vary by architecture.  This includes big-endian
>>vs. little-endian issues.  These are simply incompatible with
>>multiarch as currently designed, and incompatible with the obvious
>>variations that I can think of, and will have to either be moved
>>into arch-qualified directories (with corresponding patches to the
>>paths from which the libraries load the data) or these packages
>>can't be made multiarch.
>
> Yes.  Of these, arch-qualifying the path seem to be to be obviously
> the right answer.  Of course eg if the data files just come in big-
> and little-endian, you can qualify the path with only the endianness
> and use refcounting to allow the equal-endianness packages to share.
>
> Ian.

Preferably -data-be:all and -data-le:all packages if they can be build
irespective of the buildds endianness.

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/87zkckrwnl.fsf@frosties.localnet

Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow]

Ian Jackson  writes:

> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: 
> Summary: dpkg shared / reference counted files and version match)"):
>> This still does not solve the other issues I listed, namely binNMUs
>> have to be performed in lock-step, more complicated transitions /
>> upgrades.
>
> I don't think I see where this is coming from.  Are you talking about
> variation in gzip output ?  Given the evidence we've seen here, in
> practice I think that is not going to be a problem.  Certainly it
> won't demand that binNMUs be performed in lock-step.

Note that splitting files (specifically changelog) into -common package
would require an explicit versioned dependency on the -common package and
produce the same (or similar) lock-step problem for upgrades and
binNMUs. Arch qualifying the files on the other hand would avoid that.

Splitting data files into -common packages will also often need a close
versioned dependency forcing a lock-step of packages. But probably not
so terse that binNMUs would have to be lock-steped.

Overall I think the lock-step being required for reference counted files
won't have such a large effect as you might think.



I think the idea of splitting the binNMU changelog into an extra file is
a great idea as that would allow putting the changelog into -common:all
and depend on the source version and then have the binNMU changelog in
the foo:any package in the symlinked directory. For this to work the
binNMU changelog should be arch and pkg qualified, e.g.

/usr/share/doc/foo-common/Changelog
/usr/share/doc/foo-common/Changelog.binNMU-foo-amd64
/usr/share/doc/foo-common/Changelog.binNMU-bar-i386
/usr/share/doc/foo -> foo-common
/usr/share/doc/bar -> foo-common 

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/87vcn8rw1z.fsf@frosties.localnet

Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow]

Russ Allbery  writes:

> Joey Hess  writes:
>
>> Anyway, my worry about the refcounting approach (or perhaps M-A: same in
>> general) is not the details of the implementation in dpkg, but the added
>> mental complexity of dpkg now being able to have multiple distinct
>> packages installed under the same name. I had a brief exposure to rpm,
>> which can install multiple versions of the same package, and that was
>> the main cause of much confusing behavior in rpm. While dpkg's invariant
>> that all co-installable package names be unique (and have unique files)
>> has certianly led to lots of ugly package names, it's kept the users'
>> and developers' mental models quite simple.
>
>> I worry that we have barely begun to scratch the surface of the added
>> complexity of losing this invariant.
>
> This does seem to be more M-A: same in general, to me, since whether we
> have file overlaps or not we still have multiple packages with the same
> name.  Which will force changes in everything that deals with packages,
> like Puppet, to be able to specify packages with particular architectures.
>
> I definitely agree on the complexity this adds.  But I don't think there's
> an alternative to that complexity without using something like --sysroot
> or mini-chroots, and I don't think those are satisfying solutions to the
> set of problems we're trying to solve.

pkg:arch will still be unique and the dpkg/apt output will use the
architecture where required for uniqueness. So I think that after some
getting used to it it will be clear enough again.

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/87r4xwrvw2.fsf@frosties.localnet

Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1

[Piotrek P]

Dear All,
Please be aware that VMware ESX 3.5 is NOT supporting any of Debian as Guest OS.
Please be aware that VMware ESXi 4.1 IS supporting Debian 4.0, 5.0 as Guest OS.
Please be aware that VMware ESX 5.0 IS supporting Debian 4.0, 5.0, 6.0
as Guest OS.

I would like to ask:
- What does it means for users of Debian 5.0 on ESXi 4.1 if support of
Debian 5.0 will end?
- What about repositories of Debian 5.0?
- How can I obtain informations about major changes in packages that
were changed in Debian 6.0 and future releases?
- What is official statement of VMware about not supporting newest
versions of Debian OS?
- How is it possible to be updated if VMware is not supporting newest
version of Debian OS?

Many thanks for answers.

Best regards,
Peter P.


-- 
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/CAMZ-jvqH981-e_J7fLAO1kDrX-HQBqV+tPMV8SCJ=oybhsq...@mail.gmail.com

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

[Filipus Klutiero]

Hi Josip,

Josip Rodin wrote:

On Fri, Feb 10, 2012 at 01:25:26PM -0500, Filipus Klutiero wrote:
>  [Forgot to Cc joy]
>
>  >>debian-user's topic is user support.
>  >>
>  >>For technical discussions about development, the default group is
>  >>debian-devel@lists.debian.org.
>  
>>Reference:http://anonscm.debian.org/viewvc/webwml/webwml/english/Bugs/Reporting.wml?r1=1.18&r2=1.19
  

I made that edit ten years ago (heh) pointing people to debian-user because
helping a person to determine whether the thing they want to communicate is
a bug and how to report it - is primarily a user support issue. Users trying
to report problems is not a development discussion by default; it can be
considered a prerequisite for a development discussion, but not one in and
of itself.


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


>  There is a difference between the workflows of reporting an issue
>  without specifying a package and of asking which package a report
>  should be assigned to then reporting.
>  The latter workflow is longer, adding the delay needed for the
>  advice to come plus the delay of the reporter actually reporting the
>  issue. Furthermore, the latter assumes advice will come at some
>  point, which is probably not going to be the case.

I'm not sure I see the point of making this kind of a subtle distinction
the reason to start yet another mailing list that would handle just this
matter.


To be sure we're all on the same page, I don't think anyone said a 
mailing list should be created just for that. I suggested creating a 
mailing list, but only to show that removing this matter from 
debian-user didn't imply adding it to debian-devel. I am not aware of 
the volume of this matter and can't say whether creating a new mailing 
list is warranted.


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?



--
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/4f3bd96c.70...@gmail.com

Re: Multiarch file overlap summary and proposal

[Joey Hess]

Goswin von Brederlow wrote:
> pkg:arch will still be unique and the dpkg/apt output will use the
> architecture where required for uniqueness. So I think that after some
> getting used to it it will be clear enough again.

Here are a few examples of the problems I worry about. I have not
verified any of them, and they're clearly biased toward code I am
familiar with, which suggests there are many other similar problems.

* Puppet not only installs packages, it may remove them. A puppet config
  that does dpkg --purge foo will fail if multiarch is enabled, now
  it needs to find and remove foo:*

* dpkg-repack pkg:arch will create a package with that literal name (or fail)

* dpkg-reconfigure probably can't be used with M-A same packages.
  debconf probably generally needs porting to multiarch.

* tasksel uses dpkg --query to work out if a task's dependencies are
  installed. In the event that a library is directly part of a task,
  this will fail when multiarch is enabled.

* Every piece of documentation that gives commands lines manipulating
  library packages is potentially broken.

Seems like we need a release where multiarch is classed as an
experimental feature, which when enabled can break the system. But the
sort of problems above are the easy to anticipate ones; my real worry is
the unanticipated classes of problems. Especially if we find intractable
problems or levels of complexity introduced by dropping the unique
package name invariant.

My nightmare scenario is that we release with multiarch, discover that
it's a net negative for our users (proprietary software on amd64 aside,
nearly all the benefits are to developers AFAICS), and are stuck with it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1

[Andrew Shadura]

Hello,

On Wed, 15 Feb 2012 16:40:03 +0100
Piotrek P  wrote:

> Dear All,
> Please be aware that VMware ESX 3.5 is NOT supporting any of Debian
> as Guest OS. Please be aware that VMware ESXi 4.1 IS supporting
> Debian 4.0, 5.0 as Guest OS. Please be aware that VMware ESX 5.0 IS
> supporting Debian 4.0, 5.0, 6.0 as Guest OS.

Piotrek, I wonder, what do you mean when you say 'support'? What kind
of support do you personally need? VMware (afaik) does have some
Linux-specific hacks, but they do work regardless of a distribution and
Linux kernel version. Also, it's quite probable that there aren't any
real hacks there but just some presets (correct me if I'm wrong).

So, does it really matter?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1

[Mathieu Parent]

Le 15 février 2012 16:40, Piotrek P  a écrit :
> Dear All,
Hi,

> Please be aware that VMware ESX 3.5 is NOT supporting any of Debian as Guest 
> OS.
> Please be aware that VMware ESXi 4.1 IS supporting Debian 4.0, 5.0 as Guest 
> OS.
> Please be aware that VMware ESX 5.0 IS supporting Debian 4.0, 5.0, 6.0
> as Guest OS.

You probably take this information from the VMware compatibility guide [1].

This guide says that "Debian GNU/Linux 5.0.7" is supported on ESX
4.1U2, 4.1U1, 4.1 and ESXi 5.0. "Debian GNU/Linux 5.0.8" is only
supported on ESXi 5.0.

Given the small amount of changes between those two stable releases
[2], we can have some doubt about this compatibility list.

[1]: http://www.vmware.com/resources/compatibility/search.php
[2]: http://www.debian.org/News/2011/20110122

> I would like to ask:
> - What does it means for users of Debian 5.0 on ESXi 4.1 if support of
> Debian 5.0 will end?

You can install Debian 6.0.x and tell VMware that it is Debian 5. It
will work. Installing open-vm-tools [3] in the guest will give better
compatibility and performance.

This setup is not officially supported by vmware (do you pay for
vmware support? If so, ask them directly. If not don't expect much
from them).

[3]: http://packages.debian.org/search?keywords=open-vm-tools

> - What about repositories of Debian 5.0?

The lenny repository will stay here for some time, but without
security updates. After some time, it will go to
http://archive.debian.org/.

IMO, upgrading to squeeze is better than no "official" support from VMware.

> - How can I obtain informations about major changes in packages that
> were changed in Debian 6.0 and future releases?

There are news on http://www.debian.org/News/, the squeeze (6.0)
release is described at http://www.debian.org/News/2011/20110205a
(also look at point-releases 6.01, 6.0.2, ...)

> - What is official statement of VMware about not supporting newest
> versions of Debian OS?

Don't know. You can ask them...

> - How is it possible to be updated if VMware is not supporting newest
> version of Debian OS?
I'm not sure to understand this question.

>
> Many thanks for answers.
>
> Best regards,
> Peter P.


Regards
-- 
Mathieu Parent


--
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/CAFX5sbz3Ab0_ot1XVZDr_qR0zLY-hkT6t=X9iyQ9_mvZUc=u...@mail.gmail.com

Re: Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1

[Thijs Kinkhorst]

On Wed, February 15, 2012 16:40, Piotrek P wrote:
> Dear All,
> Please be aware that VMware ESX 3.5 is NOT supporting any of Debian as
> Guest OS.
> Please be aware that VMware ESXi 4.1 IS supporting Debian 4.0, 5.0 as
> Guest OS.
> Please be aware that VMware ESX 5.0 IS supporting Debian 4.0, 5.0, 6.0
> as Guest OS.

Professionally I run many dozens of Debian 5.0 and 6.0 guests on both ESX4
and ESXi4. VMware does indeed have a list of predefined OS'es when
creating a new virtual machine, where you can select only 4.0 and 5.0. For
6.0, just select 5.0 and this works just aswell.

We use paravirtualised SCSI (pvscsi) and VMX3 network drivers without
problems.

> I would like to ask:
> - What does it means for users of Debian 5.0 on ESXi 4.1 if support of
> Debian 5.0 will end?

My answer is that it means that you can just upgrade to 6.0 and that it
works flawlessly. Be sure to use the vmware tools or the Debian shipped
open-vm-tools for best results.


Cheers,
Thijs


-- 
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/d95f15737b9270f8ead7d6ad9a56b600.squir...@wm.kinkhorst.nl

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

[Ian Jackson]

Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: 
Summary: dpkg shared / reference counted files and version match)"):
> On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
> > I think the refcounting approach is very worthwhile because it
> > eliminates unnecessary work (by human maintainers) in many simple
> > cases.
> 
> Aside from what I said on my other reply, I just wanted to note that
> this seems to be a recurring point of tension in the project when it
> comes to archive wide source package changes, where supposed short
> term convenience (with its usually long term harmful effects) appears
> to initially seduce people over what seems to be the cleaner although
> slightly a bit more laborious solution.

The refcnt doesn't just eliminate unnecessary multiarch
conversion work.  It also eliminates unnecessary maintenance effort.
Maintaining a split package will be more work than without.

I think that over the lifetime of the multiarch deployment this extra
packaging work will far outweigh the extra maintenance and
documentation burden of the refcnt feature.

>  [...]  But trying to workaround this by coming
> up with stacks of hacked up solutions  [...]

I disagree with your tendentious phrasing.  The refcnt feature is not
a "hacked up solution" (nor a stack of them).  It is entirely normal
in Debian core tools (as in any substantial piece of software serving
a lot of diverse needs) to have extra code to make it easier to deploy
or use in common cases simpler.

Ian.


-- 
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/20283.57393.237949.649...@chiark.greenend.org.uk

Re: Multiarch file overlap summary and proposal

[Ian Jackson]

Russ Allbery writes ("Re: Multiarch file overlap summary and proposal"):
> I definitely agree on the complexity this adds.  But I don't think there's
> an alternative to that complexity without using something like --sysroot
> or mini-chroots, and I don't think those are satisfying solutions to the
> set of problems we're trying to solve.

In principle we could have added the arch name to the package name of
every library, the same way we add (part of) the version number to the
package name.

I think the current multiarch proposal is a better idea than that.

Ian.


-- 
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/20283.57580.777378.472...@chiark.greenend.org.uk

Re: Multiarch file overlap summary and proposal

[Ian Jackson]

Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
> Goswin von Brederlow wrote:
> > pkg:arch will still be unique and the dpkg/apt output will use the
> > architecture where required for uniqueness. So I think that after some
> > getting used to it it will be clear enough again.
> 
> Here are a few examples of the problems I worry about. I have not
> verified any of them, and they're clearly biased toward code I am
> familiar with, which suggests there are many other similar problems.
> 
> * Puppet not only installs packages, it may remove them. A puppet config
>   that does dpkg --purge foo will fail if multiarch is enabled, now
>   it needs to find and remove foo:*

Yes.

> * dpkg-repack pkg:arch will create a package with that literal name (or fail)

This is of course also a (new) bug.  There will be a lot of bugs like
this while we deploy multiarch.

> * dpkg-reconfigure probably can't be used with M-A same packages.
>   debconf probably generally needs porting to multiarch.

I think the non-arch-qualified nature of debconf question ids is
probably a feature rather than a bug.  These questions should be
arch-qualified by the package only if they need to be.

> [other examples]

Yes.

> Seems like we need a release where multiarch is classed as an
> experimental feature, which when enabled can break the system.

Certainly.  That's what wheezy will be.

>  But the sort of problems above are the easy to anticipate ones; my
> real worry is the unanticipated classes of problems. Especially if
> we find intractable problems or levels of complexity introduced by
> dropping the unique package name invariant.

I think the fact that (package name, architecture) is still unique on
the system will be sufficient to make it possible to update all
existing software to deal with the new model.

> My nightmare scenario is that we release with multiarch, discover that
> it's a net negative for our users (proprietary software on amd64 aside,
> nearly all the benefits are to developers AFAICS), and are stuck with it.

I don't think this is likely.

Ian.


-- 
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/20283.57768.769487.440...@chiark.greenend.org.uk

Bug#660008: ITP: libbind-config-parser-perl -- Parse BIND Config file

[Carlos Vicente]

Package: wnpp
Severity: wishlist
Owner: Carlos Vicente 

* Package name: libbind-config-parser-perl
  Version : 0.01
  Upstream Author : Matt Dainty 
* URL : http://search.cpan.org/dist/BIND-Config-Parser/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Parse BIND Config file

 BIND::Config::Parser provides a lightweight parser to the configuration file 
syntax of BIND v8  and v9 using a Parse::RecDescent grammar.

 It is in a similar vein to BIND::Conf_Parser. However, as it has no knowledge 
of the directives, it doesn't need to be kept updated as new directives are 
added, it simply knows how to carve up a BIND configuration file into logical 
chunks.



-- 
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/20120215173518.24103.37439.reportbug@ubuntu

Re: -fPIE and stuff

[Kurt Roeckx]

On Tue, Feb 14, 2012 at 11:09:44PM +, Sune Vuorela wrote:
> On 2012-02-14, Kurt Roeckx  wrote:
> > It was always my understanding that protected wasn't useful,
> > because it's even more expensive.
> 
> Can you come with a bit pointers or numbers about 'expensive' ?

So as far as I understand things the only way to make protected
work without -fPIE is using text relocations.  This has the
following effects:
- The text segment can no longer be read-only, and so can't be
  shared anymore.
- You need a relocation for each use of the variable.

And you really don't want text relocations.

> > As far as I understand things, this is supposed to work, and might
> > be a bug in the toolchain or dynamic linker.  Which might also
> > mean that they're trying to make use of a bug in the toolchain.
> 
> It is not a bug in the toolchain. It is how the processor specific ABI
> is. 

I'm assuming that you're talking about the small model of amd64.
I can't see anything in the psABI that prevents this from working.

But implementing it with text relocations is something you
don't want, so I can understand that nobody implemented it.
The bug in the toolchain is that it allows you to create
broken binaries.

Anyway, to avoid the copy relocations, I suggest you hide the
symbol and make functions to be able to use it outside the DSO.


Kurt


-- 
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/20120215173938.ga16...@roeckx.be

Re: -fPIE and stuff

[Kurt Roeckx]

On Wed, Feb 15, 2012 at 12:09:41AM +, Uoti Urpala wrote:
> > Anyway, the C standard says that there is a requirement that
> > both the DSO itself as all other objects must be able to take
> > the address of it and still get the same pointer.  And this
> > obviously fails in your example.
> 
> Yes, it fails in that example. But if you're trying to imply that this would
> mean protected visibility itself must be wrong, that does not follow: instead,
> you can say that the tools were invoked with incorrect arguments (missing
> -fPIE).

Or that the tools don't implement the needed things to make it
work without -fPIE.

> > > > As far as I understand things, this is supposed to work, and might
> > > 
> > > It cannot work in the usual setup. Relocations are not supported for the
> > > main binary even on platforms that support them for shared libraries.
> > 
> > I'm pretty sure that the main binary supports relocations.  Else
> 
> I meant the kind of text relocations that you can use in libraries on i386 but
> not on AMD64, and which -fPIC avoids.

Which has nothing to do with the executable?

> > So I would argue that the linker should either have created
> > different relocations or refused to create a binary, since
> > it's creating broken code.
> 
> How could the linker create different relocations? I think doing that at link
> stage would necessarily require adding relocations for the code of the main
> executable. Those certainly aren't supported now, and while I haven't checked
> the details, I believe adding support would require changing more than the
> linker.

And nobody will be interested in implementing it either.

> As for refusing to create a binary, that would probably be possible at least 
> in
> the protected-visibility case, as the protected status is visible in the 
> object
> file. OTOH in many cases things could still work, so a warning might be better
> than a hard failure (many libraries have no modifiable global variables, and 
> for
> many typical uses having parts of the code see different instances of a 
> constant
> symbol would still work as long as the contents of the instances are equal).

I really see no point in exporting constants and then marking
them protected.  About the only useful exported constant I
can think of is something like a version string.  And you
really want to use a function for that.

For all other cases I can't see how it's supposed to work.


Kurt


-- 
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/20120215175318.gb16...@roeckx.be

Re: Multi-arch all-architecture plugins

[Peter Samuelson]

[Goswin von Brederlow]
> Except is gimp the only way to use gimp plugins? Isn't there another app
> foo that also uses libgimp and its plugins? Then you could have
> gimp:amd64, foo:i386.

Actually ... if I remember correctly, gimp plugins are executables, not
libraries, so really they should be M-A: foreign.  So, not really
relevant to this discussion after all.

> So "Multi-Arch: same-as glibc-2.13-1" would be fine. Even "Multi-Arch:
> libc" would be fine (if it is provided).

The problem with M-A: same-as glibc-2.13-1 is that it means you need to
binNMU (or even source NMU) every nss plugin for every major glibc
release.  So, it would be nice to use something more generic.  But, at
the moment, libc's only Provides is glibc-2.13-1.


> I like both the same-as and the Recommends idea. I don't like the
> idea of using the M-A field for same-as. There could be plugins with
> M-A:same as well as M-A:allowed semantic (e.g. a plugin enabling some
> scripting support like perl for irssi), maybe even M-A:foreign.

But only M-A:same has the problem we are trying to solve, namely: if
this module is installed on amd64 we want it to also be installed on
i386.  With M-A:{allowed,foreign}, there is no question of "which
architectures", since you can only install one.

So I don't see a problem overloading the M-A header.  I'd rather see
that than a second header that is only used in this one case that
always involves M-A:same.

Now the exact syntax is a bikeshedding issue.  My original idea was
"M-A: same-as libfoo" but perhaps something like "M-A: same [libfoo]"
or "M-A: same: libfoo" or even "M-A: same: libc6, libc6.1, libc0.1..."

Finally, I note that this is somewhat similar to Enhances.  But I don't
think it's a good idea to overload Enhances.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20120215181932.ge2...@p12n.org

Bug#660010: ITP: jenkins-git-plugin -- allows use of Git as a build SCM

[Jakub Adam]

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

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

   Package name: jenkins-git-plugin
Version: 1.1.15
Upstream Author: CloudBees, Inc and others
License: MIT
Description: Jenkins Git plugin

 This plugin allows use of Git as a build SCM.




--
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/4f3bf791.3090...@ktknet.cz

Bug#660011: ITP: git-ftp -- Git powered FTP client written as shell script

[Dmitry Smirnov]

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


   Package name: git-ftp
Version: 0.6.0+git20110923-1
Upstream Author: René Moser 
URL: https://github.com/resmo/git-ftp
License: GPL-3
Description: git-ftp is a shell script for uploading Git tracked files to a 
FTP server.
 By default, it uploads only those files which have changed 
since the last upload.
 .
 This saves time and bandwidth. It can even work with different 
branches.




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

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

[Don Armstrong]

On Wed, 15 Feb 2012, Charles Plessy wrote:
> To follow the naming scheme of the Perl team, I have renamed one of
> my binary packages ‘bioperl’ to ‘libbio-perl-perl’, but I doubt it
> would be helpful to have such a name as a source package.

Perl common practice is to use the same source and binary package
names. The only exceptions I'm aware of are for perl modules bundled
with upstream distributions or things which were packaged in the mists
of time.

> Then, if one choses a Debian-specific name for an upstream work, it
> is advantageous to keep the same name for the source and binary
> package, and for R and Perl, there are conventions in place.

Right; the primary reason why that is done is because CPAN is the only
perl repository, whereas R has multiple separate repositories, so
namespace conflicts are not enforced like they are in the CPAN world.
[This balkanization is kind of silly, but that's not really something
we can solve in Debian.]
 
> An additional complication comes when a source package produces more
> than one binary package, for instance a R and a Perl library at the
> same time. The convention on the source package name is therefore at
> best a “should”.

The exceptions can be specifically delineated, as they are cases where
you 1) ship multiple binaries 2) ship binaries which encode a version
number. [This basically means that if you're not creating a shared
library, at least one of the packages you distribute should have the
same name as the source package.]

> On top of this, the benefit of of having a policy on source package
> names will be limited as it is unlikely to rename the existing ones.

The main benefit is avoiding unnecessary utilization of the source
package namespace, the secondary benefit is eliminating the current
problem of users misreporting bugs against the wrong package due to
confusing the source↔binary naming. [It is this second problem that I
continually have to deal with, and why I'm particularly aware of it.]
 
> Let's try to agree on a brief policy on naming schemes. Perhaps
> Perl, Python and Java maintainers can comment on whether it would
> make sense to have a common one (drafted as a DEP ?).

A DEP or just a policy amendment specifying the general naming
requirements with pointers to language specific naming policy would
work.
 
> PS: for the new debian-cran prepository, please consider using the
> magic tilde in the version numbers.

Yes, that's the plan.


Don Armstrong

-- 
There are two types of people in this world, good and bad. The good
sleep better, but the bad seem to enjoy the waking hours much more.  
 -- Woody Allen

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120215185057.gm15...@rzlab.ucr.edu

Re: -fPIE and stuff

[Uoti Urpala]

Kurt Roeckx  roeckx.be> writes:
> > > > > As far as I understand things, this is supposed to work, and might
> > > > 
> > > > It cannot work in the usual setup. Relocations are not supported for
> > > > the main binary even on platforms that support them for shared
> > > > libraries.
> > > 
> > > I'm pretty sure that the main binary supports relocations.  Else
> > 
> > I meant the kind of text relocations that you can use in libraries on i386
> > but not on AMD64, and which -fPIC avoids.
> 
> Which has nothing to do with the executable?

That was part of the explanation why your "is supposed to work" is wrong. The
most obvious way how the non-fPIE case could theoretically work would be having
such text relocations for main executable; without them you can't expect things
to work without special tricks.

 
> I really see no point in exporting constants and then marking
> them protected.

Marking things protected is desirable at least if the performance of the code
using them in the library matters.

> About the only useful exported constant I can think of is something like a 
> version string.  And you really want to use a function for that.

There are some use cases - special objects like in my example are perhaps the
most obvious case where things actually break as a result (there are lots of
reasons why you'd want to export constant data tables, but that doesn't usually
break). And you don't really want to add function wrappers for everything.

Note that the problem is not limited to data only. Code like
"if (obj->destructor_func != default_destructor_func)" can also fail.


> For all other cases I can't see how it's supposed to work.

This sentence does not work in its context. What "it" are you referring to here?


-- 
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/loom.20120215t195515-...@post.gmane.org

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

[Joachim Breitner]

Hi,

Am Mittwoch, den 15.02.2012, 11:22 +0900 schrieb Charles Plessy:
> Let's try to agree on a brief policy on naming schemes.  Perhaps Perl,
> Python and Java maintainers can comment on whether it would make sense
> to have a common one (drafted as a DEP ?). 

with my Haskell Group hat on, although not in your list, I am strongly
in the favor of renaming such language-specific libraries unless there
is a good reason for that (e.g. a name that is known beyond the
programming community of that language, e.g. “xmonad”).

Here is a selection of Haskell packages that are currently packaged as
“haskell-foo” – surely nobody would want these taken as source package
names directly:

arrows
authenticate
binary
cairo
bzlib
brainfuck
boolean
clock
cgi
csv
debian(!)
devscripts(!)
dpkg
hostname
keys
text
zlib

So I’d say that every group maintaining a set of packages from one
source where the upstream names behave as if they have a namespace all
for themselves (as it is the case with Haskell packages, but also for
example R packages) needs to come up with a policy to take them out of
the Debian namespace. 

I do not think that there is a  need for an agreement between the
different groups. None of the groups will likely want to spend the time
to rename all source packages.

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. Obviously, I prefer lang-foo (shorter, less noise, in
sorted list the packages are grouped) and would appreciate if new groups
would follow the scheme. But again, I don’t think we’d need a formal DEP
or something, and just leave it to the groups to do the sensible thing.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Bug#660019: ITP: network-manager-iodine -- Iodine DNS Tunnel plugin for network-manager

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: "Guido Günther" 

* Package name: network-manager-iodine
  Version : 0.0.1
  Upstream Author : Guido Günther 
* URL : 
https://honk.sigxcpu.org/piki/projects/network-manager-iodine/
* License : GPL
  Programming Lang: C
  Description : Iodine DNS Tunnel plugin for network-manager

NetworkManager-iodine is a network manager VPN plugin that allows you to
tunnel your connection through a DNS server. This can be useful if
internet access is firewalled but DNS traffic is still allowed.



--
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/20120215202948.ga20...@godiug.sigxcpu.org

Bug#660025: ITP: libtwin - A tiny window system

[Geoff Levand]

Package: wnpp
Severity: wishlist
Owner: Geoff Levand 

* Package name: libtwin
  Version : 11.12.11-gcc20d5f
  Upstream Author : Geoff Levand 
* URL : http://git.kernel.org/?p=linux/kernel/git/geoff/twin.git
* License : LGPLv2
  Programming Lang: C
  Description : A tiny window system
 With embedded systems gaining high resolution displays and powerful
 CPUs, the desire for sophisticated graphical user interfaces can be realized in
 even the smallest of systems. While the CPU power available for a given power
 budget has increased dramatically, these tiny systems remain severely memory
 constrained. This unique environment presents interesting challenges in 
graphical
 system design and implementation. To explore this particular space, a new
 window system, TWIN, has been developed. Using ideas from modern window systems
 in larger environments, TWIN offers overlapping translucent windows,
 anti-aliased graphics and scalable fonts in a total memory budget of 100KB.




-- 
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/e1rxlml-0003fp...@bombadil.infradead.org

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

[Scott Kitterman]

On Wednesday, February 15, 2012 10:50:57 AM Don Armstrong wrote:
> On Wed, 15 Feb 2012, Charles Plessy wrote:
> > To follow the naming scheme of the Perl team, I have renamed one of
> > my binary packages ‘bioperl’ to ‘libbio-perl-perl’, but I doubt it
> > would be helpful to have such a name as a source package.
> 
> Perl common practice is to use the same source and binary package
> names. The only exceptions I'm aware of are for perl modules bundled
> with upstream distributions or things which were packaged in the mists
> of time.
> 
> > Then, if one choses a Debian-specific name for an upstream work, it
> > is advantageous to keep the same name for the source and binary
> > package, and for R and Perl, there are conventions in place.
> 
> Right; the primary reason why that is done is because CPAN is the only
> perl repository, whereas R has multiple separate repositories, so
> namespace conflicts are not enforced like they are in the CPAN world.
> [This balkanization is kind of silly, but that's not really something
> we can solve in Debian.]
> 
> > An additional complication comes when a source package produces more
> > than one binary package, for instance a R and a Perl library at the
> > same time. The convention on the source package name is therefore at
> > best a “should”.
> 
> The exceptions can be specifically delineated, as they are cases where
> you 1) ship multiple binaries 2) ship binaries which encode a version
> number. [This basically means that if you're not creating a shared
> library, at least one of the packages you distribute should have the
> same name as the source package.]
> 
> > On top of this, the benefit of of having a policy on source package
> > names will be limited as it is unlikely to rename the existing ones.
> 
> The main benefit is avoiding unnecessary utilization of the source
> package namespace, the secondary benefit is eliminating the current
> problem of users misreporting bugs against the wrong package due to
> confusing the source↔binary naming. [It is this second problem that I
> continually have to deal with, and why I'm particularly aware of it.]
> 
> > Let's try to agree on a brief policy on naming schemes. Perhaps
> > Perl, Python and Java maintainers can comment on whether it would
> > make sense to have a common one (drafted as a DEP ?).
> 
> A DEP or just a policy amendment specifying the general naming
> requirements with pointers to language specific naming policy would
> work.

While I agree that preserving namespace is an important goal, I think it 
should be balanced against the goal of making packages discoverable by users.  
If they can find the source package by the upstream name (where it doesn't 
match the language specific policy requirement) then usually they can find the 
binary (or worst case a bug gets mis-filed against the source and the 
maintainer still finds out).

As an example, one of the packages I maintain is known upstream as pyspf.  The 
Debian python naming requirement for the binary is python-spf.  Since the 
upstream name is python specific and not likely to collide, I think having the 
source package match the upstream name (as it does) is quite reasonable.

I also maintain python-ipaddr.  Here the upstream name was ipaddr.  This 
seemed like far to generic a name to 'use up', so I named the source package 
after the binary, python-ipaddr.

Whatever rule you come up with, I don't think it's one size fits all.

Scott K


--
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/9430476.zv407ajPtt@scott-latitude-e6320

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

[Don Armstrong]

On Wed, 15 Feb 2012, Scott Kitterman wrote:
> While I agree that preserving namespace is an important goal, I
> think it should be balanced against the goal of making packages
> discoverable by users.

I agree; however, I think this is best accomplished by including the
upstream name in the package name (so it shows up in apt-cache search)
or in the cases where the language policy says otherwise, in the
description, so it also shows up in apt-cache search.

> As an example, one of the packages I maintain is known upstream as
> pyspf. The Debian python naming requirement for the binary is
> python-spf.

In this example, the Description of python-spf should include
something like "Also known as pyspf". [I should note that naming the
source pyspf doesn't really help with the discoverability of
python-spf, as apt-cache search does not search the Source: field...
this is why apt-cache search pyspf doesn't return python-spf, but
returns spf-tools-python.]

> Whatever rule you come up with, I don't think it's one size fits
> all.

I'm perfectly ok with specific exceptions to the rule, or even ending
up with a guideline that can be ignored when DDs decide that it's ok.


Don Armstrong

-- 
Clothes make the man. Naked people have little or no influence on
society.
 -- Mark Twain 

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120215224216.gs15...@rzlab.ucr.edu

Re: -fPIE and stuff

[Kurt Roeckx]

On Wed, Feb 15, 2012 at 07:39:50PM +, Uoti Urpala wrote:
> 
> The most obvious way how the non-fPIE case could theoretically work would be 
> having
> such text relocations for main executable; without them you can't expect 
> things
> to work without special tricks.

Yes, and I expect the toolchain to tell me that that isn't
implemented.  A warning would clearly be better than the current
behaviour.


Kurt


-- 
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/20120215230038.ga21...@roeckx.be

Re: Probable multiarch related problem in finding header file posix_types_32.h

[Carsten Hey]

* Steve Langasek [2012-02-14 09:29 -0800]:
> Where we've run across similar problems with posix_types.h in the recent
> past, it has indeed been due to the use of "gcc -I-".

Drafts of the C89 and C11 standards read:
| A preprocessing directive of the form
|   # include "q-char-sequence" new-line
| causes ...  If this search is not supported, or if the search fails,
| the directive is reprocessed as if it read
|   # include  new-line
| with the identical contained sequence (...) from the original
| directive.

GCC's texinfo documentation (for version 4.4) of both options, -I- and
-iquote, doesn't seem to contain anything that would contradict the
above.

> ultimately though I think this is a bug in linux-libc-dev for using
> #include "" here.

Or it is a bug in the preprocessor, i.e., gcc?


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/20120215230448.ga16...@furrball.stateful.de

Re: Probable multiarch related problem in finding header file posix_types_32.h

[Russ Allbery]

Carsten Hey  writes:
> * Steve Langasek [2012-02-14 09:29 -0800]:

>> Where we've run across similar problems with posix_types.h in the recent
>> past, it has indeed been due to the use of "gcc -I-".

> Drafts of the C89 and C11 standards read:
> | A preprocessing directive of the form
> |   # include "q-char-sequence" new-line
> | causes ...  If this search is not supported, or if the search fails,
> | the directive is reprocessed as if it read
> |   # include  new-line
> | with the identical contained sequence (...) from the original
> | directive.

> GCC's texinfo documentation (for version 4.4) of both options, -I- and
> -iquote, doesn't seem to contain anything that would contradict the
> above.

The directory that these files are in isn't directly on the include search
path.  It's a subdirectory of /usr/include/.

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

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

[Goswin von Brederlow]

Ian Jackson  writes:

> Serafeim Zanikolas writes ("Re: [DEP9] call for testing of reconf-inetd 
> (update-inetd replacement)"):
>> Any local sysadmin changes must be done in inetd.conf, as always.
>> 
>> The choice of /usr/share/ follows from two of the requirements I
>> have set from the beginning for DEP9 [0]:
>> 
>> - the standard configuration files of inetd and xinetd must remain the
>>   authoritative files;
>> - the solution must not change the way system administrators configure inetd
>> 
>> /usr/share/reconf-inetd fragments are not configuration files; they're just
>> input to reconf-inetd. You can think of them as the file-based equivalent of
>> command line arguments to update-inetd
>
> OK, thanks for that explanation.
>
> Ian.

+1.

One thing though: Can I add my own local fragments? Is there a fragment
dir in /etc for that?

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/874nusteej.fsf@frosties.localnet

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

Ian Jackson  writes:
> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):

>> Here are a few examples of the problems I worry about. I have not
>> verified any of them, and they're clearly biased toward code I am
>> familiar with, which suggests there are many other similar problems.

>> * Puppet not only installs packages, it may remove them. A puppet config
>>   that does dpkg --purge foo will fail if multiarch is enabled, now
>>   it needs to find and remove foo:*

> Yes.

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?

This comes back to something that I started thinking about after Guillem's
message, namely that I think the version lockstep is a feature, not a
limitation.  A lot of the complexity from biarch with RPM comes from the
fact that the packages are (as I recall) independent and can be of
different versions.  This sounds like a nice feature, but I think it's
actually a huge source of potential confusion and isn't as useful as it
may look.

I think it would be better to have a world in which all the architectures
of the foo package on the system have to have the same version, because
then you don't have to treat foo:i386 and foo:amd64 like they're separate
packages.  The list of installed architectures is an *attribute* of the
package.  A package is still either installed or not installed, but when
it's installed, it can be installed for one or more architectures.  But if
it's installed for multiple architectures, those architectures are always
upgraded together and always remain consistent.  That avoids all weirdness
of having a package work differently because the version varies depending
on the ABI, and it significantly simplifies the mental model behind the
package.

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.

I have not looked in detail at the current multiarch implementations and I
have no idea how closely the above matches what is actually being done,
but I would advocate for it, even to the degree of embedding understanding
of binNMU versioning in the package tools so that they know a binNMU is a
new version from the perspective of needing to upgrade the package but not
a new version from the perspective of version mismatches between arches.

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

Re: DEP5: minor suggestions - FSF address etc.

[Charles Plessy]

Le Wed, Feb 15, 2012 at 05:06:53AM -0500, Jari Aalto a écrit :
> 
> In my opinion, we should follow strictly how FSF recommends the GPL to be
> presented. The use of postal addresses is no longer the FSF's current
> postion.
 
Le Wed, Feb 15, 2012 at 05:14:36AM -0500, Jari Aalto a écrit :
> 
> I though that DEP5 was intended to use for Debian and not to record how
> upstram chose to write their copyright statements.
> 
> I feel that Debian should focus on standards and therefore also present
> those standards in DEP documents to the readers that follow the DEPs.

Hi again,

I think that it is very important that developers understand that the
machine-readable format is not adding any extra requirement about what
the contents of a Debian copyright file should be.

1) Correcting the FSF address in GPL-2 notices is unusual in Debian,
   and if we do so in our examples I am worried that it may be interpreted
   that it is necessary.  Again, the link you sent does not mention GPL
   version 2.  Can you point at a FSF statement that recommends, for those
   who do not upgrade to GPL version 3, to at least replace the postal
   address by the URL ?

2) The reason for collecting copyright statements is, in my understanding,
   to respect the licenses.  This need may be fictional as the source and
   binary packages are considered a single entity in order to respect the
   GPL v1 and v2, but that is the way we do it.  In that sense, reformatting
   upstream statements, even when they are bogus, is not a necessity and
   again, while the machine-readable format allows to do more than necessary
   it is important to make clear that this is optional.  In that sense,
   I think that it is good that multiple examples show multiple styles,
   even if one is inferior or typograhpically illogical.

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

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

Guillem Jover  writes:

> If packages have to be split anyway to cope with the other cases, then
> the number of new packages which might not be needed otherwise will be
> even smaller than the predicted amount, at which point it makes even
> less sense to support refcnt'ing.

I don't think the package count is really the interesting metric here,
unless the number of introduced packages is very large (see below about
-dev packages).  I'm more concerned with maintainer time and with
dependency complexity, and with the known problems that we introduce
whenever we take tightly-coupled files and separate them into independent
packages.

> It also requires maintainers to carefully consider if the (doc, etc)
> toolchains will generate predictible ouput.

Yes, I agree.  There's a tradeoff between having to think about this and
having to do the work to use arch-qualified directories.  But I think it's
worth having the tradeoff available as an option.

> This still does not solve the other issues I listed, namely binNMUs have
> to be performed in lock-step, more complicated transitions /
> upgrades. And introduces different solutions for different problems,
> while my proposal is generic for all cases.

I did review your message again (I read it when you originally posted it
as well), and I think that I addressed the cases that you pointed out in
the set of cases that I discussed in my message apart from the point about
version lockstep.

I just posted separately about version lockstep: I think this is a
feature, not a bug, in our multiarch implementation.  I think this is the
direction we *should* go, because it reduces the overall complexity of the
system.  Yes, that requires treating binNMUs as something different than a
sourceful version change, but I think that's a good idea *anyway*, even in
the absence of multiarch.  It's more semantically accurate, and it would
address other lingering problems we've had with binNMUs, or at least
reduce them.

As for the benefits of refcounting, there are three places where I think
this has substantial benefit, so let me talk through them:

1. If you look at the list of files that Steve gave in multiarch: same
   packages in Ubuntu, most of the cases that don't fall into the known
   documentation and package metadata areas are a bunch of separate
   special cases.  They don't fall easily into a handful of cases.  *But*,
   they are mostly all files in either textual or consistent binary
   formats that are installed directly from the package and are not going
   to change in a binNMU.  That means that refcounting provides a nice
   simplification: there are a bunch of random additional files of various
   different types that can all be handled the same way, without
   additional packaging complexity.  They can't all be arch-qualified in
   the same way as easily, plus arch-qualifying files that absolutely
   should not differ between architectures and where that difference would
   be a bug (such as with PAM configuration) seems wrong.

   They can also be split out into an arch: all package.  But here I think
   it's worth remembering that splitting tightly-coupled files into
   separate packages has real drawbacks and is something we should avoid
   doing if we can.  There are places where the advantages to doing so are
   overwhelming (-dev packages from shared libraries, for example), but we
   should be sure we're in that case.

   This is something that working on Lintian for a while really drove home
   for me.  People split binary packages with large data into an arch: any
   and arch: all package (often because Lintian recommends it to save
   archive space), and they do it wrong *all the time*.  They get the
   dependencies wrong, or don't think about what files belong in which
   package, or accidentally put an arch-specific file in the data package.
   I have a package that does this sort of split (gnubg), and from
   personal experience know that it's not an easy thing to maintain.
   We're not saving packaging complexity by asking people to do this
   instead of refcounting, IMO.

   Also, there are other drawbacks of splitting closely coupled files into
   separate packages even apart from packaging complexity.  For example,
   it's common for people to move the man pages and desktop files for
   binaries into that arch: all data package too, since hey they're
   arch-independent and in /usr/share and that's easy.  But this is
   usually the wrong thing to do.  Now you have created the possibility of
   having desktop files installed for binaries that don't exist, you've
   made it much harder for tools like Lintian to check that your man pages
   and desktop files are consistent with the binaries, and you have to be
   very careful about versioning dependencies.  You also create a separate
   package that's artificial from the user's perspective, may not get
   removed when the main package is removed, and shows up in apt-cache
   search and similar interfa

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

[Paul Wise]

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?

-- 
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/caktje6em9_qc_bazcannx_54xrp99avf0b4x96mvui9nt3-...@mail.gmail.com

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

[Serafeim Zanikolas]

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

[0] though the probability of that at the moment is precisely zero, because
reconf-inetd has no reverse deps yet

[1] although, the talk is more about the consensus building & development
process, rather than DEP9 per se (which would be terribly boring!)

http://video.fosdem.org/2012/crossdistro/How_to_replace_a_legacy_tool_with_100k_installations.webm


-- 
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/20120215232214.GG26977@mobee

Re: Multiarch file overlap summary and proposal

[David Kalnischkies]

On Thu, Feb 16, 2012 at 00:39, Russ Allbery  wrote:
> Ian Jackson  writes:
>> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>
>>> Here are a few examples of the problems I worry about. I have not
>>> verified any of them, and they're clearly biased toward code I am
>>> familiar with, which suggests there are many other similar problems.
>
>>> * Puppet not only installs packages, it may remove them. A puppet config
>>>   that does dpkg --purge foo will fail if multiarch is enabled, now
>>>   it needs to find and remove foo:*
>
>> Yes.
>
> 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".

You can counter this with: Then be specific while installing, but this not
only breaks backward-compatibility (especially dist-upgrades), it also adds
either unnecessary work for single-arch users or it feels strange to accept
a command in singlearch while it fails in multiarch…
(and yes, i know that i have 'lost' the 'battle' in [1], so the handling is
 different in APT vs dpkg unfortunately, but that's life it seems…)


Maybe it would help this kind of discussions if we would have a list of
interface changes in dpkg and how someone is supposed to use it in the
future in case this has changed - i personally lost track of that.
(In case someone wants to know this for APT: foo is interpreted as foo:native.
 If arch of foo is not native, the packagename is display as foo:arch.
 So at least in my eyes brain-death simple - and backward compatible.
 [and no, foo:* is currently not supported, but its on the todo])


> I think it would be better to have a world in which all the architectures
> of the foo package on the system have to have the same version, because
> then you don't have to treat foo:i386 and foo:amd64 like they're separate
> packages.  The list of installed architectures is an *attribute* of the
> package.  A package is still either installed or not installed, but when
> it's installed, it can be installed for one or more architectures.  But if
> it's installed for multiple architectures, those architectures are always
> upgraded together and always remain consistent.  That avoids all weirdness
> of having a package work differently because the version varies depending
> on the ABI, and it significantly simplifies the mental model behind the
> package.

This is the case for M-A:same packages currently.
libfoo:i386 v1 and libfoo:amd64 v2 are not supposed to be co-exist on a
system and as you describe it: its a feature in my eyes, too.
If you want co-installable different versions, call the packages libfoo1 and
libfoo2…

stable/testing users will not have a problem with this version-lock anyway
and unstable users should be able to deal with temporary uninstallable
packages caused by packages not built for all archs yet.
Its not exactly a new type of problem for them anyway…
(btw: doesn't britney do these lock-step upgrades all day long…)

(Note though that e.g. APT is not able to handle installed architectures as an
 'attribute'. It not only has to handle them as 'different' packages (and more
 specific different versions) to keep backward-compatibility, also different
 dependencies on different architectures would make it pretty messy in
 practice. But double-think is a requirement for APT development anyway. ;) )


> 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…)
The qu

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

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.

If removing the non-native architecture has cascading effects, apt is
obviously going to warn them about that already and they'll realize what's
going on.

> You can counter this with: Then be specific while installing,

No, I agree that preserving apt-get install libfoo as "install a native
libfoo" is important.

> Maybe it would help this kind of discussions if we would have a list of
> interface changes in dpkg and how someone is supposed to use it in the
> future in case this has changed - i personally lost track of that.
> (In case someone wants to know this for APT: foo is interpreted as foo:native.
>  If arch of foo is not native, the packagename is display as foo:arch.
>  So at least in my eyes brain-death simple - and backward compatible.
>  [and no, foo:* is currently not supported, but its on the todo])

Yes, one drawback of my approach is that you use that very simple rule.

> (Note though that e.g. APT is not able to handle installed architectures
> as an 'attribute'. It not only has to handle them as 'different'
> packages (and more specific different versions) to keep
> backward-compatibility, also different dependencies on different
> architectures would make it pretty messy in practice. But double-think
> is a requirement for APT development anyway. ;) )

Yes, definitely the internals of our package management software can't
fully compress the packages together; at the least, the dependencies are
going to be different between architectures and have to be stored
separately.  And I think we're going to want binNMUs in the long run as
well; they're just too helpful for library transitions.

But I think what we should be telling the *user*, regardless of our
internals, is "don't think of libfoo:i386 and libfoo:amd64 as two separate
packages that you can maintain independently; think of libfoo as being
installed for one or more architectures."

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

I think that the best long-term way to handle binNMUs may be to move the
build number into a different piece of package metadata from the version.
So a binNMU of a package with version 1.4-1 would still have version 1.4-1
but would have a build number of 2 instead of 1.  I think this would be
way cleaner in the long run, and not just for multiarch.

A lot of stuff would have to change to get to there from here, though.

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

Re: Multiarch file overlap summary and proposal

[Russ Allbery]

Russ Allbery  writes:
> David Kalnischkies  writes:

>> Maybe it would help this kind of discussions if we would have a list of
>> interface changes in dpkg and how someone is supposed to use it in the
>> future in case this has changed - i personally lost track of that.  (In
>> case someone wants to know this for APT: foo is interpreted as
>> foo:native.  If arch of foo is not native, the packagename is display
>> as foo:arch.  So at least in my eyes brain-death simple - and backward
>> compatible.  [and no, foo:* is currently not supported, but its on the
>> todo])

> Yes, one drawback of my approach is that you use that very simple rule.

Ack, sorry, that was supposed to be "that you *lose* that very simple
rule."

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