Hey,
I've found that nice stuff recently and just wanted to ask what do you
think about it? Check it out here https://is.gd/MypJ0j
My Best, Goswin von Brederlow
From: developers-reference [mailto:developers-refere...@packages.debian.org]
Sent: Monday, August 07, 2017 8:05 AM
To: wer
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Goswin von Brederlow writes (Re: Bug#664257: multiarch tuples are not
documented/defined):
It is a bug in Debian: The multiarch tuples are not documented/defined
in Debian.
They are now documented on the wiki, as previously noted
Roger Leigh rle...@codelibre.net writes:
On Tue, Jun 07, 2011 at 11:14:14AM +0200, Tollef Fog Heen wrote:
]] Steve Langasek
Hi,
| 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for
| all packages in unstable and experimental immediately, with no fallback
|
Steve Langasek vor...@debian.org writes:
Hi there,
On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote:
The Multiarch specification only covers libraries and does not
specifically deal with include files.
To make multiarch useful for cross-building as well as co-installation of
Raphael Hertzog hert...@debian.org writes:
On Sun, 03 Apr 2011, Russ Allbery wrote:
My inclination is to second this, but I want to make sure that we've
answered your and Julien's objections first.
And for complete reference, dpkg accepts those version in
/var/lib/dpkg/status (so that dpkg
Steve Langasek vor...@debian.org writes:
On Fri, Apr 08, 2011 at 07:44:27PM +0200, Goswin von Brederlow wrote:
On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote:
The Multiarch specification only covers libraries and does not
specifically deal with include files.
To make multiarch
Peter Pentchev r...@ringlet.net writes:
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude
Roger Leigh rle...@codelibre.net writes:
On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
I disagree here.
Alternatives in build-* relationships
Eugene V. Lyubimkin jac...@debian.org writes:
[ sorry for not proper 'mail-reply', used wrong mail address before ]
Huh? The presense of Replaces allows the two to be both unpacked. The
Repalces specifically disables the file conflict.
Replaces is one-way dependency, Breaks is two-way one.
Simon McVittie s...@debian.org writes:
On Sun, 22 Aug 2010 at 20:22:17 +0200, Sebastian Andrzej Siewior wrote:
This means that architecture restrictions must not be used in binary
relationship fields for architecture-independent packages (Architecture:
all).
This just forbids the following:
Eugene V. Lyubimkin ext-lyubimkin.eug...@nokia.com writes:
Seconded.
Specifically, Policy now allows use Breaks, not Conflicts if two
packages has a file conflict. I consider it as a regression - a
high-level package manager cannot assume anymore that two packages
having Breaks can be
Package: debian-policy
Version: 3.8.4.0
Severity: normal
Hi,
in May there was a discussion about the right use of Breaks or
Conflicts as part of Bug#582423, e.g.
http://lists.debian.org/debian-ctte/2010/05/msg00012.html
Since then I've noticed at least 3 people on #debian-devel asking
Package: debian-policy
Version: 3.8.4.0
Severity: normal
Hi,
Debian Policy 8.6 'Dependencies between the library and other packages
- the shlibs system' seems seriously out of date as it makes no
mentioning of symbols files at all.
Other than the lack of documentation of the superior system I
Guillem Jover guil...@debian.org writes:
Hi!
On Fri, 2010-04-23 at 10:51:56 +0200, Goswin von Brederlow wrote:
Package: debian-policy
Version: 3.8.4.0
Severity: normal
to test the actual behaviour of dpkg for this situation I created the
following 5 packages:
[...]
In conclusion
...@frosties:~/t% dpkg -s bar
Package: bar
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 44
Maintainer: Goswin von Brederlow goswin-...@web.de
Architecture: all
Version: 2b
Replaces: foo (= 1)
Breaks: foo (= 1)
Description: dummy foo
dummy package to test
m
Eugene V. Lyubimkin jac...@debian.org writes:
Package: debian-policy
Version: 3.8.4.0
Severity: normal
From Debian policy, paragraph 7.3:
-8-
If the breaking package also overwrites some files from the older
package, it should use Replaces (not Conflicts) to ensure this goes
smoothly.
Steve Langasek vor...@debian.org writes:
On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote:
I stumbled upon policy 7.4:
A Conflicts entry should almost never have an earlier than version
clause.
This would prevent dpkg from upgrading or installing the package which
Eugene V. Lyubimkin jac...@debian.org writes:
package debian-policy
retitle 578852 clarify installation of package having reverse-Replaces
thanks
Eugene V. Lyubimkin wrote:
[...]
My mail client somewhy garbaged the output in my previous message, sorry for
that.
I think the title was
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
Package: debian-policy
Severity: wishlist
The desired outcome is that all package grab the values directly from
dpkg-buildflags and that we can stop exporting the
Russ Allbery r...@debian.org writes:
Raphael Hertzog hert...@debian.org writes:
Russ, dpkg-gensymbols could be modified to do that shlibs
generation. Feel free to file a wishlist request against dpkg-dev.
Will do. Thanks! I agree with Mike that for people already maintaining a
symbols
Russ Allbery r...@debian.org writes:
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
On Thu, Mar 04, 2010 at 11:00:45PM +0100, Stefano Zacchiroli wrote:
Currently, packages ships file checksums which are computed at package
build time by the means of dh_md5sums (usually), and
Stefano Zacchiroli z...@debian.org writes:
Package: debian-policy
Severity: wishlist
Version: 3.8.4.0
[ For the full context, see the -devel thread starting at
http://lists.debian.org/debian-devel/2010/03/msg00038.html ]
On Thu, Mar 04, 2010 at 01:12:26PM -0800, Russ Allbery wrote:
Russ Allbery r...@debian.org writes:
martin f krafft madd...@debian.org writes:
I still think set -e is a good idea, but I realise it boils down to
preference. If your experience is representative, then it's probably
better to advocate not setting set -e in init scripts.
What about
Russ Allbery r...@debian.org writes:
Mike Hommey m...@glandium.org writes:
I first though having dh_makeshlibs do the right thing would be good
enough, but that would also put an unnecessary burden on those that
don't use debhelper.
Is there any way that dpkg-gensymbols could do it
Simon McVittie s...@debian.org writes:
While trying to prepare a multiarch version of libdbus I received some
conflicting advice about how much of the multiarch proposal is already
allowed by Policy, so I've prepared a multiarch version of a rather
simpler library (libgfshare) as a starting
Hector Oron hector.o...@gmail.com writes:
Hi,
2010/1/25 Bill Allombert bill.allomb...@math.u-bordeaux1.fr:
OK, I will release the new policy soon if there is no objection from the
other maintainers. Sorry I did not notice there were normative changes.
OK, revert my objection. Thanks!
Hi,
Steve Langasek (vorlon) informed me on irc that the policy changes for
multiarch are commited now but not yet released and this is now blocking
the progress of multiarch as in the case of eglibc:
11:21 vorlon mrvn: the change is committed; talk to the policy maintainers
about
Hector Oron hector.o...@gmail.com writes:
Hello Goswin,
2010/1/25 Goswin von Brederlow goswin-...@web.de:
Steve Langasek (vorlon) informed me on irc that the policy changes for
multiarch are commited now but not yet released and this is now blocking
the progress of multiarch as in the case
martin f krafft madd...@debian.org writes:
also sprach Steve Langasek vor...@debian.org [2010.01.26.0007 +1300]:
I don't see any reason for the package manager changes to block
the Policy update. Even if the multiarch field is not yet
supported, it doesn't hurt anything to have packages
Vincent Danjean vincent.danj...@ens-lyon.org writes:
Kurt Roeckx wrote:
On Fri, Nov 13, 2009 at 08:51:42PM +0100, Bill Allombert wrote:
I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
packages with rpath pointing outside /usr/lib and /lib. This clearly
warrant a REJECT
Raphael Geissert geiss...@debian.org writes:
Bill Allombert wrote:
3) If a package is lacking debian/README.source, then one should expect
that the source is ready to be used. If it not the case, even an empty
debian/README.source is better than none.
What would an empty README.source
Manoj Srivastava sriva...@debian.org writes:
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
Manoj Srivastava wrote:
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
I've documented the .ddeb format in the wiki page [1] (DDeb Format,
which is short since the format is basically that of
Russ Allbery r...@debian.org writes:
Martin Zobel-Helas zo...@ftbfs.de writes:
i would like to propose an addendum to section 7.7 of the Debian Policy:
| Build-Depends and Build-Depends-Indep must not depend directly or
| indirectly on packages which provide network services.
Package
sean finney sean...@debian.org writes:
On Thu, Jul 02, 2009 at 09:44:50AM -0500, Manoj Srivastava wrote:
The question is, why should we change something so deeply
deployed as package postinst API without compelling reasons that the
postinst should treat an upgrade differently from a
Adam D. Barratt a...@adam-barratt.org.uk writes:
On Thu, 2009-06-04 at 14:14 +0200, Bill Allombert wrote:
Consider this example: the safe printf way to do
echo $BAR
is
printf %s\n $BAR
(in case BAR hold a value like BAR=%s a)
So printf is slightly unwiedly to use and it can create
Jonathan Yu jonathan.i...@gmail.com writes:
Hi:
This is probably a stupid question, but...
On Tue, May 26, 2009 at 11:33 PM, Russ Allbery r...@debian.org wrote:
Currently, Policy's description of Architecture includes the statement:
  In the main debian/control file in the source
Russ Allbery r...@debian.org writes:
Currently, Policy's description of Architecture includes the statement:
In the main debian/control file in the source package, or in the
source package control file .dsc, one may specify a list of
architectures separated by spaces, or the
Steve Langasek vor...@debian.org writes:
On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
I thought it was generally recognized that it's a Bad Idea to implement
config files using your interpreter's 'include'
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote:
On Sun, 10 May 2009, Steve Langasek wrote:
I'm really surprised to see this approach getting traction. To me, this
seems like a significant, unprecedented departure
Holger Levsen hol...@layer-acht.org writes:
Hi,
while testing the archive with piuparts I found a failure reported by
piuparts, that after purge /var/games existed on the system while it wasnt
there before installing+purging the package.
See
Raphael Hertzog hert...@debian.org writes:
On Tue, 17 Mar 2009, Manoj Srivastava wrote:
On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
It seems to me that you are indeed close, but with the exception of
this required include in all our debian/rules, which will be a PITA to
achieve.
Steve Langasek vor...@debian.org writes:
On Wed, Mar 18, 2009 at 12:52:39AM +0100, Rafael Laboissiere wrote:
* Bill Allombert bill.allomb...@math.u-bordeaux1.fr [2009-03-17 17:02]:
What is the rational for making the library private in the first place ?
In the case of the octave package,
Kurt Roeckx k...@roeckx.be writes:
On Mon, Mar 16, 2009 at 10:44:49AM -0700, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
This recommendation needs to be elminated entirely. It is *not* ok for
packages that provide libraries to stick extra linker paths in the
global
Raphael Hertzog hert...@debian.org writes:
On Fri, 13 Mar 2009, Manoj Srivastava wrote:
3. dpkg-buildpackage is probably the wrong place to put this solution
in.
Why?
The fact that dpkg-buildpackage's setting the variables is not
easily configurable, and presents to make as
Package: debian-policy
Severity: normal
Hi,
Debian policy 10.2 Libraries says:
| Packages containing shared libraries that may be linked to by other
| packages' binaries, but which for some compelling reason can not be
| installed in /usr/lib directory, may install the shared library files
| in
Manoj Srivastava sriva...@debian.org writes:
I am wondering which is of more use to the end users as well: I
can always get the sources of the package I have already on my disk
from Debian, but getting the latest munged source seems more useful to
me.
Full ACK. The way to get the
Gabor Gombas [EMAIL PROTECTED] writes:
On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
What about these clauses as a Policy amendment?
1. If a library *only supports the retrieval of FOO_LIBS and / or
FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
Peter Samuelson [EMAIL PROTECTED] writes:
[Lucas Nussbaum]
- the number of parallel jobs should be specified by the developer
building the package. There's no way to automatically guess the
value in a sensible way, since it doesn't depend only on the number
of CPUs but also on the
Kurt Roeckx [EMAIL PROTECTED] writes:
On Thu, Jan 18, 2007 at 03:12:12PM +0100, Goswin von Brederlow wrote:
In the initial report you mentioned that sbuild has a problem with
confusing names like this. Afaik sbuild solely works on source package
name and version and that is always unique
Steve Langasek [EMAIL PROTECTED] writes:
If you want to declare a strict versioned dependency from an arch: all
package to an arch: any package... don't do that, because it will break
under binNMUs. :)
I only know of one simple way to handle this:
arch:any provides any-package-1.2-3
arch:all
Ian Jackson [EMAIL PROTECTED] writes:
Package: debian-policy
,[ § 7.2 ]
| In case of circular dependencies, since installation or removal order
| honoring the dependency order can't be established, dependency loops
| are broken at some random point, and some packages may
Charles Fry [EMAIL PROTECTED] writes:
Hi,
I recently uploaded courierpassd, which wraps some functionality of
courier-authlib in the popassd protocol. lintian has been warning me
about the use of rpath, about which I posted on debian-mentors. This
culminated in the following thread:
Steve Langasek [EMAIL PROTECTED] writes:
On Sat, Jul 15, 2006 at 02:25:49PM +0200, Goswin von Brederlow wrote:
Please note that this (rpath) prevents automatic multiarch conversion
for packages. Instead of a simple post procesing of the deb files a
much more complicated change has to be made
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote:
Policy says Build-Depends-Indep must be installed for the build
target, which sbuild calls. But sbuild does not install
Build-Depends-Indep. Same goes for dpkg-checkbuildep -B
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Whenever this has been asked in the past, sbuild has simply declared
this is how I want to do it. I have no idea why.
If there is no technical reason for sbuild to behave this way, and if
it does
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only
Manoj Srivastava [EMAIL PROTECTED] writes:
On 18 Jun 2006, Goswin von Brederlow outgrape:
Peter Eisentraut [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
Manoj Srivastava [EMAIL PROTECTED] writes:
On 16 Jun 2006, Goswin Brederlow stated:
the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at this time if you want a package to
build, you need to list mostly everything in build-depends
Manoj Srivastava [EMAIL PROTECTED] writes:
Previously, any new feature in dpkg which goes into release
foo gets into policy in release foo + 1. Is there a compelling
reason to diverge from this practice?
manoj
Isn't that for binary packages because otherwise you can't
Guillem Jover [EMAIL PROTECTED] writes:
On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
Package: debian-policy
Severity: normal
[Side note: Buildds/dpkg-buildpackage has no robust way of telling if
the optional build-arch field exists and must call build. This is
wastefull
Peter Eisentraut [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
needlessly during build. Installing and purging latex as well as all
the initex runs and font
Peter Eisentraut [EMAIL PROTECTED] writes:
One question to ask is perhaps whether splitting the build dependencies
into several sets is useful at all, considering that the current state
of having effectively only one useful set has persistent for such a
long time.
Not a lot of people
David Weinehall [EMAIL PROTECTED] writes:
On Fri, Jun 09, 2006 at 10:04:48PM +0200, Bill Allombert wrote:
On Thu, Jun 08, 2006 at 01:50:37PM -0700, Chris Waters wrote:
[snip]
Anyone who makes a change and doesn't put it in the changelog should
be chastised. But I agree, it does happen, and
Andreas Barth [EMAIL PROTECTED] writes:
* Adeodato Simó ([EMAIL PROTECTED]) [060610 03:11]:
* Margarita Manterola [Thu, 08 Jun 2006 23:35:54 -0300]:
So, in any case, I'd encourage you to patch dpkg to handle a new
Homepage field, and submit the patch. Once this is being used by a
big
Bill Allombert [EMAIL PROTECTED] writes:
On Thu, Jun 08, 2006 at 01:50:37PM -0700, Chris Waters wrote:
On Thu, Jun 08, 2006 at 02:48:34PM +0200, Bill Allombert wrote:
On Thu, Jun 08, 2006 at 04:28:36AM -0700, Chris Waters wrote:
Date: [...] Talk to the dpkg maintainers--
they're free to
Lars Wirzenius [EMAIL PROTECTED] writes:
pe, 2006-06-09 kello 22:04 +0200, Bill Allombert kirjoitti:
Sometimes, the changelog will tell you the package was last changed 3
month ago while actually it was changed yesterday and build and uploaded
today. This can lead you to go on a wild-goose
Bill Allombert [EMAIL PROTECTED] writes:
Hello Wouter,
First thank for bringing back this issue, however...
On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe to say that Bill's proposal
Russ Allbery [EMAIL PROTECTED] writes:
Hello folks,
I have proposed a modification for Policy that will permit wrapping in the
following fields in debian/control:
Wouldn't it be better to require all tools to accept multi-line fields
for any field? And recommend using it for long lines (say
Loïc Minier [EMAIL PROTECTED] writes:
On Wed, Nov 23, 2005, Goswin von Brederlow wrote:
What is your point?
In my example the binNMU done _BEFORE_ the security release sorts
_AFTER_ the security release. So updates will not get the fix.
I think we saw different use cases, I interpreted
Loïc Minier [EMAIL PROTECTED] writes:
On Mon, Nov 21, 2005, Goswin von Brederlow wrote:
Since common practice for NMU, binNMU and security versions are
flawed, as in they don't sort right with dpkg --compare-versions, I
would rather see a new scheme be made policy.
Currently versions sort
Steve Langasek [EMAIL PROTECTED] writes:
On Mon, Nov 21, 2005 at 03:23:17PM +0100, Goswin von Brederlow wrote:
Nathanael Nerode [EMAIL PROTECTED] writes:
I was surprised to discover that the standard rules for Debian
revision numbers
(maintainer revisions contain no dots;
source NMUs
Nathanael Nerode [EMAIL PROTECTED] writes:
I was surprised to discover that the standard rules for Debian
revision numbers
(maintainer revisions contain no dots;
source NMUs contain one dots;
binary NMUs contain two)
are not in Policy, but only in the Developer's Reference.
This seems
Santiago Vila [EMAIL PROTECTED] writes:
On Sun, 30 Jan 2005, Goswin von Brederlow wrote:
Where do you want to put gettext.sh? Once in every gettext-base or
only once in gettext-base-common?
I don't know, maybe in the same package as GNU.Gettext.dll :-)
(which is to say: first things first
Andreas Barth [EMAIL PROTECTED] writes:
Hi,
I made a proposal of an updated deb format definition. I based that on
the manpage deb (part of dpkg-dev), and on reverse engineering of
dpkg-deb/build.c. I hope I've written the standard in a right and easy
to understandable way. I did (by
76 matches
Mail list logo
