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
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 y
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
>>> famil
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
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, em
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 pac
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 th
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 probl
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 beginnin
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
> | # incl
* 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
|
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 tool
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
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
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
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
Descr
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, althou
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
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 binar
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
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 all
[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
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.
>
> Y
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 t
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
Des
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.
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
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
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,
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,
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
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 a
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:/
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 f
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
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
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 incompatibl
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
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 pr
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
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 somet
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 transmembra
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 g
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 t
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 : clie
45 matches
Mail list logo
