, so might that
be a good suggestion that could be added there?
Best regards
David Kalnischkies
P.S.: I do consider my sbuild setup reasonably normal/standard, so
I spare you the details, but I am happy to add them if it turns out
I am more of a unique snowflake here than I am assuming.
signature.asc
Description: PGP signature
and given that this is something that
"just" works with Docker.
As explained in the other bug, there is no veto and as you can see its
easy to completely ignore me (and anyone else) but I wanted to say it
anyhow, so that nobody is surprised later on.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Package: dpkg-dev
Version: 1.22.0
Severity: minor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The use of Maintainer in the output of dpkg-parsechangelog is
confusing, because it suggests that dpkg-parsechangelog is reporting
the Maintainer field from debian/control. I suggest Changed-By for
>From an IRC discussion Helmut asked me to mention our use case for
dynamic file registration. In emacs addon packages we currently generate
byte-compiled .elc files and some symlinks at install time. It would be
very useful not to have to track and clean those up in an ad-hoc way.
ding architecture
specific dependencies and not a whole lot of things cared too much.
Or its just because they aren't used a whole lot for reasons.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ve some "random"
files not present on disk. So your system might not even boot or spawns
interdimensional portals. You better reinstall…' is not the type of
thing you wanna here from support.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, 29 Jan 2023 at 16:01, Guillem Jover wrote:
> I'd like to move away from the master/slave terminology used in
> update-alternatives for both the external interfaces (CLI options,
> output fields) obviously preserving backwards compatibility, docs
> and for all the internal code symbols.
change – resolving this bug might be as "simple" as adding a note that
holds will be (potentially) lost if they are ignored.
Sorry, as that is probably not what you wanted to hear.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Package: dpkg
Version: 1.18.25
1st loop in /etc/cron.daily/dpkg treats missing file as a reason to backup.
2nd loop does handle missing files okay.
Result is without any arch file, unchanged files are backed up daily which
can be critical when the storage medium has limited life.
Adding a line
y not read /etc/dpkg.cfg.d files
from the root system, but that might be an even longer endeavour)
Best regards
David Kalnischkies
[0]
https://salsa.debian.org/apt-team/apt/-/commit/3fe1419433f195d57b948b100b218cf14a2841d0
signature.asc
Description: PGP signature
On Thu, Feb 06, 2020 at 08:00:26PM +0100, Johannes Schauer wrote:
> Quoting David Kalnischkies (2020-02-06 16:43:22)
> > On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote:
> > >"I have a keyring I know that I want to use (like
> > >/u
keys are no problem and the chroot hopefully ends
up with the keyring package(s) it needs? (Anyway, different topic)
Best regards
David Kalnischkies
[0] If I ever get back to
https://salsa.debian.org/apt-team/apt/merge_requests/33
the answer to which keyring is in the trusted set becomes a lot harder
and/o
ment of the least external dependencies possible).
I fear though that we will find at least one user for every feature
gnupg currently has, but wrapped in an interface which doesn't lend
itself very well to automation and/or additional wrapping.
So this could end up being a colossal undertaking…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
vision it being argued both
ways.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
say this isn't an apt bug.
(Althrough, if we decide on v2, I guess apt needs to change anyhow as
that same call thing might be just dumb luck in this case. Not even sure
if v1 is in any way "guaranteed" to be perfectly honest…)
Can't stop the feeling that we had issues with python begin called from
prerm before and the general advice was: "don't – stick to essential".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
say this isn't an apt bug.
(Althrough, if we decide on v2, I guess apt needs to change anyhow as
that same call thing might be just dumb luck in this case. Not even sure
if v1 is in any way "guaranteed" to be perfectly honest…)
Can't stop the feeling that we had issues with python begin called from
prerm before and the general advice was: "don't – stick to essential".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ould be very strange
and completely unexpected).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ng dpkg output is harder for preciously the initial
problem). It isn't really targeted for usage by the general public…
(Althrough we had it thankfully for the public as temporary workaround
at the time pseudo terminal handling ran hovac in the small differences
between linux and kfreebsd last tim
Attached please find the patch.
I don't know about the general workflow of dpkg-Team, but I think since
this is a really small patch, it does not matter.
Yours
David
From 82360734fa130a083d83f579c1bde85cc1ff6929 Mon Sep 17 00:00:00 2001
From: David Rabel <david.ra...@noresoft.com>
Dat
I have a new stretch/amd64 install created by the alpha 8 installer.
Here is my recipe to reproduce
% sudo apt-get build-dep notmuch
% debcheckout notmuch
% cd notmuch
% make debian-snapshot
This failed for me 4/4 times.
It failed once on libc, twice on libz, and once on glib.
On Sun, Dec 04, 2016 at 04:13:47AM +0100, Guillem Jover wrote:
> On Tue, 2016-11-22 at 18:50:51 +0100, David Kalnischkies wrote:
> > On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote:
> > > --\ Packages to be upgraded (17)
> > […]
>
dpkg::install::recursive "false";
dpkg::install::recursive::force "true";
So, lets let everyone pick his/her preferred poison and we will see who
dies last in this vote… (cc'ed dpkg as they are as involved in it as apt
is).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
haven't looked closely, but apt tries
to not explore solutions caused by M-A:same version screw – aptitude
seems way more willing to suggest such solutions; that is okay I guess
as it is way more interactive, too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
orry for the moment), so I aim low and
treat it as a feature request rather than a bug. Not sure how
non-apt-based frontends like dselect behave through, so for them that
might be one…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
to discuss this – nor is my existance exorbitantly interested in
'chairing' such a discussion at the moment as there are other things
I should be working on, which is also why I only think in private that
this might be a topic which should end up on d-d@ as it effects at least
the big virtual packages.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
shlist, that report would have it…
Best regards
David Kalnischkies
From bae1b41a7d450e9be895edee4220fe34bbe99946 Mon Sep 17 00:00:00 2001
From: David Kalnischkies <da...@kalnischkies.de>
Date: Sat, 23 Jul 2016 10:07:53 +0200
Subject: [PATCH] [INCOMPLETE] dpkg-maintscript-helper: support DPKG
oes OR exist as | then?, is
it a versioned relation, keeping API and/or ABI, what if v2 of a package
adds/modifies/removes the field, interaction with autoremove………
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ng with packages.
For Multi-Arch itself I managed to hide away most of it behind implicit
dependency relations, versioned provides and 'strange' virtual packages
for the libapt-based ones which made that transition quite "easy" all
things considered, but we can't pretend it will always be that "easy"…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
… I wanna
draw attention to the --keyring option of your debootstrap command.
debian-user or perhaps the porters would be a better place to ask (and
if only because of a quicker reply) such a question through as this
question isn't related to dpkg development…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
te_8h_source.html
> │ ├─dpkg-query -L imagemagick:all
> │ └─grep -F -q -x
> /usr/share/doc/imagemagick/www/api/MagickCore/utility-private_8h_source.html
Well, that looks like a maintainerscript running amok as apt doesn't
call dpkg-query. As that loop seems to be produced by
dpkg-maintscript-helper itself, reassigning to dpkg (and keeping
a clone), but perhaps its also imagemagick calling it wrong as
imagemagick is only newly 'all', it used to be 'any'…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ildcards differently if need be, but I am not
going to do it myself mainly because I expect that to have fallout – not
in apt, but in things using apt – and I don't have the energy (or the
rights) to deal with such things efficiently.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
intended.
--
In my testing I couldn't use dpkg --no-act as this 'happily' segfaults
with (the packaged dpkg does as well, just that the stacktrace is
useless without debug symbols, so I built my own dpkg from git):
Reading symbols from
/home/david/Öffentlich/debian/dpkg/build-tree/src/dpkg..
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ca93a5.3030...@gmail.com
- End forwarded message -
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
Package: dpkg
Version: 1.18.1
Severity: normal
The build fails here:
../../scripts/t/merge_changelogs.t . ok
make[5]: *** [test] Error 1
# Failed test 'makefile buildflags.mk computes all values correctly'
# at ../../scripts/t/mk.t line 41.
# Looks like you failed 1 test of 5.
for already installed
packages to an eternal chaos of never being quiet sure if the fields
are available…
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
)
Version: [-2.6.9.23~rc2-1-] {+2.6.9.23~rc3-1+}
Downgrading dpkg-dev (and libdpkg-perl) to 1.17.25 also fixes the issue.
Regards
David
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500
Hi Guillem,
On Fri, May 22, 2015 at 03:51:25PM +0200, Guillem Jover wrote:
On Fri, 2015-05-22 at 09:34:27 -0400, David Prévot wrote:
$ debdiff mozilla-noscript_2.6.9.23~rc{2,3}-1_amd64.changes
[…]
wdiff failed
On the other hand, forcing LC_ALL=C allows to workaround the issue
would
like to avoid happening. I think with the three tools we cover enough
ground to get a solid foundation. At least we should try.
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
slightly off-topic here.
But for completeness in short: APT has a battery of shellscripts we
dubbed integration tests, which can among other things build packages
and (try to) install them via apt with dpkg as non-root in a temp
directory.
Best regards
David Kalnischkies
[0]
https
.
Best regards
David Kalnischkies
¹ referring to apt-get here in particular, but anything using libapt is
effected.
² implementation-wise in libapt as it's trying to hide all of multiarch
by translating the problem to singlearch with heaps of explicitly
created implicit dependencies and (versioned
that we disagree on the
first line everything else hopefully just follows suite (or at least
makes a bit more sense).
On Sun, 2014-11-23 at 18:40:32 +0100, David Kalnischkies wrote:
On Sat, Nov 15, 2014 at 06:24:16PM +0100, Guillem Jover wrote:
And w/o wanting to get tiresome with this, take
ConfigurePending once.
Best regards
David Kalnischkies
P.S.: I will respond to other parts of the mail/thread in other
threads/bugs to keep all reasonably ordered… if that is possible.
signature.asc
Description: Digital signature
of the orders of
the day now as well…
Best regards
David Kalnischkies
¹ On an intellectual level I have the same issue with all --pending
operations, just that apt is described as going from one good state to
another, so I have less problems saying that its okay for it to fix up
all the mess currently
ConfigurePending once.
Best regards
David Kalnischkies
P.S.: I will respond to other parts of the mail/thread in other
threads/bugs to keep all reasonably ordered… if that is possible.
signature.asc
Description: Digital signature
embarrassing that I wanted to do it for 5 years now…)
Anyway, we can't enable this option retroactively even if we wanted to…
Best regards
David Kalnischkies
¹ so basically, it would do what my suggestion is above to be done by
default, BUT I would expect the call to fail if a pending trigger can't
be run
El Lunes, 30 de junio de 2014 19:10:03 David Suárez escribió:
Hi,
El Lunes, 30 de junio de 2014 04:29:43 Guillem Jover escribió:
David, would it be possible to do a simple dpkg-source unpack run over
the stable archive, with the security update (dpkg 1.16.15), to check
if there's any
Hi,
El Lunes, 30 de junio de 2014 04:29:43 Guillem Jover escribió:
David, would it be possible to do a simple dpkg-source unpack run over
the stable archive, with the security update (dpkg 1.16.15), to check
if there's any regressions there?
Not problem, just give me some time :)
Cheers
Hi * !
(hopefully quoting enough for dpkg list to get the context)
On Fri, May 16, 2014 at 12:57:27AM +0200, Aurelien Jarno wrote:
On Mon, May 12, 2014 at 09:03:50PM +0200, David Kalnischkies wrote:
On Tue, May 06, 2014 at 11:22:00PM +0200, Aurelien Jarno wrote:
| # apt-cache show libc6:mips
It is sometimes convenient to keep files deleted in the integration
branch of a version control system even if these files are dfsg free;
most recently I did this to facilitate cherry-picking patches from
upstream of an embedded library (yes, ick, I know). There is no nice
way of representing
Jonathan Nieder jrnie...@gmail.com writes:
I don't think I understand this particular use case --- why patch the
embedded library instead of just removing it?
The embedded library is actually a fork, with tiny but functionally
significant changes.
d
--
To UNSUBSCRIBE, email to
-Original-Maintainer, thus we
shouldn't warn about it. I thought this was Ubuntu specific, but was
told that I should file a bug upstream for inclusion instead.
So I'm sending a patch to add Original-Maintainer as a known header
field in debian/control.
--
David Henningsson, Canonical Ltd.
https
A lot of Ubuntu packages have this warning on build:
dpkg-deb: warning: 'package/DEBIAN/control' contains user-defined field
'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)
This warning should be removed as Original-Maintainer is
encouraged in Debian
On Sun, Apr 28, 2013 at 4:40 PM, Johannes Schauer j.scha...@email.de wrote:
Quoting David Kalnischkies (2013-04-28 14:27:12)
On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer j.scha...@email.de wrote:
My answer: X=~ and Y=. (or anything else expect : really)
As this is something you will have
regards
David Kalnischkies
--
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/caaz6_faqshx6yewt2qzq9xejjjcqzyb5umt18xhrwf--i8o...@mail.gmail.com
://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463030
A graceful kill happens on SIGINT in apt/wheezy in the sense that we will
let dpkg finish whatever it does current (which can be quiet a lot) and stop
after that.
Best regards
David Kalnischkies
P.S.: I don't see why SIGHUP is misused
Package: dpkg
Version: 1.16.9
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
amd64 system trying to install an i386 package required for multiarch setup of
Wine
* What exactly did you do (or not do)
On Miércoles, 21 de noviembre de 2012 20:01:17 Guillem Jover wrote:
On Wed, 2012-11-21 at 19:40:38 +, Noel David Torres Taño wrote:
Package: dpkg
Version: 1.16.9
Severity: important
*** Please consider answering these questions, where appropriate ***
* What led up
(as it does some direct dpkg
calling on its own as far as I know) and whatever other dpkg front-end assumed
that it could arch-qualify everything in a multi-arch universe.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe
On Mon, Sep 3, 2012 at 9:05 PM, Guillem Jover guil...@debian.org wrote:
On Mon, 2012-09-03 at 13:53:47 +0200, David Kalnischkies wrote:
On Fri, Aug 31, 2012 at 5:26 PM, Guillem Jover guil...@debian.org wrote:
So it would seem to me the arch-qualifying logic in apt is not right,
it really
On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder jrnie...@gmail.com wrote:
David Kalnischkies wrote:
As an example:
I highly doubt phonon:amd64 with a dependency on phonon-backend will
work with phonon-backend-vlc:armel which provides phonon-backend.
If phonon-backend would be a normal
David Kalnischkies
--
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/caaz6_fbmuept3nuucjtucvkw7c8ncsgbp8gnvvir-3uf36v...@mail.gmail.com
On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder jrnie...@gmail.com wrote:
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
that a dependency
is unsatisfied (same problem with depends if no architecture is specified).
Shouldn't provides be limited by the architecture their provider can work on?
Or did I miss something here?
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
On Wed, 4 Jul 2012 08:11:48 +0200, Raphael Hertzog hert...@debian.org wrote:
Just to confirm that we speak of the same thing... you have all patches
applied but you don't have the corresponding quilt metadata in .pc.
When you build the source package, dpkg-source tries to apply all the
(or specifically: not available for i386), so you either have to hack
with [arch] or make it any, both is bad…)
See also [0] and [1] in the MultiArch spec which talk about this and
a related issue.
Best regards
David Kalnischkies
[0]
https://wiki.ubuntu.com/MultiarchSpec
On Thu, Feb 16, 2012 at 23:10, Carsten Hey cars...@debian.org wrote:
* David Kalnischkies [2012-02-16 03:59 +0100]:
On Thu, Feb 16, 2012 at 00:39, Russ Allbery r...@debian.org wrote:
it needs to find and remove foo:*
foo:all (or foo:any) instead of foo:* would save the need to quote
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder jrnie...@gmail.com wrote:
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
On Fri, Feb 17, 2012 at 19:53, Carsten Hey cars...@debian.org wrote:
* David Kalnischkies [2012-02-17 14:15 +0100]:
You generously left out the paragraph describing how APT should
detect that the package foo is in fact a library ...
My impression was that you think very library centric. All
is that i don't have ${source:Version} available
currently in the version structure, but we haven't even tried pushing
apt's abibreak to sid specifically as i feared last-minute changes…)
The question just remains if it is a good idea…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email
be good to have an option in dpkg
to tell dpkg what it should consider as native architecture similar to
APT::Architecture to easily solve these kind of communication problems.
Best regards
David Kalnischkies
P.S.: Yes, this was started as a bugreport, but half way though i figured
that's a bit too
and should be the easiest to implement…
Best regards
David Kalnischkies
--
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/caaz6_fbj_xhttvh43gl7dyoyjhigvpr12b737nqsynpvoud
a similar issue with explicit mentioning of the zero
epoch in the past.
Best regards
David Kalnischkies
--
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
change
APT then, until then it will just work this way in most cases and cries
loudly in the essential-case. I just think that we don't need to delay
M-A for this essential-crossgrade as it is more or less an add-on.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ
On Tue, Dec 13, 2011 at 20:55, Julian Andres Klode j...@debian.org wrote:
On Tue, Dec 13, 2011 at 09:19:55AM +0100, Guillem Jover wrote:
On Mon, 2011-12-12 at 18:14:15 +0100, David Kalnischkies wrote:
Beside that i wonder which --force flag this should be, given that it
removes packages
On Tue, Dec 13, 2011 at 08:29, Guillem Jover guil...@debian.org wrote:
On Mon, 2011-12-12 at 18:15:12 +0100, David Kalnischkies wrote:
dpkg --remove libc6 # removing libc6:i386 and libc6:amd64
?
Users will love you for this, given that it is completely inconsistent with
what front-ends
to be become long already,
so i am not going to repeat it here, just let me reiterate that
a) it feels strange to have different interfaces in the same context
b) requiring different inputs based on the M-A state asks for confusion
c) breaking release upgrades should be avoided
Best regards
David
anyway.
So implementing this sounds for me a bit like black voodoo…
Best regards
David Kalnischkies
--
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
On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog hert...@debian.org wrote:
On Mon, 12 Dec 2011, David Kalnischkies wrote:
You talk only about output, but the title is I/O and i think it's unlikely
that dpkg has a different understanding of pkgname in output vs input,
so, you want to tell us
numbers begin with a letter and I find the dpkg source way too
confusing to understand what it does.
--
David A. Madore
( http://www.madore.org/~david/ )
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
to
proceed, so any other suggestion would be very welcome.
--
David A. Madore
( http://www.madore.org/~david/ )
diff -rup dpkg-1.16.0.1/lib/dpkg/parsehelp.c dpkg-1.16.0.1dmadore/lib/dpkg/parsehelp.c
--- dpkg-1.16.0.1/lib/dpkg/parsehelp.c 2011-04-03 17:33:31.0 +0200
+++ dpkg
as already configured (and maybe configure i386)
- fail as not specific enough
Best regards
David Kalnischkies
--
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
checked by a script).
Cheers,
David.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: dpkg
Version: 1.15.8.3
Severity: normal
Hi,
Translated manual pages are not shipped any more with dpkg.
Cheers
David
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable'), (150,
'experimental
disappeared i would assume that newPkg-{client,server}
should be marked as manual (if oldPkg was manual) as they seems to
be the follow up packages of oldPkg. awk on the other hand seems to be
just still a depends to be able to execute maintainerscripts successful.
Nothing implicit
Best regards,
David
-get call - an example:
The following packages disappeared from your system as
all files have been overwritten by other packages:
apt dpkg
Note: This is done automatic and on purpose by dpkg.
* (hint hint)
2010/4/10 David Kalnischkies kalnischkies+deb...@gmail.com:
b) a) + overload Provides
completely and
writing a full-blown version number normalizer just for this small
use case seems to be over-engineering…
Best regards,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
…
Best regards / Mit freundlichen Grüßen
David Kalnischkies
--
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/p2yc64043e61004300356za77e0adeie1a4b256808a3...@mail.gmail.com
Hello (again),
2010/4/10 Jonathan Nieder jrnie...@gmail.com:
David Kalnischkies wrote:
he needs to install git-core which he does again after noticing that it
doesn't work at the first try and face a conflict resolution process now…
(or he had git already installed through some dependencies
,
David Kalnischkies
--
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/z2rc64043e61004090453r371cdeb9xdee967f396a39...@mail.gmail.com
the simple normal package rename case a bit.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
--
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
.)
Best regards / Mit freundlichen Grüßen,
David DonKult Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
. As you
noted, updating the .list files is cheap, so retaining them should not
be expensive. As long as we can reliably detect when the database
becomes inaccurate (with false positives acceptable), we can regenerate
the cache and move on. I think this should not be a difficult problem.
David
On 08/30/2009 09:28 AM, Cyril Brulebois wrote:
David Benjamindavid...@mit.edu (29/08/2009):
The current list-files are good for the query given a package, what
did it install. They also have fairly fast updates. However, they
are extremely poorly suited for the query given a file, what
package
paths. A tar file may have problems with
--delete rewriting the entire file.
Thoughts?
David Benjamin
[1] http://github.com/davidben/dpkg/tree/tarfile-proof-of-concept
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
of the list. (This is what the original code
does, so I have mirrored its behavior.)
Signed-off-by: David Benjamin david...@mit.edu
---
src/filesdb.c | 77
1 files changed, 49 insertions(+), 28 deletions(-)
diff --git a/src/filesdb.c b
for unstable main [0]) that
e.g. the very small cs_CZ file would hide the larger cs file...
(btw: Also a suggestion which whitelist should be used would be good,
e.g. i think it is unlikely that we get a de_?? in the future...)
Best regards / Mit freundlichen Grüßen,
David DonKult Kalnischkies
Here's a patch that fixes this bug
lazarus_0.9.26.2-2ubuntu1.debdiff
Description: Binary data
Sorry guys, I accidentally sent that last message to the wrong bug.
Feel free to delete both this message and the previous one.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I've downloaded the latest git version, using git clone
git://git.debian.org/git/dpkg/dpkg.git and have changed all the .po
files and the files in /src to the correct grammar. How do I upload
the changes to git now?
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a
Canadian health remedy's...the easily method to buy
www.conceive-harmonious-wind.cn
I never once wonderful doubted grip respect umbrella your doing so. Monte
Cristo
fly join Let shrug us try what we can distance do, then, said the notary
--
To UNSUBSCRIBE, email to
1 - 100 of 146 matches
Mail list logo
