Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...
* Ximin Luo [191223 12:58]:
> dpkg and all other debian tools support it right now. It is only reprepro
> with this artifical constraint, which makes it not work for packages that are
> processable by dpkg and other debian tools.
If it is artifical, then it is artifically high. It is 128 times more than
what almost every single package needs and more than five times what the most
absurd package before needed and twice what other tools are said to have
had as limit there. I will increase it in reprepro (and maybe might make it
configurable to some extent), but there will always be an upper limit.
> Are you suggesting that dpkg and other tools have a concrete security problem?
dpkg does not check checksums of index files, so it is likely
uneffected. If apt has no limit then that likely makes some attacks
needlessly easy (though it might have other mitigations in that regard,
and there are less things apt has to care about the way it is typically
used).
Accepting absurd input without confirmation is never a secure way to handle
things, though.
Bernhard R. Link
Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...
* Ximin Luo [191223 09:16]:
> A long-term fix would be to fix this:
>
> line 151-166:
> if (f->size - f->ofs <= 2048) {
> /* Adding code to enlarge the buffer in this case
>* is risky as hard to test properly.
>*
>* Also it is almost certainly caused by some
>* mis-representation of the file or perhaps
>* some attack. Requesting all existing memory in
>* those cases does not sound very useful. */
>
> fprintf(stderr,
> "Error parsing %s line %d: Ridiculous long (>= 256K) control chunk!\n",
> f->filename,
> f->startlinenumber);
> f->failed = true;
> return RET_ERROR;
> }
>
> One reasonable option would be to rip out this code and use whatever dpkg
> itself is using to parse the fields.
As the comment describes, accepting arbitrary long control data would
open all kind of security issues and require quite some hard to properly
test code. Most of the attacks enabled by having longer control chunks
might be able to mitigated some way, but that would require all kind of
different logic that can then have some new bugs.
So allowing arbitrary absurdly long control data is not something I want
to support.
Bernhard R. Link
Bug#926233: copying arch:all across distributions does not reevaluate architectures list
* Christoph Berg [190402 13:09]:
> I think arch:all packages should always live in all architectures for
> a distribution.
It's actually a feature that architecture all packages can be different
in the different architectures. This feature makes it easier to keep
all architectures useable by avoiding architecture all packages
entering an architecture before the architecture any packages of the
same source package are built.
(Though in hindsight it is perhaps not that useful a feature compared to
the annoyance t causes in in more often seen use cases. It is already on
my list of features that might be removed in the future).
As long as there are no architecture any packages from the same source a
reprepro flood $distributionname
should also haved fixed your case.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#923319: #923319: dynalogin: FTBFS with pam >= 1.3
Control: retitle -1 dynalogin: FTBFS with pam >= 1.3
I think this problem is caused by three factors playing together:
- pam dropped support for PAM_STATIC with version 1.3.0
- libtool always compiles everything both as shared and as static
object, even if it is a pam_module that only makes sense as shared
object.
- dynalog is incorrectly defining PAM_STATIC compiled non-PIC.
AFAUI it PAM_STATIC was to be used to include a pam module into libpam
directly. As such it makes no sense for dynalogin to define it.
(Also searching for PAM_STATIC with codesearch.debian.net, usually
pam modules only check for it but do not define it (with very few
exceptions, and those I checked yet shishi and dynalogin have FTBFS
because of it)).
As libtool compiles everything both as static and as shared object
(as you might have some mechanism to also use them statically, and
libtool even have some mechanism where you can simulate loadable
plugins on architectures that only support static linking)
this needless build triggers that code.
But as pam 1.3.0 removed that possibility, it now fails.
I think the proper fix is to simple remove the following three lines:
#ifndef PIC
#define PAM_STATIC
#endif
from pam_dynalogin/pam_dynalogin.c
(Additionally it might be worth checking if setting
pam_dynalogin_la_LIBTOOLFLAGS = -shared
im Makefile.am is possible (not sure, as -shared is a compiler (so
LDFLAGS is too late) and a linker option, but not a generic option).
For a targeted fix, just not defining PAM_STATIC should be enough
and safer.)
(The same problem can also be seen in #924123 with shishi).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#924123: shishi: FTBFS with pam >= 1.3 (was: with gcc 8.3)
Control: retitle -1 shishi: FTBFS with pam >= 1.3
Just some litte fly-by comment looking over RC bugs affecting testing:
I can also reproduce the FTBFS in an unstable chroot (so nothing testing
specific with that build failure).
The log is not really helpful here, as libtool only prints stderr of the
-DPIC compilation, but hides stderr of the non-PIC compilation, while
only the non-PIC compilation fails (the PIC case only produces harmless
warnings).
Unhiding the output of that gcc run gives the following result:
| pam_shishi.c: In function 'pam_sm_authenticate':
| pam_shishi.c:185:48: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
|pam_set_data (pamh, "shishi_setcred_return", (void *) retval, NULL);
| ^
| pam_shishi.c: At top level:
| pam_shishi.c:292:8: error: variable '_pam_shishi_modstruct' has initializer
but incomplete type
| struct pam_module _pam_shishi_modstruct = {
| ^~
| pam_shishi.c:293:3: warning: excess elements in struct initializer
|"pam_shishi",
|^~~~
| pam_shishi.c:293:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:294:3: warning: excess elements in struct initializer
|pam_sm_authenticate,
|^~~
| pam_shishi.c:294:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:295:3: warning: excess elements in struct initializer
|pam_sm_setcred,
|^~
| pam_shishi.c:295:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:296:3: warning: excess elements in struct initializer
|pam_sm_acct_mgmt,
|^~~~
| pam_shishi.c:296:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:297:3: warning: excess elements in struct initializer
|pam_sm_open_session,
|^~~
| pam_shishi.c:297:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:298:3: warning: excess elements in struct initializer
|pam_sm_close_session,
|^~~~
| pam_shishi.c:298:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:299:3: warning: excess elements in struct initializer
|pam_sm_chauthtok
|^~~~
| pam_shishi.c:299:3: note: (near initialization for '_pam_shishi_modstruct')
| pam_shishi.c:292:19: error: storage size of '_pam_shishi_modstruct' isn't
known
| struct pam_module _pam_shishi_modstruct = {
|^
| /usr/include/security/pam_modules.h: In function 'pam_sm_authenticate':
| pam_shishi.c:127:7: warning: ignoring return value of 'asprintf', declared
with attribute warn_unused_result [-Wunused-result]
|asprintf ((char **) [0].msg, "Password for `%s@%s': ",
|^~
|shishi_principal_default (h), shishi_realm_default (h));
|~~~
Looking at the sourcecode of the pam sourcepackage, it seems like suppor
for PAM_STATIC was removed with pam upstream 1.3.0, which hit Debian
with 1.3.1-3 uploaded 2019-02-12.
Taking a look at other pam_modules, they do not define PAM_STATIC
themself under any circumstances but only check it,
while extra/pam_shishi/pam_shishi.c contains:
| #ifndef PIC
| #define PAM_STATIC
| #endif
Looking around at some old pam documentation, my guess is that
PAM_STATIC is only to be used if modules are to be linked into libpam
directly. So I think those three lines above are in error and without
them this build failure might also be fixed.
@vorlon: could you take a look if my understanding of PAM_STATIC is
correct and it is nothing that should be defined if compiled as
an pam module outside of the pam source tree?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#925567: gcc-8-cross: FTBFS: conftest.c:72: undefined reference to `getexecname'
Control: retitle 925567 gcc-8-cross: FTBFS: out of memory allocating 4064 bytes
after a total of 155293664 bytes
Control: notfound 925567 gcc-8-cross/26
Control: fixed 925567 gcc-8-cross/26
The error message the build failed with according to the linked log is actually:
| out of memory allocating 4064 bytes after a total of 155293664 bytes
| cc1plus: out of memory allocating 65536 bytes after a total of 3620864 bytes
(The "undefined reference to `getexecname'" if part of a check an no
error but part of the full config.log)
This bugs still appears on
https://bugs.debian.org/release-critical/other/testing.html, I guess
because bugs.debian.org says:
Found in version gcc-8-cross/26
Fixed in version 26
and thus thinks testing is still affected.
I'm trying to send some notfound and fixed commands to clear that.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#901952: fixing pristine-tar w.r.t. changed tar escaping
* Bernhard R. Link [190330 07:58]:
> I'm looking into #901952 (pristine-tar failing to checkout out old files
> with non-printable unicode characters) and think that might be solved
> with the attached patches, by calling tar with --null and giving it
> a copy of the manifest file that is unescaped and NUL-terminated.
>
> What I haven't looked into yet is whether it will break files
> generated with 1.46, as that the format incompatibly without
> changing the version of the delta (though perhaps that can be
> mitigated by an additional variant at checkout time).
>
> What are your opinions on that? Is this worth trying to get into buster?
Attached version with some small fixes, more tests convering those
changes (and compatibility with previous versions), and an additional
variant run on checkout time to also handle files commited with 1.46.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
>From c26122199aca7c2e08a8597d700d66b8734a3ad6 Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:32:13 +0100
Subject: [PATCH 1/6] revert writing unquoted filenames to manifest
this caused the filename to be unquoted two times,
break with filenames containing newlines
and changed the semantics of manifest files without changing the format version
---
pristine-tar | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pristine-tar b/pristine-tar
index 0fe132e..fe10340 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -664,7 +664,7 @@ sub genmanifest {
chomp;
# ./ or / in the manifest just confuses tar
s/^\.?\/+//;
-print OUT unquote_filename($_) . "\n" if length $_;
+print OUT $_ . "\n" if length $_;
}
close IN;
close OUT;
--
2.20.1
>From bf607f0cd6de861a461eec9f60998950267001ab Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:44:25 +0100
Subject: [PATCH 2/6] change unquoting to match how tar quotes the filenames
Tar also generates octal escape sequences (\123) for some unicode
characters, especially when run in a non-unicode locale like with
LC_ALL=C. Those were not yet unquoted.
Vertical tab was unquoted improperly \x11 instead of \x0b.
If there was a literal backslash in a filename followed by
a character like a, b, n, r, t, v, then tar escapes that to
e.g. \\b. The old unquote the \b it saw in that, which this
fixes.
With those changes the unquote matches what tar uses, which
is a prerequisite for giving tar the unquoted filenames
to work around the behaviour change in tar 1.30.
Compared to versions <= 1.45 this does not change the result
of recreating a tar (so ensures every delta produced by those
is still useable) and only make pristine-tar able to handle
more tarballs. (As unquote in those were only used to create
dummy files for missing files in git, while tar was given
the original manifest file ignoring wrongly unquoted files).
As 1.46 wrote unquoted files to the manifest, this commit
breaks using some delta files created with 1.46. A later
commit will add a compatibility step for those.
---
pristine-tar | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/pristine-tar b/pristine-tar
index fe10340..f6754c8 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -362,15 +362,27 @@ Options:
sub unquote_filename {
my $filename = shift;
- $filename =~ s/\\a/\a/g;
- $filename =~ s/\\b/\b/g;
- $filename =~ s/\\f/\f/g;
- $filename =~ s/\\n/\n/g;
- $filename =~ s/\\r/\r/g;
- $filename =~ s/\\t/\t/g;
- $filename =~ s/\\v/\x11/g;
- $filename =~ s//\\/g;
+ my $unquote_character = sub {
+if (defined $2 and $2 eq "000") {
+ die "filenames with NUL bytes are not supported";
+}
+return pack("C", oct($2)) if defined $2;
+my %map_named_escapes = (
+a => "\a",
+b => "\b",
+f => "\f",
+n => "\n",
+r => "\r",
+t => "\t",
+v => "\x0b",
+"\\" => "\\",
+);
+return $map_named_escapes{$1};
+ };
+ # unquote by calling $unquote_character for each matched group:
+ # (do all in a single run, as the octal sequences might output anything)
+ $filename =~ s/\\([abfnrtv\\])|\\([0-7]{3})/$unquote_character->()/ge;
return $filename;
}
--
2.20.1
>From c4d5609decd4b81285e92950a343b822e21608dc Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:56:52 +0100
Subject: [PATCH 3/6] send manifests file to tar NUL-terminated and unquoted
(Closes: #901952)
tar changed behavior in no longer unescaping filenames with --verbatim-files-from
breaking reading all delta files and handling files with such filenames.
(This also fixes #902115 properly this time).
---
pristine-ta
Bug#901952: fixing pristine-tar w.r.t. changed tar escaping
I'm looking into #901952 (pristine-tar failing to checkout out old files
with non-printable unicode characters) and think that might be solved
with the attached patches, by calling tar with --null and giving it
a copy of the manifest file that is unescaped and NUL-terminated.
What I haven't looked into yet is whether it will break files
generated with 1.46, as that the format incompatibly without
changing the version of the delta (though perhaps that can be
mitigated by an additional variant at checkout time).
What are your opinions on that? Is this worth trying to get into buster?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
>From c26122199aca7c2e08a8597d700d66b8734a3ad6 Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:32:13 +0100
Subject: [PATCH 1/4] revert writing unquoted filenames to manifest
this caused the filename to be unquoted two times,
break with filenames containing newlines
and changed the semantics of manifest files without changing the format version
---
pristine-tar | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pristine-tar b/pristine-tar
index 0fe132e..fe10340 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -664,7 +664,7 @@ sub genmanifest {
chomp;
# ./ or / in the manifest just confuses tar
s/^\.?\/+//;
-print OUT unquote_filename($_) . "\n" if length $_;
+print OUT $_ . "\n" if length $_;
}
close IN;
close OUT;
--
2.20.1
>From 3caa71e47a23eab2b93291960c2e5d54471dd839 Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:44:25 +0100
Subject: [PATCH 2/4] also unquote octal escape sequences returned by tar
Tar also generates octal escape sequences (\123) for some unicode
characters. Those were not yet unquoted.
This also means when such files exist, there are no longer empty
files with the incorrectly unquoted names created.
This change has no effect compared to pristine-tar <= 1.45
as those created files are then ignored as they do not appear
in the manifest file. Though there is a small chance it might
break deltas created with 1.46 with such fules (assuming those
where even able to be checked in with 1.46).
---
pristine-tar | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/pristine-tar b/pristine-tar
index fe10340..82256f5 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -362,15 +362,25 @@ Options:
sub unquote_filename {
my $filename = shift;
- $filename =~ s/\\a/\a/g;
- $filename =~ s/\\b/\b/g;
- $filename =~ s/\\f/\f/g;
- $filename =~ s/\\n/\n/g;
- $filename =~ s/\\r/\r/g;
- $filename =~ s/\\t/\t/g;
- $filename =~ s/\\v/\x11/g;
- $filename =~ s//\\/g;
+ my $unquote_character = sub {
+die "filenames with NUL bytes are not supported" if $2 eq "000";
+return pack("C", oct($2)) if defined $2;
+my %map_named_escapes = (
+a => "\a",
+b => "\b",
+f => "\f",
+n => "\n",
+r => "\r",
+t => "\t",
+v => "\x11",
+"\\" => "\\",
+);
+return $map_named_escapes{$1};
+ };
+ # unquote by calling $unquote_character for each matched group:
+ # (do all in a single run, as the octal sequences might output anything)
+ $filename =~ s/\\([abfnrtv\\])|\\([0-7]{3})/$unquote_character->()/ge;
return $filename;
}
--
2.20.1
>From ce7d2f64abf077c5f91119b53d34f0071e49c5e4 Mon Sep 17 00:00:00 2001
From: "Bernhard R. Link"
Date: Fri, 29 Mar 2019 22:56:52 +0100
Subject: [PATCH 3/4] send manifests file to tar NUL-terminated and unquoted
(Closes: #901952)
tar changed behavior in no longer unescaping filenames with --verbatim-files-from
breaking reading all delta files and handling files with such filenames.
(This also fixes #902115 properly this time).
---
pristine-tar | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/pristine-tar b/pristine-tar
index 82256f5..f6cea05 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -394,12 +394,14 @@ sub recreatetarball {
my @manifest;
open(IN, "<", $manifestfile) || die "$manifestfile: $!";
+ open(OUT, ">", "$tempdir/manifest") || die "$tempdir/manifest: $!";
while () {
chomp;
push @manifest, $_;
+print OUT unquote_filename($_) . pack("C", 0);
}
close IN;
- link($manifestfile, "$tempdir/manifest") || die "link $tempdir/manifest: $!";
+ close OUT;
# The manifest and source should have the same filenames,
# but the manifest probably has all the files under a common
@@ -526,7 +528,7 @@ sub recreatetarball_helper {
0,"--numeric-owner",
"-C", "$tempdir/workdir",
"--no-recursion", "--mode",
-"0644", "--verbatim-files-from",
+"0644", "--null",
"--files-from", "$tempdir/manifest"
);
if (exists $options{tar_format}) {
--
2.20.1
Bug#924831: another ftbfs caused by #807666
The log contains: /usr/include/x86_64-linux-gnu/mpich/mpicxx.h:22:4: error: #error 'Please use the same version of GCC and g++ for compiling MPICH and user MPI programs' so this bugs seems to be another instance of #807666 and should be fixed once the fix for that reaches testing. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#924802: #924802 looks mpicxx related, might be due to #807666
retitle 924802 madness: FTBFS: failure checking for working mpicxx block 924802 807666 thanks Just some quick fly-by observations: While the are errors about pow in the log, those seem to be harmless and properly ignored capability checking. The actual error causing the failure in the log is: -- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS) CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1") Call Stack (most recent call first): /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.13/Modules/FindMPI.cmake:1671 (find_package_handle_standard_args) external/mpi.cmake:6 (find_package) CMakeLists.txt:493 (include) FindMPI.cmake says: # If the find procedure fails for a variable ``MPI__WORKS``, then the settings detected by or passed to # the module did not work and even a simple MPI test program failed to compile. As the build attempt was done using "mpich amd64 3.3-2", most likely this is related to #807666 (as the description of that bug says it makes using mpich with c++ fail, which would fit those symptoms). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#923533: Missing Vcs-* headers
* Axel Beckert [190301 15:39]: > it is confusing that VCS related package has no Vcs-* headers. > > git-dpm though seems to have a Git repository on Salsa at > https://salsa.debian.org/brlink/git-dpm. > > So please add the according Vcs-* headers: > > Vcs-Git: https://salsa.debian.org/brlink/git-dpm.git > Vcs-Browser: https://salsa.debian.org/brlink/git-dpm That repository is a mostly semi-temporary place. I've yet not decided whether it will stay there, or if I will request a group for it (like it had on alioth) or move it to the Debian group. Also after getting disappointed two times (first git.debian.org and then anonscm.debian.org), I lost the believe that those URLs are even supposed to be be valid for a full release lifetime and thus am no longer persuaded that putting that information into the archive is the proper think to do. I'd much rather see some registry where maintainers can put information about the current leading repository whenever that changes and where tools like debcheckout can query it from. > Maybe you also want to add a Homepage header pointing to the latter > URL, too: > > Homepage: https://salsa.debian.org/brlink/git-dpm git-dpm actually had a proper homepage, which also got lost with alioth. I'm still considering where to revive that. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#924355: RM: cuyo/2.0.0brl1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please consider removing cuyo from buster. The version in testing currently is an old forked version that is in no good shape. While there is an ITA for it (#916692), that didn't got to a new upload before the freeze. Also given that it is only some small game there should be no harm in having one Debian release without it. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#916692: #916692
Hi, any news on this one? Given the poor state the package is in, do you have the resources for an upload before buster release? Otherwise I plan to request a removal from testing once the soft freeze started (as autoremoval via #916691 did not happen). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#916692: RFA: cuyo -- Tetris-like game
Package: wnpp Severity: normal I'm planing to drop maintaining cuyo. The upstream license situation is a bit complex and I lack the time to maintain a forked version. I'll request it removed from testing and get the package removed unless someone speaks up and wants to take over the package. The package description is: Cuyo, named after a Spanish relative adjective, shares with tetris that things fall down and how to navigate them. When enough "of the same type" come "together", they explode. The goal of each level is to blow special "stones" away, you start with. But what "of the same type" and "together" means, varies with the levels. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#916691: cuyo -- Not fit for next release
Source: cuyo Severity: critical Pseudo-Bug to keep cuyo out fo testing so it does not end up in the next release. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#849807: gnutls_record_send after incomplete gnutls_handshake sends data unencrypted
Package: libgnutls30
Version: 3.5.7-3
Severity: normal
Tags: security
This bug report is not about wrong behavior if libgnutls is called
correctly but rather about dangerous behaviour if the caller is using
libgnutls incorrectly.
If a handshake has not yet completed (the caller ignoring
gnutls_handshake return code or the caller having a bug in the handling
of GNUTLS_E_AGAIN) then telling libgnutls to send data causes it to send
it unencrypted. Unless there are cases where might be useful, I think a
security relevelant library like libgnutls should rather catch this
mistake and avoid sending stuff unencrypted.
Here's an example:
cat <<'EOF' > example.c
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
static ssize_t sim_write(gnutls_transport_ptr_t session, const void *data,
size_t len) {
bool found = memmem(data, len, "SECRET", 6) != NULL;
printf("Would have written %d bytes%s.\n", (int)len, found?" containing
unencrypted plain-text secret":"");
fflush(stdout);
return len;
}
static ssize_t sim_read(gnutls_transport_ptr_t session, void *data, size_t len)
{
/* simulate non-blocking io with no incoming data arrived yet */
gnutls_transport_set_errno(session, EAGAIN);
fflush(stdout);
return -1;
}
int main() {
gnutls_certificate_credentials_t xcred;
gnutls_session_t session;
int r;
r = gnutls_global_init();
assert (r == GNUTLS_E_SUCCESS);
r = gnutls_certificate_allocate_credentials();
assert (r == GNUTLS_E_SUCCESS);
r = gnutls_init(, GNUTLS_CLIENT);
assert (r == GNUTLS_E_SUCCESS);
r = gnutls_set_default_priority(session);
assert (r == GNUTLS_E_SUCCESS);
r = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, xcred);
assert (r == GNUTLS_E_SUCCESS);
gnutls_session_set_verify_cert(session, "server", 0);
gnutls_transport_set_ptr(session, session);
gnutls_transport_set_push_function(session, sim_write);
gnutls_transport_set_pull_function(session, sim_read);
r = gnutls_handshake(session);
assert (r == GNUTLS_E_AGAIN);
/* ignoring the return code and doing the sending: */
r = gnutls_record_send(session, "SECRET\n", 7);
printf("gnutls_record_send returned %d\n", r);
return 0;
}
EOF
gcc -Wall -O2 -g example.c -lgnutls && ./a.out
It outputs:
Would have written 238 bytes.
Would have written 12 bytes containing unencrypted plain-text secret.
gnutls_record_send returned 7
i.e. the data is send unencrypted (looking at the output one sees a
CLIENT_HELO followed by an APPLICATION_DATA packet with unencrypted
content).
One example where this happens is libldap, which runs into this if
gotten an non-blocking fd (as currently sssd does, see #849756),
causing sssd-ldap to corrently sending passwords unencrypted.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#849773: O: libnss-extrausers
Package: wnpp Severity: normal Hi, I'm hereby orphaning libnss-extrausers, after neglecting it a bit for too long. There is some open bug report with patches that do not apply, and the whole thing got a bit out of date as nss is a moving target (and the nss modules it was forked of are now very different). So if you take it be ready for a large chunk of upstream work. Packaging nss modules is also something of an unsolved problem with multi-arch. (You can multi-arch them, but then people have to make sure to install all the right architectures or get strange errors if they forget), so that is no easy thing either. Might perhaps best to just drop it and use the db backend instead (those are not in another directory, but at least can keep them outside the main files). You can find the package in git at https://anonscm.debian.org/cgit/collab-maint/libnss-extrausers.git/log/?h=debian (including the last upload orphaning it). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#849772: RM: xfm -- ROM; dependencies lost required functionality
Package: ftp.debian.org Severity: normal Please remove xfm from unstable. It wasn't in jessie and isn't that useful anymore since magic dropped the support it needs to identify file types. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#849756: sssd-ldap fails to connect to ldaps:// due to problem with non-blocking socket
Package: sssd-ldap
Version: 1.14.2-1
Severity: serious
Tags: security
Feel free to downgrade the severity, but as this sends passwords in cleartext
(though in a case that I hope
will never work so not that likely to loose important passwords) and makes me
wonder whether this package can
work at all with any ldaps server, I guessed it might be a suitable severity.
This might be the cause of other "[sdap_process_result] (0x0040): ldap_result
error: [Can't contact LDAP server]" bug reports, but as this error message is
so generic, I'm creating a new bug report.
sssd calls ldap_install_tls on a socket without removing and NON_BLOCKING bits
from it.
This seems to be not supported by the current libldap2-4 version, which returns
LDAP_SUCCESS but later fails.
Due to the way libldap fails the request is then send unencrypted (within the
SSL Stream).
Here it usually happens that sssd sends both the "Client Hello" and an
"Application Data" block (containing unencryted ldap_default_bind_dn and
ldap_default_authtok) before the server can even answer with an hello and the
server than sends (depending when the Application data arrives) either with an
Unexpected Message Fatal Alert or an Unencrypted Data Alert. (The ldap Server
log reports TLS handshake errors, while the on the sssd side one gets
"[sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP
server]").
Some example data extracted from the output of wireshark:
Transmission Control Protocol, Src Port: 47911 (47911), Dst Port: 636 (636),
Seq: 1, Ack: 1, Len: 150
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 145
Handshake Protocol: Client Hello
Transmission Control Protocol, Src Port: 47911 (47911), Dst Port: 636 (636),
Seq: 151, Ack: 1, Len: 140
Secure Sockets Layer
TLSv1.2 Record Layer: Application Data Protocol: ldap
Content Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 135
Encrypted Application Data:
30818402010160600201030439636e3d...
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 1, Ack: 151, Len: 0
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 1, Ack: 291, Len: 0
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 1, Ack: 291, Len: 1448
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 53
Handshake Protocol: Server Hello
Transmission Control Protocol, Src Port: 47911 (47911), Dst Port: 636 (636),
Seq: 291, Ack: 1449, Len: 0
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 1449, Ack: 291, Len: 2648
[2 Reassembled TCP Segments (3389 bytes): #29(1390), #31(1999)]
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 3384
Handshake Protocol: Certificate
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 527
Handshake Protocol: Server Key Exchange
Transmission Control Protocol, Src Port: 47911 (47911), Dst Port: 636 (636),
Seq: 291, Ack: 4097, Len: 0
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 4097, Ack: 291, Len: 216
[2 Reassembled TCP Segments (333 bytes): #31(117), #33(216)]
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 328
Handshake Protocol: Certificate Request
Handshake Protocol: Server Hello Done
Transmission Control Protocol, Src Port: 47911 (47911), Dst Port: 636 (636),
Seq: 291, Ack: 4313, Len: 0
Transmission Control Protocol, Src Port: 636 (636), Dst Port: 47911 (47911),
Seq: 4313, Ack: 291, Len: 7
Secure Sockets Layer
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unexpected Message)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
The content of the "Application Data Protocol: ldap" package is plain
non-encrypted data (here a bit redacted):
0``9cn=,cn=X,cn=,ou=X
MYPASWORD___01.3.6.1.4.1.42.2.27.8.5.1
As I can see it the cause of this is that in
../openldap-2.4.44+dfsg/libraries/libldap/tls2.c
the code is:
#ifdef LDAP_USE_NON_BLOCKING_TLS
/*
* Use non-blocking io during SSL Handshake when a timeout is configured
*/
if ( ld->ld_options.ldo_tm_net.tv_sec >= 0 ) {
ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb );
Bug#849564: python3-reportbug: reportbug fails with AttributeError: 'str' object has no attribute 'utils'
Package: python3-reportbug Version: 7.1.1 Control: affects -1 reportbug Running reportbugs fails with: *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Traceback (most recent call last): File "/usr/bin/reportbug", line 2233, in main() File "/usr/bin/reportbug", line 1107, in main return iface.user_interface() File "/usr/bin/reportbug", line 1325, in user_interface fromaddr = utils.get_user_id(self.options.email, self.options.realname, charset) File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 316, in get_user_id addr = email.utils.formataddr((realname, email)) AttributeError: 'str' object has no attribute 'utils' It looks like the parameter email shadows the module name email causing this error. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#847103: reprepro bzip2 lists decompression fails with internal decompressor
* Alberto Donato <alberto.don...@canonical.com> [161205 17:51]:
> I get the following error:
>
> $ reprepro --bunzip2 NONE update precise-security
> Error reading from
> ./lists/update-precise-security_precise-security_main_amd64_Packages.bz2:
> Trailing garbage after compressed data!
> There have been errors!
>
> Lists are downloaded correctly but they don't get decompressed. After that,
> even running with the external decompressor fails:
This looks like the Packages.bz2 file was created by concatenating two
.bz2 files, the later being empty. This is either not supported by
libbz2 directly (and would need some workaround in reprepro), or there
is a bug in libbz2.
BZ2_bzDecompress return BZ_STREAM_END.
In bz2.next_in is another header ("BZh9\027rE8P\220\000\000\000"),
bz2.avail_in is 13. (I.e. directly at the end of the current buffer
reprepro feeds into libbz2 is another BZ2 block/stream, which might
not be complete).
The actual end of the Packages.bz2 file is
000a2170: d8 9d b0 42 5a 68 39 17 72 45 38 50 90 00 00 00 ...BZh9.rE8P
000a2180: 00 .
i.e. the file has one more byte than the 16k bytes block buffer
reprepro uses to feed the data into libbz2.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#820462: reprepro: Please add an --ignore option for --export=never warnings
Control: tags -1 +pending * Frédéric Brière <fbri...@fbriere.net> [161222 15:22]: > Specifying --export=never will trigger a "no index file was exported" > warning, which can result in a slew of messages when performing a batch > of multiple operations (which is the typical case for --export=never). > An --ignore option to silence this warning would be nice. When looking to implement it, I found it was already there (albeit not documented). There is a --export=silent-never which is like --export=never but supresses most warnings. Will be documented in the next version. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#834203: reprepro: Error including .changes: "'*.debian.tar.xz' has the wrong architecture to add it to unstable!"
Control: tags -1 +moreinfo First sorry for the very late reply. * Manuel A. Fernandez Montecelo <m...@debian.org> [161222 14:03]: > Possibly I am doing something wrong and couldn't see any bugs or changes in > the > changelog that might have caused this, but I am pretty sure that this was > working only weeks ago in the same system with approximately the same versions > (it's unstable, so I update often). > > Using "--ignore wrongarchitecture" or "surprisingarch" doesn't help. > > It happens with tar.xz and .gz files, either .debian or original (for native > packages) or also diff.gz. > > includedeb works fine for including the .debs in the .changes files. > > Any clue if there's a problem somewhere or if I am doing something wrong (in > which case, sorry for the noise)? Could you make sure you have "source" in your Architectures: line in conf/distributions? (Without this reprepo thinks you do not want source files in this distribution and thus will complain if those are added.) If you do not want to include sources, please try -T deb option before the checkin. (Or -A yourarchitecture) Bernhard R. Link
Bug#827947: 827947 not a bug
Control: -1 severity wishlist Control: -1 tags +pending I'm downgrading this to wishlist, as the output does not break processincoming but some other script is confused by processincoming outputing this information. (And as it is an example script it can easily be edited to remove the line after copying it). Nevertheless I prefer scripts not being verbose by default, too, to it will be changed in the next version. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#843402: Fwd: reprepro_5.0.0-1_amd64.changes ACCEPTED into experimental
Hi, I'd appreciate if those invovled could test the version of reprepro currently in experimental. I plan to upload 5.0.1 to unstable with some additional smaller things to unstable tomorrow (Friday) evening (UTC). Thanks in advance, Bernhard R. Link - Forwarded message from Debian FTP Masters <ftpmas...@ftp-master.debian.org> - From: Debian FTP Masters <ftpmas...@ftp-master.debian.org> Date: Wed, 21 Dec 2016 23:21:44 + To: "Bernhard R. Link" <brl...@debian.org> X-local-part: brl+debian+redirect Subject: reprepro_5.0.0-1_amd64.changes ACCEPTED into experimental Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Dec 2016 21:22:52 +0100 Source: reprepro Binary: reprepro Architecture: source amd64 Version: 5.0.0-1 Distribution: experimental Urgency: medium Maintainer: Bernhard R. Link <brl...@debian.org> Changed-By: Bernhard R. Link <brl...@debian.org> Description: reprepro - Debian package repository producer Closes: 843402 Changes: reprepro (5.0.0-1) experimental; urgency=medium . * new release - drop support for apt-methods of squeeze and before - some code-refactoring (to prepare for future changes) - add support for .buildinfo in .changes files (Closes: #843402) * change debhelper compatibility level to 9 * remove jessie gnupg2 depencency workarounds * change build-dependency from libgpgme11-dev to libgpgme-dev * enable hardening compiler flags, drop support for ancient dpkg-dev Checksums-Sha1: 4cbb1544a5b686b65894dcb2518477cfb2f17472 1963 reprepro_5.0.0-1.dsc 33a27bae3a1acbf387c1de1e6209a51e55c74b0d 672057 reprepro_5.0.0.orig.tar.gz 6d54a01b3b92faed524195a795e4282cc814f0e2 18688 reprepro_5.0.0-1.debian.tar.xz eda840235f2dfcc7dcc0021b823eb0dbced2d77b 997170 reprepro-dbgsym_5.0.0-1_amd64.deb 049d7bef980e00c4321681c02ee7ffe844bad3cd 5170 reprepro_5.0.0-1_amd64.buildinfo 9900a8f634658634b15a0c306c355477ee1d043e 450256 reprepro_5.0.0-1_amd64.deb Checksums-Sha256: 867dda4666e549dead2189013b60b4dcc8e7484ecc99d4a6443ab8d511390d02 1963 reprepro_5.0.0-1.dsc da7c0dbdd80afb1b49ea6740448bec1a7e7ab10e05520c33a9b11f5b8ca49f0b 672057 reprepro_5.0.0.orig.tar.gz 9c987e71583242c15de3067fd669897b39e5e20832cb6b349c06ee6fd3b8af90 18688 reprepro_5.0.0-1.debian.tar.xz dfa62606508970123e705f08f8a73e717d912578284320f10a8c7bbe0827 997170 reprepro-dbgsym_5.0.0-1_amd64.deb 6bf03ae96e55d24411c559ff8d5a322694774fea50b51e9b3db212d8bb1e3fb6 5170 reprepro_5.0.0-1_amd64.buildinfo 2b2b17498ff32ebb48ec10b9c21d09e505c3c7f99f3d343e0233cfccd8396296 450256 reprepro_5.0.0-1_amd64.deb Files: 18285327421dc384cb540f25f36fcd5b 1963 utils extra reprepro_5.0.0-1.dsc 7d13c1af92e95aeeb6330112af662cf9 672057 utils extra reprepro_5.0.0.orig.tar.gz b21dade6e8c4354a128f75d7f0d37f4b 18688 utils extra reprepro_5.0.0-1.debian.tar.xz 063145457cda9a0940dd49ab140ce113 997170 debug extra reprepro-dbgsym_5.0.0-1_amd64.deb ec9d3fe058662fd95630b766da01e2f0 5170 utils extra reprepro_5.0.0-1_amd64.buildinfo d4651302bdfc2f4f431c14adec8e8634 450256 utils extra reprepro_5.0.0-1_amd64.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEER2LYZQQfdf9pay9D6ZZIQUY/gV8FAlhbB+0SHGJybGlua0Bk ZWJpYW4ub3JnAAoJEOmWSEFGP4Ffej4P/iBgwH92AgpbHscBk9PSuQsoJG6xBy2a OzW/iYgCbl4TwL9qm9O0gDDlZOoNMC2CMqRL4kaFKK9Sq9I8yUBIuvoaGJwQvCC2 6ULB80A6vaK1NRpVqO1z7X+Mj2vMG25qDNdD2xImj7fsz6GXsMEcYQbS18wTz5Br 0oT4Q9cpiLmhYggHWNIaYddXTxh04qOhws04JfTJ3oXHz6Bwe5yVE2zPbMNHb4Dn x8xhCyap6YAOZhfGfyntAX1E0tt4nrqD25bD53LzAUcDjiOkK1lGFXCIkBb/I6B+ qoXKZc2kBhaHCUU8TS+EQbLe/91V5O4u2fpN80Gq3gZcdn2ucJ6ikVTUGfzXl8vo c+EDzMmyELcxqnDvzlVqflL87QMc5Fihiy4Q2n7aUdiceq2OffedxCopioGUW+HT BpYbfoLFXxpD/oh9L638SK+ckSuP/AEUD1G1S2zGuR0EGAF9/1Wd13kIHlA0kqvh 1rr9VsgDNVLSVTufkvIbUzr0+7kTznC7xy+OvdJUpAMyXOukwuqnchr4XxirOrCs xNFN6nco6y+Smii0P+3nODQq6p0H6lw4GBzODN1729OLvjMT6/kQHrtqjz0ajzQ8 1Rqz5l6EKcbb71H4rtnVPf4xLqfTFsJPyJxJL+IYKo42x0gmGiZnp8zwhJCXhyBo UV4pOlzS6uH5 =7MEj -END PGP SIGNATURE- Thank you for your contribution to Debian. - End forwarded message - -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#789608: reprepro: no passphrase prompt - possible cause
Control: tags -1 +pending First a sory for the late reply. * Paul Casto <pca...@bricata.com> [161221 21:45]: > Observed the same problem - attempted to run `reprepro export` and was not > prompted for gpg passphrase. > Conditions were similar to ones reported above. > While not explicitly stated above, only pinentry-curses was listed, so > assuming that this is a non X11 system. > > Banged my head for a bit, and then discovered this post > https://bbs.archlinux.org/viewtopic.php?id=138546 > > I didn't follow that back through to find the status of the bug, but... > > I did lead me down the path of discovering that this is an issue when running > reprepro under an account where an su is involved. > If I log in directly as the user that will be running reprepro (and has the > keys), then it works - ncurses prompt for passphrase. > If I log in as another user, and then su to the user that is running reprepro > (and has the keys) it does not. With the symptoms as described above. For pinentry that is to be expected. AFAIUI it tries to access /dev/tty and that belongs to the logged in user and does not allow anyone else to write there. The next version of reprepro will add the following sentence in the manpage of --ask-passphrase: (With current versions of gnupg you need to set 'pinentry-mode loopback' in your .gnupg/gpg.conf file to use '--ask-passphrase'. Without that option gnupg uses the much safer and recommended pinentry instead). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#824521: [reprepro] Please add dep-11 support
I'd suggest to report a bug against apt for this. (Asking for files not advertised and generating such an output is definitely a bug in apt, no matter wether reprepro supports to generate those files or not). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#823629: reprepro: Please provide a way to compact references.db after some of its content has been freed
* intrig...@debian.org <intrig...@debian.org> [160506 22:00]: > for Tails we have a system that uses reprepro snapshots intensively > (basically, a large subset of the Debian archive is snapshot'ed four > times a day). And then, we use _removereferences (+ manually removing > the corresponding directory in dists/) to free the snapshots we don't > need anymore. > > But despite the cleanup operation (_removereferences), it seems that > references.db keeps growing. As a result, some operations become very > slow unless there's enough memory available to keep that file in the > disk cache. > > FYI, we're talking of a (currently) 5.4 GiB references.db here. > > I'm sure that there must be a good reason (such as optimizing I/O) for > the current behavior, and that's fine with me. But would it be > possible to have one extra operation, that one could run from time to > time, and that compacts references.db so that it uses only the disk > space (and thus, the in-memory disk cache) that it needs? You might want to start with checking the stats of that file to see if there is some libdb corruption in there or only no space freed. db*_verify db/references.db db*_stats -d db/references.db -s references (With the tools from the db*-util package matching the libdb version your reprepro binary is linked against). > And, just in case I find someone ready to implement it: any pointer to > where and how it could be done? It's a pity that libdb does not come with some dbX.Y_compact utility. For a short hot-fix you might try to use db*_dump and db*_load to create a copy of the database. If you are willing to lose all the snapshot-information, just deleting the references.db file and running "reprepro rereference" will also create a file with all but the snapshot references in them. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#820867: reprepro: Please allow to apply overrides on already installed packages
* Raphaël Hertzog <hert...@debian.org> [160413 11:21]: > For some reasons it seems that "update" + "pull" rules do not properly > transfer the priority... for instance I have the emdebian-archive-keyring > which is priority extra in Debian's Packages files but priority important > in the .deb itself. And it ended up as priority important in the Kali > archive... I didn't yet have the time to try to reproduce this part. (Current behaviour should be that reprepro get the priority the time the specific version of a package was added to a specific distribution. If that happend due to "update" or "pull" it should get the Priority of the source distribution (and only the one from the file if the file is added locally via include*/processincoming). Though if the Priority changed in the source distribution, reprepro will currently not update to local one (unless there is a new version of the package)). > Now I want to fix this priority so I added the "DebOverride" directive > to conf/distributions but the next "export" does not apply this updated > priority. Instead I have to remove the package and add it back to get > it applied. > > It would be nice if the overrides could either be automatically applied > or at least have a command to apply them without requiring such trickery. There is "reprepro reoverride" for this part. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#820460: reprepro: Omitting Release from DebIndices still generates that file
package reprepro tags 820460 +moreinfo thanks * Frédéric Brière <fbri...@fbriere.net> [160408 18:51]: > The documentation for DebIndices states that omitting the optional > Release filename will result in no file being generated. This does not > appear to work for me; Release files are still generated, despite having > "DebIndices: Packages . .gz .xz" in my configuration. That file should no longer be generated, but reprepro will not delete an old file if it is still there. Could you check if it is newly generated or just the old file? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Bug#798478: ratpoison: diff for NMU version 1.4.8-1.1
* Luca Falavigna <dktrkr...@debian.org> [151226 15:42]:
> I've prepared an NMU for ratpoison (versioned as 1.4.8-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
Thanks.
Bernhard R. Link
Bug#480576: [debhelper-devel] Bug#480576: debhelper and dh-autoreconf
* Wookey woo...@wookware.org [150612 19:00]: I would second the opinion that running dh-autoreconf by default is something that should be expected to work. In practice it does work except for old and languishing packages that have very old autofoo: those need some updates. Often very simple ones, but in a few cases deeper ones. See (https://wiki.debian.org/Autoreconf for useful info) There is not only the situation with current autoconf/automake. The question is also if this is enabled what will happen in the future. While autoconf/automake got a very long way in no longer breaking packages every so often, the incompatible changes for tests is not so long ago (and happened after everyone already claimed those problems are a think from the past), that this cannot be ruled out to cause problems in the future. So I would like to clarify whether there is a plan to do this in debhelper for level 10 or not, as mooted in this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744915#25 Maintainers (at least one) seem to be expecting it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788321#20 but perhaps that is premature? Is the situation 'yes, if someone sends patches', or 'yes, it's underway', or 'maybe, sometime', or 'no never, it's a dumb idea' (or something else)? In my personal opinion running autoreconf at build time is a derivitation from upstream at least on the same level as having some patch is. There is nothing inherently bad about derivating from upstream or applying patches, but I think there should be at least a good reason to. Then there is also the problem that as autoreconf is supposed to be run by people doing upstream work, there is no built-in mechanism to clean up after that. (There is make maintainer-clean, but last I looked it semantics were excplitely something like whatever the maintainer thinks reasonable). This leads those gross hacks dh-autorconf does to clean up. (And then even so strange clean up that does not clean but copy files back and forth last I looked). That said it might be a good idea to integrate some solution for this deeper with debhelper and at least warn in some cases when this is not used. (I guess looking for libtool or even usage of the 'canonical' variables (detectable by having guess.guess/config.sub)) Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781077: mark 781077 pending
package debhelper
tags 781077 + pending
thanks
* brl...@debian.org brl...@debian.org [150405 02:29]:
This is an automated email from the git hooks/post-receive script.
brlink pushed a commit to branch master
in repository debhelper.
commit 40656c02c319461e65879c2dba7475b2f288b578
Author: Bernhard R. Link brl...@debian.org
Date: Sat Apr 4 19:04:41 2015 +0200
dh_installwm: call after dh_link in dh call sequence, error out in compat
10 if there is no man page
Move dh_installwm after dh_link, so that a manpage created by dh_link
can be found.
Also error out in compat 10 if no manpage is found.
---
debhelper.pod| 5 +
debian/changelog | 2 ++
dh | 2 +-
dh_installwm | 4
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/debhelper.pod b/debhelper.pod
index 2c33aab..1e28e60 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -565,6 +565,11 @@ Bdh_installdeb no longer installs a maintainer-provided
debian/Ipackage.shlibs file. This is now done by Bdh_makeshlibs
instead.
+=item -
+
+Bdh_installwm refuses to create a broken package if no man page
+can be found (required to register for the x-window-manager alternative).
+
=back
=back
diff --git a/debian/changelog b/debian/changelog
index a00b8be..2d24a46 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -92,6 +92,8 @@ debhelper (9.20150101.1) UNRELEASED; urgency=medium
--disable-silent-rules (otherwise). (Closes: #551463, #680686)
* dh_compress: exclude .xz .lzma and .lz files from compression
(Closes: #778927)
+ * dh_installwm: call by dh after dh_link (Closes: #781077),
+error out in compat 10 if no man page found
[ Jason Pleau ]
* dh_installchangelogs: Add CHANGES.md to the list of common changelog
diff --git a/dh b/dh
index eceb62e..93111da 100755
--- a/dh
+++ b/dh
@@ -381,7 +381,6 @@ my @i = qw{
dh_installpam
dh_installppp
dh_installudev
- dh_installwm
dh_installgsettings
dh_bugfiles
dh_ucf
@@ -392,6 +391,7 @@ my @i = qw{
dh_usrlocal
dh_link
+ dh_installwm
dh_installxfonts
dh_compress
dh_fixperms
diff --git a/dh_installwm b/dh_installwm
index b09bc3a..8fa0253 100755
--- a/dh_installwm
+++ b/dh_installwm
@@ -102,6 +102,10 @@ WM: foreach my $wm (@wm) {
}
}
}
+ if (! compat(9)) {
+ error(no manpage found (creating an
x-window-manager alternative requires a slave symlink for the manpage));
+ }
+ # Reaching this code means a broken package will be
produced.
autoscript($package,postinst,postinst-wm-noman,s:#WM#:$wm:;s/#PRIORITY#/$dh{PRIORITY}/,);
}
}
--
Alioth's /usr/local/bin/git-commit-notice on
/srv/git.debian.org/git/debhelper/debhelper.git
___
debhelper-devel mailing list
debhelper-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debhelper-devel
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778927: [debhelper-devel] Bug#778927: dh_compress: Please do not compress xz compressed files
Control: tags -1 + pending
* Andreas Tille ti...@debian.org [150221 22:15]:
This result is surprising since bz2 compressed files are not gzipped by
dh_compress. So please do not compress .xz files.
Should be fixed by the following commit, pushed to master:
diff --git a/debian/changelog b/debian/changelog
index b80d1f3..1105d73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -82,6 +82,8 @@ debhelper (9.20150101.1) UNRELEASED; urgency=medium
* autoconf is always passed one of
--enable-silent-rules (if DH_QUIET is set) or
--disable-silent-rules (otherwise). (Closes: #551463, #680686)
+ * dh_compress: exclude .xz .lzma and .lz files from compression
+(Closes: #778927)
-- Niels Thykier ni...@thykier.net Thu, 01 Jan 2015 17:24:38 +0100
diff --git a/dh_compress b/dh_compress
index 53a6bb1..bbd5847 100755
--- a/dh_compress
+++ b/dh_compress
@@ -121,6 +121,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
! -iname *.epub ! -iname *.jar ! -iname
*.zip \\
! -iname *.odg ! -iname *.odp ! -iname
*.odt \\
! -iname .htaccess ! -iname *.css \\
+ ! -iname *.xz ! -iname *.lz ! -iname
*.lzma \\
! -iname *.svg ! -iname *.svgz ! -iname
*.js \\
! -name index.sgml ! -name objects.inv !
-name *.map \\
! -name copyright 2/dev/null || true;
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551463: tagging 551463, tagging 680686, tagging 639168, tagging 680687 pending
limit source debhelper tags 551463 + pending tags 680686 + pending tags 639168 + pending tags 680687 + pending thanks commited to git: * add DH_QUIET environment variable to make things more silent * dh: don't output commands to run if DH_QUIET is set * buildsystems print commands unless DH_QUIET is set (Closes: #639168, * #680687) * autoconf is always passed one of --enable-silent-rules (if DH_QUIET is set) or --disable-silent-rules (otherwise). (Closes: #551463, #680686) Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#155931: Implemented permissions exceptions file
package debhelper tags 155931 - patch thanks That patch needs some improvements: - chown after chmod will revert some permissions (like suid) - no error handling: lines with exactly three words in in will be silently ignored Possible further improvements: - globbing (can't use filedoublearray's but would needs its own just like dh_install) - input validation (for permissions? is there a way to avoid people using dynamic user/group names here?) Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774227: busybox-static: execs applets when chrooting
Package: busybox-static Version: 1:1.22.0-14 Severity: important Tags: patch #599101 is back, at least in busybox-static (I have not not tested the other one): Things like chroot /target dpkg ... do not call dpkg but instead call busybox's internal command (which leads to quite hard to debug error messages trying to run debootstrap). To fix it the same patch as before is needed, which is also the end of debian/patches/applets-fallback.patch.sav: --- a/coreutils/chroot.c +++ b/coreutils/chroot.c @@ -41,5 +41,7 @@ int chroot_main(int argc UNUSED_PARAM, c /*argv[2] = NULL; - already is */ } - BB_EXECVP_or_die(argv); + execvp(argv[0], argv); + xfunc_error_retval = (errno == ENOENT) ? 127 : 126; + bb_perror_msg_and_die(can't execute '%s', argv[0]); } Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759886: [debhelper-devel] Bug#759886: debhelper: please make mtimes of packaged files deterministic
* Jérémy Bobbio lu...@debian.org [141228 22:06]: Joey Hess: Jérémy Bobbio wrote: Joey Hess: My other idea is to make dh_fixmtimes set something that a later command (eg, dh_builddeb) could use and warn if it was not run. Maybe it should be integrated to dh_builddeb, then? I don't think it belongs in dh_builddeb directly. Unfortunately, while trying to understand why r-cran-gbm was not building reproducibly [1], I noticed that there might be a compelling reason to merge dh_fixmtimes in dh_builddeb. When DH_ALWAYS_EXCLUDE is specified, dh_builddeb might delete files. When this happens, parent directories get their mtime updated, reverting dh_fixmtimes work. So the ideal moment to set deterministic mtimes is after that pass. Which means integrating the find+xargs+touch in dh_builddeb… May I suggest to just duplicate the DH_ALWAYS_EXCLUDE handling in dh_fixmtimes for the time being? If they are already removed then dh_builddeb should not do any new harm and this way you keep more control over dh_fixmtimes so there is less chances debhelper will ship outdated code. Those two can then still later be merged if that still looks sensible then. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773965: binNMUed db5.3 FTBFS due to --link-doc check
* Helmut Grohne hel...@subdivi.de [141226 11:06]: My attempt to cross build db5.3 for x32 from amd64 failed. A log is attached. The relevant bits are: | dh_installdocs -pdb5.3-doc -plibdb5.3-java | dh_installdocs: No packages to build. | dh_installdocs --remaining-packages --link-doc=libdb5.3 | dh_installdocs: WARNING: --link-doc between architecture all and not all packages breaks binNMUs | dh_installdocs: Aborting build as this is a binNMU (leading to a broken package) | debian/rules:250: recipe for target 'override_dh_installdocs' failed As you can see, this is not specific to cross building. Looking closer at the db5.3 source package one can see that it only builds two arch:all packages. Those are db5.3-doc and libdb5.3-java. Given the --remaining-packages switch in the second dh_installdocs invocation, it does not cover any arch:all packages and thus should not error out. In theory, debhelper does cover for --remaining-packages in dh_installdocs. I do not see why this mechanism does not work for db5.3. I hope that someone can figure this out. The problem seems to be 97993b514bfbcc84c213e9e5d68c1b1c3a833ce7 (the commit introducing INTERNAL_EXCL_DOPACKAGES). With that commit reverted it work as far as my limited tests concluded. I think the key here is that the binary-arch is called, which causes debhelper to limit everything to architecture dependent packages. As above commit causes dh_installdoc --link-doc to specifically also look at packages excluded because of this it looks at the packages thus causes this false positive. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769577: how to configure reprepro to make repository of what is installed on host
* Richard Betham rich...@betham.org.uk [141202 19:48]: Thank you very much for your e-mail, It is useful to know that I must remove the : and whatever follows, from the end of the package name, so that it will be suitable input for reprepro FilterList. I guess that still needs to be added to the documentation. (Those :architecture are a relatively new addition to the dpkg --get-selections output format added due to multi-arch support) I have got my Makefile script file to work well enough to generate an image for a cdrom which seems to be acceptable to apt-cdrom, and to apt-get. However, when I run my script again, trying to use the cdrom as one of the sources, reprepro generates an error message and aborts. The text of the error messages is copied into the attached file called make.op.txt I have tried various variants of the update file, using: Method: cdrom:[...] Method: cdrom://[...] Method: cdrom:[...] I did not put ..., I put Debian~Wheezy~in~part~as~at~2014-11-29+21:20:36. I prefer to have spaces in the name, but that seemed to cause trouble. I attach copies of various files which seem relevant. Please advise me of the correct format for the line in the file conf/updates, which starts: Method: cdrom:... I haven't yet used the cdrom method with reprepro, so I am a bit of a loss what the correct syntax is. Adding enough verbosity (I think you need several -V to get to those details) you can see what reprepro gives the apt cdrom method. I don't knwow that format the apt method expects exactly, but doc/method.dbk in apt source package lists some example URLs: file:/var/mirrors/debian/ ftp://ftp.debian.org/debian ftp://jgg:MooCow@localhost:21/debian nfs://bigred/var/mirrors/debian rsync://debian.midco.net/debian cdrom:Debian 2.0r1 Disk 1/ so I guess it might be a single colon without any other additions (though I do not know how current that example is). Perhaps it is easier to just mount the .iso files somewhere and just use the file:/ method. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768046: reprepro: 'includedsc' fails for native packages with 'debian/' being a symlink
* Stephan Sürken abs...@debian.org [141104 14:39]: with a Debian native package having a setup like (for example) so debian - debian-wheezy debian-squeeze/ debian-wheezy/ , i.e., 'debian/' being a symlink, reprepro fails to find 'debian/control', and finally fails with --- No section and no priority for 'PACKAGE', skipping. There have been errors! --- This is due to 'sourceextraction.c: parse_tarfile()', which iterates through all archive entries, and will never find debian/control as archive member string. I.e., iterating of libarchive entries, you only get debian debian-wheezy/control in this case. Maybe some extra code when debian/ is a symlink may help here, in that loop. Of course this (i.e., using a symlink here) is not a standard or desireable setup; however, other Debian tools just work find with such a setup, and I don't know of any documented restrictions -- so I think this should be fixed in reprepro. To quote the manpage: Note that .dsc files do not contain section or priority, but the Sources.gz file needs them. reprepro tries to parse .diff and .tar files for it, but is only able to resolve easy cases. If reprepro fails to extract those automatically, you have to either specify a DscOverride or give them via -S and -P i.e. extracting the section and priority from the source package is a let's try efford, and there are other cases where I decided reprepro will just give up (like some cases where debian/control is both in .orig.tar.gz and .diff.gz). I'll have a look. I guess the case where the symlink is before the directory might be easy to add, while the reverse case will likely fall in the not easily done with sequential parsing, thus not supported category. Sorry. There are three workarounds: - As the manpage says, name section or priority with -S and/or -P or via a override file. - Use include with the .changes file. A .changes file usually contains section and priority for the source, so reprepro - for private repositories or packages, there is a non-standard (and I guess also undocumented) extension reprepro has: If a .dsc contains Section: or Priority: it will use those values instead of looking further. (Not sure what the best way is to get them there, in specific workflows adding a XS-Section: in addition to the Section: in the debian/control might get this. Only suiteable for private packages of course). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768015: reprepro fails on 'uniform compressed' dpkg binary packages
retitle 768015 reprepro: better error message if processing .deb file needs a missing uncompressor * Daniel Baumann daniel.baum...@progress-technologies.net [141104 19:39]: and now i found out that the problem is that, when using lzip, depending on using lunzip and that fails if it's not installed (people are using lzip -d, not lunzip anymore).. so the only remaining thing is that it would be nice to have a more accurate error message when the reprepro uncompressor is not installed/available. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769981: reprepro complaining about 'all' architecture
* Michael P. Soulier msoul...@digitaltorque.ca [141119 20:51]: On Nov 19, 2014, at 12:45 PM, Debian Bug Tracking System ow...@bugs.debian.org wrote: - delete all from all Architecture: lines in conf/distributions - run reprepro --delete clearvanished (reprepro should tell you to do this if you try to run it) So for my packages that will run on any platform, should they be architecture “any” then? Your package is Architecture all. If you include it, reprepro will by default add it to every architecture. So for an architecture any package the split is done at build time: debian/control Architecture: any Binaries generated by the different builds: _amd64.deb _i386.deb _deb put into: binary-amd64/Packages, binary-i386/Packages, binary-.../Packages while for an architecture all package the split is done when including it into a repository: debian/control Architecture: any Binaries generated by the builds: _all.deb put into: binary-amd64/Packages, binary-i386/Packages, binary-.../Packages Hope that clears it up, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769577: how to configure reprepro to make repository of what is installed on host
* Richard Betham rich...@betham.org.uk [141114 18:06]: I wish to be able, conveniently to make a repository containing the packages which: + are installed on my computer; and + are not included in the Official DVD, (or are a later version). I prefer the new repository to contain the versions of packages which are installed in my computer. These have always been tested, even if not much. I wish to copy the result to a CD-R, or to a DVD, which should be acceptable to apt-cdrom, and to apt-get. (apt-move used to do almost this.) It is not obvious from the documentation of reprepro, how to do this. I have started trying to make a script file to do this. Does anybody else want it? Has anybody already written one? Is there an easy way to make a repository containing only installed packages? To get the list of installed packages suitable for reprepro, do: dpkg --get-selections | sed -e 's/:[^ \t]*//' conf/mylist.lst This you can then give to reprepro in a conf/updates block listing the source where you get your packages and add something like FilterList: purge mylist.lst to make that update rule pull only package that you have installed. Removing newer packages than some given set is not that easy AFAIK. (There is support for the other way around: Doing a mirror with only packages from the DVD that you do not have a newer version around). If you compare the versions yourself and know which packages not to include, you can add create another list with packagename purge in each lines and give that to FilterList to exclude them: FilterList: purge mylist.lst without.lst Hope that helps, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747141: debhelper: dh_installdocs --link-doc forces source-version dependencies (was: Re: Bug#766795: afterstep not binnmu safe and not installable in sid)
* Axel Beckert a...@debian.org [141109 17:33]:
I suspect that's currently the only solution. zsh is affected, too:
Depends: zsh-common (= 5.0.7-3), zsh-common (= 5.0.7-3+b1), [...]
debian/control says:
Depends: zsh-common (= ${source:Version}),
${misc:Depends},
[...]
So it may be worth reinvestigating this issue instead of removing
${misc:Depends} from tons of packages (and causing lintian warnings
about that) and requesting freeze exceptions for all these uploads. (I
expected hundreds of them, zsh and afterstep only being some
examples.)
Any advice by the release team on this issue is appreciated.
The problem is that removing the misc:Depends just replaces one bug with
another one: The packages created that way will not include a changelog
for the binnmu.
Packages using --link-doc to link from an architecture any[1] to an
architecture all package are not really bin-nmuable. So the only
possiblities I see are:
- keep the way it is which causes those packages generate uninstallable
packages if binnmu'd [2]
- remove the dependencies (in the packages or debhelper), causing
binnmu'd packages to have no changelog of the binnmu.
- try to add some bin-nmu and affectedness detection (with the danger of
false positives) to debhelper to make thsoe packages fail to build
if binnmu'd so that no uninstallable packages are generated.
- change the affected packages in question to not use --link-doc.
Bernhard R. Link
[1] Or rather anything but all.
[2] What is the status if multi-arch and bin-nmu, does being bin-nmu'd
still break multi-arch packages?
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747141: [debhelper-devel] Bug#747141: debhelper: dh_installdocs --link-doc forces source-version dependencies (was: Re: Bug#766795: afterstep not binnmu safe and not installable in sid)
* Bernhard R. Link brl...@debian.org [141109 19:45]: - keep the way it is which causes those packages generate uninstallable packages if binnmu'd [2] I forgot to mention that the smalles possible change to bring any package that became uninstallable by binNMU back to working state is a MU or source-full NMU (other changes are only needed if one wants to fix the problem that another binNMU breaks them again). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763569: git-dpm generates incorrect patches with the ident gitattribute
* Sam Hartman hartm...@debian.org [141109 19:15]: I've been working with this a bit more. One possibility would be to add an export option or some git dpm option to generate a dsc or a tree that could be used to generate a dsc. At that point you could either add the changes as a final patch or unapply them. Being able to just call dpkg-buildpackage in a checkout of the git repository with needing to call git-dpm at all is quite an import feature of git-dpm for me. Besides: how would that help if the problem is that the patches generated do not fit the files? I think there are only two posibilities: - not using git-format-patch. Perhaps needed in the long term anyway to get nicer patch headers. But then I'm not sure that can be easily fixed using any other invocation of git's diff machinery (and not running in other problems on the way). And using non-git diff on trees exported with git to generate the patches sounds like no nice way to be heading. - fix the information in git. I fear in the end the only feasible solution is to document that one needs to do an git-dpm import-new-upstream with --exclude .gitattribute here. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747141: debhelper: dh_installdocs --link-doc breaks binNMUs
I guess the easiest thing to do is simply to warn and in future compat
levels to error out with something like:
diff --git a/dh_installdocs b/dh_installdocs
index 3eefcdf..4ccd373 100755
--- a/dh_installdocs
+++ b/dh_installdocs
@@ -166,6 +166,14 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
my $link_doc=($dh{LINK_DOC} $dh{LINK_DOC} ne $package);
if ($link_doc) {
+ # TODO: does this need getpackages to be called first?
+ if (package_arch($package) ne package_arch($dh{LINK_DOC})) {
+ if (compat(9)) {
+ warning(WARNING: --link-doc between
architecture all and not all packages breaks binNMUs);
+ } else {
+ error(--link-doc not allowed between
${package} and $dh{LINK_DOC} (one is all and the other not));
+ }
+ }
# Make sure that the parent directory exists.
if (! -d $tmp/usr/share/doc ! -l $tmp/usr/share/doc) {
doit(install,-g,0,-o,0,-d,$tmp/usr/share/doc);
Everything additional looks like it would have or cause quite some
problems:
- erroring out now breaks even the normal non-binNMU cases
- replacing the dependency with another version in case all-non-all
link is not possible.
- replacing the dependency with another version in case non-all-all
link gets complicated by the possibility of having different versions
for different packages. (and then results in a package nowhere having
the changelog for the binNMU, so many complications and special cases
for a not-really-solution).
- ignoring --link-doc if the packages have different arch:all-ness might
also have some nasty side-effects. And doing that only if there in an
bin-NMU case would be quite suprising and likely not that much better
than now.
- aborting with an error in case there is a broken --link-doc and there
is an binNMU currently happening has the problem of detecting that the
dependency is actually affected (due to binary packages maybe having
differing versions) and could perhaps break some binNMU that by some
other hard to forsee factors perhaps would not create a broken
package.
Of those at most erroring out in case of binNMU that is considered to
create uninstallable packages seems worth considering to me, and making
that good enough to not create new problems looks hard.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768507: #768507 - debhelper
Hi Niels, If you want a team for maintaining debhelper, I'm more than willing to join. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763569: git-dpm generates incorrect patches with the ident gitattribute
* Sam Hartman hartm...@debian.org [141001 03:33]: I'm packaging software that uses the ident tag in .gitattributes in the upstream git directory. Basically all the files in the tree have a $Id$ tag. Why, I don't know; I thought we all learned we hated that back in the bad old days of cvs. Unfortunately this produces really unfortunate results with patches. Attached is an example of the uunrepresented changes in a package I'm working on: I'm not quite sure how git dpm update-patches generates patches but it manages to capture the patches with the old blob IDrather than with the blob ID that results from the merged content. So, dpkg-source claims there are unrepresented upstream changes in the form of all the blob id updates for all the files patched by git dpm. This is quite an ugly problem. git-dpm just uses git-format-patch and that as far as I see it has no way to generate the proper patches. Even worse removing the .gitattribute file usually does not help either, as it caused git to put something different in the internal storage than what the file actual has (so removing the .gitattribute will make git claim the content of the file changed). The only way I see around this is importing a tarball of the sources on top of it (for example using git-dpm import-new-upstream). If the tarball contains the .gitattribute even that will not help without the new --exclude option added it git-dpm 0.9. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: it's actively harmful
* Matthias Urlichs matth...@urlichs.de [141103 07:48]: As long as only a small number of packages have the wrong priority, starting with that set and pulling the rest in via dependencies is likely to not run into any ugly problems. So simple algorithms have a chance. I'm not saying that we should immediately replace Required and Important priorities with two metapackages (which would depend on every top-level package that's currently marked as such). That'd be too complex for simple tools like debootstrap. What I am saying is that if package A is Important / Required and has a simple dependency on B, then (absent any Pre-Depends) the priority of B is not relevant any more and thus doesn't need to be overridden. And what about the dependencies of B? Is it allowed to have non-simple dependencies in your suggestion? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: it's actively harmful
* Matthias Urlichs matth...@urlichs.de [141029 19:48]: That's obvious. What is not so obvious, to me, is why we would still want the current policy in the first place, given that everything(?) is resolved via dependencies these days. Resolving dependencies is a hard and complex task. In general it will not even have a unique solution. And virtual packages, alternatives and versioned depends needs more complexity (including backtracking to find solutions) than most tools can do. As long as only a small number of packages have the wrong priority, starting with that set and pulling the rest in via dependencies is likely to not run into any ugly problems. So simple algorithms have a chance. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760579: git-dpm: Adopt git-bp style tag names
package git-dpm tag 760579 + pending thanks * Barry Warsaw ba...@debian.org [140905 19:09]: On Sep 05, 2014, at 07:24 PM, Bernhard R. Link wrote: Could you check if after git config --global dpm.debianTag 'debian/%e%v' git config --global dpm.patchedTag 'debian/%e%v' git config --global dpm.upstreamTag 'debian/%e%u' A new repo and ran: git config dpm.debianTag 'debian/%e%v' git config dpm.patchedTag 'patched/%e%v' git config dpm.upstreamTag 'upstream/%e%u' And it worked perfectly. Thanks! (Yes, I think we want this per-repo so that team members don't have to set their global settings when working with other non-team git-dpm repos.) The current master branch at git://anonscm.debian.org/git-dpm/git-dpm.git now also has support for storing tag names in debian/.git-dpm (and some more %-sequences (to support the different ways epochs and tildes are escaped). Thanks for your suggestions and testing very welcome, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760579: git-dpm: Adopt git-bp style tag names
* Barry Warsaw ba...@debian.org [140905 16:36]: Because of backward compatibility, you probably have to preserve the current behavior as a default, but here's a request to allow for some configurability here, in say a debian/gitdpm.conf file. Could you check if after git config --global dpm.debianTag 'debian/%e%v' git config --global dpm.patchedTag 'debian/%e%v' git config --global dpm.upstreamTag 'debian/%e%u' git-dpm produces tags more to your liking? (I guess for tagging it might make sense to also have some config in the repository itself, currently almost all git-dpm config is only per-repository or per-user). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757599: O: xbuffy - monitor mailboxes and/or newsgroups
Package: wnpp Severity: normal Control: affects -1 + xbuffy I'm orphaning xbuffy as I haven't used it myself for over two years so lack the setup to test it properly. Current packages can be found in git at git://anonscm.debian.org/collab-maint/xbuffy.git http://anonscm.debian.org/cgit/collab-maint/xbuffy.git http://anonscm.debian.org/gitweb/?p=collab-maint/xbuffy.git;a=summary Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756399: reprepro: use britney's HeidiResult file to update a distribution
* Raphaël Hertzog hert...@debian.org [140729 16:27]: Kali is using reprepro and we're starting to use britney to maintain a derivative of testing. So britney is generating us an HeidiResult file and it would be nice if reprepro could make use of that file to update a distribution. $ reprepro setcontent codename heidi-file The HeidiResult file looks like this: 0ad 0.0.16-4 amd64 games 0ad-data 0.0.16-1 all games [...] 0ad 0.0.16-4 armhf games 0ad-data 0.0.16-1 all games [...] 0ad 0.0.16-4 source games 0ad-data 0.0.16-1 source games Note that entries for arch all packages are (needlessly) duplicated. Each binary/source package has its own entry. It's possible that the HeidiResult file lists multiple versions of source packages (it might keep older versions around during transitions) as well as some obsolete binary packages. Any package not listed in the HeidiResult file must be removed. Packages are to be found in other distributions of the reprepro setup. PS: No hurry, for now we opted to use a custom script that calls reprepro many times with copy and remove commands. Does that actually has different values for the different architectures? If not then this might easily be translated to two filter files for FilterList and FilterSrcList for a pull rule. (something like sed -n -e 's/^\(.*\) \(.*\) source .*/\1 = \2/p' srcfilterlist sed -n -e 's/^.* .* source .*//' -e 's/^\(.*\) \(.*\) .* .*/\1 = \2/p' binfilterlist Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748658: Please consider supporting generation of .xz index files.
* Daniel Baumann daniel.baum...@progress-technologies.net [140728 10:18]: what is the status of this? reprepro 4.15.0-1 ships with an /usr/share/doc/reprepro/examples/xz.example script to generate Packages.gz using a DebIndices hook. Native generation of the .xz files is there but not enabled in the Debian packages to avoid depending in both liblzma and xz-utils as the native unpackaging of .xz files still needs some more work. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756034: #756280: please don't claim other people wrote or maintain software they do not
Upstream Author : Bernhard R. Link brl...@debian.org While I somtimes no longer remember what features I've already added to some code a long time ago, I think I would at least remember if I had written a whole program. In other words, please make sure to look up the correct upstream author. | ircii (20131230-1.1) unstable; urgency=low | * Non-maintainer upload. | * New upstream release (Closes: #747700) | | -- Denis Rodrigues Ferreira denis...@gmail.com Fri, 18 Jul 2014 13:34:53 +0100 ircii is orphaned. You cannot do an non-maintainer upload because there is no maintainer. Please either adopt it and do an MU or do a QA upload instead. (also the empty line after the first line is missing, which makes this uneccassary hard to read.) | Source: ircii | Section: net | Priority: optional | Maintainer: Bernhard R. Link brl...@debian.org | Build-Depends: debhelper (= 9), autotools-dev, libncurses5-dev, quilt | Standards-Version: 3.9.5 | Homepage: http://www.eterna.com.au/ircii/ | Vcs-Git: git://anonscm.debian.org/collab-maint/ircii.git | Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/ircii.git;a=summary Thanks for volunteering me to maintain this package. But if I take over a package I'd like to decide that on my own. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
* Mike Hommey m...@glandium.org [140713 12:55]: … while IMHO it's possible to safely mix openssl and libressl if we prepare for that (i.e. make sure that _everything_ in libressl is only exported with properly versioned symbols) Contrary to what you seem to believe, this only really works if *both* libraries have versioned symbols. Otherwise, you can end up with libraries linked against the unversioned one using symbols from the versioned one at run time when both are loaded in the same address space. Actually, both having versioned symbols is not enough. It is either both must always have had versioned symbols or both must have versioned symbols now and every binary linked against either must have been built (or rebuilt) after the symbols got versioned. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753800: tracker.debian.org: please give the details link some content
Package: tracker.debian.org Severity: minor Please add some content to the span title=details links. Currently the whole content of the a .. is a i... tag without any content and the image of the question mark in the circle is put there as background image. This causes some text browsers to not offer anything to select there, so the link is not shown and cannot be followed. It would be nicer if there was some img .. with a proper alternate text. Thanks in advance, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570623: reprepro: please add multiple version management
* Benjamin Drung benjamin.dr...@profitbricks.com [140612 17:30]: the logging and tracking was not working in all cases when adding packages with the include command. The fix is in the attached 0003 patch. The include and processincoming commands do work now (except when these commands want to remove a package, which is still on my todo list). What version of reprepro is that patch relative to? I'm a bit at loss at packagedata.c. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752457: reprepro: Please release lock after crash
package reprepro tag 752457 -patch +wontfix thanks When reprepro crashes, the database lock file is not released, because the lock file still exists on the system. A patch is attached that changes the locking system to use fcntl() to lock the database lockfile instead of open with O_EXCL. With this change, the lock is correctly released in case of the reprepro process is crashing. That is currently intentional (at least as long as using bdb). Once reprepro crashes it is likely that bdb just corruptet itself, so one needs a check of the database, anyway. So it is nothing I want to just step over. (Perhaps the error message if there is already a lock file should be made a bit scarier). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748936: apt doesnt understand architecture wildcards
* Johannes Schauer j.scha...@email.de [140522 13:30]: Debian policy 11.1.1 [1] and the associated footnote [2] allow architecture wildcards of the form os-any and any-cpu. Apt seems to equal cpu with debian architecture which is not correct. Here is an example of correct matching: dpkg-architecture -aarmhf -iany-arm echo any-arm matches armhf Apt would instead only match the deprecated arm architecture with any-arm. This doesnt seem to be a problem in practice though because: 1) apt does not check whether a source package can be compiled on the current host architecture (it ignores the Architecture field of source packages) 2) all packages that have any-arm in their build dependency architecture restrictions also include any-armel, any-armeb and any-armhf Nevertheless, apt behaviour should reflect dpkg behaviour and naturally policy. The correct behaviour is encoded in dpkg scripts/Dpkg/Arch.pm and needs the files /usr/share/dpkg/triplettable and /usr/share/dpkg/cputable to work correctly. Urgh. Really? This is far too complicated for most programs to implement properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote describes absolutely nothing currently, and having such important fields a meaning that you cannot calculate without knowing what architectures the system finally using the package uses makes it unhandable). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749126: downloadable maintainer mbox contains from message dates
Package: debbugs Severity: normal The From message header in the downloadable maintainer mbox does not contain the date of the message like in the mbox folder or status mbox but instead the current date. This causes answers to those mails attributing the sender with the wrong date in the reply (like in the header mutt inserts on top of a quotation). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742417: bls tag for configure syntax errors
Sorry for the late reply. I totally missed your bug report. * Evgeni Golov evg...@debian.org [2014-03-23 14:38]: Those errors might look like this in the build log: checking for idna_to_ascii_from_locale... no ../configure: line 12285: test: =: unary operator expected This usually means that there is a syntax error in the configure script but the execution could be completed. Syntax errors can lead to unexpected configuration results. Do you have an example of a buildd log that contains a line like that? I did a manual scan of all packages currently in unstable with the regexp you gave and could not find any example. Those errors might look like this in the build log: checking for idna_to_ascii_from_locale... no ../configure: line 12285: test: =: unary operator expected This usually means that there is a syntax error in the configure script but the execution could be completed. Syntax errors can lead to unexpected configuration results. --- data/bls/descriptions/X-configure-syntax-error.description | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 data/bls/descriptions/X-configure-syntax-error.description diff --git a/data/bls/descriptions/X-configure-syntax-error.description b/data/bls/descriptions/X-configure-syntax-error.description new file mode 100644 index 000..7df52f6 --- /dev/null +++ b/data/bls/descriptions/X-configure-syntax-error.description @@ -0,0 +1,14 @@ +## Match: regexp:.*configure: line [0-9]\+: I'd would have expected that regexp to be quite expensive due to the starting with .* but it currently hardly increases the number of states in the compile finite state machine and it really cannot be helped that much I guess it does not matter. +This is an experimental tag. It needs review and a better description. +br +The build log contains a message from ttconfigure/tt starting with +pre +configure: line X: +/pre +br +This message usually means that there is a syntax error in the configure +script, but the execution could be completed. Syntax errors can lead to +unexpected configuration results. +br +If you have more information for this description or want it escalated +to warning or error, please let me know. I guess it makes sense to start with an warning right away (I guess error is a bit too hard as it might not be an actual problem) I guess a longer description might be nice but currently the only thing I can think of is perhaps making the example line a bit more specific like +configure: line NNN: SOME-ERROR-MESSAGE Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570623: reprepro: please add multiple version management
* Benjamin Drung benjamin.dr...@profitbricks.com [140521 16:48]: I got distracted by different tasks, but now I have time to work on reprepro again. Am Dienstag, den 04.02.2014, 23:23 +0100 schrieb Bernhard R. Link: * Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]: Okay. Attached the patch for my prototype. Be aware: It's just a prototype that is just able to run the commands that I wanted to test, but isn't near to be ready for mainlining. The prototype implements case 2 just because that was my initial idea, but now I tend to think that case 1 might be easier/cleaner. Thanks. I'll take a look this weekend. Any feedback so far? It's too long ago for me to remember. AFAIR it mostly was that libdb trick that is quite hard to understand. It sounds quite slow either way. Perhaps the way to go is instead changing the data format, like having the version first (perhaps even in preparsed format to speed things up). Good idea, but is this function really time critical? It should be only called when comparing duplicate keys (which shouldn't happen that often, does it?). It might also happen when updating some value otherwise. (And if the version is in some meta-data first one also does not have to differentiate between binaries and sources that much). One could also take the opportunity of a format change to allow for other possible future meta data (like the first added timestamp). How flexible should the new data structure be? What meta data besides the timestamp could be relevant? It would be nice if it allowed other fields to be added later without breaking the format again. Like some (field-length-content)* format. How do you want to preparse the version? if versions are compared they are split into epoch version and revision and version and revision are gain split into sequences of numbers and not-numbers. Dpkg for example first parsed all the functions and later only compares the already split part. if easily possible it could make sense to store it in a format like that (but then parsing a on-disk format of the split data might be just as time-consuming as just looking at the real data). The version and revision can have a nearly unlimited amount of concatenated numbers and not-numbers. You could store the parts as list with type information. I doubt that a different on-disk format could increase the speed. We could split the full version into epoch, version, and revision and store them separately, but parsing these parts will be more time consuming. My feeling is that we should stick with the full version as string. Yes, might not make much sense if one has to store the preparsed format. While working on reprepro, I found a typo. A patch for that is attached. applied. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748658: Please consider supporting generation of .xz index files.
* peter green plugw...@p10link.net [140519 12:57]: Please consider supporting generation of xz index files, xz is much faster to decompress than bz2. If you feel adventurous you can try the code at http://anonscm.debian.org/gitweb/?p=mirrorer/reprepro.git;a=shortlog;h=refs/heads/master Otherwise take a look at the standalone bzip example (/usr/share/doc/reprepro/examples/bzip.examples in the packages). Replacing all bzip2 with xz and .bz2 with .xz in there should make it possible to generate Packages.xz and/or Sources.gz Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747674: make-dfsg: undeterministic build due to missing configure arguments/build-conflicts
* Manoj Srivastava sriva...@acm.org [140511 02:09]: debian/rules does not tell configure which optional features to use, so they are added or not depending on autodetection, that is whether some packages are installed or not. As those are also not found in the Build-Conflicts, the build is nondeterministic: All kinds of things make build non-deterministic. Setting up the build environment consistently is required for any kind of determinism. A clean machine with build-essential and the build depends will result in make without guile. As such, all kinds of things in the user environment may change the behaviour of the software built. I guess with clean you mean minimal here. Because the bug causes the outcome to behave differently in different clean chroots, depending on what packages are installed. Also packages are practically never build in a truely minimal chroot. For example most people use chroots still have apt and its dependencies like gnupg installed. Build environments like sbuild support speeding up builds by keeping installed packages installed (in the past that was even the behaviour of offical Debian buildds) and last but not least debugging of packages is much easier outside of a temporary chroot, so a bug like this makes it much harder for porters or users running into some problem. Even if requiring some minimal build environment, a indeterminism like this bug can cause problems: Imagine between the last upload of make-dfsg and the release of jessie, and of the build-dependencies gains a dependency to guile-dev, then a security upload to jessie would suddenly change the behaviour of make in this regard. Finally the whole point of the existance of Build-Conflicts is that a minimal set of installed packages is not a guaranteed property of a build. If a package needs that guarantee, that is what Build-Conflicts is for. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745675: email uploader when there's an error in processincoming
* Antoine Beaupré anar...@debian.org [140424 01:03]: it is pretty confusing for users when their upload fails to register in reprepro - they have no way to tell what went wrong, short of looking into the log, something which only admins have access to. could reprepro email the uploader when errors happen? This is a long planed feature, TODO already lists implement sending mails to uploader, but also a quite complicated one. For one the error reporting needs some revamping, as most error reporting currently goes directly to stderro. Then there is a question of where to send mails to. I guess one wants something like a whitelist there, to make sure DDs are not pestered with mails if someone tries to add their package to some local repository somehwere in the world. As an intermediate step, you might want to consider if it makes sense for you to write this log to some place where users can look at them. (as the repository generated is usually available via plain html, making the log visible on the same way is usually easy, unless you consider any information in there especially protectworthy). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747753: Strange Replaces: none and Conflicts: none in control information
Package: snmptrapfmt Version: 1.14+nmu1 Severity: important The control information of snmptrapfmt_1.14+nmu1_amd64.deb contains the two lines Replaces: none Conflicts: none which causes apt to believe there is a virtual package none around. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747674: make-dfsg: undeterministic build due to missing configure arguments/build-conflicts
Package: make
Version: 4.0-5
Severity: normal
debian/rules does not tell configure which optional features to use, so
they are added or not depending on autodetection, that is whether some
packages are installed or not. As those are also not found in the
Build-Conflicts, the build is nondeterministic:
Debdiff of generated .deb with and without guile-2.0-dev installed:
Control files: lines which differ (wdiff format)
Depends: [-guile-2.0-libs,-] libc6 (= [-2.17), libgc1c2 (= 1:7.2d)-] {+2.17)+}
-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages make depends on:
ii libc6 2.18-5
make recommends no packages.
Versions of packages make suggests:
pn make-doc none
-- no debconf information
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746973: dpkg-gensymbols(1) is misleading to omit important part of symbols file maintainance
Package: dpkg Version: 1.17.9 Severity: normal Tags: patch dpkg-gensymbols(1) reads as if applying the dpkg-gensymbols generated diff to a symbols file was all there was to do for a new upstream version. Attached patch hopefully fixes that: From 7f2679cb82526a14b0c5c3b1418b09c6c2d92762 Mon Sep 17 00:00:00 2001 From: Bernhard R. Link brl...@debian.org Date: Sun, 4 May 2014 15:31:54 +0200 Subject: [PATCH] dpkg-gensymbols(1): Fix seriously misleading part about applying diffs to symbols files --- man/dpkg-gensymbols.1 | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/man/dpkg-gensymbols.1 b/man/dpkg-gensymbols.1 index 65b042c..bf6c8c0 100644 --- a/man/dpkg-gensymbols.1 +++ b/man/dpkg-gensymbols.1 @@ -61,8 +61,12 @@ option). The symbols files are really useful only if they reflect the evolution of the package through several releases. Thus the maintainer has to update them every time that a new symbol is added so that its associated minimal -version matches reality. To do this properly the diffs contained in the -build logs can be used. In most cases, the diff applies directly to the +version matches reality. +As as start for this the diffs contained in the build logs can be used, +but the maintainer has to ensure additionally that the behaviour of that +symbol was not changed in a way that something using that symbol linked +against the new version no longer works against the old package. +In most cases, the diff applies directly to the debian/\fIpackage\fR.symbols file. That said, further tweaks are usually needed: it's recommended for example to drop the Debian revision from the minimal version so that backports with a lower version number @@ -79,6 +83,14 @@ Note that you can put comments in symbols files: any line with '#' as the first character is a comment except if it starts with '#include' (see section \fBUsing includes\fP). Lines starting with '#MISSING:' are special comments documenting symbols that have disappeared. +.P +Do not forget to check if old symbols' versions needs to be increased. +There is no way \fBdpkg\-gensymbols\fP can warn you about this. +Blindly applying the diff or assuming there is nothing to change +if there is no diff without checking this leads to packages +with dependencies that claim the package working with older versions +it cannot work with, thus introducing hard to find bugs with +(partial) upgrades. .SS Using #PACKAGE# substitution .P In some rare cases, the name of the library varies between architectures. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742623: Please show the whole git repository directory of a project instead of just one repository
* Olivier Berger olivier.ber...@telecom-sudparis.eu [140421 20:02]: Thanks for the suggestion. I'm not sure this is the best way to do it. That URL corresponds to one linked from the SCM tool (https://alioth.debian.org/scm/?group_id=), when following the Browse git repository link. I think it may be better to list all repositories of a project in that base page of the SCM tool, instead. Having a nicer list earlier would also be nice, but it's more complicated while just fixing the iframe at the Browse Git Repository page is an easy fix with hardly any disadvantage (one click more for projects that really only have one git repository in their directory). Having the list already at the /scm/?group_id= page would either mean the php code needs to know about which git repositories exist (not very recommendable, as that would mean more reading of untrusted data from the php code) or just embedding the iframe to gitweb already there. Which again would likely mean to change the layout there and so on and so forth... [...] I'll forward it in upstream bugtracker. Thanks, Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742623: Please show the whole git repository directory of a project instead of just one repository
Package: gforge-plugin-scmgit
Version: 5.2.3-1
Currently https://alioth.debian.org/scm/browser.php?group_id=
shows an iframe with the git repository named like the project in the
project's directory for git repositories.
It would be nicer if it could instead show the list of all git
repositories in that directory. That's one more click if there is
only one but much better visibility of other repositories
(and even allows to have no repository there named like the project
itself).
Needs at least gitweb 1.7.10-rc0. (wheezy has already 1.7.10.4)
Index: fusionforge-5.2.3/plugins/scmgit/common/GitPlugin.class.php
===
--- fusionforge-5.2.3.orig/plugins/scmgit/common/GitPlugin.class.php
2014-03-25 16:14:29.341835604 +0100
+++ fusionforge-5.2.3/plugins/scmgit/common/GitPlugin.class.php 2014-03-25
16:15:28.949835377 +0100
@@ -212,7 +212,7 @@
if ($project-usesPlugin($this-name)) {
if ($this-browserDisplayable($project)) {
- print 'iframe
src='.util_make_url(/plugins/scmgit/cgi-bin/gitweb.cgi?p=.$project-getUnixName().'/'.$project-getUnixName().'.git').'
frameborder=0 width=100% height=700/iframe' ;
+ print 'iframe
src='.util_make_url(/plugins/scmgit/cgi-bin/gitweb.cgi?pf=.$project-getUnixName()).'
frameborder=0 width=100% height=700/iframe' ;
}
}
}
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741178: xterm mis-sets terminal size (again)
Package: xterm Version: 302-1 Severity: normal Control: found -1 303-1 It looks like #347308 aka #347774 is back: If I open an xterm my window manager makes it fill out the whole frame instantly, but xterm again sometimes does not seem to set the terminal size to it (but instead to some previous size) until I trigger a resize of the window, in which case xterm sets the terminal size to the window size. Btw: #461773 might be a another duplicate of #347308. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Versions of packages xterm depends on: ii libc6 2.18-4 ii libfontconfig1 2.11.0-5 ii libice6 2:1.0.8-2 ii libtinfo5 5.9+20140118-1 ii libutempter01.1.5-4 ii libx11-62:1.6.2-1 ii libxaw7 2:1.0.12-1 ii libxft2 2.3.1-2 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.4-1 ii xbitmaps1.1.1-2 Versions of packages xterm recommends: ii x11-utils 7.7+1 Versions of packages xterm suggests: pn xfonts-cyrillic none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Sam Hartman hartm...@debian.org [140205 13:27]: no, that means I have to maintain the artifact (namely the .orig.tar.gz). The archive software (both reprepro and dak were I to use that) require that the .orig.tar.gz not change checksums. I don't want my build machines to be able to push back to my master repository. Nor do I want to have to release upstream versions if I lose state on my build machines. So this violates my requirements because I have to maintain an artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum never changes. This answers the question why you want to use a 3.0 (native) package. But the real question here is: Why do you want to use a version with - for such a package? Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570623: reprepro: please add multiple version management
* Benjamin Drung benjamin.dr...@profitbricks.com [140203 13:15]: Okay. Attached the patch for my prototype. Be aware: It's just a prototype that is just able to run the commands that I wanted to test, but isn't near to be ready for mainlining. The prototype implements case 2 just because that was my initial idea, but now I tend to think that case 1 might be easier/cleaner. Thanks. I'll take a look this weekend. It sounds quite slow either way. Perhaps the way to go is instead changing the data format, like having the version first (perhaps even in preparsed format to speed things up). Good idea, but is this function really time critical? It should be only called when comparing duplicate keys (which shouldn't happen that often, does it?). It might also happen when updating some value otherwise. (And if the version is in some meta-data first one also does not have to differentiate between binaries and sources that much). One could also take the opportunity of a format change to allow for other possible future meta data (like the first added timestamp). How do you want to preparse the version? if versions are compared they are split into epoch version and revision and version and revision are gain split into sequences of numbers and not-numbers. Dpkg for example first parsed all the functions and later only compares the already split part. if easily possible it could make sense to store it in a format like that (but then parsing a on-disk format of the split data might be just as time-consuming as just looking at the real data). How would the data format change? Currently the database value contains just the control junk. We could put the pair (version, control) as value into the database. How should the pair separated? Maybe with a null character? something like that. Then we could just use the pointer to the value as version string (the null character from the pair separation would also be used to terminate the string). Yes. That would be the store verbatim and non-preparsed variant. Alternatively one could first store a length of the string, so one can even faster jump to the control part. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570623: reprepro: please add multiple version management
* Benjamin Drung benjamin.dr...@profitbricks.com [140108 15:51]:
First sorry for my late reply. I must have totally missed your mail.
The first step is to agree on the database layout change. I came up with
two alternatives:
1) Allow duplicate entries in packages.db and sort duplicate entries by
their Debian version. They can be sorted a) upwards or b) downwards.
Depending on the request, we will either search for all versions of a
package, one specific version of the package, or for the latest version
of a package.
2) Rename the key of packages.db to also contain the version of the
package, e.g. sl|3.03-17 or hello_2.8-4 (which delimiter should we
use?). This would allow us to check directly for a specific version of a
package. We need to add a secondary table that allows us to access the
database as described in 1) through the secondary table. This secondary
table will allow duplicate entries and the values of the secondary table
point to the key in packages.db. Depending on the task, we either query
the first or secondary table. The secondary table will be kept in sync
by BerkeleyDB.
In the first case, we need to add a function to iterate over the
duplicate packages to find a specific version. In the second case, we
need to create the secondary table and transform the database.
Which layout do you prefer?
I think that layout is better that better fits the code. Not yet having
looked at the code, I cannot say. I guess 1 might be simpler. In the
case of 2 I think | is fine, as it is already used elsewhere (though
I guess one should make sure reprepro does not allow | in package
names).
Another issue is the sorting of the packages in the database. We need
one function to sort all entries in the table. So we need one function
to sort binary packages and source packages, but we have
binaries_getversion() and source_getversion(). Here's the example code
(without the error handling) of the sorting function:
static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b) {
char *a_version, *b_version;
int versioncmp;
binaries_getversion(a-data, a_version);
binaries_getversion(b-data, b_version);
dpkgversions_cmp(a_version, b_version, versioncmp);
return versioncmp;
}
Do you have a suggestion how to improve this function?
It sounds quite slow either way. Perhaps the way to go is instead
changing the data format, like having the version first (perhaps even in
preparsed format to speed things up).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628878: patch to fix xli with png with palette and transparency
package xli
severity 628878 normal
tags 628878 + patch
thanks
It looks like the thing to trigger this bug is a png in palette mode
that uses transparency, as the way png is used it told to expand this
into an alpha channel (which is then dropped, but that happens to late,
so the size information is wrong).
The following patch fixes it for me:
--- xli-1.17.0+20061110.orig/png.c 2006-11-11 06:52:14.0 +0100
+++ xli-1.17.0+20061110.new/png.c 2014-01-06 14:29:28.522747134 +0100
@@ -206,6 +206,7 @@
gflag = PNG_BACKGROUND_GAMMA_FILE;
}
png_set_background(png, bg, gflag, expand, gval);
+ png_set_strip_alpha(png);
}
if (bit_depth 8 (bit_depth 1 ||
PNG_COLOR_TYPE_GRAY != color_type)) {
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--- xli-1.17.0+20061110.orig/png.c 2006-11-11 06:52:14.0 +0100
+++ xli-1.17.0+20061110.new/png.c 2014-01-06 14:29:28.522747134 +0100
@@ -206,6 +206,7 @@
gflag = PNG_BACKGROUND_GAMMA_FILE;
}
png_set_background(png, bg, gflag, expand, gval);
+ png_set_strip_alpha(png);
}
if (bit_depth 8 (bit_depth 1 ||
PNG_COLOR_TYPE_GRAY != color_type)) {
Bug#697630: Can't include changes files which contain a duplicate arch all
package reprepro
tags 697630 - patch
thanks
* Simon McVittie simon.mcvit...@collabora.co.uk [131126 17:44]:
On Tue, 08 Jan 2013 at 23:11:55 +0100, Bernhard R. Link wrote:
* Sjoerd Simons sjo...@debian.org [130107 20:33]:
With our usage of reprepro we get .changes files form multiple builders
(different architecture), all of them build arch dependent and arch
independent. This unfortunately means reprepro will error out as soon as a
second buld of an arch all package is received.
Thanks for your patch, but I fear it is not that easy.
[...]
This only does not copy the file, and even takes the contents from the
old file (I don't know if that is good and ugly or bad and ugly, most
likely something of both), but the checksum is still the one from the
new file.
Here's a later version of Sjoerd's patch, which seems to address this.
We've been using it for a while and it appears to work fine in practice.
[...]
+.B updatedarchall
+When asked to include a architecture all package into a repository which
+already includes that same file with a different checksum ignore the request.
+Useful when getting multiple builds include architecture independent packages
That's not what this patc does. It's rather:
When asked to include a architecture all package into a repository which
already includes the same file (in the same or another distribution),
the package will be included with the information for the Packages
file (like description or the dependencies apt sees) from the new
package, while the file (which is then all dpkg sees) is taken from
the already existing package. This can be useful if multiple builds
create an architecture all package (i.e. if all using dpkg-buildpackage
-b instead of dpkg-buildpackage -B), but great care has to be taken
has to be taken to not end up with conflicting information [...]
The more I try to describe it, the more I think this is not something
I want to have.
How about something like the following instead (it would have the
disadvantage of not adding the arch all package at all if the
conflicting package is in another distribution, but better no package
than a package where content and index might be not match):
diff --git a/checkin.c b/checkin.c
index 1884273..8a1d456 100644
--- a/checkin.c
+++ b/checkin.c
@@ -880,12 +880,13 @@ static retvalue changes_check(const struct distribution
*distribution, const cha
}
static retvalue changes_checkfiles(const char *filename, struct changes
*changes) {
- struct fileentry *e;
+ struct fileentry *e, **pe;
retvalue r;
r = RET_NOTHING;
- for (e = changes-files; e != NULL ; e = e-next) {
+ pe = changes-files;
+ while ((e = *pe) != NULL) {
//TODO: decide earlier which files to include
if (e-type == fe_BYHAND) {
/* byhand files might have the same name and not
@@ -918,6 +919,21 @@ static retvalue changes_checkfiles(const char *filename,
struct changes *changes
return RET_ERROR_OOM;
/* do not copy yet, but only check if it could be included */
r = files_canadd(e-filekey, e-checksums);
+ if (r == RET_ERROR_WRONG_MD5
+ e-architecture_into == architecture_all
+ IGNORABLE(conflictingarchall)) {
+ struct fileentry *removedentry;
+
+ fprintf(stderr,
+Ignoring '%s' as --ignore=ignoreconflictingarchall given and there is already
a file with different contents of that name.,
+ e-name);
+
+ removedentry = e;
+ *pe = removedentry-next;
+ removedentry-next = NULL;
+ freeentries(removedentry);
+ continue;
+ }
if (RET_WAS_ERROR(r))
return r;
/* If is was already there, remember that */
@@ -943,6 +959,7 @@ static retvalue changes_checkfiles(const char *filename,
struct changes *changes
}
free(fullfilename);
}
+ pe = e-next;
}
return RET_OK;
diff --git a/ignore.h b/ignore.h
index 5a64288..d2c0c5d 100644
--- a/ignore.h
+++ b/ignore.h
@@ -36,7 +36,8 @@
IGN(wrongarchitecture) \
IGN(oldfile) \
IGN(longkeyid) \
- IGN(missingfile)
+ IGN(missingfile) \
+ IGN(conflictingarchall)
enum ignore {
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730572: reprepro: support for ddebs (debug symbols)
* Simon McVittie simon.mcvit...@collabora.co.uk [131126 18:03]:
(Deliberately not tagging this +patch right now, since Debian doesn't
officially support ddebs yet, and the archive layout looks likely to change.)
Ubuntu has a semi-separate archive for separate debug symbols, and
https://wiki.debian.org/AutomaticDebugPackages is the proposal to
add the same thing to Debian. It would be great if reprepro could
support them, too.
The attached patch is a proof-of-concept implementation: it treats them
as a mixture of .deb and .ddeb. It seems to work OK in conjunction with
Ubuntu's pkg-create-dbgsym.
Thanks. That fits the coding style of reprepro quite well. If you'd
have claimed I had written it and just forgotten about about, I'd
have had a hard time arguing against that.
diff --git a/checkin.c b/checkin.c
index 02ba279..ba5331f 100644
--- a/checkin.c
+++ b/checkin.c
@@ -130,7 +130,7 @@ static void freeentries(/*@only@*/struct fileentry
*entry) {
free(entry-section);
free(entry-priority);
free(entry-name);
- if (entry-type == fe_DEB || entry-type == fe_UDEB)
+ if (FE_BINARY(entry-type))
deb_free(entry-pkg.deb);
else if (entry-type == fe_DSC) {
strlist_done(entry-needed_filekeys);
I've already applied this one. As it makes sense anyway.
@@ -1164,8 +1169,7 @@ static retvalue changes_checkpkgs(struct distribution
*distribution, struct chan
e = changes-files;
while (e != NULL) {
char *fullfilename;
- if (e-type != fe_DEB e-type != fe_DSC
- e-type != fe_UDEB) {
+ if (!FE_PACKAGE (e-type)) {
e = e-next;
continue;
}
This, too. But without the space between E and (.
+ /* we use the deb overrides for ddebs too - ddebs aren't
+ * meant to have overrides so this is probably fine */
binoverride = distribution-overrides.deb;
components = distribution-components;
I think if those packages will finally come without a Priority or
Section in the package, there will be a more complex solution needed,
as without no Section at all, reprepro will not accept the package
yet (unless there is one in the override file).
@@ -173,20 +176,36 @@ static retvalue gentargetcontents(struct target
*target, struct release *release
struct filetorelease *file;
struct filelist_list *contents;
struct target_cursor iterator;
+ const char *suffix;
+ const char *symlink_prefix;
if (onlyneeded target-saved_wasmodified)
onlyneeded = false;
+ switch (target-packagetype) {
+ case pt_ddeb:
+ symlink_prefix = d;
+ suffix = -ddeb;
+ break;
+ case pt_udeb:
+ symlink_prefix = s;
+ suffix = -udeb;
+ break;
+ default:
+ symlink_prefix = ;
+ suffix = ;
+ }
+
contentsfilename = mprintf(%s/Contents%s-%s,
atoms_components[target-component],
- (target-packagetype == pt_udeb)?-udeb:,
+ suffix,
atoms_architectures[target-architecture]);
Will there even be Contents files for ddebs?
+/* This is pretty close to duplicating the enum typedef'd to filetype
+ * in changes.h, but its order corresponds to typesuffix[]. Do not
+ * confuse them. */
enum filetype { ft_UNKNOWN,
uh, oh. Indeed, I should probably rename one of those two.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729321: keyboard-configuration: changes /etc/default/keyboard upon upgrade without asking
Package: keyboard-configuration Version: 1.103 Severity: serious After upgrading keyboard-configuration from 1.102 to 1.103, /etc/default/keyboard was changed (perhaps to some old state?). The state before was: | # KEYBOARD CONFIGURATION FILE | | # Consult the keyboard(5) manual page. | | XKBMODEL=pc105 | XKBLAYOUT=de | XKBVARIANT=nodeadkeys | XKBOPTIONS=compose:rwin,terminate:ctrl_alt_bksp,caps:none | | BACKSPACE=guess Afterwards the caps:none was gone. There were no questions asked while upgrading. -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages keyboard-configuration depends on: ii debconf 1.5.52 ii initscripts 2.88dsf-43 ii liblocale-gettext-perl 1.05-7+b2 keyboard-configuration recommends no packages. keyboard-configuration suggests no packages. Versions of packages console-setup depends on: ii console-setup-linux 1.103 ii debconf 1.5.52 ii xkb-data 2.5.1-3 Versions of packages console-setup suggests: ii locales 2.17-94 ii lsb-base 4.1+Debian12 Versions of packages console-setup-linux depends on: ii kbd 1.15.5-1 Versions of packages console-setup-linux suggests: ii console-setup 1.103 Versions of packages keyboard-configuration is related to: pn console-common none pn console-datanone pn console-tools none ii kbd 1.15.5-1 -- debconf information: * keyboard-configuration/layoutcode: de * keyboard-configuration/optionscode: compose:rwin,terminate:ctrl_alt_bksp debian-installer/console-setup-udeb/title: * keyboard-configuration/layout: * keyboard-configuration/switch: No temporary switch * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages * console-setup/fontsize-fb47: 8x16 * keyboard-configuration/modelcode: pc105 keyboard-configuration/unsupported_layout: true console-setup/framebuffer_only: * keyboard-configuration/unsupported_config_options: false * keyboard-configuration/variantcode: nodeadkeys * keyboard-configuration/toggle: No toggling * console-setup/charmap47: UTF-8 console-setup/store_defaults_in_debconf_db: true * keyboard-configuration/altgr: The default for the keyboard layout * keyboard-configuration/compose: Right Logo key * keyboard-configuration/other: console-setup/use_system_font: * keyboard-configuration/variant: German - German (eliminate dead keys) * console-setup/fontface47: Fixed * keyboard-configuration/model: Generic 105-key (Intl) PC * keyboard-configuration/ctrl_alt_bksp: true keyboard-configuration/unsupported_options: true console-setup/codesetcode: Lat15 keyboard-configuration/unsupported_config_layout: true * keyboard-configuration/xkb-keymap: de(nodeadkeys) * keyboard-configuration/store_defaults_in_debconf_db: true console-setup/fontsize: 8x16 console-setup/fontsize-text47: 8x16 console-setup/guess_font: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709104: Should not Depends or Recommends gnupg-agent
* Bernhard Reiter wrote I do believe that gnupg2 should depend on gpg-agent! Rationale: Some users will be suprised by core behaviour of gnupg2 not working correctly in the case of gpg-agent not being installed. That's a reason for a Recommends. Not at all a reason for a Depends. About dragging in GUI resources via pinentry: There is pinentry-curses which does not GTK or Qt dependencies. So it does not drag in GUI resources. As libgpgme11 depends on gpgme2 that means you get that pulled in in every non-interactive setup (like buildds) if you have anything that uses libgpgme11. But perhaps that just means libgpgme will die for goog because everyone replaces it with something that calls gpgme(1.4) directly because of gpgme2's dependencies. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722520: make 3.82: with -j tries to run receipes without prerequisites yet done
Package: make Version: 3.82-1 Severity: important Control: block 720706 by -1 With the following 3 makefiles: ## Makefile # all: a b a: $(MAKE) -C data b: $(MAKE) -C src clean: $(MAKE) -C src clean $(MAKE) -C data clean .PHONY: all a b clean ## src/Makefile # all: A1 A2 A3 A4 A5 A6 A7 A1 A2 A3 A4 A5 A6 A7: sleep 10 $@ clean: -rm -f A* .PHONY: all clean # data/Makefile # SHELL = /bin/bash # Give directory a/ a chance to start anything: test := $(shell sleep 1) .PHONY: all clean list = B1 B2 B3 B4 B5 all: $(list) B3: B1 B2 B5: B3 B%: @for pred in $^ ; do printf %s $@: checking $$pred: ; if test -f $$pred ; then echo found ; else echo not found ; exit 1 ; fi ; done echo $^ $@ .SECONDARY: $(list) clean: rm -f B* # and running make -j8 in the top level directory, I get: $ make -j8 make -C data make -C src make[1]: Entering directory `/mydir/src' sleep 10 A1 sleep 10 A2 sleep 10 A3 sleep 10 A4 sleep 10 A5 sleep 10 A6 sleep 10 A7 make[1]: Entering directory `/mydir/data' echo B1 echo B2 echo B4 B5: checking B3: not found make[1]: *** [B5] Error 1 [...] That means despite make knowing that B3 is a prerequisite to B5, B5 is run with B3 not yet done in this case. -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Versions of packages make depends on: ii libc6 2.17-92+b1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720448: git-dpm update-patches wipes out dep-3 headers on previous patches
* Paul Elliott pelli...@blackpatchpanel.com [130829 22:24]: As a workaround till this is fixedI suggest starting each commit with a single line followed by an empty line. (As suggested by the DISCUSSION section of git-commit(1)). That does not work. The dep-3 standard clearly states: A header always ends on the first empty line. So the result would loose some of the dep-3. Please take a look at http://dep.debian.net/deps/dep3/ at the the Fix regex problems sample DEP-3 header. That's the kind of DEP-3 header you can create with git-dpm. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720448: git-dpm update-patches wipes out dep-3 headers on previous patches
* Paul Elliott pelli...@blackpatchpanel.com [130829 03:35]: Ok I will send you an example. [...] Tell me if this example is helpfull. Yes, it is helpful. That seems to be a ugly effect of git wanting to allow multi-line short descriptions. As a workaround till this is fixedI suggest starting each commit with a single line followed by an empty line. (As suggested by the DISCUSSION section of git-commit(1)). Thanks for your example, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720448: git-dpm update-patches wipes out dep-3 headers on previous patches
* Paul Elliott pelli...@blackpatchpanel.com [130822 04:15]: ++From: Paul Elliott pelli...@blackpatchpanel.com ++Date: Wed, 21 Aug 2013 02:09:27 -0500 ++Subject: =?UTF-8?q?harden=20library=20against=20buffer=20overflow=20attack?= ++ =?UTF-8?q?s=20on=20sprintf=0Acalls=20to=20sprintf=20with=20'%s'=20in=20fo?= ++ =?UTF-8?q?rmat=20string=20replaced=20with=20snprintf?= I cannot reproduce that here. Do you have anything active that could cause git-format's patch to garble that subject line (or rather why does it try to put the newline =0A in the subject itself?) Notice that the lines deleted were dep-3, because I hand edited it to be dep-3. When the new patch installed, this dep-3 was removed and replaced with unreadable stuff that is not dep-3! If you use update-patches you have to put the dep-3 headers in the commit message, so they end up in the generated patches. dep-3 patch headers are highly recommended but not required by debian. http://dep.debian.net/deps/dep3/ Note that this explicitely allows the Author in From: and the having a Subject: for parts of the description. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720706: cuyo: FTBFS in parallel mode with make 3.82 from experimental: Unbound module Farbe
* Daniel Schepler dschep...@gmail.com [130824 18:33]: config.status: creating po/Makefile config.status: creating config.h config.status: executing depfiles commands dh_testdir dh_testdir /usr/bin/make -C data /usr/bin/make -C src make[1]: Entering directory `/tmp/buildd/cuyo-2.0.0brl1/src' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DPKGDATADIR=\/usr/share/games/cuyo\ -DLOCALEDIR=\/usr/share/locale\ -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -W -ansi -pedantic -MT bilddatei.o -MD -MP -MF .deps/bilddatei.Tpo -c -o bilddatei.o bilddatei.cpp ... make[1]: Entering directory `/tmp/buildd/cuyo-2.0.0brl1/data' /usr/bin/ocamlopt -o pam.cmi -c pam.mli /usr/bin/ocamlopt -o natmod.cmi -c natmod.mli /usr/bin/ocamlopt -o helfer.cmi -c helfer.mli /usr/bin/ocamlopt -o graphik.cmi -c graphik.mli File graphik.mli, line 20, characters 0-10: Error: Unbound module Farbe Is that all output of that directory? The Makefile has a line graphik.cmi: farbe.cmi xpmlex.cmi pam.cmi so I am a bit lost why this version of make thinks it can try to generate that file before it does farbe.cmi. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714626: please check for redundant search paths
* Simon Ruderich si...@ruderich.org [130815 00:20]:
On Mon, Jul 01, 2013 at 02:39:58PM +0200, Matthias Klose wrote:
Please check for redundant search paths for -I and -L flags, which are
already
included in the search paths of the compiler.
That is, things like
/usr/{include,lib}
/usr/local/{include,lib}
/usr/{include,lib}/multiarch
/usr/local/{include,lib}/multiarch
[...]
[...]
Implementing this should be straight-forward, but I'm not sure if
blhc is the best place to add this.
Bernhard, what do you think? Should this get implemented in blhc
or in your general buildd log scanner?
I'm also undecided which is the best place. As blhc already looks at
similar flags it might be easy to add there, but then it is quite a
different check compared to those blhc has.
If you think blhc is the right place, what buildd-mode messages (e.g.
I-foo, W-foo) should I use?
If you consider it something blhc should do, I'd suggest something like
W-dangerous-search-path. Otherwise I'll add a new rule to my log
scanner.
(btw. are the sources of the buildd log scanner available)
The scanner itself is available at git://anonscm.debian.org/qa/bls.git,
the rules are embedded in their descriptions at
http://anonscm.debian.org/viewvc/qa/trunk/data/bls/descriptions/
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717486: RFA: xfm -- X file and application manager
Package: wnpp Severity: normal I plan to request removal of xfm, as I think it is no longer useful (libmagic no longer makes definitions available to other packages, so xfm has a outdates copy and most users are no longer capable of using the interface as being trained to expect different behaviour by other graphic file managers. If you still consider it useful and want to maintain it, feel free to contact me or adopt it directly. I plan to request it's removal otherwise. (I'll have it removed from jessie now and currently plan to request removal from unstable after jessie released). The package description is: Xfm is a file and application manager program for the X Window System, based on the Xaw3d widget set. It provides virtually all of the features that you would expect in a file manager; move around your directory tree in multiple windows, move, copy or delete files, and launch programs with simple mouse operations. Directory displays are updated automatically in regular intervals when the contents of the directory change. The integrated application manager provides a kind of shelf onto which you can place your favorite applications, as well as the files and directories you are currently working with. It also allows you to access different groups of applications and files. User-definable file types let you specify a command to be executed when double-clicking on a file or dropping other files onto it. Last not least, xfm can automatically mount and unmount special devices like floppies as you open and close the corresponding directories (mount points). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717487: please keep xfm out of testing (I plan to request removal)
Package: xfm Version: 1.5.4-3 Severity: serious As xfm lost updates to file format detection as libmagic no longer ships magic definitions for other programs and due to its old age, I plan to request removal of xfm. To give anyone a fair warning time, I'm filing this bug to keep it out of testing. I've filed a RFA as #717486, feel free to adopt the package if you want it to live longer instead. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717489: RM: xfm/1.5.4-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove xfm from testing. I plan to drop it (RFA #717486 filed in the unlikely case anyone wants to take it over instead) and have filed #717487 to stop it from migrating back to testing. (I currently plan to request removal from unstable once jessie released (preferable without xfm)). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714418: new dak extra source feature causes problems for reprepro systems pulling from debian testing
* peter green plugw...@p10link.net [130629 04:27]: For some time now dak has been keeping arround extra versions of source packages to satisfy built-using. Recently dak also started including them in packages files marked with the extr control field Extra-Source-Only: yes. Extra source versions may be either older or newer than the primary source version. Wanna-build has also been made to ignore packages that are marked with Extra-Source-Only: yes. [...] IMO until/unless reprepro implements proper support for built-using and extra packages to support it packages with Extra-Source-Only: yes should be ignored when updating. This will restore the old behaviour before dak started adding those packages to it's Sources file. Thanks. I'll take a look at the weekend. Until then note that using FilterFormula: Extra-Source-Only (!= yes) in conf/updates you can filter them out manually. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658829: Bug#706895: transition: db5.3
* Ondřej Surý ond...@debian.org [130611 08:27]:
the information from Matthias was correct, and Berkeley DB 6.0 has been
released today, + packaged and uploaded to unstable.
db-defaults has been updated to 6.0 dependencies and uploaded to
experimental.
Are those package also available somewhere while it is still stuck in
NEW? I managed to build something from git but that needed to remove a
patch that already seems to be applied upstream and removing some
signature check to make it build.
I don't expect bigger problems with the transition since I think we went
through the biggest hell when transitioning from db4.{7,8} to db5.1, but
there might be still some packages which will need some patching to support
major version bump (although I think I have provided patches for most of
those when the bump from 4 to 5 happened).
The API changes from 5 - 6 at least break reprepro.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698648: zconf.h not cross-compiler safe
* Mark Brown broo...@debian.org [130522 20:01]: On Wed, May 22, 2013 at 07:40:55PM +0200, Bernhard R. Link wrote: If the issue is only that the file is broken when zlib is compiled with a cross compiler, wouldn't make more sense to simply fail the build if a cross-compiler is used, instead of introducing the hack of moving the file to an architecture specific directory? (Assuming there are no other bugs in that file making it architecture specific). You haven't provided any context here so it's difficult to tell what you're talking about... I tried opening a web browser and looking at the bug log but it's pretty hard to associate your comments with the report, this is nothing to do with building the package since Debian package builds are always native. The original bug reports says | Because the test is built with the cross-compiler when cross-compiling | it will (in general) not be able to run so if this package is | cross-built then that line is not replaced. If it is built natively | then it is replaced. i.e cross and natively built packages have | different zconf.h files This is a problem when bootstrapping a new | architecture when low-level libraries like this must be cross-built | until the arch is self-hosting. So the only verified case of zconf.h depending on a Debian system on the build (which would make it not safe for /usr/include in the current state but needing /usr/include/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/) is about cross-compile architectures. As you say, Debian packages are usually always build natively, so if it only fails with cross-compiling, it might not be worth the hassle to move it into a subdirectory of /usr/include (which causes other problems, including but not limited to #707537). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698648: zconf.h not cross-compiler safe
If the issue is only that the file is broken when zlib is compiled with a cross compiler, wouldn't make more sense to simply fail the build if a cross-compiler is used, instead of introducing the hack of moving the file to an architecture specific directory? (Assuming there are no other bugs in that file making it architecture specific). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707951: popularity-contest: please leak less private information
* Bill Allombert bill.allomb...@math.u-bordeaux1.fr [130512 12:39]: On Sun, May 12, 2013 at 11:53:17AM +0200, Bernhard R. Link wrote: Package: popularity-contest Version: 1.57 Please do not send second resolution information about program usage. Best only send out information what is actually used by the resulting graphs (i.e. a per-package NO-FILES/OLD/RECENT-CTIME/VOTE information and nothing else). I am considering rounding the number of second to the next multiple of 24h. However, unless you are using strictatime, you probably do not leak much information already. Doesn't relatime update atime when it is older than a day? So doesn't relatime/strictatime just change from second of last use before popcon run so second of first use in a 24 hours window, but still exact to a second? It is important the vote determination is done in a centralised way. How does that prevent not sending timestamps? Additionally it would be nice to have a blacklist of packages to not send information from. Or perhaps some filter on packagename (mycompany-*) or sections (local/*). I am considering to allow packages to opt out of popcon by adding a control field like X-Popcon: no. Would that be suitable ? That means you have to consider that when creating packages, which would be quite complicated to get retroactively. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707951: popularity-contest: please leak less private information
* Bill Allombert bill.allomb...@math.u-bordeaux1.fr [130519 23:24]: Doesn't relatime update atime when it is older than a day? So doesn't relatime/strictatime just change from second of last use before popcon run so second of first use in a 24 hours window, but still exact to a second? Not exactly. It is only updated if it is 24 hour old. So you get the exact time of an event you cannot qualify. This is the stopped watch fallacy. The worst case with strictatime is a program called less than once per day, where popcon sends out total usage information. With relatime exactly the same happens. It is important the vote determination is done in a centralised way. How does that prevent not sending timestamps? If you do not have the timestamps, then you have to rely on the client computation being correct. So you can trust clients to collect correct timestamps, but not to compare them? I do not understand. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708181: requests password to boot
Package: grub-pc
Version: 2.00-14
Severity: important
After upgrading to 2.00-14, grub asks for a password at boot time and
no longer boots unless the superuser password is entered.
-- Package-specific info:
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
terminal_input console
terminal_output console
set timeout=1
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option 'gnulinux-simple-redacted' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'
redacted
else
search --no-floppy --fs-uuid --set=root redacted
fi
echo'Loading Linux 3.8-1-amd64 ...'
linux /boot/vmlinuz-3.8-1-amd64 root=UUID=redacted ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.8-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-redacted' {
menuentry 'Debian GNU/Linux, with Linux 3.8-1-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.8-1-amd64-advanced-redacted' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
--hint='hd0,msdos1' redacted
else
search --no-floppy --fs-uuid --set=root redacted
fi
echo'Loading Linux 3.8-1-amd64 ...'
linux /boot/vmlinuz-3.8-1-amd64 root=UUID=redacted ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.8-1-amd64
}
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.2.0-4-amd64-advanced-redacted' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
--hint='hd0,msdos1' redacted
else
search --no-floppy --fs-uuid --set=root redacted
fi
echo'Loading Linux 3.2.0-4-amd64 ...'
linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=redacted ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-4-amd64
}
menuentry 'Debian GNU/Linux, with Linux 3.2.0-3-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.2.0-3-amd64-advanced-redacted' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
--hint='hd0,msdos1' redacted
else
search --no-floppy --fs-uuid --set=root redacted
fi
echo'Loading Linux 3.2.0-3-amd64 ...'
linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=redacted ro quiet
Bug#707951: popularity-contest: please leak less private information
Package: popularity-contest Version: 1.57 Please do not send second resolution information about program usage. Best only send out information what is actually used by the resulting graphs (i.e. a per-package NO-FILES/OLD/RECENT-CTIME/VOTE information and nothing else). Without that installing popularity-contest on any computers with actual users is simply impossible, as it is too much of a hassle to get consent from all the users (not too speak about even explaining them what you seek consent for), as given that much information there is simply no way to can legally run it without informed consent. Additionally it would be nice to have a blacklist of packages to not send information from. Or perhaps some filter on packagename (mycompany-*) or sections (local/*). Bernhard R. Link P.S: I thought that was old news, but I was told it is not, so here your bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
