Hi,
Sam Hartman wrote:
> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision i
Hi,
Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila wrote:
>> What I said is that no sane package in Debian/main should need to put
>> files directly in /etc/opt. That's an oddity, a very unorthodox thing,
>> it would be like a Debian package in main putting stuff directly in
Hi,
Sean Whitton wrote:
> On Wed 25 Jul 2018 at 05:14PM +0100, Iain Lane wrote:
>> Some tools, like git-buildpackage, can support merging an upstream's
>> version history into Debian packaging repositories. This enables more
>> rich usage of (D)VCS when packaging - for example `git blame' works
>
Hi,
Julian Andres Klode wrote:
> Today's research has shown that rolling hashes do not perform well
> on executables because of changing offsets and so on destroying the
> hashes. There were no measurable space savings when adding fairly
> similar firefox releases to either a casync or borg repos
(dpkg -> bcc)
Niels Thykier wrote:
> Any updates on this bug? The gitweb trigger cycle is currently the last
> trigger cycle left[1].
It should be interest-noawait. I was preparing an upload to do that,
but other things preempted that :/. I will try to make the upload
tonight and don't mind if
Guillem Jover wrote:
> In this case though, it seems switching to interest-noawait is the
> correct fix, because gitweb just wants to be notified when the
> apache2-maintscript-helper program appears to be able to configure
> itself, but apache does not care and does not need to await the
> trigge
Hi Niels,
Niels Thykier wrote:
> Debian `dpkg' package management program version 1.17.23 (amd64).
[...]
> chain of packages whose triggers are or may be responsible:
> gitweb -> gitweb
> packages' pending triggers which are or may be unresolvable:
> gitweb: /usr/share/apache2/apache2-maint
reassign 774607 dpkg 1.7.22
affects 774607 + gitweb src:git
forcemerge 771730 774607
quit
Jonathan Nieder wrote:
> Erwan David wrote[1]:
>> dpkg: cycle found while processing triggers:
>> chain of packages whose triggers are or may be responsible:
>> gitweb -> gitw
Hi dpkg maintainers,
Erwan David wrote[1]:
> Package: gitweb
> Version: 1:2.1.4-2
> Severity: normal
>
> When upgrading apache and gitweb I get :
>
> dpkg: cycle found while processing triggers:
> chain of packages whose triggers are or may be responsible:
> gitweb -> gitweb
> packages' pendi
Aurelien Jarno wrote:
> As a subsidiary question, do you know how to prevent libc6-amd64:i386 to
> be installed on a native amd64 system, but allow it on an i386 system,
> even with libc6:amd64 already installed?
Use Conflicts against dpkg:amd64, maybe. :(
--
To UNSUBSCRIBE, email to debian-dp
Wookey wrote:
> +++ Guillem Jover [2013-08-16 14:15 +0200]:
>> I've been pondering about the (old) updated proposal, and while I can
>> see Ian's argument and can agree with the problems he presents, I
>> can't really see using a syntax like «pkg [foo] [bar]» as something
>> desirable given the cu
Charles Plessy wrote:
> Le Thu, Jul 25, 2013 at 08:00:55AM +0900, Charles Plessy a écrit :
>> does the current patch (attached) address your concerns ? If yes, would
>> you second it ?
>
> Hi all,
>
> I would like to make one more call for feedback.
Sorry for the long silence.
My feeling is tha
Michael Biebl wrote:
> Couldn't debhelper/dh_installdeb generate that Pre-Depends via
> ${misc:Pre-Depends} if debian/*.triggers contains noawait?
> That sounds better to me then hard-coding the dependency.
I think that sounds reasonable, but presumably the folks on
debian-devel should be informe
Ian Jackson wrote:
> Jonathan Nieder writes ("Re: Temporary solution for changelog problem in
> binNMUs"):
>> One problem that that doesn't solve is what to do when a package would
>> be able to borrow its /doc/ directory from another package
>> (usi
Hi,
Ian Jackson wrote:
> The real problem is that these changelog files are primarily intended
> for human beings. They should live in /usr/share/doc, and their
> location should be transparent.
I was convinced of this until I remembered that package descriptions
are very similar in this respec
Guillem Jover wrote:
> I've just started a new dpkg FAQ on the wiki [0], to collect usual
> user question regarding errors, behavior or common feature requests.
Thanks. As a side-effect, it can also serve a good starting point for
wannabe contributors, to figure out tweaks to dpkg's behavior, ou
(dpkg@ -> bcc; cc: apt@)
Hi Alejandro,
Alejandro Alcántar wrote:
> wen i try to install "playonlinux" they add
> "python-wxgtk2.8"
>
> "
> W: Fallo al obtener
> http://ftp.mx.debian.org/debian/pool/main/w/wxwidgets2.8/python-wxgtk2.8_2.8.12.1-12_i386.deb
> La suma hash difiere
> "
>
> translate
Hi Parin,
Parin Porecha wrote:
> I am new to this group and I would like to contribute to this community.
> So, in order to solve bugs, I need some help to get started.
Thanks for your interest.
If you'd like an exercise to start, I'd suggest writing a patch to
split one of the larger functions
Niels Thykier wrote:
> Not all of them should be absolute. The Debian Policy states that
> symlinks within a "top-level" directory should be relative, where as
> symlinks between two different "top-level" directories should be
> absolute. See Policy §10.5[1] and its footnote[2].
For future refe
Johannes Schauer wrote:
> As I learned, the above means, that there must be only one package
> providing linux-kernel-headers.
>
> The problem is, that with linux-libc-dev conflicting with
> linux-kernel-headers of all arches, linux-libc-dev is not co-installable
> with itself anymore even though
Russ Allbery wrote:
> Let's go with 1:1.2.3.3.dfsg in the example to show the common case
> instead of the unusual case. I've applied this:
Thanks. Looks good.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.
Russ Allbery wrote:
> Okay, once more for the win.
Hoorah! :) I don't see any problems in the normative content, so I'd
second this if I could. Cosmetic nits (patch below):
[...]
> +++ b/policy.sgml
[...]
> @@ -5633,17 +5634,29 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
[...]
>
Hi,
berta...@ptitcanardnoir.org wrote:
> I can understand the reasons not to fix the trigger bug, sounds like
> something not that tricky.
>
> However, given how it actually break the upgrade process, and will like
> likely in the future, it would probably be a good idea to document
> somewhere f
Guillem Jover wrote:
> On Mon, 2012-07-23 at 17:06:18 +0200, Guillem Jover wrote:
>> On Sun, 2012-07-22 at 00:23:43 -0500, Jonathan Nieder wrote:
>>> Those are just the libraries I currently have installed on the machine
>>> I am using to type this.
>>>
>
Hi,
Neil McGovern wrote:
> dpkg-1.16.8/dpkg-deb/main.c
> -" -h|--helpShow this help message.\n"
> -" --versionShow the version.\n"
> +" -?, --help Show this help message.\n"
> +" --versionSho
Guillem Jover wrote:
> On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote:
>> What dpkg commands should apt run to upgrade from this state?
>
> In this particular case, apt would need to check that there's no multiple
> instances present if the new package is swi
Hi,
Cyril Brulebois wrote:
> dpkg's current diff between testing and unstable, once *.po and *.gmo
> stripped is:
> 323 files changed, 7307 insertions(+), 4626 deletions(-)
>
> There's #681332 about that, which was left unanswered.
Dpkg development has been happening pretty quickly lately, so t
Hi,
In 2004, Frank Küster wrote:
> And while we're at it, and a copy goes to debian-policy@l.d.o,
>
> ,
> | You should not use `dpkg-divert' on a file belonging to another
> | package without consulting the maintainer of that package first.
> `
>
> Not only that a warning about
Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> in this example:
>> Package: foobar
>> Architecture: amd64
>> Depends: package-bar
>> that last line is in fact read as:
>> Depends: package-bar:amd64
>
> Why? I don
David Kalnischkies wrote:
> in this example:
> Package: foobar
> Architecture: amd64
> Depends: package-bar
> that last line is in fact read as:
> Depends: package-bar:amd64
Why? I don't think that would help humans any more than reading it as
Depends: package-b
David Kalnischkies wrote:
> On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder wrote:
>> I agree here. If I understand correctly, you are saying that it would
>> be best if a dependency
>>
>> Package: a
>> Depends: phonon-backend
>>
>&g
Martin-Éric Racine wrote:
> Still, as the original reporter complained, blindly trying to figure
> out why a package repeatedly fails to build with "No space left" -
> even though it compiled succesfully - on a hard-disk with several GB
> of space, when it turns out that it's simply because dpkg u
clone 617299 -1
retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR
submitter -1 !
reassign -1 debian-kernel-handbook 1.0.13
quit
Martin-Éric Racine wrote:
> The solution to bug #617299 is therefore to either define TMPDIR to
> some actual hard-disk with sufficient stora
Hi,
David Kalnischkies wrote:
> On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder wrote:
>> Conflicts with an architecture seem kind of like conflicts with a
>> version. That would mean that that virtual packages wouldn't qualify.
>> Could that work well in prac
Martin-Éric Racine wrote:
> I have already stated that the .config is copied as-is from the stock
> Debian 3.2 kernel's config.
Oh, interesting.
May we have a debdiff of the binary packages, too?
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe".
Martin-Éric Racine wrote:
> 2012/7/13 Jonathan Nieder :
>> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?
>
> Yup.
Ok. Please attach your .config so we can reproduce this.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject
Martin-Éric Racine wrote:
> (putting back the CC to the bug, which will probably need to be
> reassigned to 'linux')
> 2012/7/13 Jonathan Nieder :
>> (dropping dpkg maintainers from cc)
>> Martin-Éric Racine wrote:
>>> I'm already aware of the effects
Hi,
Martin-Éric Racine wrote:
> Actually, this feels like an upstream kernel 3.2 bug: as a test, I
> purposely disabled TMPFS for /tmp just to see if the kernel package
> would finally build as expected. It did, except that the resulting DEB
> is a whopping 488MB in size, compared to 22MB for the
Hi Raphael,
Raphael Hertzog wrote:
> I know that in the long term you're in favor of moving the changelog in
> the package metadata and I agree with this plan. But IMO we must find
> an interim solution in the mean time.
>
> Here's a suggestion. Please share your thoughts:
>
> 1/ we modify dh_ins
David Kalnischkies wrote:
> while playing around with the APT code regarding architecture-specific
> dependencies I stumbled over the handling of Provides in that context:
>
> Package: pkga
> Status: install ok installed
> Architecture: i386
> Provides: foo
>
> Package pkgb
> Architecture: amd64
>
Jonathan Nieder wrote:
> I'll reply with an interdiff relative to the last version of the
> patch.
Here it is.
Subject: Clarifications to symbols and shlibs policy
subject/verb agreement: s/provide/provides/
Packages with libraries or binaries linking to a shared library must
use
Hi,
Helge Kreutzmann wrote:
> short:
> goobox fails during man page generation (see below) with very similar
> issues like #675613 fixed in dpkg 1.16.4 on some architectures, on
> some not. I'm unable to reproduce, but every time it fails,
> dpkg is < 1.16.4, every time it suceedes, dpkg >= 1.1
Sato Mayamoto wrote:
> Is it too complicated to have a kind of automatization for divert as
> a feature in deb-packages?
It sounds like a good feature if someone has time to work on it. In
fact, I think someone did a Google summer of code project on it last
summer, though they were not very acti
Hi Niels,
Niels Thykier wrote:
> I was considering to document the functions of ar.c when I noticed a
> possible issue in dpkg. It seems to me that dpkg_ar_member_get_size may
> (silently) truncate a "large file" when off_t is 32 bits. But I admit
> being uncertain here as I had difficulties fi
Sato Mayamoto wrote:
> I host several private repositories that offer packages that contain
> files and configurations for ubuntu clients. these files often
> replace files of different packages, without breaking the package.
>
> My problem is indeed that, once I am forced to remove the packages
>
Andreas Barth wrote:
> Do we have other tools than dpkg that parse the changelog to find out
> the package version?
Yes, debian/rules parses the changelog in a low-tech way in some
source packages. Someone with access to the lintian lab might be able
to say how many packages would be hurt by not
Raphael Hertzog wrote:
> As such, I suggest that we handle "binary rebuild" differently:
> - debian/changelog is left unmodified since it's the source changelog
> => it defines the ${source:Version} substvar
> - debian/changelog.binary-rebuild (or any other better name) is created
> when we wa
Russ Allbery wrote:
> Why?
No strong reason. The tech-ctte is free to decide any matter of
technical policy they choose to, so there's no constitutional reason
to go the way I was suggesting.
Since it sounds like you've thought about this carefully already,
I'm satisfied. Sorry for the noise.
Hi Russ,
Russ Allbery wrote:
> I believe at this point the dpkg-buildflags solution has proven reasonably
> successful and is being widely deployed. I think we should confirm that
> the TC agrees with that approach and close out this bug.
While I understand that the PR effect would be good, I e
Goswin von Brederlow wrote:
> Guillem Jover writes:
>> On Fri, 2012-04-20 at 14:58:33 -0700, Chris Hiestand wrote:
>>> Actually now that I'm trying to install from scratch instead of upgrade
>>> the message seems to be different (libgtk2.0-0:any instead of libgtk2.0-0):
Unpacking adobereade
Guillem Jover wrote:
> The API is preserved as long as no multiarch is enabled. With
> multiarch enabled any sane behaviour implies an interface change.
> Outputting multiple paragraphs per package set would imply you need
> to know which paragraph belongs to which package instance, it would
> als
(dropping cc to bug#660712)
Russ Allbery wrote:
> (I didn't reply because I
> didn't know enough about the internal data model of dpkg to be able to
> discuss it meaningfully.)
Do you mean on disk or in memory?
If you mean on disk, everything is in /va
Raphael Hertzog wrote:
> It's not going to happen. This interface choice has been discussed at
> length. I don't want to rehash the discussion.
Forgive my ignorance: could you explain the rationale for the choice
that was made for the meaning of "dpkg-query -L " when
is multiarch:same? If the e
Julien Cristau wrote:
> On Mon, Mar 19, 2012 at 17:26:04 -0500, Jonathan Nieder wrote:
>> What about libraries like glib (assuming one only uses old symbols)
>> that are never supposed to change soname?
>
> What about them?
I wanted to make sure that forbidding hard-coded de
lkcl luke wrote:
> performance is never a major issue here :) but
> i believe, last time i looked, all the dependencies had been sorted
> out (with one exception) by the mingw, msys and git-win32 teams. i
> had to track down an implementation of flock but that was about it.
Russ Allbery wrote:
> I'm therefore including here the complete
> SGML source of that section not in diff format, followed by the diff of
> everything *outside* of that section. I think this will be easier to
> review.
Thanks! I would have preferred a diff since it
Hi Thomas,
Thomas Adam wrote:
> When coming out of eval blocks and reporting on errors, make sure $@ is
> included as part of the textual output so that the real underlying error is
> reported.
> ---
> I was recently bitten by this:
>
> dpkg-source: error: source package format `3.0 (native)' i
Guillem Jover wrote:
>> On 2012-03-16 15:07 +0100, Guillem Jover wrote:
>>> + if (opt_verbose > 0)
>>> + printf(_("Ignoring removal of shared diversion
>>> '%s'.\n"),
>>> + diversion_describe(contest));
[...]
> Would the following clarify?
>
>
Goswin von Brederlow wrote:
> If it causes headaches then the packages are bugy because they did not
> set the right dependencies.
To avoid too much noise: John has been performing upgrades that skip
many major Debian releases and expecting them to work for some reason.
The tsort hack is not enou
John Hendrickson wrote:
> unsure how to file this. checking rdeps on a list (while unpacking
> or ...) is checking sorting so...
No. Please don't write to unrelated bugs.
Thanks for your interest,
Jonathan
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "u
Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> Why would it be intuitive to add a specific value for the arch attribute with
>> apt-get install foo # arch |= native
>> but remove all values of the attribute with
>> apt-get remove foo# arch &= ~all-a
David Kalnischkies wrote:
> Why would it be intuitive to add a specific value for the arch attribute with
> apt-get install foo # arch |= native
> but remove all values of the attribute with
> apt-get remove foo# arch &= ~all-architectures
> ?
>
> Isn't it more intuitive to have it this way:
David Kalnischkies wrote:
> You generously left out the paragraph describing how APT should
> detect that the package foo is in fact a library and not, say, a
> plugin, a dev-package, a dbg-package or a future-coinstallable binary.
> And the foo:* default would be okay and intuitive for all of tho
Ian Jackson wrote:
> Another relevant question is whether there are other files that are
> shared, and which don't want to move, besides ones in /usr/share/doc.
One example is header files in /usr/include, from -dev packages. In
the simple examples I've seen, putting them in /usr/include/,
works
Guillem Jover wrote:
> I have a problem with merging unreviewed code, though, that among other
> things might and do have design issues, as witnessed in the past. I also
> have not seen Cyril jump to do any kind of code review during all this
> time as quickly as he jumped to pester and with threa
Hi,
Cyril Brulebois wrote:
> Based on Raphaël's comments and the lack of further reply on your side,
> I've used Raphaël's fixup commit, keeping the originally-proposed
> version.
>
> Based on the lack of objections and the lack of alternative plans, I'll
> proceed with the NMU this evening, usin
Eugene V. Lyubimkin wrote:
> On 2011-12-16 17:25, Jonathan Nieder wrote:
>> No, a version ':1.2.3' would still not be allowed, since there is a
>> colon but the text before it ("") is not a number, violating
>>
>> This is a single (generally
Eugene V. Lyubimkin wrote:
> I agree it could be intepreted so, but I see no benefits in allowing
> trailing '-'. After all, it's just confusing.
>
> By the way, using this interpretation for epoch too, a version ':1.2.3'
> would be also correct?
No, a version ':1.2.3' would still not be allowed,
forcemerge 631816 633943
quit
Jonathan Nieder wrote:
> Raphael Hertzog wrote:
>> It's accepted by dpkg at least. Why would it be invalid?
>
> It all depends on how one interprets the phrase "may not" in the
> following sentence describing debian_version
>
Raphael Hertzog wrote:
> On Fri, 16 Dec 2011, Jonathan Nieder wrote:
>> "6.0.0-" is not a valid version number.
>
> It's accepted by dpkg at least. Why would it be invalid?
It all depends on how one interprets the phrase "may not" in the
following senten
#clone 631816 -1
#reassign -1 libqwt-dev 6.0.0-1
## policy §7.1 "Syntax of relationship fields"
#severity -1 important
severity 633943 important
found 633943 qwt/6.0.0-1
#merge -1 633943
quit
David Kalnischkies wrote:
> APT detects installed vs. the online version as different versions
> because
Hi,
On Mon, Nov 28, 2011 at 08:22:13PM +0100, Raphael Hertzog wrote:
> On Mon, 28 Nov 2011, dE . wrote:
>> By default, when overwriting config files, dpkg will ask about it
>> and the default action will be no. On Desktop systems with
>> inexperienced users, the default action may not be a good i
Raphael Hertzog wrote:
> I verified and all thoses issues are fixed in my pu/multiarch/full
> branch.
Yes, checked.
BTW, thanks for the new bisectable version of that tree. If I ran the
world, there would be a pu/multiarch/testing branch that is bisectable
and never gets rewinded (aka pu/multia
Jonathan Nieder wrote:
> Did you remember to push to wagner?
Found it (on the pu/multiarch/for-guillem branch). Sorry for the
noise.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Raphael Hertzog wrote:
> Then I tried to run the test
> suite and it doesn't work. I identified several issues:
Ah. I should have read my email before sending a redundant report.
[...]
> I pushed a new commit that modifies pkg_db_find_set() to initialize
> pkgset->pkg.installed.arch & pkgset->p
Hi Guillem and Raphaël,
Being the adventurous sort, I tried building and installing dpkg from
guillem/pu/multiarch/master. "dpkg" seems to work ok, but dpkg-query
is broken (it always segfaults).
Ok, back to dpkg/sid (thanks for the maintainer scripts that make
switching between very easy). Luc
Phillip Susi wrote:
> What does keeping it out of dpkg gain?
Maintainability. Running "eatmydata dpkg -i .deb" disables
fsyncs in maintainer scripts, too, which might match the desired
behavior better. (On the other hand, if you only want to suppress
fsync()s in admindir, perhaps because you ke
Guillem Jover wrote:
>* Fix typo to correctly set DEB_*_ARCH_BITS instead of DEB_*_ARCH in
> architecture.mk.
There's still a typo, alas. :/ Presumably architecture.mk should get
the treatment described at [1] to avoid problems like this in the
future.
[1] http://lists.debian.org/debi
Guillem Jover wrote:
> On Wed, 2011-04-20 at 20:11:33 -0500, Jonathan Nieder wrote:
>> +m4_pattern_forbid([^PKG_[A-Z_]+$], [missing some pkg-config macros])
>
> The problem with this is that it's managing someone else's namespace,
> which I don't think it&#
Guillem Jover wrote:
> On Wed, 2011-10-05 at 08:26:06 -0500, Jonathan Nieder wrote:
>> The message this is a reply to was forwarded to the debian-dpkg@ list.
>> It should not have been --- dpkg bugs only go to the debian-dpkg-bugs@
>> list.
>
> This is actually a l
Hi,
The message this is a reply to was forwarded to the debian-dpkg@ list.
It should not have been --- dpkg bugs only go to the debian-dpkg-bugs@
list.
Thanks for keeping the bts running well,
Jonathan
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscr
Hi,
vot...@gmx.de wrote:
> Another szenario might be that i have installed service xyz but i have
> disabled
> it because i did not want to use it right now. If it is updated via a package
> update the default postinst behaviour is to register the init script in the
> runlevels and starts the da
the message “master file was not
found” instead of doing something useful until version 0.41 (r2317,
2010-11-03).
Signed-off-by: Jonathan Nieder
---
Hi,
Squeeze i386 system. Building dpkg master (but I assume the last
uploaded sid version would behave similarly):
| $ dpkg-query -W po4a
| po4a 0.4
Nikolaus Rath wrote:
> On 09/30/2011 02:43 PM, Robert Millan wrote:
>> 2011/9/28 Nikolaus Rath :
>>> Does this mean that the package has to become Arch: any now? That seems
>>> wrong to me...
>>
>> Not necessarily, you can instead use:
>>
>> Depends: fuse | fuse4bsd
>
> S3QL depends on fuse when r
Hi Raphaël,
Didier Raboud wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
[...]
>> dpkg-source: error: aborting due to unexpected upstream changes, see
>> /tmp/bsdgames_2.17-19.diff.RWwHlX
>> dpkg-source: info: you can integrate the local changes with d
Raphael Hertzog wrote:
> It looks great, I made a few typo fixes, added a sentence wrt
> Jonathan's concern and sent it.
Thanks! (Just for the record, it was not really the maintainers that
are unsure that I was worried about. ;-) And such a Pre-Depends is
basically always safe, as long as the
Guillem Jover wrote:
> Ok! Release tagged, pushed and uploaded.
>
> I reworded some things, and added the new stuff since 1.15.7 that I
> mentioned on my other mail. Hope to not have missed anything else
> important/user visible. Please take a look, and feel free to send.
Re the new triggers:
|
Jonathan Nieder wrote:
> Talles wrote:
>> # Failed test '--list should fail'
>> # at ../../src/t/100_dpkg_divert.t line 56.
>
> That's odd. Looking at t/100_dpkg_divert.t, that means that @$args
> was ("--list") but $opts{'expect_failur
Talles wrote:
> # Failed test '--list should fail'
> # at ../../src/t/100_dpkg_divert.t line 56.
That's odd. Looking at t/100_dpkg_divert.t, that means that @$args
was ("--list") but $opts{'expect_failure'} was true, and none of the
tests are actually set up that way.
I suspect your perl in
Hi,
Talles wrote:
> When trying to compile dpkg some tests cases fail.
Which test cases? :)
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829173444.gg2...@eli
reassign 639229 dpkg
quit
Rene Engelhard wrote:
> On Thu, Aug 25, 2011 at 08:50:03AM +0200, Matthias Cramer wrote:
>> When upgrading to the newest package, dpkg fails to unpack the .deb file:
>>
>> Preparing to replace libreoffice-base 1:3.3.4-1 (using .../libreoffice-
>> base_1%3a3.3.4-2_amd64.
Raphael Hertzog wrote:
> I also wonder whether we should keep -Werror=format-security given that no
> archive rebuild has been made with this option so we don't really know how
> many packages will be affected by this.
I'd say, enable it, keeping in mind that the failure mode is just a
failed bui
John D. Hendrickson and Sara Darnell wrote:
> I looked at the dpkg ant aptitude sources. It seems there's allot
> of maybe's involved "grading"
I'm afraid I have no idea what you're talking about, sorry.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsub
Hi,
John D. Hendrickson and Sara Darnell wrote:
> I've always had problems especially during upgrade (last was sarge
> to sqeeze) and wished to help.
Thanks for the offer of help. There are always problems with upgrades
"skipping a few releases" like this, since package maintainers do not
tend
Raphael Hertzog wrote:
> -maintainer_script_alternative(pkg, PRERMFILE, "pre-removal", cidir,
> cidirrest,
> - "upgrade", "failed-upgrade");
> +if (versioncompare(&pkg->available.version,
> + &pkg->installed.version) > 0) /* Upgrade *
Hi Raphael,
Raphael Hertzog wrote:
> 1/ I'd argue that in the case of downgrade, dpkg should not try to run
>the failed-upgrade fallback because there's no way the oldest version
>can be aware of how to work-around a problem in a prerm script of a
>newer version that did not exist at
Hi,
(moving to list since I'm veering off-topic)
Raphael Hertzog wrote:
> Since private symbols are not to be used outside of the source package,
> we can just invent a special value to use in the associated minimal
> version field.
> symbol@Base *private*
Thanks. That reminds me, I almost wan
Luk Claes wrote:
> Because people want to have both atomic changes of their /bin/sh as well
> as being able to choose between more than 2 options for their /bin/sh ...
See http://repo.or.cz/w/dash/debian/jrn.git/commitdiff/cea77edd1 for
an example where the ability to atomically "steal" a diversi
Phillip Susi wrote:
> Sorry for the delayed response, but what?
Sorry for the nonsense. What I was fumbling to say was that it had
been many months since this last came up with nothing changed but
still you were asking "Is this a bug in apt?". It seemed more like a
time to act, for example by f
Hi Otto,
Otto Kekäläinen wrote:
> *Does the config file within a deb package execute before the
> dependencies of a package is configured?*
See dpkg-preconfigure(8), debconf-devel(7), and [1]. In general, the
answer is that no, you can't rely on the order that .config scripts
are run.
> Can I
1 - 100 of 345 matches
Mail list logo
