Hi Stephen,
Stephen Kitt wrote:
> We still need to figure out how to handle the triplet. There are multiple
> goals, from end users’ perspectives, some conflicting:
>
> * provide a Windows cross-compiler with a good selection of libraries, within
> Debian, so that it’s easy to build Windows
Hi,
Helmut Grohne wrote:
> I find myself repeating a mapping from Debian architectures to the
> typical output of uname -m (and occasionally -s) in various packages.
> Copying such code is going to be a maintenance nightmare, so it should
> live somewhere central. I propose
Hi,
Guillem Jover wrote:
> So, first, thanks for the constructive proposals! But I'd rather not
> revert this change. I'm happy to implement anything sane people might
> find useful to cope with such change. This includes the following
> changes which I've started coding:
>
> * DPKG_PAGER
Hi,
Nicholas Brown wrote:
> /usr/share/perl5/Dpkg/Source/Package/V3/Git.pm regularly calls out to git
> using
> "system('git'," yet libdpkg-perl does not Require or even Recommend that
> Git is installed.
>
> This makes using dpkg-source with the 3.0 (git) format fail, for example in a
>
Hi,
Petter Reinholdtsen wrote:
[Guillem Jover]
I've not checked those bug reports, but I'm assuming that the
package might also fail in case apache2 is not installed at all? Or
how do you handle that case? And the subsequent missing
configuration when apache2 gets installed later on?
For
forcemerge 733746 719348
# confusing error message
severity 733746 minor
quit
Hi,
Thomas Mayer wrote:
pd-purest-json (1.0.0) UNRELEASED; urgency=low
Is this a native package? (See [1] for what I mean.)
Curious,
Jonathan
[1]
Hi,
David Bremner wrote:
[Subject: please consider it anyway, even if useless for non-free files]
Please keep in mind that these emails appear in a crowded inbox, so
the subject line can be a good place to put valuable context.
It is sometimes convenient to keep files deleted in the
Hi,
Jérémy Bobbio wrote:
Guillem Jover:
For example, in the generated data.tar the files will contain
different modification times, some will come untouched from the source
files if they just get copied, and others will be newer if the files
got created at build time. Preserving these
Hi,
Christoph Anton Mitterer wrote:
- Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
Unpacking replacement foo ...
- Setting up foo (2.0-1) ...
but also the less oftem messages like:
- (Reading database ... ?%
- Processing triggers for ?
Quite frankly, these are
Guillem Jover wrote:
... I'm attaching a small tentative patch, on the best place I could
find, just in case.
I think it belongs in section issues.dbk:
Sometimes, changes introduced in a new release have side-effects
we cannot reasonably avoid, [...]
Ideally it should be
severity 703092 important
quit
Hi,
Norbert Preining wrote:
[Subject: setting this to critical]
Please keep in mind that these appear as emails in a crowded inbox,
where a subject line can provide valuable context.
It might look harmless, but we do *NOT* want to release Debian
with a dpkg
Guillem Jover wrote:
Ok, I've merged these two patches with some modifications
Looks good. Thanks for taking care of it.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Maurizio,
Maurizio Oliveri wrote:
Of course, dpkg --get-selections | grep gnome-terminal returns
gnome-terminal install.
What is the output of dpkg --configure -a?
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe.
Guillem Jover wrote:
Some packages might be using -Werror, adding -Wall might cause FTBFS,
please see the recently created FAQ [0] for the procedure to follow to
add a new flag to the default set.
When working with upstream projects that don't use -Wall, adding it
can create a lot of noise
),
The link should go in the SEE ALSO section, not the EXAMPLES section.
With that tweak
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
retitle 692164 dpkg-source -x: upstream .pc directory prevents patch application
severity 692164 normal
quit
Hi Michael,
Michael Gilbert wrote:
Hi, dpkg-source will have trouble dealing with upstream tarballs
containing pre-existing .pc directories. For example, see:
Raphael Hertzog wrote:
In both cases the purpose of the file is to provide identification
information about the OS.
Identification for what purpose? So I know which programmer to
complain to when running into compatibility bugs, like the HTTP
User-Agent field? For display and theming? To
Guillem Jover wrote:
On Sun, 2012-10-28 at 02:53:57 -0700, Jonathan Nieder wrote:
Here's another try at putting it in the description of --export. What
do you think?
Certainly an improvement, although I'm not yet sold on the embedded
examples, it would probably also make more sense
Raphael Hertzog wrote:
Surely you don't have to invent X ways to identify the OS just because
you want to identify it in different contexts?
Yes, I think this is where we disagree.
Using a single source is just a better design that avoids mistakes
where /etc/dpkg/origins/default says Debian
it in the description of --export. What
do you think?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
man/dpkg-buildflags.1 | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1
index ea61306b
Raphael Hertzog wrote:
Why would it be better to deploy a
dpkg-specific file over a generic file even if dpkg is the only software
making use of that generic file?
Because it makes the purpose of the file clearer, and if other
programs make use of files with
it uses double quotes ('') around arguments that might
contain spaces. Any additional escaping (e.g., '\' before spaces)
would be passed through to configure and break the build.
How about this patch?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
man/dpkg-buildflags.1 | 18
Hi Matthias,
Matthias Klose wrote:
A lot of rules files uses loops around configure calls, however there's no
export mode which escapes the spaces in the output. Please add one. The sh
mode
won't work either for this case.
Doesn't
set -e; \
eval $$(dpkg-buildflags
Hi,
Nicholas Bamber wrote:
Sorry yes I did not mean to imply that there was a copyright issue
with the inclusion of debhelper fragments in maintenance scripts, just
an example of techincally it might happen. The policy explicitly
mentions incorporating source code.
Based on
reassign 685378 src:qt4-x11 4:4.8.2-2
forcemerge 684556 685378
quit
Hi Benedikt,
Benedikt Spranger wrote:
Unpacking replacement libqtcore4:amd64 ...
dpkg: error processing
/var/cache/apt/archives/libqtcore4_4%3a4.8.2-2+b1_amd64.deb (--install):
trying to overwrite shared
Hi,
Guillem Jover wrote:
The main issue I have with this request is that the upstream triplet just
seems wrong, as it encodes part of the ABI in the vendor field. That's
AFAIR, from reading the thread back then.
For dpkg tools the vendor is irrelevant, and having to take it into
account
Hi Stephen,
Stephen Kitt wrote:
[...]
I've added tests to deactivate stack protector and relro on Windows,
Good. Thanks much for that.
and more
controversially I've added x86 and x64 entries in cputable.
I think that's a
block 684625 by 681289
# difficult
severity 684625 wishlist
quit
Hi Nelson,
Nelson A. de Oliveira wrote:
dpkg: error processing
/var/cache/apt/archives/libqtcore4_4%3a4.8.2-2+b1_amd64.deb (--unpack):
trying to overwrite shared '/usr/share/doc/libqtcore4/changelog.Debian.gz',
which is
Hi Raphael,
Raphael Hertzog wrote:
I'm also not sure that there's any nicer solution... this feature has
been there to ease the transition between 1.0 and 3.0 (quilt) mainly.
I was not expecting that people would continue to create new packages
where patches would be pre-applied without the
Hi again,
Jakub Wilk wrote:
* Jonathan Nieder jrnie...@gmail.com, 2012-05-01, 13:22:
I'm not convinced this is worth a dpkg-buildpackage option on its own.
Well, I am.
Good, now our positions are staked out. Hopefully it is possible to
take care of all our needs without interfering
Jakub Wilk wrote:
* Jonathan Nieder jrnie...@gmail.com, 2012-07-02, 09:24:
In case (a), wouldn't you only need to patch one builder (namely
the one you use),
Is this a polite way of saying nobody else but you would use this
feature anyway?
No. I said before that the proposed feature would
Miroslav Suchý wrote:
Negative.
I run update-catalog --update-super. The build is still failing
with the same error.
Ok, thanks. What indicates that this is the same bug?
If it's the same bug, then reopening would be the right thing, but
if I understand http://bugs.debian.org/675613
Guillem Jover wrote:
On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
dpkg-gencontrol makes annoying noise like this:
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which
is not NFS-safe
Please silence it.
But you can silence it yourself, by installing
Hi Sylvestre,
Sylvestre Ledru wrote:
I will be very happy to have help (or a patch) for this bug.
There is a patch at http://bugs.debian.org/638236#10. Anything
more flexible will require infrastructure that does not exist.
What do you think should be done?
Thanks,
Jonathan
--
To
Hi,
Miroslav Suchý wrote:
[Subject: Re: Bug#676122: still not fixed]
Please keep in mind that these appear as emails in a crowded inbox,
so the subject line can be a good place to put valuable context.
I'm still getting the error.
[...]
nsgmls:/etc/sgml/gnome-doc-tools.cat:8:8:E: cannot
'} and -r
$ENV{'HOME'}/.gnupg/trustedkeys.gpg) {
push @exec, --keyring, $ENV{'HOME'}/.gnupg/trustedkeys.gpg;
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
The house style would be to use if ($ENV{'HOME}' and -r ... but I think
the behavior here is better anyway
Marc Haber wrote:
On Thu, May 19, 2011 at 05:05:33PM +0100, Nicholas Bamber wrote:
It would be nice to have --stderr, --stdout and --stdin options to control
the IO of the daemon process.
+1!
Can you say a little more? What daemon, what workaround are you using
instead, can you think of
Joachim Breitner wrote:
An in case this bug now hinders the migration that mehdi set up for
today:
The severity does seem inflated. Luckily it doesn't hinder migration
since it is not a new bug (debbugs shows the version in testing as
already affected).
[...]
(Doesn’t
clone 676874 -1
found 676874 dpkg/1.16.4
reassign -1 ghc 7.4.1-3
found -1 ghc6/6.4-1
retitle -1 ghc: update-alternatives priority out of range
quit
Joachim Breitner wrote:
Am Sonntag, den 10.06.2012, 22:05 +0200 schrieb Guillem Jover:
OTOH I honestly don't see the danger in lowering the
P. J. McDermott wrote:
As mentioned previously by Wookey and Jonathan, staged binary packages
should be marked as such in their control files so they aren't
accidentally uploaded to the archive as complete packages.
To this end, I propose the addition of a new Build-Stage: N (or
similar)
Wookey wrote:
an uploadable
build should always be done against complete build-deps - anything
built against 'staged' packages must be considered 'tainted'.
Sounds good. If I understand correctly:
* dpkg-checkbuilddeps: in a stage-N
retitle 675979 dpkg-buildpackage: --no-unapply-patches should be the default
severity 675979 wishlist
block 675979 by 643043
tags 675979 + wontfix
quit
Santiago Vila wrote:
On Mon, 4 Jun 2012, Jonathan Nieder wrote:
Thanks again for explaining, and sorry for the ramble. I think
Santiago Vila wrote:
Hmm, why do you say that the usual case does not involve modifying
any source files?
Sorry, I was probably unclear. I meant that running debian/rules
binary usually does not cause source files to be modified.
There is one exception I know of: some build systems run
Hi Santiago,
Santiago Vila wrote:
The problem is that at the same time, dpkg-buildpackage seems to
unapply the patches *after* building the package, when the source tree
is full of executables, objects, Makefiles and so on. This is when a
disaster might happen, as some of the patches might
Santiago Vila wrote:
I see it as an inconsistent state which does not make any sense.
As far as I can tell, most people starting from the patches-unapplied
state keep that form in version control. If the build does not
involve modifying any source files (the usual case), they can use
usual
Guillem Jover wrote:
On Sat, 2012-05-26 at 16:03:01 -0500, Jonathan Nieder wrote:
dh_builddeb -- -Zgzip -z9
dpkg-deb: building package `btrfs-tools' in
`../btrfs-tools_0.19+20120328-1_amd64.deb'.
dpkg-deb: building package `btrfs-tools-dbg' in
`../btrfs-tools-dbg_0.19+20120328-1_amd64
. (For
example, maybe the first -Z option should not reset the strategy,
while later ones would? I can imagine the result being very
confusing.)
So I don't want to see this patch applied as is, but perhaps it can
provide some amusement. What do you think?
Signed-off-by: Jonathan Nieder jrnie
Hi,
Guillem Jover wrote:
On Wed, 2012-05-16 at 22:04:30 +0200, Carsten Hey wrote:
dpkg-query --list should add arch suffix to all foreign arch packages.
[...]
single-instanced packages should not really be arch-qualified
because there will always only be a single instance
Would it
Hi Jakub,
Jakub Wilk wrote:
The attached patch adds option to build package multiple times in a
row. This is useful for testing correctness of the clean target.
The patch looks noisy, because I had to indent a few dozen of lines;
but other than that, it adds just a few lines.
If case you
reassign 670607 apt 0.8.15.10
# making the bug more visible to avoid dups
severity 665727 important
forcemerge 665727 670607
quit
Hi Steffen,
Steffen Moeller wrote:
To update a package that is available both as amd64 and i386 on my machine,
dpkg fails as in
[...]
dpkg: error: --configure
jaalto wrote:
It looks like Emacs diff-mode does something to it on save.
That makes sense and is analagous to Guillem's mangling-by-mail-
client guess. Thanks and sorry for the noise. (I was trying to see
if git had started misbehaving in some circumstance.)
Jonathan
--
To UNSUBSCRIBE,
jaalto wrote:
On 2012-04-22 21:52, Guillem Jover wrote:
| but it seems
| to me those are just somewhat bogus anyway, did you manually create
| that patch or maybe it was extracted from a mail client that mangles
| the body (evolution for example)?
It was straight diff from git 1.7.10:
Wookey wrote:
(out of order for convenience)
Attached is a slightly better version which is at least useful enough to
work with.
Thanks. What did you think of Raphaël's idea of the virtual
bootstrap-stage package?
Won't there be need for a Build-Conflicts-Stage1, too?
[...]
I've been
tags 661538 - patch
quit
Gustavo Prado Alkmim wrote:
Patch updated to work on dpkg-1.16.2.
Same comments as before apply.
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
reassign 667843 apt 0.8.15.10
forcemerge 665727 667843
quit
Hi,
Flavio Stanchina wrote:
The plan was to find a couple of packages
that I don't normally use, with a small set of dependencies, and try to
install the i386 version of those packages on amd64. The
Hi Helmut,
Helmut Grohne wrote:
On IRC Steve Langasek pointed out that some part of the difference
resides in the architecture-kernel part. You cannot run a x32 binary on
an arbitrary x86_64 linux kernel
Yes, that's true. The kernel needs CONFIG_X86_X32_ABI set.
There are all sorts of
Hi Peter,
Peter Eisentraut wrote:
The format security flags offered by dpkg-buildflags are
CFLAGS/CXXFLAGS=-Wformat -Wformat-security -Werror=format-security
[...]
Please remove -Wformat-security from the default configuration.
I suspect the intent is to allow
forcemerge 642802 664557
quit
Hi László,
Szalma László wrote:
Upgrading dpkg 1.15.8.12 to dpkg_1.16.1.2_i386.deb breaks all
package installation, because further package install fail with:
tar: --warning=no-timestamp switch unknown (translated back to English)
Yes, this is
Hi,
Wookey wrote:
Cyclic build-dependencies are a big problem in Debian, which make new
ports very difficult, or rebuilds for other reasons such as hardware
optimisations.
Thanks very much for working on this.
I'll let others talk about any thorny design issues. :) I just have
a couple of
found 655411 dpkg/1.16.1.2
# doesn't affect Debian architectures
severity 655411 wishlist
quit
Hi,
dan...@ruoso.com wrote:
The implementation of vsnprintf in the compat library uses and
caches the file descriptor for a temporary file.
If the vsnprintf function is called before a fork, two
[Just forwarding to the correct bug. :)]
---BeginMessage---
Jonathan Nieder jrnie...@gmail.com escreveu:
Yeah, that's true. Maybe it would be worth dropping the
!HAVE_VSNPRINTF fallback altogether, or we could use one of the many
implementations of vsnprintf available under GPL-compatible
Guillem Jover wrote:
I'm committing a fix, that still uses a cached file per process.
Thanks, that makes sense. Sorry, I should think more before throwing
things out like that atfork suggestion.
Thanks and sorry for the noise.
Jonathan
--
To UNSUBSCRIBE, email to
severity 654905 normal
notfound 654905 dpkg/1.15.8.8
found 654905 dpkg/1.16.1.2
merge 642802 654905
quit
Hi Raphael,
Raphael Manfredi wrote:
The following happens when I attempt to install 1.16.1.2:
tar: unrecognized option `--warning=no-timestamp'
Try `tar --help' or `tar --usage' for more
found 620958 dpkg/1.16.1.2
quit
Hi Raphael,
Raphael Manfredi wrote:
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 1682
package 'sudo':
missing architecture
What do I need to do to fix these warnings
Reinstalling sudo (and any other packages that have the missing
Raphael Manfredi wrote:
I wrote a little perl script to do the conversion. God bless you for
using a text file for the database and not some binary format:
---
#!/usr/bin/perl
use strict;
my @lines;
my $seen_arch = 0;
while () {
push (@lines, $_);
Petter Reinholdtsen wrote:
The users of --force-unsafe-io seem to be those that
[...]
In retrospect, introducing --force-unsafe-io was probably a mistake.
Making sure to always call a wrapper function that behaves just like
fsync() but can be disabled would be a maintenance burden for almost
no
Moritz Muehlenhoff wrote:
Is the evaluation order of GCC options properly specified, i.e. is there
a guarantee that -Os overrides the previous -O2
Yes.
(From the manual:
If you use multiple -O options, with or without level
numbers, the last such option is the one that is
Roger Leigh wrote:
On Sun, Nov 13, 2011 at 04:53:07PM -0600, Jonathan Nieder wrote:
Roger Leigh wrote:
New version attached. It includes your changes, plus the
documentation fixes you suggested.
Looks good to me.
Super. If you need anything further, I'll be happy to do more
work
reassign 653810 ibritish-insane
tags 653810 = moreinfo
quit
Hi Mark,
Mark Hobley wrote:
# dpkg -r ibritish-insane
(Reading database ... 109559 files and directories currently installed.)
Removing ibritish-insane ...
/usr/bin/perl:
reassign 653834 xfce4-session 4.8.2-1
quit
Hi Arno,
Arno Schuring wrote:
I noticed the following when doing a regular safe-upgrade from aptitude:
Preparing to replace xfce4-session 4.8.2-1 (using
.../xfce4-session_4.8.2-2_i386.deb) ...
update-alternatives: removing manually selected
Moritz Muehlenhoff wrote:
One recurring issue I found in many rules files is that they're
building with different optimization levels other than O2. In most
cases it's -O3 or -Os.
In such cases, maintainers have to query dpkg-buildflags and substitute
the output with the optimitation level
retitle 649531 dpkg-buildpackage -T: manpage should explain need to run
dpkg-source --before-build first
severity 649531 minor
quit
Raphael Hertzog wrote:
I'm pretty sure we will have people complaining that debuild clean
should also unapply the patches if they have been applied by the
Hi Robert,
Robert Luberda wrote:
While working on my package, I've noticed that the
debuild -nc -b
command no longer works properly - i.e. it recompiles
almost everything instead of just use already built files.
It's because dpkg-source automatically unapplied patches
as a part of the
clone 649521 -1
retitle -1 dpkg-buildpackage -Ttarget should call dpkg-source
--before-build first
quit
Robert Luberda wrote:
I've just came up with another reason why the current behavious is
wrong: let's imagine that maintainer modifies the clean action of
upstream's Makefile (see the
retitle 649521 please add dpkg-buildpackage --no-unapply-patches, to keep
patches applied
severity 649521 wishlist
unarchive 643043
forcemerge 649521 643043
quit
Robert Luberda wrote:
I can even modify my debuild script to do `quilt push -a',
but it won't change the fact that unapplying
Raphael Hertzog wrote:
I have another idea to propose. Create debian/files.new with
O_CREAT|O_EXCL and if it fails with EEXIST, sleep for Xms and try again.
That sounds right to me fwiw. Fortunately dpkg-gencontrol opens
$fileslistfile.new for writing before opening $fileslistfile for
Hi,
Tom Hughes wrote:
[...]
+++ b/scripts/Dpkg/Arch.pm
@@ -66,11 +66,17 @@ my %debarch_to_debtriplet;
return $ENV{DEB_BUILD_ARCH} || get_raw_build_arch();
}
-sub get_gcc_host_gnu_type()
-{
- return $gcc_host_gnu_type if defined $gcc_host_gnu_type;
-
- my
Hi Nicholas,
Nicholas Bamber wrote:
The following change:
* Changed dpkg-source --after-build to automatically unapply patches that it
has applied during --before-build.
causes a problem where the clean rules of the upstream makefile
have been patched to ensure that the clean works.
Jonathan Nieder wrote:
Note that --after-build only unapplies patches when patches were
applied during --before-build (as indicated by
debian/patches/.dpkg-source-applied).
For the confused: I should have said as indicated by
.pc/.dpkg-source-unapply. Sorry for the noise
Nicholas Bamber wrote:
I maintain a package using git. So in the normal state in which I check
stuff in the the patches are unapplied. The upstream makefiles happen to
remake a number of files (to generate random numbers for security).
Obviously I don't want to stop that, but I do want to
Roger Leigh wrote:
I'm a bit busy for the next week (thesis submission), but I'll take
care of all the points you've raised in early October as time allows,
and I'll get an updated patch back to you.
Thanks. Here's another tweak to consider when the time comes.
With the proposed semantics,
Jonathan Nieder wrote:
For example, dpkg itself doesn't seem to have
large-file support.
... in squeeze. Looks like aspects of this were fixed in version
1.16.0. I'm not sure yet why the squeeze dpkg binary here has a
reference to the (32-bit) open() function --- another pitfall
Steve Langasek wrote:
On Sat, Sep 24, 2011 at 03:49:11PM -0500, Jonathan Nieder wrote:
It also has a negative side-effect that Debian would no longer be doing
its part to get
#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64
put directly in upstream's config.h when appropriate
found 629480 dpkg/1.16.1
quit
Roger Leigh wrote:
dpkg currently supports
Build-Depends (arch all and any)
Build-Depends-Indep (arch all)
and the same Build-Conflicts.
This patch adds
Build-Depends-Arch (arch any)
and Build-Conflicts-Arch.
Sorry for the slow reply. Let’s see.
Hi Steffen,
Steffen Moeller wrote:
[Subject: -L and -c/--content should work on multiple .deb files]
Actually, dpkg -L already works with multiple package arguments. ;-)
$ dpkg -c ../build-area/*.deb
dpkg-deb: error: --contents takes exactly one argument
I just do not see why. Would you
Niko Tyni wrote:
From fsync(2):
EBADF fd is not a valid file descriptor open for writing.
*digs* Looks like that description was added between man-pages-1.10
(16-Jan-1996) and man-pages-1.11 (15-Apr-1996). From a look at Linux
0.99.10, I think fsync has just looked at the dirent and
/changelog
@@ -186,6 +186,16 @@ dpkg (1.16.1~jrn) local; urgency=low
* Add new --raw-extract option to dpkg-deb combining --control and
--extract. Closes: #552123
+ [ Jonathan Nieder ]
+ * Defer installing hard links with their final name until the file has
+been fsynced. This avoids
@@ dpkg (1.16.1~jrn) local; urgency=low
* Add new --raw-extract option to dpkg-deb combining --control and
--extract. Closes: #552123
+ [ Jonathan Nieder ]
+ * Defer installing hard links with their final name until the file has
+been fsynced.
+ * Open extracted files for reading
Jonathan Nieder wrote:
To fix that, we should fsync() each file with multiple hard links only
once and then rename all links, so the logic to skip fsync would be no
longer needed.
... and here's a patch on top implementing that.
---
debian/changelog | 13 ++---
src/archives.c
.
Therefore open files for reading, not writing, before fsyncing them
and only fall back to opening for writing if the system requires it.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
debian/changelog |4
src/archives.c | 51 ++-
2
and
--extract. Closes: #552123
+ [ Jonathan Nieder ]
+ * Open extracted files for reading, not writing, in order to fsync() them.
+Otherwise the open can error out when preparing to rename a binary into
+place that has a hard link already in use. Regression introduced in
+1.15.6.1
Michal Suchanek wrote:
It's possible to take some random binary which is likely to be native
(eg. /bin/sh), run ldd on it, and parse the output to determine what
libc is actually used.
But that's the point. Which libc is used depends on the binary.
/bin/sh might be an i386 binary and /bin/ls
Hi,
Raphael Hertzog wrote:
On Tue, 02 Aug 2011, Michal Suchanek wrote:
Also you can have libraries for *both* subarchs and there is no way to
tell on what arch you are actually running, /etc/ld.so.conf will surely
include both.
Sorry I have been a bit quick to close the report. But it's
Raphaël Hertzog wrote:
dpkg-dev: add some common makefile snippets for use in rules files
Hoorah! Thanks, Raphaël.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Raphael Hertzog wrote:
There's no explicit list of value... a trigger name is just that, the name
of a trigger.
Can you suggest a wording that would make it clearer for you because I
don't see what can be improved.
Have you tried reading it as though you were a new packager,
forgetting what
reopen 633406
reassign 633406 libc6
tags 633406 + moreinfo
quit
Raphaël Hertzog wrote:
On Sun, 10 Jul 2011, Jameson Graef Rollins wrote:
Maybe, or I'm just the first person to report it.
If all builds were failing since a month, we would have noticed it. :-)
That's true. But an upgrade
Hi,
Jameson Graef Rollins wrote:
dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by
debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: '').
What does
ldd debian/notmuch/usr/bin/notmuch
say?
Thanks for reporting,
Jonathan
--
To UNSUBSCRIBE, email
Package: dpkg
Version: 1.16.0.3
Severity: minor
Justification: documentation
Files: /usr/share/man/man1/dpkg-trigger.1.gz
Hi,
Today I was looking to make a bug fix that would involve using
dpkg-trigger in a maintainer script directly. So, to the manpage. It
says:
SYNOPSIS
Hi,
Raphael Hertzog wrote:
The easiest solution for now is to purge the packages in config-files
status.
sudo aptitude purge ~c
Make sure you don't need to keep the configuration of the affected
packages though. And for the other affected packages you should just
reinstall them.
Thanks
Roger Leigh wrote:
There's no reason why we can't add such a feature to sbuild. We
could add a build environment hash to allow specific environment
variables to be set when running dpkg-buildpackage (if this is
what you're asking for?).
That also sounds very interesting. I actually meant
1 - 100 of 195 matches
Mail list logo
