Hi Matthias,
Matthias Klose wrote:
There is more than a handful of packages which do not care about
dpkg-buildflags yet in debian/rules. Currently it's difficult to
tell if a package build honors dpkg-buildflags or not. The only way
to do this currently is to edit the config files for a
Raphael Hertzog wrote:
Do you often need to verify if a package supports dpkg-buildflags?
In what context?
I can think of some:
- wanting to be sure that setting hardening flags on these packages
through the dpkg-buildflags mechanism will actually work;
- guaging whether the mechanism
Hi Eugene,
Eugene V. Lyubimkin wrote:
As it was discovered in some places (#558151), some system modifications
cannot be sanely made without specifying --auto-deconfigure to dpkg.
Please provide a --deconfigure command, so dpkg front-ends can plan and
request deconfigurations themselves.
I
Eugene V. Lyubimkin wrote:
On 2011-05-20 13:16, Jonathan Nieder wrote:
unpack libc6
unpack libc-bin
configure libc-bin
configure libc6
Emm, the whole #558151 was about the order above does not work unless
you specify --force-bad-path which Guillem was much against.
Ah
Hi again,
A quick note to finish the tangent.
Jonathan Nieder wrote:
In an ideal world, the upgrade path
would be
unpack libc-bin
unpack libc6
configure libc-bin
configure libc6
with no deconfigure step (essential packages are not supposed to ever
need
Raphaël Hertzog wrote:
dpkg: improve pre-dependency check on unpack
When a pre-dependency is not satisfied due to a package in
triggers-awaited state, immediately run the trigger processing
and continue without errors.
This make it possible to blindly use --no-triggers
Raphael Hertzog wrote:
On Sat, 14 May 2011, Jonathan Nieder wrote:
Shouldn't packages that have been configured and had triggers satisfied
once remain usable (and satisfy pre-dependencies) until they are
deconfigured, without requiring triggers to be run again?
They do. And my patch should
Hi Matteo,
Matteo Cortese wrote:
Would you consider a flag to switch this warning off?
Like David, I've already missed a number of errors hidden in a sea of
version string does not start with digit lines.
I think a good fix would be to unconditionally batch the errors and
require a
Guillem Jover wrote:
On Tue, 2011-05-10 at 16:28:56 -0500, Jonathan Nieder wrote:
I think a good fix would be to unconditionally batch the errors and
require a --verbose or similar flag to get the full list. Would you
be interested in working on that?
I've already code
Modestas Vainius wrote:
All examples of minimal dh rules have been recommending contrary all this
time.
Also, where I said policy has required I should have said just
recommended.
Many packages will be broken unless this is dealt with in dh.
Personally, I don't see why this can't be fixed
Modestas Vainius wrote:
I don't think this scales well. Something like $(dpkg-buildflags --
export=make) would be better to suggest. IMHO, project shall decide on clear
recommendations how to proceed.
Side note: I don't know how to do that with GNU make, actually.
$(shell ...) works for one
Hi,
Yves-Alexis Perez wrote:
as said on irc, it'd be nice if dpkg could handle package upgrade
involving symlinks and directories a bit more nicely.
See also [1], [2], and [3].
The intent of the current behavior is that the sysadmin is free to use
symlinks to cause files in one directory to
Raphael Hertzog wrote:
However I agree that --extend-diff-ignore used after -isomething should
probably extend the previous setting (for example if you have diff-ignore in
debian/source/options and extend-diff-ignore in
debian/source/local-options). I have pushed a fix for this but this is
Hi,
Gilles Filippini wrote:
The attached patch appears to solve my problem, with
--extend-diff-ignore specified either from the command line or from a
debian/source/[local-]options file.
Rationals are:
* options from the command line should be interpreted first
* then should come options
, makes sense.
On Tue, May 3, 2011 at 01:05, Jonathan Nieder jrnie...@gmail.com wrote:
If anyone interested in working on this has any questions, please feel
free to let us know.
I could work on that...
That would be excellent!
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ
forcemerge 316521 625241
quit
Hi,
Ondřej Surý wrote:
I don't know whether it is real dpkg bug or not, but that's something
I have found in php5 piuparts testing.
Both php5-common and php5-cli (and other SAPIs) owns /etc/php5
(/var/lib/dpkg/info/*.list), now after
dpkg --remove php5-cli
Raphael Hertzog wrote:
I'm not going to cherry-pick in a huge patch when the request is to
remove a dot from a single string :)
Your loss. :)
Also I'm not sure unfuzzying the translations makes sense, other languages
might have final punctuation that should be removed as well.
I meant I'd
argument contains a '/'; simplify by
not checking again for the same thing.
The real motivation is to avoid confusing behavior in an edge case:
when execve fails with ENOEXEC, execvp will run the script using the
system shell but execv will error out.
Signed-off-by: Jonathan Nieder jrnie
Hi,
Raphael Hertzog wrote:
The change is very old, not many users will be affected by this.
Guillem, what do you think? Should we silence the warning due to this?
I am not Guillem :) but I think the ideal thing would be a way for the
user to (perhaps explicitly) update the status db by
Gordon Haverland wrote:
None of those packages are official Debian packages. I suggest you get in
touch with the providers of those packages so that they update them
accordingly.
As noted, it's not a bug but a deliberate change.
Wait a second. I'm not up to speed on the exact design, but
Jonathan Nieder wrote:
Gordon Haverland wrote:
Sorry, sloppy of me. The quoted text is by Raphaël, not Gordon, for
those who were wondering what had happened to the world. :).
None of those packages are official Debian packages. I suggest you get in
touch with the providers of those packages
severity 620679 important
forcemerge 620679 620880
quit
Hi Thorsten,
Thorsten Glaser wrote:
In a sid chroot, just now:
tg@frozenfish:~ $ sudo apt-get --purge dist-upgrade
[...]
Unpacking replacement libperl-dev ...
dpkg: error processing
Hi,
Guillem Jover wrote:
On Mon, 2011-04-04 at 23:57:39 -0500, Jonathan Nieder wrote:
I'd be happy to work on a fix to this that fits nicely with dpkg's
design and is agreeable to people. Any hints or pointers?
Sorry, I guess I don't follow, a fix for what? We are talking about
just
-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi,
Raphaël Hertzog wrote:
--- a/src/divertcmd.c
+++ b/src/divertcmd.c
@@ -216,8 +216,10 @@ file_copy(const char *src, const char *dst)
return -1;
dstfd = creat(dst, 0600);
- if (dstfd 0)
+ if (dstfd 0
Hi Yann,
Yann Dirson wrote:
dpkg-deb -b apparently uses some temporary files which can take some
place. When it fills /tmp, it stops with a no space left on device
error, but since it cleans up before exiting, the user is left with
few clues as to where to add space. An explicit message
a similar fix.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Ian,
Ian Jackson wrote:
On Sat, Mar 15, 2008 at 05:25:56PM +, Ian Jackson wrote:
* retain the manual configuration but simply not use it when
then user's manual selection is unavailable.
[...]
If we do this and retain the existing maintainer scripts then
everything will be fine
user debian-pol...@packages.debian.org
usertags 604397 + normative discussion
quit
(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,
Roger Leigh wrote:
[out of order for convenience]
Just for the record, I've implemented support in debhelper's dh
reopen 613738
reassign 613738 tar 1.23-3
retitle 613738 [mips] tar: ./postinst: Cannot utime: Unknown error 4294967207
quit
Hi Nigel,
Nigel Horne wrote:
An apt-get upgrade failed midflow today with strange utime errors such as:
tar: ./postinst: Cannot utime: Unknown error 4294967207
tar:
files.
Reported-by: Stéphane Glondu glo...@debian.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Raphaël Hertzog hert...@debian.org
---
Raphael Hertzog wrote:
You should also update the code for the source package formats
because both 1.0 and 3.0 (quilt) pass an explicit value
Raphael Hertzog wrote:
On Sat, 12 Feb 2011, Jonathan Nieder wrote:
2. Raphaël, maybe dpkg-source could do something like this?
utime does not return ENOENT unless all its arguments do not
exist.
What's the point? I don't see how it matters...
When the filesystem is NFS, utime
Raphael Hertzog wrote:
Yes, so what matters is the undef parameter, and you want to modify all
files in a single call to have the same timestamp everywhere. But I'm not
sure you have that guarantee.
Hmph, true enough. perl calls futimes(fd, NULL) in a loop.
... and thus you
might
Hi again,
Some quick clarifications.
Jonathan Nieder wrote:
GNU patch just _preserves_ file timestamps when patching. Could
dpkg-source do that?
No, dpkg-source shouldn't (Bug#105750). It also seems I misunderstood
patch's behavior --- sorry for the nonsense.
(NEEDSWORK: does not handle
Hi Stéphane,
Stéphane Glondu wrote:
Le 12/02/2011 16:53, Raphael Hertzog a écrit :
AFAIK the ctime can't be modified except if we do things like chown/chmod
on the file. I don't see why quilt push would modify it...
Well... it does... and so does touch.
I think ctime is a red herring here.
Guillem Jover wrote:
Not really, bootstrapping should be possible from the pure upstream
part (although there's some pending issues there), but the Debian
packaging part relies on debhelper and dpkg itself
Ah, sorry for the thinko.
In that case I can say enthusiastically that I like Colin's
Colin Watson wrote:
--- a/debian/rules
+++ b/debian/rules
@@ -80,6 +80,13 @@ install: check
cd build-tree $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
+ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu echo yes))
+ # Ubuntu's i386 architecture is built for i686 (the
found 525160 dpkg/1.15.8.8
quit
Raphael Hertzog wrote:
On Mon, 24 Jan 2011, Peter van Dijk wrote:
However, removing+purging menu does not remove those triggers. Is this
intended behaviour? I'm asking because in a situation with a non-Debian
package, I installed a version without trigger
Julien Cristau wrote:
On Mon, Jan 24, 2011 at 21:37:01 +0100, Sven Joachim wrote:
I wonder whether the Breaks against the emacs2[12] packages need to be
taken out as well. In a chroot the upgrade process removes emacs and
its dependencies:
Possibly the breaks is a bad idea for anything
-by: Jonathan Nieder jrnie...@gmail.com
---
Jonathan Nieder wrote:
Julien Cristau wrote:
Possibly the breaks is a bad idea for anything that's more than just an
info viewer.
Info viewers, too, right?
In other words, how about something like this patch?
debian/control | 13 -
1
Hi again,
Peter Gyongyosi wrote:
But I do not understand your other remark: I am indeeed using TRACEME,
all other ptrace calls are just to limit the tracing to only forks and
to get the PID we need.
Sorry, that was just my sloppiness. Perhaps renaming the function,
along the lines of
Hi,
First of all, thanks for sending this.
Peter Gyongyosi wrote:
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
[...]
@@ -361,6 +369,152 @@ pid_list_free(struct pid_list **list)
[...]
+static void
+start_trace(pid_t pid)
+{
+ wait(NULL);
+
+ int retries;
+
reassign 609627 gwibber
quit
Hi Kartik et al,
Ben Bromley wrote:
I've installed Firefox in /opt so that I can run the beta. I linked
/opt/firefox/firefox to /usr/bin/firefox, and I have been using that location.
I have Firefox listed as the preferred application for web browser, and used
Raphael Hertzog wrote:
On Mon, 03 Jan 2011, Bastian Blank wrote:
Unified diff files are applied from the start to the end, file by file.
There is no notion of duplicate files in it.
While such files are valid patch files, diff will never generate such a
patch. So it's a sign either of a
Package: dpkg-dev
Version: 1.15.9
Severity: wishlist
Thorsten Glaser wrote:
dpkg-architecture appears to be called rather often.
It’s slow though…
r...@ara0:~/T # time dpkg-architecture
DEB_BUILD_ARCH=m68k
[...]
0m7.49s real 0m2.97s user 0m4.02s system
The system is
NightStrike wrote:
What's wrong with using the existing GNU triplet?
FWIW sorry for setting off this discussion (but thank you --- the
answers have been very helpful to me!). Luckily you provided a
good example that might help explain the purpose of Debian triplets
later in the thread:
forcemerge 595927 606966
quit
Hi Sam,
Sam Morris wrote:
Package: dpkg
Version: 1.15.8.5
Severity: normal
dpkg hung while unpacking a package:
[...]
[5416783.438276] INFO: task dpkg:28315 blocked for more than 120 seconds.
[5416783.438330] echo 0
Dmitrijs Ledkovs wrote:
There are currently two free implementations of msvcrt: mingw.org and
mingw-w64.
Programs built with mingw32 *unable* to safely use DLLs built with
mingw64 there are subtle differences in implementations.
That answers my main question. Then I suppose:
We have one
Hi,
Some uninformed reactions.
Dmitrijs Ledkovs wrote:
--- a/ostable
+++ b/ostable
@@ -31,3 +31,4 @@ bsd-openbsd openbsd openbsd[^-]*
sysv-solaris solaris solaris[^-]*
uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi
Package: dpkg-dev
Version: 1.15.9
Severity: wishlist
Hi,
As mentioned at [1], using dpkg-buildflags --export from a makefile is
more trouble than one might like.
It would be simpler to do something closer to the current thing:
CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
reassign 604114 debconf 1.5.36
quit
Kurt Roeckx wrote:
it seems that
debconf is turning a triggered into a configure.
Yes. Maybe /usr/share/debconf/frontend near 69:
if ($ARGV[0] =~/^(.*[.\/])(?:postinst|preinst)$/) {
could be
Ted Ts'o wrote:
On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:
It means we don't need to keep it in RAM since we're not going to
read/modifiy it again in the near future. Thus the writeback can be
started right now since delaying it will not save us anything.
At least
Ted Ts'o wrote:
Most files won't, but consider a postinstall script which needs to
scan/index a documentation file, or simply run one or more binaries
that was just installed. I can definitely imagine situations where
using POSIX_FADV_DONTNEED could actually hurt performance.
Hmm. Maybe
(pruned cc list)
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Probably a silly question, but what does The specified
Hi Guillem,
Guillem Jover wrote:
Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
instead, skimming over the kernel source seems to indicate it might
end up doing more or less the same thing but in a portable way?
Could someone with ext4/btrfs/xfs/etc test w/ and w/o the
Hi Ted,
Ted Ts'o wrote:
1) Suppose package contains files a, b, and c. Which are you
doing?
a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a);
extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b);
extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new,
Raphael Hertzog wrote:
On Sun, 21 Nov 2010, Juergen Kosel wrote:
yesterday I have upgraded an old computer from Lenny to Squeeze.
This machine has a long history. Debian Woody was installed on it 2005.
Now dpkg gives the following complaints on packages which were installed
long ago:
Raphael Hertzog wrote:
On Sat, 13 Nov 2010, Jonathan Nieder wrote:
Matthias Klose wrote:
Currently dpkg-architecture and dpkg-parsechangelogs allow printing
all key/value pairs with one invocation, while dpkg-buildflags just
gives an error message without parameters. Please provide a mode
Hi Matthias,
Matthias Klose wrote:
Currently dpkg-architecture and dpkg-parsechangelogs allow printing
all key/value pairs with one invocation, while dpkg-buildflags just
gives an error message without parameters. Please provide a mode
that prints all flags (like dpkg-architecture). This
(+cc: debian-kernel)
Ken Bloom wrote:
And what mount options are you using? If you're using
defaults, /etc/mtab (and therefore the mount command) won't know what
the default values are, but you can check /proc/mounts which will
include the data= mount option.
data=ordered. That's the
Hi,
jamesb wrote:
The epiphany browser cannot be changed graphically. extremely irritating
You've got the wrong bug report, I'm afraid.
You see, iiuc epiphany-browser is not even managed systemwide through
the alternatives system. The default browser is rather managed
something like this:
Jonathan Nieder wrote:
jamesb wrote:
The epiphany browser cannot be changed graphically. extremely irritating
[...]
- Modern, desktop-agnostic apps use the xdg-open(1) utility,
which detects the current browser and tries some of the above.
... detects the current desktop environment
reassign 594908 debian-faq
quit
Hi FAQ maintainers,
[reordered for convenience]
Vincent Lefevre wrote:
$ dpkg --compare-versions '1.2.3-2+b1' le '1.2.3-2local1'
zsh: exit 1 dpkg --compare-versions '1.2.3-2+b1' le '1.2.3-2local1'
and both apt-get and aptitude want to upgrade the local
forcemerge 590885 591692
quit
Hi Harald,
Harald Dunkel wrote:
Seems that the new dpkg cannot read /var/lib/dpkg/status anymore.
Known bug in dealing with iffy version strings.
Any hint how to get out of this mess without corrupting the
database would be highly appreciated.
Just a guess,
Jonathan Nieder wrote:
Harald Dunkel wrote:
Any hint how to get out of this mess without corrupting the
database would be highly appreciated.
Just a guess, but wouldn’t dpkg --clear-avail work?
Err, no, it wouldn’t. But you can edit /var/lib/dpkg/status
and change the version string
tags 591182 + patch
quit
Philipp Kern wrote:
Your package failed to build from source when scheduled as a binNMU. Is it
possible that it cannot cope with that fact and the + in the testcase harness
is actually messing things up?
Makese sense to me.
Untested.
Signed-off-by: Jonathan Nieder
severity 591010 normal
quit
Modestas Vainius wrote:
I do believe that dpkg-buildpackage
should be changed to support absolute paths for -r again (what's the point not
to, they are more secure anyway?) and thus save sbuild users (buildd admins
and
severity 579790 important
quit
Hi Moritz,
Moritz Beyreuther wrote:
/usr/bin/dpkg --status-fd 11 --force-depends --force-remove-essential
--remove courier-mta courier-base courier-authdaemon courier-authlib-userdb
courier-authlib
However courier-authlib is deinstalled first which breaks
Jonathan Nieder wrote:
severity 579790 important
More thoughts.
1. --force-depends makes semantics hard to reason about, but the
algorithm is actually very simple (from src/packages.c):
| The criteria for satisfying a dependency vary with the various
| tries. In try 1 we treat
Moritz Beyreuther wrote:
The following does not do the job::
dpkg --auto-deconfigure --force-depends --force-remove-essential \
--remove courier-mta courier-base courier-authdaemon \
courier-authlib-userdb courier-authlib
What happens when you leave out the --force-
# [1]
severity 579790 serious
quit
Moritz Beyreuther wrote:
On Sat, Jul 17, 2010 at 08:56:51AM -0500, Jonathan Nieder wrote:
Moritz Beyreuther wrote:
dpkg: dependency problems prevent removal of courier-mta:
Oh, right; --auto-deconfigure only applies to Conflicts and Breaks,
not newly
Raphael Hertzog wrote:
No, the time has not yet come, we're at the end of the squeeze cycle,
we're not supposed to make such important changes. We should do it
at the start of squeeze+1.
Isn’t that a kind of question for the release team to decide?
--
To UNSUBSCRIBE, email to
Jonathan Nieder wrote:
Isn’t that a kind of question for the release team to decide?
To clarify: if you are worried about debian/rules as produced
by e.g. dh_make, that is a different story; I can understand
holding off until debhelper learns to do something reasonable with
DEB_BUILD_OPTIONS
Hi kernel team,
Andreas Beckmann wrote:
Unfortunately since the last dpkg changes concerning sync()/fsync() this
no longer works out well - the continuous sync() from a virtual chroot
on tmpfs hits the physical system really hard, causing speed loss
factors between 3-5, probably more if
# Modestas Vainius wrote:
#
# first of all, I'm fully aware of [1] and [2].
# [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635
# [2] https://bugzilla.kernel.org/show_bug.cgi?id=15910
#
# Ah, but are you aware of 584254? :)
merge 584254 588254
quit
--
To UNSUBSCRIBE, email to
Hi LaMont,
LaMont Jones wrote:
With the introduction of fsync() calls to protect data, applications
that do potentially large apt-get install invocations may not want
to incur the penalty of fsync() calls from dpkg.
In the case of building a livecd, this can be the difference between
a 10
Guillem Jover wrote:
Have you tested
1.15.7.2 (which includes that change), and do the performance issues
persist there. We actually got pretty good results from several testers
on ext4
Right, though still significantly (about 20%) worse in some cases than
without any fsync[1]. So I can
reassign 581807 gecko-mediaplayer 0.9.9.2-1
retitle 581807 cannot unpack with /usr/lib/firefox/plugins -
../mozilla/plugins symlink
quit
Hi Cesare,
Brandon reported trouble unpacking the latest version of gecko-mediaplayer.
The package contents include
Hi Brandon,
Brandon wrote:
Upon reinstalling or upgrading to the 0.9.9.2-1 version of the gecko-
mediaplayer package, the 1.15.7.1 version of dpkg performs a deferred extract
unpacking of /usr/lib/mozilla/plugins/gecko-mediaplayer.so as the target of a
number of symbolic links, but
Hi Brandon,
Brandon wrote:
Unpacking replacement gecko-mediaplayer ...
dpkg: error processing
/var/cache/apt/archives/gecko-mediaplayer_0.9.9.2-1_i386.deb (--install):
unable to open '/usr/lib/mozilla/plugins/gecko-mediaplayer.so.dpkg-new': No
such file or directory
That helped. My
found 560070 dpkg/1.15.7
quit
Bill Allombert wrote:
[ Raphaël Hertzog ]
* Introduce a new script called dpkg-buildflags: its purpose is to
retrieve
compilation flags and it should be used within debian/rules to pass
the right compilation flags to the build process.
Hi,
Raphael Hertzog wrote:
Can you try with the dpkg version that is in the branch pu/async-sync
of git://git.hadrons.org/git/debian/dpkg.git ?
Some rough numbers.
master+sid+asyncsync:
cold cache 16.86user 4.21system 0:50.52elapsed 41%CPU (119major)pagefaults
warm cache 16.82user
Hi Regid,
Regid Ichira wrote:
I think DEB_BUILD_OPTIONS is in policy. Isn't dpkg-buildflags and
DEB_BUILD_OPTIONS interfering with each other?
No, because dpkg-buildflags respects DEB_BUILD_OPTIONS.
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to
reassign 580152 apt apt/0.7.25.3
thanks
Hi APT team,
Jari Aalto wrote:
During upgrade under unstable:
Processing triggers for menu ...
W: Unable to read /etc/apt/preferences.d/ - FileExists (2: No such
file or directory)
Could this be caused by the fact that here the
clone 577650 -1
retitle -1 conflict on git-completion should be versioned to avoid dpkg bug
# justification: makes upgrade without --force-depends ugly
severity -1 serious
reassign -1 git git/1.7.0.4-2
thanks
Eugene V. Lyubimkin wrote:
merge 575786 577650
[...]
Hi James, thanks for reporting
Package: dpkg
Version: 1.15.5.6
Severity: wishlist
If the administrator tries to upgrade or downgrade a package in such a
way as to violate another package’s dependencies, dpkg does nothing to
stop him or her.
You can try it:
1. Build packages packagea_1_arch.deb and packageb_1_arch.deb,
retitle 20471 dpkg: check rdepends on unpack
thanks
Raphael Hertzog wrote:
Yes we want that, but another bug is not needed it's a very old one that is
marked as important, it has a preliminary patch by Ian Jackson
Oh! That’s good to hear.
but it
doesn't work suitably yet.
See #20471
Raphaël Hertzog wrote:
On Thu, 07 Jan 2010, Jonathan Nieder wrote:
Making the .pc directory by hand makes this work again.
[...]
This is a duplicate report, it's already fixed in the sid branch.
Sorry for the noise. Indeed, commit a77468f works here.
Thanks,
Jonathan
--
To UNSUBSCRIBE
Package: dpkg-dev
Version: 1.15.5.5
Working with a simple package, debian/source/format contains
3.0 (quilt), no debian/patches directory, no .pc directory, upstream
sources modified. When I try to 'debuild -I -i', dpkg-source fails:
| dpkg-source: info: using source format `3.0 (quilt)'
|
. (Is the Debian mailing lists’ filtering
policy documented anywhere?)
My feeling is that these patches should be more readable than
the last series, too. I hope you enjoy them, and I look
forward to your thoughts.
Jonathan Nieder (15):
libdpkg: Reduce scope of combuf[] in compress_cat
libdpkg
retitle 542149 dpkg: please change pre-dependency to lzma | xz-lzma
thanks
Hi,
Guillem Jover wrote:
Switching the support from lzma to xz has been on my radar for some
time, but given that the tools and library in unstable didn't seem to
be ready, and the ones which seemed to were in
Package: dpkg
Version: 1.15.3.1
Severity: wishlist
Mohammed Adnène Trojette wrote:
To conclude, one funny request: why don't we make xz the first
xz-compressed package? Having such packages is a release goal for the
next release.
Raphael Hertzog wrote regarding Bug#542149:
- instead of
# I should sleep more before sending such requests...
# Apologies for the confusion.
retitle 542160 dpkg: please support xz compressed packages
thanks
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Raphael Hertzog wrote:
* Some users may want to install XZ Utils without the legacy commands
(by installing xz-utils but not xz-lzma nor lzma). dpkg should still
work for such users.
Why would it not work?
xz-utils does not include /usr/bin/lzma (though xz-lzma does).
Do you have a plan
Package: dpkg
Version: 1.15.3.1
Severity: wishlist
I have been working on packaging XZ Utils, which is supposed to
eventually supersede LZMA Utils. To that end, it provides “lzma”,
“unlzma”, etc commands for compatibility with lzma, but scripts and
other programs are encouraged to use “xz”
---
Here is the second step: move the PATH-searching function to
lib/dpkg/path.c. The only changes to the body of the function
consist of reformating to fit the style of the code around it ---
no functional change intended.
Like the first patch, this patch is not even tested.
Regardless, any
101 - 195 of 195 matches
Mail list logo
