Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug

(Redirected off the bug report as the BTS makes a poor mailing list archive for the kinds of extensive threads that TC discussions produce.) Eugene V. Lyubimkin writes ("Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug"): > Please reaffirm that Debian bug #575786 again

Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug

Goswin von Brederlow writes ("Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug"): > Just to make sure that means now the following is to be used, right? Thanks for the helpful presentation of the questions. Typically the situation involves an old package and a new

Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug [and 1 more messages]

> >> Action | A Flags | B Flags > >> +---+- > >> Move file from A to B | Depends: B (>=) | Replaces: A (<<) > >> | or Breaks: B (<<) | > >> | as

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

Raphael Hertzog writes ("Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?"): > Of course, the pre-depends become mostly irrelevant when the version in > oldstable supports it but that's not the case yet. And it's not unusual for > people to try an upgrade that skips a release.

Re: Semantic change for dpkg triggers?

Raphael Hertzog writes ("Semantic change for dpkg triggers?"): > I am considering changing the default behaviour of dpkg triggers. [1] > Currently when a package activates a trigger (except if it uses > dpkg-trigger directly with the --no-await option, and that is a minority > of cases), the triger

authbind (LD_PRELOAD) and multiarch

I'm maintainer and upstream for authbind, which is a set-id helper to permit and control the binding of low ports by unprivileged programs, with an LD_PRELOAD wrapper so it can be used by naive callers which just expect to call bind. I would like some advice about how to do multiarch support for i

Re: authbind (LD_PRELOAD) and multiarch [and 1 more messages]

Raphael Hertzog writes ("Re: authbind (LD_PRELOAD) and multiarch"): > On Mon, 12 Dec 2011, Ian Jackson wrote: > > * I will need to arrange for the same LD_PRELOAD setting to load the > >correct libauthbind for each arch. So I guess I do > >LD_PRELO

Re: authbind (LD_PRELOAD) and multiarch

Goswin von Brederlow writes ("Re: authbind (LD_PRELOAD) and multiarch"): > Raphael Hertzog writes: > > What does fakeroot do? My first idea would be to fail early and provide a > > useful error message. > > fake(ch)root sets LD_PRELOAD=lib.so and > LD_LIBRARY_PATH="/usr/lib/fakeroot:/usr/lib32/fa

Re: Please test gzip -9n - related to dpkg with multiarch support

Russ Allbery writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"): > Another possible solution is to just give any package an implicit Replaces > (possibly constrained to /usr/share/doc) on any other package with the > same name and version and a different architecture. Th

Re: Please test gzip -9n - related to dpkg with multiarch support

Guillem Jover writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"): > On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote: > > One thing which no-one yet seems to have suggested is to have > > multiarch:same packages put the changel

Re: Please test gzip -9n - related to dpkg with multiarch support

Goswin von Brederlow writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"): > Ian Jackson writes: > > One thing which no-one yet seems to have suggested is to have > > multiarch:same packages put the changelog in a filename which is > > disti

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

Russ Allbery writes ("Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)"): > There's been a lot of discussion of this, but it seems to have been fairly > inconclusive. We need to decide what we're doing, if anything, for wheezy > f

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

Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)"): > On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > > * The binNMU process is changed to add the binNMU changelog entry to an > > arch-quali

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

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 becaus

Re: Multiarch file overlap summary and proposal

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

Re: Multiarch file overlap summary and proposal

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.

Re: Important information regarding upcoming dpkg 1.16.2 upload

Guillem Jover writes ("Re: Important information regarding upcoming dpkg 1.16.2 upload"): > On Mon, 2012-03-19 at 08:12:08 +0100, Raphael Hertzog wrote: > > It has always been possible to sort-of "duplicate" a system by doing > > "dpkg --get-selections >file" on one computer and running "dpkg > >

Re: libdpkg: m_fork and friends

lkcl luke writes ("Re: libdpkg: m_fork and friends"): > um... is there any chance of redesigning dpkg to not require fork? > popen looks like it could be used in movecontrolfiles; likewise in > extracthalf. dpkg was never intended to be portable to not-at-all-unix-like systems. I'm afraid you ar

Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'

Iain Lane writes ("Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'"): > Greetings, > > [ I already asked this on d-dpkg, but go no response, so am "re-posting" > this question to -devel. The original report along with full

Re: Temporary solution for changelog problem in binNMUs

Guillem Jover writes ("Re: Temporary solution for changelog problem in binNMUs"): > dpkg supports --control-show and --control-list (already in wheezy), which > can be used for stuff like: > $ dpkg-query --control-show dpkg changelog > for installed packages, for example. Or: > $ dpkg-deb --in

Re: Temporary solution for changelog problem in binNMUs

Jonathan Nieder writes ("Re: Temporary solution for changelog problem in binNMUs"): > I was convinced of this until I remembered that package descriptions > are very similar in this respect. My gut feeling to expect to find > changelogs in /usr/share/doc/ is actually mostly due to > habit, I susp

Idea: rsync-based source format

(if there are vcs commits at all) to a series of patch files. This causes some difficulties. We have a large number of tools in Debian to cope with these difficulties. -- Ian Jackson personal email: These opinions are my own.http://www.chiark.greenend.org.uk/~ijackson/

Re: License audit on dpkg source tree

s file started as GPL-2 only with commit a4f9322a6417e1683183ea > > by Wichert Akkerman, which only included cisdigit() and cisalpha(). > > > > Ian Jackson added a new cisspace() function in commit c91dc9f, and > > refactored the fgets_checked() and fgets_must() functions from &g

Multiarch interpreter problem

The proposal for Multi-Arch: same Architecture: all Implementation approach: Such a package is like a collection of identical .debs for all available architectures, all marked Multi-Arch: same Architecture: Normally, such a .deb is treated by dpkg as if it were for the n

Re: Idea: rsync-based source format

Guillem Jover writes ("Re: Idea: rsync-based source format"): > On Fri, 2015-08-21 at 16:32:09 +0100, Ian Jackson wrote: > > (I spoke to Guillem about this at Debconf and promised to write it up > > so he could think about it properly at his leisure.) > > [ Checke

Re: Idea: rsync-based source format

Joerg Jaspert writes ("Re: Idea: rsync-based source format"): > This will make NEW a tad more complex: For most of us, NEW review > consists of two shells, one of which runs the NEW tool, the other a tmux > with an mc in it. Which allows *fast* and easy browsing of near any kind > of archive (neste

Re: Replacing ldconfig maintscripts with declarative methods

Niels Thykier writes ("Replacing ldconfig maintscripts with declarative methods"): > A possible solution is to replace these scripts with an > "activate-no-await" trigger (again, no-await to avoid trigger cycles). > I would need libc-bin to promote its trigger to part of its API for this > to work

Re: Idea: rsync-based source format

Joerg Jaspert writes ("Re: Idea: rsync-based source format"): > On 14044 March 1977, Ian Jackson wrote: > > Are you saying you want to review just the Debian delta ? Or are you > > trying to avoid extracting the source package ? Or to put it another > > way, I do

Re: License audit on dpkg source tree

[resent; first copy failed due to mua bug] Guillem Jover writes ("Re: License audit on dpkg source tree"): > Thanks all! I'm going to push the attached patch. Hope the S-o-b are > fine. LGTM, thanks. (If at some point you feel like updating my email address in the various notices, to ijack...@ch

Re: License audit on dpkg source tree

Guillem Jover writes ("Re: License audit on dpkg source tree"): > On Wed, 2015-09-16 at 15:21:29 +0100, Ian Jackson wrote: > > (If at some point you feel like updating my email address in the > > various notices, to ijack...@chiark.greenend.org.uk, please do. But > >

dpkg-source and gitish patches

Guillem Jover writes ("Re: Bug#75: dpkg-dev: please make mtimes of packaged files deterministic"): > The --clamp-mtime options looks primising, but I'm not happy about its > current situation. Please get this upstreamed first. I don't mind making > dpkg depend on an extremely recent GNU tar, b

Re: dpkg-source and gitish patches

Guillem Jover writes ("Re: dpkg-source and gitish patches"): > Hi! > > [lots of stuff] Thanks for your explanations, which are very helpful. > Maybe that was the wrong choice, and I should probably have brought this > up on the list for wider comment. If people consider this is the case, > I'm o

Re: dpkg-deb silently fails?

Andrew Pollock writes ("dpkg-deb silently fails?"): > I haven't filed a bug for this yet because I'm only secondarily involved, > but if you look at the build log > https://buildd.debian.org/status/fetch.php?pkg=ceph&arch=mipsel&ver=0.80.11-1&stamp=1453099724 > it appears that ceph-test-dbg got sil

Re: [RFC/dpkg PATCH] Introducing an relaxed-Essential-like "Important" field

Julian Andres Klode writes ("Re: [RFC/dpkg PATCH] Introducing an relaxed-Essential-like "Important" field"): > Are there any better proposals? Do we want this field to be ignored by old versions of the tools, or to prevent installation of the package ? I think the answer is (a) in which case we

Re: Update alternatives priority mismatch in openSUSE

Tomas Chvatal writes ("Update alternatives priority mismatch in openSUSE"): > Hello everyone, > > In SUSE we noticed that some of our python packages were not updating > their alternatives when migrating from ie python2.6 to python2.7. > > This is due to unfortunate priority set by the maintainer

Re: Update alternatives priority mismatch in openSUSE

Tomas Chvatal writes ("Re: Update alternatives priority mismatch in openSUSE"): > Thanks for the review. I will try to use it only until we fix all the > python/ruby packages we have because atm it results in quite broken > systems without it. Of course what you do in your distro is up to you, but

dpkg-buildpackage -ucb

I often find myself running dpkg-buildpackage -uc -b. Should dpkg-buildpackage have a -ucb option which does the same ? This would: - Be a nod to UC Berkeley - Be slightly more mnemonic (given that there's -B and -us etc. etc. too) - Be vaguely amusing Ian.

Re: dpkg-buildpackage -ucb

Guillem Jover writes ("Re: dpkg-buildpackage -ucb"): > Hi! Hi. I see you've dropped -curiosa, which is fair enough. > For dpkg 1.18.5 I've reworked the built type selection by adding a > single --build option with comma-separated components "source", "any", > "all" and "full", to try to improve

Re: dpkg-buildpackage -ucb

Johannes Schauer writes ("Re: dpkg-buildpackage -ucb"): > Quoting Ian Jackson (2016-04-28 13:45:46) > > So "all" means only packages `Architecture: all' ? Or `all bits of > > the build' ? > > > > Is it too late to change this ? Maybe `aa

Re: Problem making large .deb files

Guillem Jover writes ("Re: Problem making large .deb files"): > Yes, and a known one: > > also mentioned in the format spec: > a A friend reports: 16:32 largest file in my debian mirror 16:3

Re: [PATCH v2] Support for PAX extended header and Linux extended attributes

Stefan Berger writes ("[PATCH v2] Support for PAX extended header and Linux extended attributes"): > The following patch adds support for the tar pax extended header to the tar > parser so that tar files with pax extended headers containing Linux extended > attributes can be processed by dpkg. Ess

Re: tarball signatures in source packages and jessie

Julien Cristau writes ("tarball signatures in source packages and jessie"): > Hi Guillem, > > dpkg-source in sid now picks up orig.tar.gz.asc files and lists them in > the source package. Unfortunately dpkg-source in jessie then explodes > on such source packages because it doesn't know what to d

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

Josh Triplett writes ("Handling Multi-Arch packages that must be installed for every enabled architecture?"): > That would solve the problem for the couple of cases it has come up in, > but it seems far from ideal; I'd welcome an cleaner alternative > solution. Notably, this doesn't work well for

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

Josh Triplett writes ("Re: Handling Multi-Arch packages that must be installed for every enabled architecture?"): > On Sat, Jun 25, 2016 at 07:08:39PM +0100, Ian Jackson wrote: > > * LD_PRELOAD hacks need their .so installing for all architecture "for > > w

Request for help - faithful source format (related to dgit)

h features end up being used. This has already caused some lossage, where a new not-backward-compatible source sub-format was accidentally introduced into our archive (!) One part of the task I need help with is negotiating and selecting an appropriate technical approach. Thanks fo

Re: debian-policy: please document build profiles

Johannes Schauer writes ("Re: debian-policy: please document build profiles"): > One way to solve this, would be to change the build profile spec to > say that the Built-For-Profiles field is only to be added if either > one of the following build profiles was active during the build: > > - pkg.$

Re: debian-policy: please document build profiles

> Quoting Javier Serrano Polo (2016-07-10 19:25:59) > > There is an introduction at https://bugs.debian.org/830524 . The goal is > > to build a subset of binary packages. For instance, the linux source > > package should have a way to build only linux-image-4.6.0-1-686 (profile > > pkg.linux.686),

Attention Javier Serrano Polo (was Re: Mail delivery failed: returning message to sender)

If someone who can email Javier could pass this on, I'd appreciate it. Mail Delivery System writes ("Mail delivery failed: returning message to sender"): > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its >

Re: debian-policy: please document build profiles

Cyril Brulebois writes ("Re: debian-policy: please document build profiles"): > FWIW, src:linux already lets you configure a specific flavour and build > only that one: > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.5 Oh, cool, I didn't know about that. > Yeah, that's out

Intent to commit craziness - source package unpacking

branch). Comments welcome. Please be quick - this is very close to the top of my dgit todo list. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Intent to commit craziness - source package unpacking

Guillem Jover writes ("Re: Intent to commit craziness - source package unpacking"): > On Mon, 2016-09-26 at 15:37:19 +0100, Ian Jackson wrote: > > tl;dr: > > > > * dpkg developers, please tell me whether I am making assumptions > >that are likely t

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Thanks for your comments. I feel unblocked :-). So, I now intend to go and implement my plan. There will be a little while (perhaps a few weeks) before I am in a postion to release this in dgit 2.

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Guido Günther writes ("Re: Intent to commit craziness - source package > unpacking"): > > Hi Ian, > > Hi, thanks for your attention. Please disregard this email. I hadn't finished editing it! Ian.

Re: Intent to commit craziness - source package unpacking

dgit created > history finally looks once you implemented it. I'll send you an example. > gbp-pq's conversion algorithm is not expected to change (at least in > the default configuration, I have some other ideas about patch > handling but that would not modify t

Re: Intent to commit craziness - source package unpacking

rrently the output of dpkg-source --commit doesn't look much like the output of git-format-patch. I have tried to make dgit produce patches (when it needs to produce patches) that look like dpkg-source --commit. But maybe it should produce patches using git-format-patch (or that look like git

Re: Intent to commit craziness - source package unpacking

Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Guido Günther writes ("Re: Intent to commit craziness - source package > unpacking"): > > 'gbp pq import' does have 'debian/patches' since it just puts the

Re: Intent to commit craziness - source package unpacking

Guido Günther writes ("Re: Intent to commit craziness - source package unpacking"): > On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote: > [..snip..] > > Recommends: pristine-tar (>= 0.5) ...> > > > pristine-tar has been declared unmaintainab

Re: Intent to commit craziness - source package unpacking

Russ Allbery writes ("Re: Intent to commit craziness - source package unpacking"): > Ian Jackson writes: > > I'm not sure of the logic behind that. I don't think dgit helps much > > with the kind of tasks that pristine-tar helps with. > > The main bene

Re: Intent to commit craziness - source package unpacking

the final argument had a default ? :-) Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory

such a change would be accepted. If I were you I would propose the name and semantics here before writing the code. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory

here before writing the code. > > Ding ding ding! Yes. If we want the production quality cross-support, this > would be the best option. > > Two choices: either a --configdir command line option to override > CONFIGDIR or an environment variable, say DPKG_CONFIGDIR. Since > --ad

Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory

will hopefully get the benefit of your code contribution. So, thanks. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Idea: sbuild/pbuilder "--dgit" option

uld do even if there was one, but I think it might be an alias for --dot-git-files=upstream. Anyway, thanks to everyone for your opinions, whatever they may be. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Idea: sbuild/pbuilder "--dgit" option

he above first > because I don't want to add an option just to deprecate it one release later. These are all good questions. Please do ask more probing questions. Before anyone actually implement this I would also like to hear from at the very least the pbuilder maintainers. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Idea: sbuild/pbuilder "--dgit" option

Mattia Rizzolo writes ("Re: Idea: sbuild/pbuilder "--dgit" option"): > On Thu, Dec 15, 2016 at 08:25:53PM +, Ian Jackson wrote: > > What would you think (particularly, sbuild and pbuilder folks) about a > > supporting a --dgit option ? The effect would be

Re: Idea: sbuild/pbuilder "--dgit" option

really understand git-dpm but I'm interested in ways to make dgit play better with it. I confess that I found our last conversation too frustrating but I'm happy to try again. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Idea: sbuild/pbuilder "--dgit" option

nvoke their build tooling via dgit, in which case dgit will pass approprate -i -I to the build tools.) Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Feedback on 3.0 source format problems

x27; has done due to its reliance on patch). If we manage to store our the revision control history elsewhere, in a proper revision control server, we do not need the archive to contain the revision control history. I think my proposal for `3.0 (rsync)' would meet these requirements and I'

Re: Idea: sbuild/pbuilder "--dgit" option

.gitignore problem (which is the main reason why using existing build runes sometimes don't work) only turns up if the package contains changes to .gitignore. If you mean "do other build tools like sbuild already have this --dgit option" then the answer is "no". Getting a co

Re: Feedback on 3.0 source format problems

Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format problems"): > On 2017-01-03 16:58:21 [+], Ian Jackson wrote: > > Looked at another way, it is trying to be a version control system, > > layered on top of the Debian archive. But it is only abo

Re: Feedback on 3.0 source format problems

Of course that's not of very much direct benefit to you. > Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try > to maintain all my packages in git in unapplied state, This is supported by dgit. Thanks, Ian. -- Ian JacksonThese opinions are my ow

Re: Feedback on 3.0 source format problems

of patches around build operations is complete madness if you ask me - but I don't see a better approach given the constraints. dgit sometimes ends up doing this (and moans about it), which is even madder given that dgit has git to help it out. Ian. -- Ian JacksonThese opinions are my

Re: Accepted dpkg 1.18.19 (source) into unstable

Hi, Guillem. I'm afraid I find myself writing a critical email. Guillem Jover writes ("Accepted dpkg 1.18.19 (source) into unstable"): > Date: Fri, 27 Jan 2017 05:43:36 +0100 > Source: dpkg > Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect AIUI this has missed the deadline for migration i

Re: Line ending issue when "Reading database"

Craig Francis writes ("Line ending issue when "Reading database""): > When running `apt-get upgrade` via a cron job, there is a "Reading database" > section. > > In the email this appears as: ... > It's not a major issue, as it just breaks DKIM signing of emails; > where the "\ r" is changed to a

Re: Line ending issue when "Reading database"

Sven Joachim writes ("Re: Line ending issue when "Reading database""): > One problem here is that there is currently no option for dpkg to > suppress the output entirely, see bug #539617[1]. The other one is that > apt always runs dpkg in a tty, unless an undocumented option is used[2]. I wasn't

Re: Line ending issue when "Reading database"

Guillem Jover writes ("Re: Line ending issue when "Reading database""): > On Tue, 2017-03-28 at 15:57:33 +0100, Ian Jackson wrote: > > Would someone care to file a bug against apt, requesting that the > > default be changed early in the buster cycle ? > &g

Re: comments/string changes and issues with dpkg's messages

Adam Heath writes ("Re: comments/string changes and issues with dpkg's messages"): > ohshite should really be for internal errors only. Things that "Should Not > Happen(tm)". This is totally 100% INcorrect. ohshite is used nearly everywhere for system call failures, eg `disk full'. Ian. --

Re: comments/string changes and issues with dpkg's messages

Eddy Petrisor writes ("comments/string changes and issues with dpkg's messages"): > 1) dpkg-1.13.8/dselect/helpmsgs.cc states that it is generated from > helpmsgs.src by mkhelpmsgs.pl. > Neither of these two files is present. Where are they? This is very strange. The last version of dpkg I hav

dpkg vanishing conffiles bug (#108587)

Scott, in case you don't know why I'm messing about with dpkg: during an upgrade from Ubuntu Hoary to Breezy you get a spurious conffile prompt about xinitrc, which is due (in part) to #108587. Will you have any time soon to read the mail I sent today to the BTS, describing what I plan to do ? (T

Re: comments/string changes and issues with dpkg's messages

Denis Barbier writes ("Re: comments/string changes and issues with dpkg's messages"): > On Fri, Aug 26, 2005 at 06:36:39PM +0100, Ian Jackson wrote: > > Adam Heath writes: > > > ohshite should really be for internal errors only. Things that > > > "S

Re: comments/string changes and issues with dpkg's messages

Martin Quinson writes ("Re: comments/string changes and issues with dpkg's messages"): > But maybe the problem is that they should first get translated from geek to > regular english? > > What about changing "cannot stat %s" to "cannot access %s"? I know it loses > a bit of information, but does

Re: comments/string changes and issues with dpkg's messages

Jacob Sparre Andersen writes ("Re: comments/string changes and issues with dpkg's messages"): > I find this a very bad example. In most cases "could not > stat file" is just an incomprehensible way of writing "file > not found". But if the error _is_ due to an error in the > program and not due

Re: Put a fixed md5sum into sarge-updates?

Scott James Remnant writes ("Re: Put a fixed md5sum into sarge-updates?"): > So shipping a changed md5sum in sarge would actually make it > incompatible with unstable. There is no significant compatibility problem with what the TC resolution calls the bare output format. The compatibility problem

Re: Put a fixed md5sum into sarge-updates?

Scott James Remnant writes ("Re: Put a fixed md5sum into sarge-updates?"): > So this is slightly complicated ... while there was a "fixed" md5sum in > dpkg for a while, it became "unfixed" again because dpkg no longer ships > an NIH version of md5sum and instead the coreutils md5sum gets the name.

Re: Suggested clean-up of debian/control

Frank Lichtenheld writes ("Re: Suggested clean-up of debian/control"): > As you're the maintainer it's your call. I don't think it is actually > useful for anyone to keep that old stuff around but feel free to > ignore the patch. I have several times upgraded systems directly from one Debian relea

Re: [EMAIL PROTECTED]: Mail delivery failed: returning message to sender]

Jeroen van Wolffelaar writes ("[EMAIL PROTECTED]: Mail delivery failed: returning message to sender]"): > [EMAIL PROTECTED] is unavailable for at least 4 days now. It seems that > ns2.dpkg.org is misconfigured (refuses to give out details), and ns0 and > ns1 are down. I'm the administrator of the

ChangeLog vs debian/changelog

Can someone explain to me why we have two changelogs in the dpkg tree containing almost exactly the same information ? I'm referring to dpkg-.../ChangeLog and dpkg-.../debian/changelog. This seems to me to be an error-prone and wasteful practice. There should be one canonical changelog, and ther

md5sum diversion: patches which restore sanity

n/md5sum-supplying corutils). This preserves any later +sysadmin-installed diversions of md5sum.textutils. + * Fix md5sum diversion problems with a hacksaw (Closes: #340119) +(change imported from Debian 5.94-1: some additional rm -f's to make + the diversion removal more aggressive^W

Re: md5sum diversion: patches which restore sanity

Frank Lichtenheld writes ("Re: md5sum diversion: patches which restore sanity"): > I will apply the patch to dpkg. Excellent, thanks. > Since the patch for coreutils only adds some checks so that it doesn't > try to fix something that isn't broken it is probably safe to do so > in a uncoordinated

Re: Using GNU's install-info in Debian instead of dpkg's install-info

Ian Zimmerman writes ("Re: Using GNU's install-info in Debian instead of dpkg's install-info"): > It's wrong on two counts: > 1/ The visual format of the dir file is used for collecting the sections. > This has all the robustness of, say, grepping for text in a Postscript file. > > 2/ Since no re

Re: Using GNU's install-info in Debian instead of dpkg's install-info

Ian Zimmerman writes ("Re: Using GNU's install-info in Debian instead of dpkg's install-info"): > One more thing: the longer this thread gets, the more I think that the > original bug is in fact the inclusion of i-i in dpkg. I'm afraid I have to disagree with you there. There is nothing wrong wi

Re: Please improve the wording of the translatable messages

Eddy Petrişor writes ("Please improve the wording of the translatable messages"): > Way too spartan messages to be understood (I looked at the code and > couldn't understand how they should have been translated as, until I > realised the format was "operation that was attempted: error string") W

dpkg.org wiki data

I have obtained a copy of the data from Scott's dpkg.org wiki. It's in Moin format. Does anyone have an existing working Moin setup that we could drop it into ? I haven't provided a URL for the data as that will probably just cause zillions of forks which is very bad for wiki data. Ian. -- T

Re: PATCH: Make install-info use fcntl (via perl's flock) for locking

tags 2531 - patch thanks Nathanael Nerode writes ("PATCH: Make install-info use fcntl (via perl's flock) for locking"): > This patch converts install-info to use perl's flock for locking. ... > As part of this change, it now operates directly on the dir file Unfortunately, this is wrong. If you

Re: PATCH: Make install-info use fcntl (via perl's flock) for locking

Ian Jackson writes ("Re: PATCH: Make install-info use fcntl (via perl's flock) for locking"): > So the process of locking and updating would be: > 1. Attempt to open .lock for writing O_EXCL >a. If this succeeds, write "perl-flock\n" >b. If this fa

Re: dpkg.org wiki data

Jeroen van Wolffelaar writes ("Re: dpkg.org wiki data"): > DSA ([EMAIL PROTECTED]), best is if the grunt work can be > done by someone else (that is, giving DSA some files to simply copy over > or whatever it takes). So, do we have a Moin expert who would like to look over the tarball and mail dsa

tab/space formatting in some {src,lib}/*.c

Particularly in the context of my forthcoming implementation of Breaks, I'd like to ask whether the dpkg maintainers would mind terribly if I ran `expand -t2' on these files: lib/showpkg.c lib/tarfn.c src/configure.c src/archives.c (function quote_filename only) These are part of dpkg

Breaks is going to be implemented

At the Ubuntu meeting in France[1] we agreed that we (well, I) will implement Breaks in dpkg in Ubuntu. I trust that this meets with the approval of everyone here. The full plan for the Ubuntu deployment is here https://wiki.ubuntu.com/PackageDependencyFieldBreaks including references to the sem

Re: Breaks is going to be implemented

Nicolas François writes ("Re: Breaks is going to be implemented"): > Not my patch, but there is a patch for #170825 (and #20471, #217862, > #270545) in the BTS. Ah, yes, that old chestnut. Thanks for the pointer. > The patch currently in the BTS is failing, and I don't know if it's > maintained,

Re: Breaks is going to be implemented

Andreas Barth writes ("Re: Breaks is going to be implemented"): > Actually, though breaks sounds like a good idea, I would really like if > dpkg changes are discussed here before (or did I just overlook the > discussion here?). This particular dpkg feature has been specified and on the wishlist fo

  1   2   3   4   5   6   >