Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

[Damien Wyart]

Hi,

The problem is discussed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512

In the meantime, a workaround is to add

-fno-printf-return-value to CFLAGS.

Best regards

Damien

Bug#792854: [pkg-dhcp-devel] Bug#792854: isc-dhcp-client: Dhclient fails to set hostname

[Michael Gilbert]

On Mon, Nov 21, 2016 at 8:49 AM:
> Hello!
>
> I've also faced the bug. And it's also mentioned here:
> http://blog.schlomo.schapiro.org/2013/11/setting-hostname-from-dhcp-in-debian.html
>  .
>
> It's caused incorrect if in file /sbin/dhclient-script

Does the fix applied for #604883 help?  That's been in
testing/unstable for a while now, and all of the messages in this bug
log have been about the jessie package.

Best wishes,
Mike

Bug#841153: eatmydata-udeb: Use /etc/ld.so.preload instead of /etc/apt/apt.conf.d/95install-dpkg-eatmydata?

[Petter Reinholdtsen]

Control: reassign -1 eatmydata-udeb
Control: found -1 105-4

Thomas Lange came up with two other speed improvements.  When using ext*
file systems, mounting with barrier=0 should speed up disk writes.  Also,
placing /var/lib/dpkg/ in ramfs will speed up all dpkg operations.

I believe both could be done using d-i hooks.

-- 
Happy hacking
Petter Reinholdtsen

Bug#845687: [Pkg-protobuf-devel] Bug#845687: protobuf: FTBFS on ppc64el: testMergeFrom segmentation fault

[GCS]

Hi,

On Fri, Nov 25, 2016 at 9:34 PM, Aaron M. Ucko  wrote:
> Source: protobuf
> Version: 3.0.0-8
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest ppc64el build of protobuf failed:
[...]
> Could you please take a look?
 There are two problems and the first have a proposed patch. It seems
to be working, but the 'testMergeFrom' Python 3 check seem to still
fail sometimes, sometimes working at least on armel. I'll post more as
I know more details.

May you have a local ppc64el machine? What happens if you try the
build say three - four times?

Thanks,
Laszlo/GCS

Bug#823910: debian-policy: document Build-Depends-Arch/Build-Conflicts-Arch and when it's safe to use them

[Stuart Prescott]

Hi josch,

Thanks for putting together the necessary documentation for Build-Depends-
Arch and Build-Conflicts-Arch.

> Could somebody please comment on the patch? I'd like to fix its problems
> if they exist.

Your patch looks good to me.

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist

[Steve M. Robbins]

Package: libc6
Version: 2.24-7
Severity: normal

Tried to install libc6:i386 but cannot.

$ sudo apt-get install libc6:i386
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 cli-common : Depends: perl but it is not going to be installed
 libc6 : Breaks: libc6:i386 (!= 2.24-7) but 2.24-5 is to be installed
 libc6:i386 : Breaks: libc6 (!= 2.24-5) but 2.24-7 is to be installed
[...]

I don't know how to make sense of these "breaks" versions.  libc6
doesn't even have a revision -7.  Should both of those be
"breaks ... != 2.24-6"?

-Steve


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.2.1-5

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  cdebconf [debconf-2.0]  0.219
ii  debconf [debconf-2.0]   1.5.59
ii  glibc-doc   2.24-7
ii  libc-l10n   2.24-7
ii  locales 2.24-7

-- debconf information:
* glibc/disable-screensaver:
  glibc/kernel-too-old:
* glibc/upgrade: true
* glibc/restart-services: spamassassin samba openbsd-inetd exim4 cron atd 
apache2
  glibc/kernel-not-supported:
  glibc/restart-failed:
* libraries/restart-without-asking: true

Bug#474528: Remove package from unstable

[Dr. Tobias Quathamer]

control: reassign -1 ftp.debian.org
control: retitle -1 RM: mffm-timecode -- RoQA; orphaned, low popcon

Dear FTP-Masters,

please remove the package mffm-timecode. The last activity has been five 
years ago, see this bug for details. The only reverse dependency (wsola) 
has also long been removed from unstable:


$ dak rm -nR mffm-timecode
Will remove the following packages from unstable:

mffm-timecode |  1.6-2 | source
mffm-timecode-dev |  1.6-2 | all

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#845266: R: Bug#845266: ITP: node-cliui -- easily create complex multi-column CLIs

[Pirate Praveen]

On Friday 25 November 2016 05:09 PM, Paolo Greppi wrote:
> Yes but I am stuck with node-wrap-ansi, tests are failing  fot some
> issue with node-chalk. See my message to pkg-javascript earlier this week.

We can enable tests later, many a times the issue is test environment
not the code. You can ask upstream for help as well.

> I'm on the move now, will push my node-wrap-ansi and node-cliui repos
> later today.
> 

ok.



signature.asc
Description: OpenPGP digital signature

Bug#845720: gnupg: missing dependency on dirmngr

[Heinrich Schuchardt]

Package: gnupg
Version: 2.1.15-9
Severity: normal

Dear Maintainer,

on a fresh system setup with debootstrap I got the following output:

gpg --list-keys 79BE3E4300411886 || \
gpg --keyserver keys.gnupg.net --recv-key 79BE3E4300411886
gpg: directory '/home/user/.gnupg' created
gpg: can't open '/usr/share/gnupg/dirmngr-conf.skel': No such file or directory
gpg: new configuration file '/home/user/.gnupg/gpg.conf' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: error reading key: No public key
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/run/user/1000/gnupg/S.dirmngr' failed: No such 
file or directory
gpg: keyserver receive failed: No dirmngr

Please, add the missing dependency on package dirmngr.

Best regards

Heinrich Schuchardt

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.9.0-rc6-next-20161124-1-gbf7e142 (SMP w/4 CPU cores; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-9
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-5
ii  libgcrypt201.7.3-2
ii  libgpg-error0  1.25-1
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-1
ii  libsqlite3-0   3.15.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b3

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-9
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#832342: sitesummary: SiteSummary.pm fails to extract information w/ recent stretch linux-images

[Petter Reinholdtsen]

The following patch get rid fo the hardcoded eth0/eth1 entries in sitesummary.

I am unsure what ordering should be used to avoid using interfaces like virbr0
when deciding how to identify a machine.

diff --git a/SiteSummary.pm b/SiteSummary.pm
index e9f2a93..ad90031 100644
--- a/SiteSummary.pm
+++ b/SiteSummary.pm
@@ -207,19 +207,15 @@ sub get_primary_macaddress {
 #
 sub get_unique_ether_id {
 my $ifconfigoutput = shift;
-my $eth0mac;
-my $eth1mac;
-my $eth2mac;
+my %macs;
 open(IFCONFIG, $ifconfigoutput) || return undef;
 while () {
 chomp;
-$eth0mac = $1 if (m/^eth0\s+Link encap:Ethernet  HWaddr (\S+)/);
-$eth1mac = $1 if (m/^eth1\s+Link encap:Ethernet  HWaddr (\S+)/);
-$eth2mac = $1 if (m/^eth2\s+Link encap:Ethernet  HWaddr (\S+)/);
+$macs{$1} = $2 if (m/^(\w+)\s+Link encap:Ethernet  HWaddr (\S+)/);
 }
 close (IFCONFIG);
-#print STDERR "MAC: $eth0mac\n";
-my $mac = $eth0mac || $eth1mac || $eth2mac || "unknown";
+my $if = (sort keys %macs)[0];
+my $mac = $macs{$if};
 return lc("ether-$mac");
 }
 
diff --git a/sitesummary-nodes b/sitesummary-nodes
index a889fe7..cb9108e 100755
--- a/sitesummary-nodes
+++ b/sitesummary-nodes
@@ -145,7 +145,15 @@ sub is_remote_nagios_client {
 sub get_switch_info {
 my $hostid = shift;
 my %switch = ();
-for my $if (qw(eth0 eth1)) {
+my $ifconfigoutput = get_filepath_current($hostid, "/system/ifconfig-a");
+my %ifs;
+open(IFCONFIG, $ifconfigoutput) || return ();
+while () {
+chomp;
+$ifs{$1} = $2 if (m/^(\w+)\s+Link encap:Ethernet  HWaddr (\S+)/);
+}
+close (IFCONFIG);
+for my $if (sort keys %ifs) {
 my $path = get_filepath_current($hostid, "/system/cdpr.$if");
 my ($id, $addr);
 if (open(my $fh, $path)) {

Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2016-11-16 16:32:05)
> Quoting Martin Pitt (2016-11-16 16:17:29)
> > Johannes Schauer [2016-11-16 14:13 +0100]:
> > > I have another autopkgtest-specific question. Currently, when using this
> > > code with sbuild and I hit Ctrl+C to send a SIGINT, it appears as if
> > > autopkgtest would immediately call hook_cleanup(). Can that be? How do I
> > > prevent that from happening? It only happens with my uchroot backend and
> > > not any other, so I'm probably doing something wrong. Trapping SIGINT in
> > > the shell script doesn't seem to have any effect.
> > 
> > Right, lib/VirtSubproc.py does that in prepare(). The idea was that ^C
> > would cleanly shut down the virt runner, then the frontend
> > (autopkgtest) would notice and do its cleanup part.
> > 
> > How is calling hook_cleanup() not working/not enough for uchroot? We can
> > certainly make that more flexible if needed.
> 
> Then I still don't understand something. In sbuild, when I hit ^C, the
> autopkgtest schroot backend does not seem to get closed immediately because
> sbuild is still doing some cleanup stuff before sending the "close" command to
> autopkgtest.
> 
> But with the autopkgtest uchroot backend, the hook_cleanup() seems to get
> immediately called after my ^C, thus the cleanup code will fail and the 
> "close"
> command will be futile because the autopkgtest pipe does not even exist 
> anymore
> at that point.
> 
> So I don't understand this difference in behaviour.

I think I got it now.

So if I use sbuild with the autopkgtest schroot backend, and then press Ctrl+C
during dpkg-buildpackage, the following will happen:

 - the hook_cleanup() of autopkgtest-virt-schroot is called
 - schroot is unable to close the session because it cannot unmount stuff that
   is still used by sbuild. It thus sleeps for one second.
 - sbuild starts cleaning up some stuff... time passes...
 - schroot tries again to close the session and fails again for the same
   reason. Waits another second...
 - sbuild does some more things, finally releasing its last use of stuff inside
   the chroot and sends an explicit "close" to autopkgtest
 - schroot tries again to close the session - this time succeeds

With the uchroot autopkgtest backend, hook_cleanup() is also called
immediately.  But in contrast to the schroot autopkgtest backend, the
hook_cleanup() will immediately try wiping the whole rootfs and succeed in
doing so. This in turn will lead to further cleanup actions by sbuild after a
failed build to fail because the chroot already became unusable.

I don't know what the best course of action here is. Should sbuild expect that
after the user presses Ctrl+C, the autopkgtest backend takes care to completely
shut down the backend by itself? I don't think this is a viable option because
the autopkgtest backend used by sbuild might be one that carries over changes
made by sbuild to the next session. And in that cases, the session must not
just close under sbuild's feet but sbuild must be given the chance to clean up
after itself after the user cancelled the build with Ctrl+C.

Is there an existing way that would allow me to kill a job I run via
autopkgtest (after the user pressed Ctrl+C) which does *not* switch off the
whole session but allows sbuild to do its cleanup duties and then explicitly
send the "close" itself after it's done?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#521883: adduser: Please accept underscore prefixed system names

[Afif Elghraoui]

Control: tag -1 + confirmed

على الخميس 24 تشرين الثاني 2016 ‫16:30، كتب Guillem Jover:
>> I am also in favor of reducing unnecessary incompatibilities that can
>> > cause confusion. People of #432562, do you have any comments?
> At least Ian seemed to retract his previous support for Debian-style
> names in ,
> but I'll let him confirm this.
> 
> I also think allowing Debian-style names by default would be a bad
> idea, and I'm glad that bug is marked as wontfix. ;)

I thought that bug report was simply about using a capital letter
prefix, not necessarily [dD]ebian-* (especially since it was an
Ubuntu-proposed change). Anyway...

> 
> (You might also like to check the thread starting at
> .)

Many thanks for these links. I've read through all of them, as well as
the much older threads and tickets that were linked from these discussions.

Since considering underscore-prefixed names as a valid format for system
user accounts does not necessarily mandate its use, I have no problem
accepting this. The campaign for making it the resolution of #248809 is
another matter.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*

[Cyril Brulebois]

Cyril Brulebois  (2014-03-16):
> Control: severity -1 important
> 
> Colin Watson  (2014-03-15):
> > On Sat, Mar 15, 2014 at 12:37:17PM +0100, Cyril Brulebois wrote:
> > > I'm tempted to commit the '--' addition in debian-installer for now
> > > anyway, including a comment pointing here, and to lower the severity
> > > to important (since other callers might be affected as well).
> > > 
> > > Does that look OK to you?
> > 
> > It's not ideal, but I think it's reasonable for now, yes.
> 
> Great, thanks for the confirmation, and also for the initial suggestion;
> pushed on the d-i side as:
>   
> http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=d85d105

kfreebsd-* builds are now failing to build with:
| # Create the ISO with Joliet extensions, needed for win32-loader.ini
| # NOTE: "-- -J" is a workaround for #741656 in grub-common
| grub-mkrescue --output=./tmp/netboot-10/mini.iso ./tmp/netboot-10/cd_tree -- 
-J
| xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.
| 
| xorriso : FAILURE : Not a known command:  '-J'
| 
| xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
| install -m 644 -D ./tmp/netboot-10/mini.iso dest/netboot-10/mini.iso
| install: cannot stat './tmp/netboot-10/mini.iso': No such file or directory
| Makefile:798: recipe for target 'dest/netboot-10/mini.iso' failed

I think that started with grub2 (2.02~beta3-1) reaching unstable:
  https://tracker.debian.org/news/805858

as upload timing would match the start of the FTBFS according to graphs
on the summary page:
  https://d-i.debian.org/daily-images/daily-build-overview.html

Also, util/grub-mkrescue.c's argument handling got changed between grub2
2.02~beta2-36 and 2.02~beta3-1.


KiBi.


signature.asc
Description: Digital signature

Bug#845719: gitlab produces 500 errors if it detects a license

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

I migrated from a custom gitlab installation to the debian gitlab package 
today, and found that
attempting to view one of my git repositories was giving a 500 error.

When this occurred, the log gave:

ActionView::Template::Error ('gpl-3.0' is not a valid license key):
38: 
39:   - if @repository.license_blob
40: %li
41:   = link_to license_short_name(@project), license_path(@project)
42: 
43:   - if @repository.contribution_guide
44: %li
  app/helpers/projects_helper.rb:118:in `license_short_name'
  app/views/projects/show.html.haml:41:in 
`_app_views_projects_show_html_haml__3251184896114945331_47088563639140'
  lib/gitlab/request_profiler/middleware.rb:15:in `call'
  lib/gitlab/middleware/go.rb:16:in `call'



Some more tracking down of the issue (and comparing to my previous working
setup) suggests that the problem may be a problem with ruby-licensee package:
the debian package doesn't contain the
vendor/choosealicense.com/_licenses/*.txt files, but the ruby-licensee code
expects to find them in ../../vendor/choosealicence(etc.)

Thus gitlab and/or ruby-licensee seem to be (correctly) identifying the project
as GPLv3 licensed, and try to get some information about the license, but it
fails because the expected files don't exist.

I tried creating a /usr/lib/ruby/vendor symlink to
~/src/ruby-licensee-8.0.0/vendor (so that it can temporarily find the expected
files via the symlink into my `apt-get source' download directory) and this
cleared up the problem: the 500 error disappears and gitlab works again, with
the license showing "GNU GPLv3", which is presumably the license short name
that it gets from ruby-licensee.


(I realize, given the above, this bug probably belongs against ruby-licensee,
but since it seems to be packaged entirely for the benefit of gitlab, I thought
filing against gitlab might get the problem noticed faster).


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  apache2 [httpd]   2.4.23-7
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b2
ii  bundler   1.12.5-3
ii  debconf [debconf-2.0] 1.5.59
ii  git   1:2.10.2-3
ii  gitlab-shell  3.6.6-1
ii  gitlab-workhorse  0.8.5+debian-3
ii  init-system-helpers   1.46
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161101
ii  nodejs4.6.1~dfsg-1
ii  openssh-client1:7.3p1-3+b1
ii  postfix [mail-transport-agent]3.1.3-2
ii  postgresql-client 9.6+177
ii  postgresql-client-9.5 [postgresql-client  9.5.4-3
ii  postgresql-client-9.6 [postgresql-client  9.6.0-1
ii  postgresql-contrib9.6+177
ii  rake  10.5.0-2
ii  redis-server  3:3.2.5-2
ii  ruby  1:2.3.0+4
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-1
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-3
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-3
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails

Bug#845716: Acknowledgement (gcc-4.9: "#define something" doesn't work)

[Stiepan Aurélien Kovac]

Please close this bug: I have first tried to submit it upstream but it
seemingly failed (server timeouts), so I decided to submit it here. In
fact the bug was still somehow submitted and in the meantime, upstream
dev pinskia solved it "

PPORT_FTP is used as an enum which is what is causing the issue. I am
generating a testcase which shows why the error message is not clear.

"


On 11/26/16 05:03, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   cont...@it-kovac.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian GCC Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 845...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#845718: maildir-filter: link against -lpcre in LIBS instead of LDFLAGS

[Logan Rosen]

Package: maildir-filter
Version: 1.20-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

LDFLAGS should only be used for linker options, not for libraries to link
against. Putting libraries here breaks linkers that use the --as-needed flag
(such as in Ubuntu), since they expect the libraries after the files that
need them.

LIBS should be used instead.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: Remove -lpcre from DEB_LDFLAGS_MAINT_APPEND; it doesn't
belong in that Makefile variable.
  * debian/patches/makefile_flags_and_dir: Update to add -lpcre to the LIBS
variable.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru maildir-filter-1.20/debian/patches/makefile_flags_and_dir maildir-filter-1.20/debian/patches/makefile_flags_and_dir
--- maildir-filter-1.20/debian/patches/makefile_flags_and_dir	2016-09-16 18:31:51.0 -0400
+++ maildir-filter-1.20/debian/patches/makefile_flags_and_dir	2016-11-25 23:07:21.0 -0500
@@ -3,15 +3,14 @@
 Samuel Henrique 
 Last-Update: 2016-09-16
 
-Index: maildir-filter-1.20/Makefile
-===
 maildir-filter-1.20.orig/Makefile
-+++ maildir-filter-1.20/Makefile
-@@ -1,11 +1,10 @@
+--- a/Makefile
 b/Makefile
+@@ -1,11 +1,11 @@
  CC=gcc
 -CFLAGS=-O6 -pipe -g -Werror -Wall
 -LDFLAGS=-lpcre
  BINNAME=maildir-filter
++LIBS+=-lpcre
  
  all: maildir-filter
  
@@ -20,7 +19,7 @@
  	cp maildir-filter $(DESTDIR)/usr/bin/${BINNAME}
  	chmod 755 $(DESTDIR)/usr/bin/${BINNAME}
  	chown root.root $(DESTDIR)/usr/bin/${BINNAME}
-@@ -15,6 +14,7 @@ update-templates:
+@@ -15,6 +15,7 @@
  	-xgettext -d maildir-filter -j -o po/maildir-filter.pot -k_ -T maildir-filter.c 
  
  maildir-filter: maildir-filter.o
diff -Nru maildir-filter-1.20/debian/rules maildir-filter-1.20/debian/rules
--- maildir-filter-1.20/debian/rules	2016-09-16 18:31:24.0 -0400
+++ maildir-filter-1.20/debian/rules	2016-11-25 23:03:42.0 -0500
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_LDFLAGS_MAINT_APPEND = -lpcre
 
 %:
 	dh $@

Bug#841090: Why not just set signal handlers?

[Dmitry Bogatov]

Hello!

Dear maintainer, can you please explain, why can't dgit just setup
signal handlers to value to wanted value instead of aborting?

I just took time to explore dgit and discovered, that it does not work
under dvtm or dtach (did not tested screen or tmux).

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp65k_d2OGeE.pgp
Description: PGP signature

Bug#845308: Sponsoring imagemagick/8:6.8.9.9-5+deb8u6

[Luciano Bello]

On Friday, 25 November 2016 17:42:13 EST Bastien Roucaries wrote:
> Can i add a newer patch fixing the last cve ?

Do you think you can upload it for tomorrow? Let me unroll everything on this 
end (I already asked for a DSA id, but I think I can put it back). Let me know 
if you can upload to mentors asap.

Cheers, luciano

Bug#845717: RM: gtest -- ROM; Superceded by source package googletest

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal

The binaries produced by source package gtest are now produced by
source package googletest.  So the former is obsolete and can be
removed.

Thanks,
-Steve

Bug#845716: gcc-4.9: "#define something" doesn't work

[Stie]

Package: gcc-4.9
Version: 4.9.2-10
Severity: important

Dear Maintainer,

Tried to build the legacy LineMode web browser, version 0.11a (available on 
browserarchive.org: 
http://cdn.browserarchive.org/worldwideweb/NeXT/WWWLineMode_0.11a.tar.gz)

When issuing the command "make", gcc outputs the following error:
cc -c  -I../../../Implementation/ -I../ ../../../Implementation/HTFTP.c
.../../../Implementation/HTFTP.c:46:20: error: expected identifier before 
numeric constant
 #define IPPORT_FTP 21
^
.../CommonMakefile:52: recipe for target 'HTFTP.o' failed
make: *** [HTFTP.o] Error 1

Note that the line where the error occurs in HTFTP.c is wrapped by an ifndef / 
endif:

#ifndef IPPORT_FTP
#define IPPORT_FTP 21
#endif


Whilst I would expect some compatibility issues with this code from the early 
90s, "#define IPPORT_FTP 21" should work just fine (see also 
http://stackoverflow.com/questions/40804244 for a very similar issue involving 
the same GCC version). 
Something definitely seems broken in this specific version of GCC (4.9.2-10), 
with the way #define directives are processed.
Any confirmation of whether this happens in higher versions would be welcome.



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: should not matter for this bug

Kernel: should not matter for this bug
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-4.9 depends on:
ii  binutils2.25-5
ii  cpp-4.9 4.9.2-10
ii  gcc-4.9-base4.9.2-10
ii  libc6   2.19-18+deb8u6
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc-4.9-dev  4.9.2-10
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-18+deb8u6

Versions of packages gcc-4.9 suggests:
pn  gcc-4.9-doc   
pn  gcc-4.9-locales   
ii  gcc-4.9-multilib  4.9.2-10
pn  libasan1-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath-dbg   
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#823910: debian-policy: document Build-Depends-Arch/Build-Conflicts-Arch and when it's safe to use them

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2016-09-18 08:11:10)
>  - it is already supported by much software in the archive, most importantly
>  it is supported by package builders and installability testers

with the upload of version 1.4, Build-Depends-Arch and Build-Conflicts-Arch are
now also supported by apt.

> Please find attached a patch that documents Build-Depends-Arch and
> Build-Conflicts-Arch.

Could somebody please comment on the patch? I'd like to fix its problems if
they exist.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#845715: debian-policy: Please document that packages are not allowed to write outside their source directories

[Johannes Schauer]

Package: debian-policy
Severity: wishlist
Tags: patch

Hi,

source packages are forced to not write into $HOME by sbuild and
pbuilder, so any package attempting to do so currently FTBFS. It would
be nice to have this requirement be documented in policy. I propose the
following patch:


diff --git a/policy.sgml b/policy.sgml
index 9cd182b..42efd18 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1944,6 +1944,16 @@ zope.
   For packages in the main archive, no required targets
   may attempt network access.

+   
+ None of the required targets must attempt to write outside of the
+ source package package directory tree. An exception to this rule is
+ the use of /tmp which is permitted as long as temporary
+ files are deleted and not re-used by subsequent execution of the
+ target. This is to prevent that source package builds create and
+ depend on state from the outside and thus affect multiple independent
+ rebuilds. Most notably, none of the required targets must attempt to
+ write into $HOME.
+   
 

  The targets are as follows:


Thoughts?

Thanks!

cheers, josch

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Wookey]

On 2016-11-23 18:19 +0100, Didier 'OdyX' Raboud wrote:
> The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up 
> the different outcome possibilities, which would help forming our opinions.
> Not all these options are exclusive, or would need an actual TC decision.
> 
> Here we go:
> 
> B) A fresher version of 'global' is uploaded to experimental 'soon'
>(with or without interested parties' help; with or without a TC decision)
> 
> This would imply:
>  - any interested party would file (and close) Debian bugs for issues and
>regressions (with appropriate severities), to make the 'fitness for a
>stable release' assessment easier, and earlier.

OK, as Punit and I have prepared a current 6.5.5 which would be a
candidate for a 'modern' release, and I think it's useful to have such
a version available for people to test and file bugs against, I will
do a 5-day delayed NMU to experimental. Putting it in experimental
does not imply automatic transtion to stretch, nor block uploads via
unstable, so seems a reasonable thing to do.

This version is not perfect, but it is current with updated
packaging. I'll include details of the known issues in one of the
'please can we have a new version' bugs. I think it's more useful to
have the current state of play avalable than for me to keep messing
with it privately.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#845714: ITP: tpm -- tmux plugin manager

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: tpm
  Version : v3.0.0
  Upstream Author : 2014 Bruno Sutic
* URL : https://github.com/tmux-plugins/tpm
* License : Expat
  Programming Lang: bash
  Description : tmux plugin manager

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#845713: reportbug: Report Bug not asking for a password for email

[Nancy Anthracite]

Package: reportbug
Version: 6.6.6
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? I configured report bug to use my email
saying that it required TLS, gave it the email but I was not asked for a port
or a password and when I tried to submit the report, it did not ask me  for a
password and it timed out.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?  I found $HOME/.reportbugsrc and commented out everything
except the three lines that were recommended.  That gave me a message that the
headers were incorrect, so I read the /etc/reportbugs.conf and went back to
using my email address and added the port and password and that worked.
   * What was the outcome of this action? It is working now.
   * What outcome did you expect instead? Unless it is less difficult to make
it work, many users will not be able to report a bug as rerunning with
-configure does not fix the problem.  I actually had to edit the .reportbugsrc
directly.  I have an earthlink email address, which is pretty common, so I
think a lot of users may be unable to report.




-- Package-specific info:
** Environment settings:
INTERFACE="gtk2"

** /home/nancy/.reportbugrc:
reportbug_version "6.6.6"
mode standard
ui gtk2
email "nanthrac...@earthlink.net"
smtphost "smtpauth.earthlink.net:587"
smtpuser "nanthrac...@earthlink.net"
smtppasswd 
smtptls

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt   1.3.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88~RC4-2
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC4-2
ii  file   1:5.29-1
ii  gnupg  2.1.15-9
ii  python-gtk22.24.0-5.1
ii  python-gtkspellcheck   3.0-1.1
pn  python-urwid   
ii  python-vte 1:0.28.2-5+b1
ii  xdg-utils  1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.3.1
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#828489: Building with OpenSSL 1.0.2 is sufficient for stretch

[Michael Prokop]

close 828489 0.6.9-4
thanks

* Michael Prokop [Sat Nov 26, 2016 at 12:37:27AM +0100]:

> Thanks for the patch, Adrian.
> WFM and I just did a QA upload towards unstable.

Forgot to mention the bug number #828489 in my upload (sorry for
that), closing the bug report hereby

regards,
-mika-


signature.asc
Description: Digital signature

Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)

[Santiago Vila]

Hi.

This is indeed related to localhost entries as you say, not to the
hostname as I believed.

My localhost lines are like this:

127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback

but when I enter the chroot, localhost lines inside the chroot become
like this:

127.0.0.1   localhost
127.0.0.1   localhost ip6-localhost ip6-loopback

This is supposed to be controlled by /etc/schroot/default/nssdatabases,
which reads like this:


# System databases to copy into the chroot from the host system.
#
# 
passwd
shadow
group
gshadow
services
protocols
networks
hosts


Maybe this is just a bug in schroot, for the strange way of "copying"
the /etc/hosts file?

But even in such case: Should we allow packages to FTBFS when the
autobuilder does not have IPv6? It would seems a gratuitous
requirement to me.

Thanks.

Bug#845712: dh-virtualenv: generates symbolic link of python3 interpreter to building directory instead of deployment dir

[anon]

Package: dh-virtualenv
Version: 0.10-1~bpo8+1
Severity: normal



Hi,

when building a .deb packet with a python3 virtual environment and a few 
requirements I've found out, that the symbolic link $ENV/bin/python points to 
/$MYHOMEDIR/$MYBUILDDIR/$MYPACKETDIR/debian/$MYPACKETNAME/$DESTINATIONDIR/bin/python3

I assume, that the correct link destination would be ./python3 instead of the 
absolute path of where the packet has been built. Correct me, if I'm wrong.

debian/rules looks as follows:
#!/usr/bin/make -f
export DH_VIRTUALENV_INSTALL_ROOT=/srv

%:
dh $@ --with python-virtualenv --install-suffix my_app_name --python 
/usr/bin/python3 --builtin-venv --skip-install

I'm going to tweak some options, and maybe I'll dirtyfix this problem by simply 
recreating the link, if the problem remains, but in any case I thought, that 
you want to know, that there's a bug hidden somewhere.




-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-virtualenv depends on:
ii  libjs-sphinxdoc  1.2.3+dfsg-1
ii  python   2.7.9-1
ii  virtualenv   1.11.6+ds-1

dh-virtualenv recommends no packages.

dh-virtualenv suggests no packages.

-- no debconf information

Bug#845710: RFS: mongovi/1.0.0-1 [ITP]

[Tim Kuijsten]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "mongovi"

* Package name: mongovi
  Version : 1.0.0-1
  Upstream Author : me
* URL : https://github.com/timkuijsten/mongovi
* License : ISC
  Section : database

It builds those binary packages:

  mongovi- Command line interface for MongoDB

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/mongovi


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mongovi/mongovi_1.0.0-1.dsc


Regards,

Tim

Bug#845711: RFP: qt5gtk2 -- GTK+2.0 integration plugins for Qt5

[Tom Maneiro]

Package: wnpp
Severity: wishlist

* Package name: qt5gtk2
  Version : 0.3
  Upstream Author : Ilya Kotov , 
* URL : https://bitbucket.org/trialuser02/qt5gtk2
* License : GPL
  Programming Lang: C++
  Description : GTK+2.0 integration plugins for Qt5

This package provides compatibility for using GTK+2.x themes on Qt 5 apps,
starting with Qt version 5.7 which dropped native support for GTK+ themes
(instead moving such support to style plugins, but upstream now only provides
support for GTK+3.x themes)

Bug#845709: genisoimage: Miss-reads configuration file .genisoimagerc

[Richard Betham]

Package: genisoimage
Version: 9:1.1.11-3
Severity: normal

Dear Maintainer,

The configuration file ./.genisoimagerc contains:
COPY=home/rb/private.txt
PUBL=Richard Betham
PREP=Richard Betham
SYSI=Linux/Debian

I gave the command:
genisoimage -o test.iso ~/standards/ 

I expected the computer to read the .genisoimagerc file,
read the directory tree and produce an iso image file.
I hoped for no errors.

 got an error message:
Using ".genisoimagerc"
.genisoimagerc:1: field name 'OPY=' unknown
.genisoimagerc:2: field name 'UBL=' unknown
.genisoimagerc:3: field name 'REP=' unknown
.genisoimagerc:4: field name 'YSI=' unknown
I: -input-charset not specified, using utf-8 (detected in locale 
settings)
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 10396
Path table size(bytes): 94
Max brk space used 21000
505 extents written (0 MB)

genisoimage ignored the contents of ./.genisoimagerc ,
except for giving the above error message.
I tested for this by the command:
isoinfo -d -i test.iso
.

Please alter the code so that the ./.genisoimage file will be read 
correctly.

Thank you very much for maintaining the package genisoimage.

with best regards from
Richard Betham








-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages genisoimage depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u6
ii  libmagic1   1:5.22+15-2+deb8u2
ii  zlib1g  1:1.2.8.dfsg-2+b1

genisoimage recommends no packages.

Versions of packages genisoimage suggests:
ii  cdrkit-doc  9:1.1.11-3
ii  wodim   9:1.1.11-3

-- no debconf information

Bug#100808: Message

[Tania Manuel]

Hello,


Please I need a help.
Please contact me for details.

Best regards,


Miss. Tania Manuel

Bug#780709: vpnc: fails with "Inappropriate ioctl for device"

[Mike Miller]

On Wed, Mar 18, 2015 at 08:25:09 +0100, M. Dietrich wrote:
> the vpn can't be established with the message:
> 
>   vpnc-connect: can't initialise tunnel interface: Inappropriate ioctl 
> for device
> 
> short investigation shows that in case /dev/net/tun does not exists vpnc
> creates it with
> 
>   open("/dev/net/tun", O_RDWR|O_CREAT, 0666) = 3
> 
> after that a call
> 
>   ioctl(5, TUNSETIFF, 0x7fffbc71f7d0) = -1 ENOTTY (Inappropriate ioctl 
> for device)
> 
> fails. if i issue a
> 
>   mknod /dev/net/tun c 10 200
> 
> manually vpnc works fine.

Does this bug still affect your system, with an unpatched vpnc and
vpnc-script?

I see that you reported this in March 2015. This was around the same
time that several related bugs were filed, see #780255 [1] and its
duplicates [2],[3],[4].

I don't know if anything needs to be fixed in either vpnc or
vpnc-script, this was just a temporary problem due to a miscoordination
between updates of the kmod and systemd packages.

Do you think vpnc-script should still be patched? If so can someone get
the patch(es) reviewed and applied upstream?

[1]: https://bugs.debian.org/780255
[2]: https://bugs.debian.org/780256
[3]: https://bugs.debian.org/780295
[4]: https://bugs.debian.org/780299

-- 
mike

Bug#845708: O: libjs-chosen -- select box enhancer for jQuery and Protoype

[David Prévot]

Package: wnpp
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org,
haskell-hoo...@packages.debian.org

I intend to orphan the libjs-chosen package.

The package description is:
 Chosen is a JavaScript plugin that makes long, unwieldy select boxes
 more user-friendly.

Context in #818561, not sure the package is usable anymore (#797166).



signature.asc
Description: OpenPGP digital signature

Bug#845707: python-templayer: Section should be “python”

[Ben Finney]

Package: python-templayer
Version: 1.5.1-3
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python programming
language or libraries. This is, with very few exceptions, the correct
section for any package that primarily installs a Python library.

The package ‘python-templayer’ installs primarily a library, of
interest only to Python programmers or as dependencies to other
packages. It should not be in the “video” section.

Please set the field “Section” appropriately on this package.


First, since the package is already in Debian with a different
section, you need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one, and be sure not
to close this one until that new one is completed.

-- 
 \ “The Things to do are: the things that need doing, that you see |
  `\ need to be done, and that no one else seems to see need to be |
_o__)   done.” —Richard Buckminster Fuller, 1970-02-16 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#845706: RM: node-stringprep [armel] -- RoQA; nodejs no longer available on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

nodejs is no longer available on armel.

Bug#828489: Building with OpenSSL 1.0.2 is sufficient for stretch

[Michael Prokop]

* Adrian Bunk [Fri Nov 25, 2016 at 10:58:19PM +0200]:
> Control: tags -1 patch

> Not a perfect solution but sufficient for stretch is the patch below to 
> use OpenSSL 1.0.2

> The "| libssl-dev (<< 1.1.0~)" is added for backports.
[...]

Thanks for the patch, Adrian.
WFM and I just did a QA upload towards unstable.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#845705: RM: ttf-femkeklaver -- RoQA; binary package now built by src:fonts-femkeklaver

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

ttf-femkeklaver was the only binary package built by src:ttf-femkeklaver

ttf-femkeklaver is now built (as transitional package)
from src:fonts-femkeklaver

Please remove the obsolete ttf-femkeklaver

Please do NOT remove the ttf-femkeklaver package built
from src:fonts-femkeklaver

Thanks

Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)

[Santiago Vila]

On Fri, Nov 25, 2016 at 11:00:38PM +, Luca BRUNO wrote:
> severity 842634 minor
> thanks
> 
> On Sunday, 30 October 2016 23:09:35 UTC Santiago Vila wrote:
> 
> 
> > I wonder what exactly this test "no_lookup_host_duplicates" does.
> > My autobuilder do not have a FQDN, it has just this in /etc/hosts:
> > 
> > public-ip   skywalker1
> > 
> > Is this a bug in my autobuilder? I hope not.
> > 
> > In either case, I would just forward this upstream and disable the
> > test which fails.
> 
> I'm just lowering the severity here to unblock the migration, but I honestly 
> believe your autobuilder is misconfigured. The "no_lookup_host_duplicates" 
> tries to resolve localhost and verify that there aren't ipv4/ipv6 duplicates, 
> however your host is missing an /etc/hosts line for localhost and the test 
> panics.
> I don't have any reference at hand, but I'd consider the environment broken.

Hmm, maybe I did not explain it well enough.

By "it has just this" I was only talking about lines containing the hostname,
not that the line above was the full contents of /etc/hosts.

I have a line for localhost, of course.

I'll repeat the build a few more times to see if this still happens,
but "minor" is probably lowering too much if your intention was to let
this package migrate to testing.

Thanks.

Bug#845704: RM: golang-pq-dev -- RoQA; binary package now built by src:golang-github-lib-pq

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

golang-pq-dev was the only binary package built by src:golang-pq-dev

golang-pq-dev is now built (as transitional package)
from src:golang-github-lib-pq

Please remove the obsolete golang-pq-dev

Please do NOT remove the golang-pq-dev package built
from src:golang-github-lib-pq

Thanks

Bug#845652: [l10n] Updated Spanish translation (es.po) of apt-listbugs

[Francesco Poli]

On Fri, 25 Nov 2016 15:52:26 +0100 Laura Arjona Reina wrote:

[...]
> Hi
> 
> Attached you can find the updated Spanish translation of
> apt-listbugs.
> 
> Thank you

Hello Laura!
Thanks to you for the update.

I will soon push the translation to the public git repository; it will
be included in the next upload.

Your contribution is really appreciated!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgptpg7K1CVeS.pgp
Description: PGP signature

Bug#845703: RM: golang-uuid -- RoQA; binary package now built by src:golang-github-pborman-uuid

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

golang-uuid-dev was the only binary package built by src:golang-uuid

golang-uuid-dev is now built (as transitional package)
from src:golang-github-pborman-uuid

Please remove the obsolete golang-uuid

Please do NOT remove the golang-uuid-dev package built
from src:golang-github-pborman-uuid

Thanks

Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3

[Aurelien Jarno]

On 2016-11-23 09:43, Michael Stapelberg wrote:
> Source: linux
> Severity: wishlist
> Tags: patch
> 
> Thank you for your work on maintaining the Linux kernel in Debian, I really
> appreciate it!
> 
> I am interested in running Debian on the Raspberry Pi 3.
> 
> As per https://github.com/anholt/linux/wiki/Raspberry-Pi-3, the mainline Linux
> kernel in version 4.8 includes support for the Raspberry Pi 3, so we are in
> pretty good shape already.
> 
> However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> noticed that the kernel can’t find any block devices (and hence no root file
> system). This is because the bcm2835-sdhost MMC driver has not actually made 
> it
> into Linux 4.8; it is still under review:
> https://www.spinics.net/lists/arm-kernel/msg513433.html

While this is correct, please note that the BCM2835 has two sdhost
controller, one that can be used for the wireless card and one for the
sdcard. The 4.8 kernel already has support for the other sdhost
controller, namely the iProc one. You can use this one for your root
filesystem as it is built in the Debian kernel.

I guess you have a problem somewhere, maybe in the device tree that
causes the wrong SD controller to be used. I use the device tree that is
provided by the kernel:

|sdhci: sdhci@7e30 {
|compatible = "brcm,bcm2835-sdhci";
|reg = <0x7e30 0x100>;
|interrupts = <2 30>;
|clocks = < BCM2835_CLOCK_EMMC>;
|status = "disabled";
|};

This work since at least kernel 4.8.4-1~exp1.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#845702: RM: libjs-handlebars.runtime -- RoQA; binary package now built by src:libjs-handlebars

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

libjs-handlebars.runtime was the only binary package built
by src:libjs-handlebars.runtime

libjs-handlebars.runtime is now built from src:libjs-handlebars

Please remove the obsolete libjs-handlebars.runtime

Please do NOT remove the libjs-handlebars.runtime package built
from src:libjs-handlebars

Thanks

Bug#842634: [Pkg-rust-maintainers] Bug#842634: rustc: FTBFS (sys_common::net::tests::no_lookup_host_duplicates fails)

[Luca BRUNO]

severity 842634 minor
thanks

On Sunday, 30 October 2016 23:09:35 UTC Santiago Vila wrote:


> I wonder what exactly this test "no_lookup_host_duplicates" does.
> My autobuilder do not have a FQDN, it has just this in /etc/hosts:
> 
> public-ip skywalker1
> 
> Is this a bug in my autobuilder? I hope not.
> 
> In either case, I would just forward this upstream and disable the
> test which fails.

I'm just lowering the severity here to unblock the migration, but I honestly 
believe your autobuilder is misconfigured. The "no_lookup_host_duplicates" 
tries to resolve localhost and verify that there aren't ipv4/ipv6 duplicates, 
however your host is missing an /etc/hosts line for localhost and the test 
panics.
I don't have any reference at hand, but I'd consider the environment broken.

Ciao, Luca

signature.asc
Description: This is a digitally signed message part.

Bug#845701: xrdp: leaves old conffiles on upgrade

[Thorsten Glaser]

Package: xrdp
Version: 0.9.1~20161119+gite8308d5-1+b1
Severity: normal

Upgrading xrdp from 0.9.0~20161027+gitc524b06-1
to 0.9.1~20161119+gite8308d5-1+b1 leaves old conffiles around:

tg@leee:~ $ paxtar -xOf 
/var/cache/apt/archives/xrdp_0.9.1~20161119+gite8308d5-1+b1_i386.deb 
data.tar.xz | paxtar -tJf - | fgrep etc/xrdp
./etc/xrdp
./etc/xrdp/cert.pem
./etc/xrdp/key.pem
./etc/xrdp/km-0407.ini
./etc/xrdp/km-0409.ini
./etc/xrdp/km-040a.ini
./etc/xrdp/km-040b.ini
./etc/xrdp/km-040c.ini
./etc/xrdp/km-0410.ini
./etc/xrdp/km-0411.ini
./etc/xrdp/km-0414.ini
./etc/xrdp/km-0415.ini
./etc/xrdp/km-0416.ini
./etc/xrdp/km-0419.ini
./etc/xrdp/km-041d.ini
./etc/xrdp/km-0807.ini
./etc/xrdp/km-0809.ini
./etc/xrdp/km-080c.ini
./etc/xrdp/km-0813.ini
./etc/xrdp/km-0816.ini
./etc/xrdp/km-100c.ini
./etc/xrdp/km-e0010411.ini
./etc/xrdp/km-e0200411.ini
./etc/xrdp/km-e0210411.ini
./etc/xrdp/pulse
./etc/xrdp/pulse/default.pa
./etc/xrdp/sesman.ini
./etc/xrdp/startwm.sh
./etc/xrdp/xrdp.ini
./etc/xrdp/xrdp_keyboard.ini
tg@leee:~ $ ls /etc/xrdp/
cert.pem km-0410.ini  km-0807.ini  km-0409.ini  km-0416.ini  
km-0816.ini  sesman.ini
key.pem  km-0411.ini  km-0809.ini  km-040a.ini  km-0419.ini  
km-100c.ini  startwm.sh
km-0407.ini  km-0414.ini  km-080c.ini  km-040c.ini  km-041d.ini  
km-e0010411.ini  xrdp.ini
km-0409.ini  km-0415.ini  km-0813.ini  km-0410.ini  km-0807.ini  
km-e0200411.ini  xrdp_keyboard.ini
km-040a.ini  km-0416.ini  km-0816.ini  km-0411.ini  km-0809.ini  
km-e0210411.ini
km-040b.ini  km-0419.ini  km-100c.ini  km-0414.ini  km-080c.ini  
pulse
km-040c.ini  km-041d.ini  km-0407.ini  km-0415.ini  km-0813.ini  
rsakeys.ini

The file /etc/xrdp/km-0407.ini, for example, is one of those that
must be cleaned up by the upgrade (except when aborted) but wasn’t.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xrdp depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-5
ii  libfuse2 2.9.7-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopus0 1.1.3-1
ii  libpam0g 1.1.8-3.3
ii  libssl1.11.1.0c-2
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxrandr2   2:1.5.0-1
ii  lsb-base 9.20161101

Versions of packages xrdp recommends:
ii  xorgxrdp  0.9.1~20161119+gite8308d5-1+b1

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.24-5
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.0-2

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+18

Versions of packages xrdp is related to:
ii  vnc4server [vnc-server]  4.1.1+X4.3.0-39

-- no debconf information

Bug#845700: RM: golang-snappy-go -- RoQA; binary package now built by src:golang-github-golang-snappy

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

golang-snappy-go-dev was the only binary package built
by src:golang-snappy-go

golang-snappy-go-dev is now built (as transitional package)
from src:golang-github-golang-snappy

Please remove the obsolete golang-snappy-go

Please do NOT remove the golang-snappy-go-dev package built
from src:golang-github-golang-snappy

Thanks

Bug#845699: RM: python-dogpile.core -- RoQA; binary packages now built by src:python-dogpile.cache

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The binary packages previously built by src:python-dogpile.core
are now built (as transitional packages) by src:python-dogpile.cache

Please remove the obsolete python-dogpile.core

Please do NOT remove any packages built from src:python-dogpile.cache

Thanks

Bug#845698: RM: golang-prometheus-client -- RoQA; binary package now built by src:golang-github-prometheus-client-golang

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

golang-prometheus-client-dev was the only binary package built
by src:golang-prometheus-client

golang-prometheus-client-dev is now built (as transitional package)
from src:golang-github-prometheus-client-golang

Please remove the obsolete golang-prometheus-client

Please do NOT remove the golang-prometheus-client-dev package built
from src:golang-github-prometheus-client-golang

Thanks

Bug#842195: patch

[Mike Miller]

On Fri, Nov 04, 2016 at 14:02:28 -0500, Brent S. Elmer Ph.D. wrote:
> I have found a fix thanks to Tibor Boesze.  He fixed an older version
> of Ubuntu so I applied the fix to debian.  The only change is in 
> /auth-dialog/main.c.
> 
> @@ -997,6 +997,7 @@ static int get_config (GHashTable *optio
>   if (csd_wrapper && !csd_wrapper[0])
>   csd_wrapper = NULL;
> 
> + openconnect_set_xmlpost(vpninfo, 0);
>   openconnect_setup_csd(vpninfo, getuid(), 1, OC3DUP
> (csd_wrapper));
>   }
> 
> 
> His comments were 
> * Do not attempt to post XML authentication requests when a cds
>  wrapper is configured.
> 
> I have never made a patch before but I tried.  I will attach my attempt
> at a patch.
> 
> Once I make the small change, network-manager-openconnect connects to
> my vpn.
> 
> I am guessing that the change above is doing what 
> --no-xmlpost is doing in the openconnect command line connection that
> works.

Right. But this is not a general solution that can be applied to the
package for everyone.

The openconnect man page describes the --no-xmlpost as a fallback
option. IOW you should not have to use this setting at all. If you need
it to connect to your gateway, there may be some compatibility problem
that needs to be fixed.

Can you report this upstream and help come up with a better fix that
works for you? See /usr/share/doc/openconnect/html/mail.html.

Otherwise all I can do is close this as won't fix, because making
nm-openconnect use --no-xmlpost is not a solution.

-- 
mike

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Vincent Lefevre]

Control: found -1 2:3.3.12-2

On 2016-11-26 09:44:44 +1300, Ben Caradoc-Davies wrote:
> I think that this bug affects only systems that have /usr on a separate
> filesystem.
> 
> I upgraded procps on a system in which /usr is on the root filesystem and
> encountered no problems at boot time.
> 
> Please consider adjusting the title of this report for the benefit of your
> apt-listbugs readers because critical bugs cause apt-get upgrade to prompt
> for user input.

In any case, nothing has changed in procps, i.e. with
procps 2:3.3.12-2, I get:

$ ldd =ps
linux-vdso.so.1 (0x7ffea6b6e000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7fc3129f1000)
libprocps.so.6 => /lib/x86_64-linux-gnu/libprocps.so.6 
(0x7fc3127cd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc3125c9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc31222b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc31200e000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fc311f82000)
^^^
/lib64/ld-linux-x86-64.so.2 (0x55e95d899000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7fc311d5a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc311b52000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc31192c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fc31171a000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fc31140b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fc311196000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fc310f82000)

So, marking as found in 2:3.3.12-2 so that apt-listbugs doesn't
complain in the upgrade.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#832898: simple-cdd: problem with check dependency of local repo

[Vagrant Cascadian]

Control: tags 832898 +pending

On 2016-07-29, Lev Borodin wrote:
> After reprepo simple-cdd use debcheck for check package dependency.
>
>
> For example, if we have non-free deb package with dependency of main deb
> package, debcheck says error dependencies.
> Because simple-cdd don't use -bg option.

Thanks for the patch! Applied to git, will include in a future upload:

  
https://anonscm.debian.org/cgit/collab-maint/simple-cdd.git/commit/?id=a2787130d48155faa6ec945017003ff293fcef24


live well,
  vagrant


>  build-simple-cdd| 20 
>  simple_cdd/tools/mirror_reprepro.py | 22 --
>  2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/build-simple-cdd b/build-simple-cdd
> index 39c1be2..204eff0 100755
> --- a/build-simple-cdd
> +++ b/build-simple-cdd
> @@ -550,14 +550,26 @@ class SimpleCDD:
>  continue
>  yield os.path.join(root, wanted_arch)
>  
> -for pathname in find_packages_dirs(dists_root, a):
> +packages_dirs = find_packages_dirs(dists_root, a)
> +
> +for pathname in packages_dirs:
> +bg_pkgfile = [os.path.join(i, "Packages.gz") for i in 
> packages_dirs if i != pathname]
> +bg_command = []
> +
> +for file in bg_pkgfile:
> +bg_command.append('--bg')
> +bg_command.append(file)
> +
> +command = [debcheck, "--failures", "--explain"]
> +command.extend(bg_command)
> +
>  pkgfile = os.path.join(pathname, "Packages.gz")
>  if not os.path.exists(pkgfile): continue
> -
> +command.append(pkgfile)
>  output = io.StringIO()
>  retval = run_command(
> -"{} {}".format(pkgfile, debcheck),
> -[debcheck, "--failures", "--explain", pkgfile],
> +"distcheck:",
> +command,
>  logfd=output
>  )
>  if retval != 0:
> diff --git a/simple_cdd/tools/mirror_reprepro.py 
> b/simple_cdd/tools/mirror_reprepro.py
> index 6ede389..cdf4b1b 100644
> --- a/simple_cdd/tools/mirror_reprepro.py
> +++ b/simple_cdd/tools/mirror_reprepro.py
> @@ -269,13 +269,31 @@ class ToolMirrorReprepro(ToolShell):
>  return
>  
>  for a in self.env.get("ARCHES"):
> -for component in self.env.get("mirror_components"):
> +mirror_components = self.env.get("mirror_components")
> +for component in mirror_components:
> +
> +bg_pkgfile = [
> +self.env.format(
> +
> "{MIRROR}/dists/{CODENAME}/{component}/binary-{a}/Packages",
> +component=i, a=a)
> +for i in mirror_components if i != component
> +]
> +
> +bg_command = []
> +for file in bg_pkgfile:
> +bg_command.append('--bg')
> +bg_command.append(file)
> +
> +command = [debcheck, "--failures", "--explain"]
> +command.extend(bg_command)
>  pkgfile = self.env.format(
>  
> "{MIRROR}/dists/{CODENAME}/{component}/binary-{a}/Packages",
>  component=component, a=a)
>  if os.stat(pkgfile).st_size == 0: continue
>  log.info("Checking package file %s using %s", pkgfile, 
> debcheck)
> -proc = subprocess.Popen([debcheck, "--failures", 
> "--explain", pkgfile], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
> +command.append(pkgfile)
> +
> +proc = subprocess.Popen(command, stdout=subprocess.PIPE, 
> stderr=subprocess.PIPE)
>  stdout, stderr = proc.communicate()
>  retval = proc.wait()
>  if retval != 0:
> -- 
> 2.7.4


signature.asc
Description: PGP signature

Bug#845697: tracker.debian.org: "Package XY does not exist" when pasting a blank into Jump to package field

[Florian Schlichting]

Package: tracker.debian.org
Severity: wishlist

When accidentally pasting a (leading or trailing) blank into the "Jump
to package..." field, an error message is shown, e.g.

https://tracker.debian.org/search?package_name=+libgetopt-argvfile-perl

"Package libgetopt-argvfile-perl does not exist."

As Debian package names cannot contain leading or trailing blanks, this
should be easy to filter, either client-side with JavaScript but also
server-side, in the application or the webserver config.

Thanks!

Bug#845696: FTBFS on all 32 bit architectures

[Tobias Hansen]

Source: cython
Severity: serious
Version: 0.25.2~b0-1
Control: forwarded -1 https://github.com/cython/cython/issues/1530

Dear maintainer,

the package fails to build on 32 bit architectures. There is already an
upstream bug report and a partial fix.

Best,
Tobias

Bug#828513: proftpd-dfsg: FTBFS with openssl 1.1.0

[Hilmar Preuße]

On 24.11.2016 18:34, Laurent Bigonville wrote:

Hi,

>> Still no solution for this. I've asked upstream if a patch for proftp
>> stable (1.3.5) could be made available[1] too. Not sure if there will be
>> some help.
>> According to [2] one could use libssl1.0-dev as BD instead.
>> Unfortunately this removes libpq-dev, which is needed by our package
>> too. Not sure if the Postgres people will change here so we can use the
>> work around for stretch.
>> Third solution would be to use rc release from upstream and patch from
>> github. I guess I'll have to got this way.
> 
> It seems that the patch has been merged in the 1.3.5 branch too
> 
...but it is not suitable for the code in our git repo. I guess we have
to got to 1.3.5b before. ;-(

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#845695: gnupg1: [INTL:nl] Dutch po file for the gnupg1 package

[Frans Spiesschaert]

 

Package: gnupg1 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch po file for the gnupg1 package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
=== 
 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Bug#845694: openvas-scanner: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: openvas-scanner 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch translation of openvas-scanner debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Ben Caradoc-Davies]

I think that this bug affects only systems that have /usr on a separate 
filesystem.


I upgraded procps on a system in which /usr is on the root filesystem 
and encountered no problems at boot time.


Please consider adjusting the title of this report for the benefit of 
your apt-listbugs readers because critical bugs cause apt-get upgrade to 
prompt for user input.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#845693: nginx: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: nginx 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch translation of nginx debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Bug#845692: mysql-5.7: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: mysql-5.7 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch translation of mysql-5.7 debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Bug#845691: tzdata: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: tzdata 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of tzdata debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

[Meelis Roos]

Package: gcc-6
Version: 6.2.1-5
Severity: normal

Dear Maintainer,

while testing latest 4.9-rc6+ git kernels, I noticed that the kernel
failed to boot very early (only Booting the kernel was displayed) on
multiple machines.

Not that this is not about passing the pie flags to gcc or stack
protector options breaking compilation. That one was worked around in
current development version of the kernel, and for bisecting I had to
patch the kernel by hand.

The patterns so far:

6.2.0-9 is creating working kernels on all computers.

6.2.1-3 and 6.2.1-5 are OK on at least two 32-bit x86 machines tested so
far (Pentium 4 and Athlon MP).

6.2.1-4 and 6.2.1-5 create nonbootable kernels on all x86-64 machines
tested so far (P4 era 64-bit Xeons, 51xx era Xeons, Opteron 2xx, i5 660
at least). Kernel configurations vary - they are available when I go to
the machines physically to restart them to working kernels (maybe
Monday) but differ a lot between the machines (all are optimized for
specific CPU and hardware set for test coverage) so the configuration
does nto seem to be too important.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-rc6-00157-g16ae16c (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-6 depends on:
ii  binutils  2.27.51.20161124-1
ii  cpp-6 6.2.1-5
ii  gcc-6-base6.2.1-5
ii  libc6 2.24-6
ii  libcc1-0  6.2.1-5
ii  libgcc-6-dev  6.2.1-5
ii  libgcc1   1:6.2.1-5
ii  libgmp10  2:6.1.1+dfsg-1
ii  libisl15  0.17.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.5-1
ii  libstdc++66.2.1-5
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-6

Versions of packages gcc-6 suggests:
pn  gcc-6-doc 
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#845683: grub2: /etc/default/grub: incorrect code comment

[Colin Watson]

On Fri, Nov 25, 2016 at 12:18:10PM -0800, Ryan Cunningham wrote:
> The file 'debian/default/grub' in the GRUB 2 source code tree, which
> becomes '/etc/default/grub' when GRUB 2 is installed, has an incorrect
> comment line.  Such a line says that the text-mode terminal only works
> in 'grub-pc'; I have tested the functionality with 'grub-efi-amd64' on
> my MacBook and it works perfectly, with an 80x25 character EFI console
> centered on my MacBook screen.

While this is absolutely true, I unfortunately need to defer applying
your patch for an indefinite time (not intended as a euphemism for
"wontfix").  The problem is that the packaging process for
/etc/default/grub was badly designed and doesn't deal with merging user
changes very well, so essentially any packaging change to this file will
result in a confusing prompt on upgrade (and almost everyone has GRUB
installed, so that's a lot of prompts).  We should certainly fix that at
some point, but until then I've been strenuously avoiding changing this
file in any way.

When we do fix it, I'm somewhat more inclined to just remove these
ad-hoc bits of documentation and instead just leave it to the
documentation reference at the top of the file.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#799609: konsole: Can't fully handle Alt Gr key combination

[Francesco]

Package: konsole
Followup-For: Bug #799609

Dear Maintainer,


  The bug seems to be disappeared, now the Alt Gr key combination works



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages konsole depends on:
ii  kio   5.27.0-2
ii  konsole-kpart 4:16.08.2-2
ii  libc6 2.24-5
ii  libkf5completion5 5.27.0-1
ii  libkf5configcore5 5.27.0-1
ii  libkf5configgui5  5.27.0-1
ii  libkf5configwidgets5  5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  libkf5crash5  5.27.0-1
ii  libkf5dbusaddons5 5.27.0-1
ii  libkf5i18n5   5.27.0-2
ii  libkf5iconthemes5 5.27.0-1
ii  libkf5kiowidgets5 5.27.0-2
ii  libkf5notifyconfig5   5.27.0-1
ii  libkf5widgetsaddons5  5.27.0-1
ii  libkf5windowsystem5   5.27.0-1
ii  libkf5xmlgui5 5.27.0-1
ii  libqt5core5a  5.7.1~20161021+dfsg-5
ii  libqt5gui55.7.1~20161021+dfsg-5
ii  libqt5widgets55.7.1~20161021+dfsg-5
ii  libstdc++66.2.0-13

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#828581: Building with OpenSSL 1.0.2 is sufficient for stretch

[Adrian Bunk]

Control: tags -1 patch

Not a perfect solution but sufficient for stretch is the patch below to 
use OpenSSL 1.0.2

The "| libssl-dev (<< 1.1.0~)" is added for backports.

--- debian/control.old  2016-11-25 21:02:33.0 +
+++ debian/control  2016-11-25 21:02:56.0 +
@@ -2,7 +2,7 @@
 Section: net
 Priority: extra
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 9.0.0), dpkg-dev (>= 1.16.1~), libssl-dev, 
libconfuse-dev, automake, autotools-dev, pkg-config, autoconf
+Build-Depends: debhelper (>= 9.0.0), dpkg-dev (>= 1.16.1~), libssl1.0-dev | 
libssl-dev (<< 1.1.0~), libconfuse-dev, automake, autotools-dev, pkg-config, 
autoconf
 Homepage: http://www.turnserver.org/
 Standards-Version: 3.9.3
 Vcs-Git: git://anonscm.debian.org/pkg-voip/turnserver.git


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#828489: Building with OpenSSL 1.0.2 is sufficient for stretch

[Adrian Bunk]

Control: tags -1 patch

Not a perfect solution but sufficient for stretch is the patch below to 
use OpenSSL 1.0.2

The "| libssl-dev (<< 1.1.0~)" is added for backports.

--- debian/control.old  2016-11-25 19:09:55.0 +
+++ debian/control  2016-11-25 19:10:00.0 +
@@ -10,7 +10,7 @@
  zlib1g-dev,
  comerr-dev,
  e2fslibs-dev (>= 1.25),
- libssl-dev,
+ libssl1.0-dev | libssl-dev (<< 1.1.0~),
  libpam0g-dev,
  gettext
 Standards-Version: 3.9.8


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845689: kcollectd must build-depend on collectd

[Adrian Bunk]

Package: kcollectd
Version: 0.9-3
Severity: serious
Tags: patch

kcollectd cannot currently re-enter testing due to:
- kcollectd/mips64el unsatisfiable Depends: collectd

collectd is currently not available on mips64el due to
tthe following build dependency chain:
collectd -> libvirt -> qemu

Work is ongoing on making qemu available on mips64el,
but for getting kcollectd back into testing in time
for stretch the following patch limits the building
kcollectd to the architectures where collectd is available:

--- debian/control.old  2016-11-25 20:48:24.0 +
+++ debian/control  2016-11-25 20:49:11.0 +
@@ -9,6 +9,7 @@
  libboost-filesystem-dev,
  librrd-dev,
  shared-mime-info,
+ collectd
 Standards-Version: 3.9.8
 Homepage: http://www.forwiss.uni-passau.de/~berberic/Linux/kcollectd.html
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/kcollectd.git

Bug#845688: freefem3d: diff for NMU version 1.0pre10-3.4

[Andrey Rahmatullin]

Package: freefem3d
Version: 1.0pre10-3.3
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for freefem3d (versioned as 1.0pre10-3.4) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -Nru freefem3d-1.0pre10/debian/changelog freefem3d-1.0pre10/debian/changelog
--- freefem3d-1.0pre10/debian/changelog	2015-07-08 17:34:44.0 +0500
+++ freefem3d-1.0pre10/debian/changelog	2016-11-26 00:55:28.0 +0500
@@ -1,3 +1,13 @@
+freefem3d (1.0pre10-3.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper compat level 10 (Closes: #817460).
+  * Add B-D: dh-autoreconf (Closes: #796431).
+  * Drop Christophe Prud'homme from Uploaders (Closes: #835013).
+  * Honor CFLAGS and CXXFLAGS envvars.
+
+ -- Andrey Rahmatullin   Sat, 26 Nov 2016 00:55:28 +0500
+
 freefem3d (1.0pre10-3.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru freefem3d-1.0pre10/debian/compat freefem3d-1.0pre10/debian/compat
--- freefem3d-1.0pre10/debian/compat	2011-09-19 18:30:29.0 +0600
+++ freefem3d-1.0pre10/debian/compat	2016-11-26 00:55:28.0 +0500
@@ -1 +1 @@
-4
+10
diff -Nru freefem3d-1.0pre10/debian/control freefem3d-1.0pre10/debian/control
--- freefem3d-1.0pre10/debian/control	2014-02-16 14:02:09.0 +0600
+++ freefem3d-1.0pre10/debian/control	2016-11-26 00:55:28.0 +0500
@@ -1,12 +1,13 @@
 Source: freefem3d
 Priority: optional
 Maintainer: Debian Science Team 
-Uploaders: Christophe Prud'homme 
 Section: math
 Standards-Version: 3.9.2
 Vcs-Svn: svn://svn.debian.org/svn/debian-science/packages/freefem3d/trunk/
 Vcs-Browser: http://svn.debian.org/viewsvn/debian-science/packages/freefem3d/trunk/
-Build-Depends: cdbs (>= 0.4.23-1.1), autotools-dev, debhelper (>= 4.1.0), automake1.11, libtool (>= 1.5), doc-base, bison, texlive, texlive-latex-extra
+Build-Depends: cdbs (>= 0.4.23-1.1), autotools-dev, debhelper (>= 10),
+ automake1.11, libtool (>= 1.5), doc-base, bison, texlive, texlive-latex-extra,
+ dh-autoreconf
 
 Package: freefem3d
 Architecture: any
diff -Nru freefem3d-1.0pre10/debian/patches/compile-flags.patch freefem3d-1.0pre10/debian/patches/compile-flags.patch
--- freefem3d-1.0pre10/debian/patches/compile-flags.patch	1970-01-01 05:00:00.0 +0500
+++ freefem3d-1.0pre10/debian/patches/compile-flags.patch	2016-11-26 00:55:28.0 +0500
@@ -0,0 +1,26 @@
+Description: Honor CFLAGS and CXXFLAGS environmen vars.
+Author: Andrey Rahmatullin 
+Last-Update: 2016-11-26
+
+Index: freefem3d-1.0pre10/m4/compile.m4
+===
+--- freefem3d-1.0pre10.orig/m4/compile.m4
 freefem3d-1.0pre10/m4/compile.m4
+@@ -70,13 +70,13 @@ dnl Check debugging mode for compilation
+ 
+   if test $ac_use_debug_code = "yes"
+   then
+-CXXFLAGS="-g -Wall"
+-CFLAGS="-g -Wall"
++CXXFLAGS="$CXXFLAGS -g -Wall"
++CFLAGS="$CFLAGS -g -Wall"
+   else
+ if test $ac_use_opt_code = "yes"
+ then
+-  CXXFLAGS="-Wall -DNDEBUG -O2 -funroll-all-loops -fargument-noalias-global -fno-gcse"
+-  CFLAGS="-Wall -DNDEBUG -O2 -funroll-all-loops -fargument-noalias-global -fno-gcse"
++  CXXFLAGS="$CXXFLAGS -Wall -DNDEBUG -O2 -funroll-all-loops -fargument-noalias-global -fno-gcse"
++  CFLAGS="$CFLAGS -Wall -DNDEBUG -O2 -funroll-all-loops -fargument-noalias-global -fno-gcse"
+ else
+   CXXFLAGS="$CXXFLAGS -Wall -DNDEBUG"
+   CFLAGS="$CFLAGS -Wall -DNDEBUG"
diff -Nru freefem3d-1.0pre10/debian/patches/series freefem3d-1.0pre10/debian/patches/series
--- freefem3d-1.0pre10/debian/patches/series	2015-07-08 17:36:35.0 +0500
+++ freefem3d-1.0pre10/debian/patches/series	2016-11-26 00:55:28.0 +0500
@@ -1 +1,6 @@
+10_gcc44_enum.patch
+20_gcc44_include.patch
+30_gcc47.patch
+40_gcc5.patch
 debian-changes-1.0pre10-3
+compile-flags.patch
diff -Nru freefem3d-1.0pre10/debian/rules freefem3d-1.0pre10/debian/rules
--- freefem3d-1.0pre10/debian/rules	2015-07-08 17:34:51.0 +0500
+++ freefem3d-1.0pre10/debian/rules	2016-11-26 00:55:28.0 +0500
@@ -1,9 +1,15 @@
 #!/usr/bin/make -f
 
+HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
+ifeq ($(HOST_ARCH_CPU), ppc64el)
+	export DEB_CPPFLAGS_MAINT_APPEND = -U__vector
+endif
+
+export DEB_CXXFLAGS_MAINT_APPEND = -std=gnu++98
+
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/autoreconf.mk
-include /usr/share/cdbs/1/rules/simple-patchsys.mk
 
 DEB_AC_AUX_DIR = $(DEB_SRCDIR)/m4
 DEB_CONFIGURE_EXTRA_FLAGS := --enable-optimize --disable-gui
@@ -14,13 +20,6 @@
 DEB_AUTO_UPDATE_AUTOCONF = yes
 DEB_AUTO_UPDATE_AUTOHEADER = yes
 
-HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
-ifeq ($(HOST_ARCH_CPU), ppc64el)
-	CPPFLAGS+=-U__vector
-endif
-
-CXXFLAGS 

Bug#819442: [Pkg-postgresql-public] Bug#819442: postgresql-common: pg_ctlcluster fails if data directory is not in the standard place

[Oliver Elphick]

On Thu, 2016-11-24 at 15:33 +0100, Christoph Berg wrote:
> 
> pg_ctlcluster does pass "-c config_file" to pg_ctl (and in turn to
> postgres), which I believe has been the state of affairs since
> postgresql-common was invented (and possibly even before that, when
> your name was still on the postgresql packages :D). Non-standard
> PGDATA locations are supported and generally work.
> 
> So the problem must have been elsewhere in the interaction of
> postgresql-common with your setup. Can you still reproduce it?

Yes. I am now on 9.6 and it is still happening.

The problem is in specifying -D with the wrong path as a result of
reading the config file for the location of the data directory. -D
actually specifies the location of the config file. The package seems
to be treating -D as specifying the data directory.

$ man pg_ctl
...
   -D datadir
   --pgdata datadir
  Specifies the file system location of the database configuration
  files. If this is omitted, the environment variable PGDATA is
  used.

Bug#845634: Not fixed in sid

[Bastien ROUCARIES]

control: notfixed -1 imagemagick/8:6.9.6.2+dfsg-2

Corrected not fixed in sid, really sorry for this.

Will resend a new sid version

Bug#843885: installer broken: multipath-udeb depends on non-existent libgcc1 udeb

[Cyril Brulebois]

Hi,

Ritesh Raj Sarraf  (2016-11-10):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Thu, 2016-11-10 at 13:48 +0100, Allan Jacobsen wrote:
> > 
> > This bug har been reported earlier as #779579, and it was supposed to be
> > fixed, but it is still present in the current netboot images.
> > 
> > I am using the latest install files from 20160914.
> > 
> > This is a PXE install and i have downloaded linux and initrd.gz from 
> > http://ftp.dk.debian.org/debian/dists/Debian8.6/main/installer-amd64/current/i
> > mages/netboot/debian-installer/amd64/
> > 
> > If i make my own initrd.gz with the libgcc1 file, then the error i gone, 
> > there
> > are other problems then, but i will make a separate bugreport on that. (it 
> > is
> > another package)
> 
> As you mentioned, this was fixed long back. The D-I team would have noticed 
> and
> reported it, if the udeb had such a dependency. I've CCed them. Let's see if
> they have any pointers.

At least at the moment, multipath-udeb doesn't show up here:
  https://d-i.debian.org/dose/#stable

so no obvious issues as far as I can tell.


KiBi.


signature.asc
Description: Digital signature

Bug#773996: assword: Problems with accents in context

[Jameson Graef Rollins]

On Sun, May 08 2016, Jameson Graef Rollins  wrote:
> [ Unknown signature status ]
> On Fri, 26 Dec 2014 23:17:12 +0100 Ivan Vilata i Balaguer  
> wrote:
>> Ivan Vilata i Balaguer (2014-12-26 22:42:15 +0100) wrote:
>> 
>> > […] Maybe it's some kind on encoding problem.  If I dump the database,
>> > I can see that the context is always escaped using ``\u`` (even if
>> > ``\x`` was enough), i.e. it has become ``aix\u00f2``.  There should be
>> > no need of such escaping since JSON documents are UTF-8 native, so
>> > this only adds a chance for encoding errors. […]
>> 
>> Please ignore this, I already checked that this escaping is also native
>> for JSON to fit in ASCII encoding. :-/
>
> Hi, Ivan.  Sorry for the very late reply.
>
> We think the 2to3 conversion we're doing right now will fix this bug.
> We'll be making a new release eminently.

The 0.10 release, which uses python3 in the utility program and seems to
handle accents much better, has been uploaded to unstable.

jamie.


signature.asc
Description: PGP signature

Bug#836819: simple-cdd fails with custom installer

[Vagrant Cascadian]

Control: tags 836819 +pending

On 2016-09-06, Stefan Kisdaroczi wrote:
> simple-cdd fails with custom installer.
> log and patch attached.

Thanks for the patch!

Applied to git, will include in upcoming upload:

  
https://anonscm.debian.org/cgit/collab-maint/simple-cdd.git/commit/?id=3460e24f108d115dc2dd5e2ba5a07246e308


live well,
  vagrant

> rsync: mkdir "/tmp/cdd/tmp/mirror/dists/wheezy/main/installer-i386/current" 
> failed: No such file or directory (2)
> rsync error: error in file IO (code 11) at main.c(674) [Receiver=3.1.1]
> Traceback (most recent call last):
>  File "/usr/bin/build-simple-cdd", line 637, in 
>scdd.build_mirror()
>  File "/usr/bin/build-simple-cdd", line 280, in build_mirror
>self.get_custom_installer()
>  File "/usr/bin/build-simple-cdd", line 299, in get_custom_installer
>subprocess.check_call(["rsync", "--delete", "-aWHr", os.path.join(di_dir, 
> "."), current_installer])
>  File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
>raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['rsync', '--delete', '-aWHr', 
> '../../d-i/i386/.', 'dists/wheezy/main/installer-i386/current/']' returned 
> non-zero exit status 11

> diff -uNrp simple-cdd-0.6.1.orig/build-simple-cdd 
> simple-cdd-0.6.1/build-simple-cdd
> --- simple-cdd-0.6.1.orig/build-simple-cdd2015-08-15 13:00:52.0 
> +0200
> +++ simple-cdd-0.6.1/build-simple-cdd 2016-09-06 09:59:33.076688587 +0200
> @@ -295,7 +295,7 @@ class SimpleCDD:
>  
>  if os.path.isdir(di_dir):
>  log.info("using installer from: %s", di_dir)
> -os.makedirs(di_dir, exist_ok=True)
> +os.makedirs(current_installer, exist_ok=True)
>  subprocess.check_call(["rsync", "--delete", "-aWHr", 
> os.path.join(di_dir, "."), current_installer])
>  
>  def compute_kernel_params(self):


signature.asc
Description: PGP signature

Bug#845687: protobuf: FTBFS on ppc64el: testMergeFrom segmentation fault

[Aaron M. Ucko]

Source: protobuf
Version: 3.0.0-8
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The latest ppc64el build of protobuf failed:

  testMergeFrom (google.protobuf.internal.message_test.Proto3Test) ... 
Segmentation fault
  debian/rules:42: recipe for target 'override_dh_auto_test-arch' failed
  make[1]: *** [override_dh_auto_test-arch] Error 139
  make[1]: Leaving directory '/«PKGBUILDDIR»'
  debian/rules:5: recipe for target 'build-arch' failed
  make: *** [build-arch] Error 2

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#845686: protobuf: FTBFS (32-bit): name 'long' is not defined

[Aaron M. Ucko]

Source: protobuf
Version: 3.0.0-8
Severity: serious
Justification: fails to build from source (but built successfully in the past)

32-bit Linux builds of protobuf failed:

  Traceback (most recent call last):
File "/«PKGBUILDDIR»/python3/google/protobuf/internal/reflection_test.py", 
line 639, in testIntegerTypes
  TestGetAndDeserialize('optional_uint32', 1 << 31, long)
  NameError: name 'long' is not defined

(Non-Linux builds have been failing for other reasons, per #837310.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#845442: udev: does not honor configuration files in /etc/udev/hwdb.d

[Michael Biebl]

Am 25.11.2016 um 20:55 schrieb Michael Biebl:
> Am 23.11.2016 um 14:16 schrieb Norbert Preining:
>> Package: udev
>> Version: 232-6
>> Severity: important
>>
>> Dear all,
>>
>> I have added a config file
>>  /etc/udev/hwdb.d/61-keyboard-local.hwdb
>> containing:
>>  evdev:input:b0003v045Ep00DB*
>>   KEYBOARD_KEY_c022d=pageup
>>   KEYBOARD_KEY_c022e=pagedown
>> to remap the default "zoomin" and "zoomout" to pageup and pagedown.
> 
> Does it work if you rename the file to /etc/udev/hwdb.d/60-keyboard.hwdb?

I'm asking, because /lib/udev/hwdb.d/60-keyboard.hwdb already contains
an entry for evdev:input:b0003v045Ep00DB* and I'm not entirely sure if
you can override an existing entry by adding it again to a file which is
sorted later.
The documentation is clear though, that an existing
/etc/udev/hwdb.d/60-keyboard.hwdb will take precedence over
/lib/udev/hwdb.d/60-keyboard.hwdb


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#840566: (no subject)

[mls]

Seems to be fixed with latest bash update:

bash (4.4-2) unstable; urgency=medium

  * Apply upstream patches 001 - 005.
- Closes: #844299, LP: #1641832.
  * Don't build with PIE. Closes: #842037.

 -- Matthias Klose   Tue, 15 Nov 2016 19:49:00 +0100

Bug#845684: libopenhmd: FTBFS on kFreeBSD: libpthread.so.0 ... missing from command line

[Aaron M. Ucko]

Source: libopenhmd
Version: 0.2.0-2
Severity: important
Justification: fails to build from source

Builds of libopenmhd for kFreeBSD have been failing:

  /usr/bin/ld: ../../src/.libs/libopenhmd.a(libopenhmd_la-platform-posix.o): 
undefined reference to symbol 'pthread_join@@GLIBC_2.3'
  //lib/x86_64-kfreebsd-gnu/libpthread.so.0: error adding symbols: DSO missing 
from command line
  collect2: error: ld returned 1 exit status

Could you please take a look?  Building with -pthread may help.

Thanks!

Bug#845685: neovim-qt: FTBFS on kFreeBSD: tst_neovimconnector fails

[Aaron M. Ucko]

Source: neovim-qt
Version: 0.2.4-1
Severity: important
Justification: fails to build from source

The kFreeBSD build of neovim-qt failed:

Start  2: tst_neovimconnector
   2/12 Test  #2: tst_neovimconnector ..***Failed   15.12 sec
  * Start testing of NeovimQt::Test *
  Config: Using QtTest library 5.7.1, Qt 5.7.1 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 6.2.0 20161109)
  PASS   : NeovimQt::Test::initTestCase()
  QWARN  : NeovimQt::Test::reconnect() MsgpackIO fatal error "IO device needs 
to be sequential"
  PASS   : NeovimQt::Test::reconnect()
  QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
vim_get_api_info()"
  QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
vim_get_api_info()"
  QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
vim_get_api_info()"
  PASS   : NeovimQt::Test::isReady()
  QWARN  : NeovimQt::Test::encodeDecode() Encoding String into MsgpackIODevice 
without an encoding (defaulting to utf8)
  QWARN  : NeovimQt::Test::encodeDecode() Decoding String from MsgpackIODevice 
without an encoding (defaulting to utf8)
  QDEBUG : NeovimQt::Test::encodeDecode() Unknown Neovim function "Array 
vim_get_api_info()"
  PASS   : NeovimQt::Test::encodeDecode()
  FAIL!  : NeovimQt::Test::connectToNeovimTCP() 'SPYWAIT(onError)' returned 
FALSE. ()
 Loc: [/«PKGBUILDDIR»/test/tst_neovimconnector.cpp(62)]
  QWARN  : NeovimQt::Test::connectToNeovimSocket() Neovim fatal error 
"QLocalSocket::connectToServer: Invalid name"
  PASS   : NeovimQt::Test::connectToNeovimSocket()
  QDEBUG : NeovimQt::Test::connectToNeovimEnvEmpty() Unknown Neovim function 
"Array vim_get_api_info()"
  PASS   : NeovimQt::Test::connectToNeovimEnvEmpty()
  QWARN  : NeovimQt::Test::metadataTimeout() Request 0 timed out: 159
  QWARN  : NeovimQt::Test::metadataTimeout() Neovim fatal error "Neovim is 
taking too long to respond"
  PASS   : NeovimQt::Test::metadataTimeout()
  PASS   : NeovimQt::Test::cleanupTestCase()
  Totals: 8 passed, 1 failed, 0 skipped, 0 blacklisted, 15111ms
  * Finished testing of NeovimQt::Test *
  [...]
  92% tests passed, 1 tests failed out of 12

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#845683: grub2: /etc/default/grub: incorrect code comment

[Ryan Cunningham]

Source: grub2
Severity: minor
Tags: patch

The file 'debian/default/grub' in the GRUB 2 source code tree, which
becomes
'/etc/default/grub' when GRUB 2 is installed, has an incorrect comment
line.
Such a line says that the text-mode terminal only works in 'grub-pc'; I
have
tested the functionality with 'grub-efi-amd64' on my MacBook and it
works
perfectly, with an 80x25 character EFI console centered on my MacBook
screen.

Though I am not sure, this functionality may also work with PowerPC, IBM
POWER,
and Sun SPARC machines.

A patch is attached against the GRUB 2 source code tree, which will fix
this
problem.

--- debian/default/grub 2016-11-25 12:02:14.125816399 -0800
+++ debian/default/grub 2016-11-25 12:03:14.685816399 -0800
@@ -14,7 +14,7 @@
 # the memory map information from GRUB (GNU Mach, kernel of
FreeBSD ...)
 #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
 
-# Uncomment to disable graphical terminal (grub-pc only)
+# Uncomment to disable graphical terminal
 #GRUB_TERMINAL=console
 
 # The resolution used on graphical terminal

 -- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#845563: apt-get update which ends up in grub-probe loops near Stack.pm uninitialized value

[Graeme Vetterlein]

On 25/11/16 10:47, David Kalnischkies wrote:

Control: reassign -1 debconf 1.5.56

(version number is a guess from the apt/stable version)

On Thu, Nov 24, 2016 at 04:45:35PM +, Graeme Vetterlein wrote:

In brief. If I attempt to build a docker container using apt-get install , and 
that process kicks off a grub-probe. The probe
fails (because we are in a container)  not a surprise. However this causes 
apt-get install to loop, presumably in the grub specific
setup scripts.

apt has no "setup scripts" and no grub specific pieces. The packages
which are installed carry them with them (if any) and hence any bug with
them is a bug for them, not for the tool unfortunately enough to be
tasked with running them (= dpkg ← apt ← user).

So, reassigning to … debconf (which is another tool tasked by others
with doing stuff…) as "uninitialized value" sounds bad and I have no
idea if it is debconfs or grubs fault…



yes | apt-get install --force-yes --allow-unauthenticated -y lttng-modules-dkms || echo 
"Ignore failure, hope that's OK"

Thanks for the nightmares tonight!

Really, that is some very scary commandline. Are you really sure that
you want (whatever package actually) so desperately that you completely
ignore security AND destroy your system (okay, its a container, but
still) for it? With destroying your system you might be able to live,
but I guess you want to use the container for something later on… bad if
an attacker has already infected it with rootkits due to that command.

Also, there are better ways to answer dpkg-conffile questions and to let
debconf pick the default option than to run 'yes' over them. I can't
give blank advice on that as it depends on what you want to do and stuff
but I would highly suggest looking into it! Some pointers:
DEBIAN_FRONTEND=noninteractive and dpkg --force-conf{new,old,def}.


David,

Probably not as bad as you fear. This actual container I don't want 
(it'll be deleted unused)
I produced it just to show the bug. The container I produced used 
several private repos only.
Authentication did not work with these. If there is rogue code in there 
, it's already inside the company

adding it to a container would be the least of our problems :-)

I'm only doing this to reproduce a build environment  used by another 
group. Once I have it working I'll be moving to

a more up-to-date distro (this was wheezy) .

As an interesting aside. I built this OK in an LXC container. I assume 
this is because the way you build an LXC container
has you manually running apt-get at the command line (so stdin is my 
tty) . I think this is an issue in Docker because
it requires to run "unattended" in a script. I'm guessing as Docker 
popularity grows more of these kind of thing will turn up.


(this is my personal email, I'll forward your notes to work and read the 
hints there, thanks for those)

Anway: On to the actual bug:


  ... < elided>.

debconf: falling back to frontend: Teletype

Creating config file /etc/default/grub with new version
grub-probe: error: cannot find a device for / (is /dev mounted?).
grub-probe: error: cannot find a device for /boot (is /dev mounted?).
grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
Configuring grub-pc
---

You chose not to install GRUB to any devices. If you continue, the boot loader
may not be properly configured, and when this computer next starts up it will
use whatever was previously in the boot sector. If there is an earlier version
of GRUB 2 in the boot sector, it may be unable to load modules or handle the
current configuration file.

If you are already using a different boot loader and want to carry on doing so,
or if this is a special environment where you do not need a boot loader, then
you should continue anyway. Otherwise, you should install GRUB somewhere.

Continue without installing GRUB?
Use of uninitialized value $_[1] in join or string at 
/usr/share/perl5/Debconf/DbDriver/Stack.pm line 111.
grub-probe: error: cannot find a device for / (is /dev mounted?).
grub-probe: error: cannot find a device for /boot (is /dev mounted?).
grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
Use of uninitialized value $_[1] in join or string at 
/usr/share/perl5/Debconf/DbDriver/Stack.pm line 111.
You chose not to install GRUB to any devices. If you continue, the boot loader
may not be properly configured, and when this computer next starts up it will
use whatever was previously in the boot sector. If there is an earlier version
of GRUB 2 in the boot sector, it may be unable to load modules or handle the
current configuration file.

If you are already using a different boot loader and want to carry on doing so,
or if this is a special environment where you do not need a boot loader, then
you should continue anyway. Otherwise, you should install GRUB somewhere.

Continue without installing GRUB?
grub-probe: error: cannot find a device for / (is /dev mounted?).
grub-probe: 

Bug#845442: udev: does not honor configuration files in /etc/udev/hwdb.d

[Michael Biebl]

Am 23.11.2016 um 14:16 schrieb Norbert Preining:
> Package: udev
> Version: 232-6
> Severity: important
> 
> Dear all,
> 
> I have added a config file
>   /etc/udev/hwdb.d/61-keyboard-local.hwdb
> containing:
>   evdev:input:b0003v045Ep00DB*
>KEYBOARD_KEY_c022d=pageup
>KEYBOARD_KEY_c022e=pagedown
> to remap the default "zoomin" and "zoomout" to pageup and pagedown.

Does it work if you rename the file to /etc/udev/hwdb.d/60-keyboard.hwdb?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#845682: ocl-icd-libopencl1: queries clGetPlatformInfo() through clGetExtensionFunctionAddress

[Simon Richter]

Package: ocl-icd-libopencl1
Version: 2.2.9-2
Severity: minor

Hi,

the ICD loader verifies that the clGetPlatformInfo symbol is exported
(as required by the spec), but then also requests the symbol through
clGetExtensionFunctionAddress(). If this function returns a non-NULL
pointer, it is used preferentially.

To me, that smells a bit fishy, as this is a standard function, so it
shouldn't be queried through the extension function interface.

   Simon

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ocl-icd-libopencl1 depends on:
ii  libc6  2.24-5

ocl-icd-libopencl1 recommends no packages.

Versions of packages ocl-icd-libopencl1 suggests:
pn  opencl-icd  

-- no debconf information

Bug#844666: libpam-ldap-186: regression: reads from the wrong conf file

[Brian Kroth]

Brian Kroth  2016-11-23 15:44:
FYI, the patch I had attached last time is wrong.  I'd just copied and 
pasted from the old one, but that used cdbs, whereas this doesn't.  I 
think this one should be better, though I'm no packaging expert.


Let me know if you have any comments or questions.

Thanks,
Brian


Ack, also missed a build depends on dh-exec in that one.

Brian

Bug#629100: Winexe 1.1 is available in the Kali Linux repository

[Stephen Thomas]

and appears to work just fine with Debian Testing's libraries. Kali is 
built as a rolling release from Debian Testing, so it ought to stay 
working most of the time. Perhaps some generous Debian maintainer could 
arrange for the Kali winexe package to find a second home in Sid?


Until that happens, here's a recipe for using the Kali package in Testing:

To a standard Debian Testing installation, add 
/etc/apt/sources.list.d/kali.list containing the following:


deb http://http.kali.org/kali kali-rolling main

Add /etc/apt/preferences.d/kali-rolling containing the following:

Package: kali-archive-keyring
Pin: release a=kali-rolling
Pin-priority: 500

Package: winexe
Pin: release a=kali-rolling
Pin-priority: 500

Package: *
Pin: release a=kali-rolling
Pin-Priority: -1

Then update and install:

cd /tmp
wget 
http://repo.kali.org/kali/pool/main/k/kali-archive-keyring/kali-archive-keyring_2015.2_all.deb

su -
dpkg -i /tmp/kali-archive-keyring_2015.2_all.deb
apt update
apt install winexe

Having done that, I can now winexe to my Server 2012R2 boxes with 
complete success.

Bug#845193: dpkg: recent -specs PIE changes break openssl

[Adrian Bunk]

On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> > 
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if no other flags marks it as to be
> > >disabled) on all architectures were gcc has not enabled this by
> > >default.
> > 
> > … that. And that is just plain wrong. Either dpkg should inject
> > -specs= stuff on all architectures or on none. Differing like this
> > just invites hidden and hard to track down bugs.
> 
> As long as gcc enables PIE on a subset, there will be need to inject
> some form of specs on either subset of those arches, either on
> hardening=+pie or on hardening=-pie, pick yout poison. :(
>...

Both gcc and dpkg playing with PIE just increased the number of bugs
without bringing any benefit.

I fixed many PIE related issues in packages when the gcc change was.

And now we got a new batch of FTBFS bugs for cases where the
dpkg specs change broke packages using "hardening=+all,-pie".

Please do the following:
1. discuss with porters whether PIE is working on their architecture
2. gcc and dpkg maintainers have to agree which package enables PIE

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845681: wishlist: libpam-ldap-standalone: a libpam-ldap package copy that can be used with libpam-ldapd

[Brian Kroth]

Package: libpam-ldap
Version: 186-1+caejessie4
Severity: wishlist

Dear Maintainer,

As described in [1] and elsewhere, the nslcd variant of libpam-ldap, 
libpam-ldapd, doesn't currently provide the ability to specify per 
service pam stack ldap configs in order to override on on a per service 
basis various authentication/authorization ldap filters, search bases, 
etc.  libpam-ldap does provide such functionality via the config= 
parameter to its pam_ldap.so module within each pam server stack config.


However, aside from a library naming conflict, the two packages could be 
compatible.  That is, one can mix libpam-ldapd's pam_ldap.so and 
libpam-ldap's pam_ldap.so in the same stack, so long as they're 
named/referenced differently so that they're each loaded separately.


Attached is a patch which adjusts the libpam-ldap package to also 
produce a copy of itself under a different library install location and 
package name, libpam-ldap-standalone, in order to facilitate just that 
ability.  Note, it also includes the patches for reading from the usual 
config file that I submitted in bug #844666.


There are comments within the patch to hopefully help flush out the 
details of the expected use cases and configs.


In my example I've disabled most debconf control of the 
pam_ldap_standalone.so module into the various /etc/pam.d/common-* 
stacks, as it's not intended to be a replacement for those, but rather a 
tack on for specific services.  Instead, libpam-ldapd is supposed to 
handle the brunt of the /etc/pam.d/common-* work.


Let me know if you have any questions/comments.

Thanks,
Brian

[1] 


-- System Information:
Debian Release: 8.6
 APT prefers stable
 APT policy: (500, 'stable'), (120, 'testing'), (110, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpam-ldap-standalone depends on:
ii  libc6   2.19-18+deb8u6
ii  libldap-2.4-2   2.4.40+dfsg-1+deb8u2
ii  libpam-runtime  1.1.8-3.1+deb8u1
ii  libpam0g1.1.8-3.1+deb8u1+b1

libpam-ldap-standalone recommends no packages.

Versions of packages libpam-ldap-standalone suggests:
ii  libnss-ldapd  0.9.4-3+deb8u1
ii  libpam-ldapd  0.9.4-3+deb8u1

-- no debconf information
diff -u -ruN libpam-ldap-186/debian/changelog libpam-ldap-186.cae.standalone/debian/changelog
--- libpam-ldap-186/debian/changelog	2016-04-09 16:14:51.0 -0500
+++ libpam-ldap-186.cae.standalone/debian/changelog	2016-11-25 13:17:12.663261899 -0600
@@ -1,3 +1,16 @@
+libpam-ldap (186-1+caejessie4) cae-jessie-backports; urgency=medium
+
+  * Non-maintainer upload.
+  * Backporting for jessie (RT #430785).
+  * Also update debian/rules to use the old /etc/pam_ldap.conf file by default
+instead of /etc/ldap.conf
+  * Fixup build rules for pure dh instead of cdbs.
+  * Don't let it copy the /etc/ldap.conf file in - let debconf handle that as
+before.
+  * Add a libpam-ldap-standalone package.
+
+ -- Brian Kroth   Fri, 28 Oct 2016 17:13:57 -0500
+
 libpam-ldap (186-1) unstable; urgency=medium
 
   * New upstream release
diff -u -ruN libpam-ldap-186/debian/control libpam-ldap-186.cae.standalone/debian/control
--- libpam-ldap-186/debian/control	2016-04-04 07:26:09.0 -0500
+++ libpam-ldap-186.cae.standalone/debian/control	2016-11-25 13:45:23.258026883 -0600
@@ -6,6 +6,7 @@
 Standards-Version: 3.9.7
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
+   dh-exec (>= 0.3),
libldap2-dev,
libpam0g-dev,
libsasl2-dev,
@@ -22,3 +23,27 @@
  user authentication system. Using it along with libnss-ldapd or libnss-ldap
  allows LDAP to entirely replace other lookup methods (such as NIS or
  flat-file) for system account tables.
+
+Package: libpam-ldap-standalone
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}, libpam-runtime (>= 1.0.1-6), libpam0g (>= 1.1.3-2)
+Suggests: libnss-ldapd, libpam-ldapd
+# libpam-ldap-standalone is only intended to be used in combination with
+# libpam-ldapd.  It doesn't make sense to combine it with itself.
+# NOTE: We have to include a version in the match, else libpam-ldapd (which
+# Provides libpam-ldap) will also be matched by the Conflicts rule.
+Conflicts: libpam-ldap (>= 0)
+Description: Pluggable Authentication Module for LDAP
+ This package provides an interface between an LDAP server and the PAM
+ user authentication system. Using it along with libnss-ldapd or libnss-ldap
+ allows LDAP to entirely replace other lookup methods (such as NIS or
+ flat-file) for system account tables.
+ .
+ NOTE: This is essentially a copy of the libpam-ldap package that's intended to
+ coeexist with the libpam-ldapd package (which conflicts with the usual
+ libpam-ldap 

Bug#845610: don't add 'New upstream release' to changelog when -b option is given

[James McCoy]

Control: merge 842468 -1
Control: retitle 842468 [uupdate] Omit 'New upstream release' entry when 
version matches changelog (with -b)

On Fri, Nov 25, 2016 at 12:15:15PM +0530, Pirate Praveen wrote:
> We commonly use uupdate -b in npm2deb to add generated debian folder
> with upstream tarball (debian folder is generated from npm metadata
> first and upstream tarball is downloaded later). It would be good if
> uupdate checks the version in current changelog when -b option is passed
> and don't add 'New upstream release' when it is the same version.
> Currently we have to remove this line from changelog for every package
> we create using npm2deb.

Merging with the existing bug, but thanks for clarifying that the
requested change is for uupdate.  The earlier report made me think the
issue was with uscan.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#839707: Bug#842040: Please add https support

[Raphael Geissert]

Hi,

On Sunday, 20 November 2016 16:49:57 CET Philipp Kern wrote:
> On 2016-11-20 12:10, Julien Cristau wrote:
> > I think until there's a ca-certificates-udeb, adding wget for https in
> > all images isn't reasonable, vs google rebuilding d-i with added wget
> > and the PEM bits you need.  I guess ca-certificates-udeb would need
> > some way to preseed a list of trusted CAs.
[...]
> The problem with rebuilding d-i is that you can't really do it from the
> source package in unstable, you need to do it from the VCS.
> 
> It boils down to the question if it's useful beyond just us. :)

FWIW, at work we've also had the need of https (and ftps) support in d-i for 
retrieving preseeds and some other files plus uploading a few logs.

Given the need of ftps we've switched from the then-proposed wget-udeb to a 
curl-based one (#839707). It is more flexible and future-proof, all in all.

As for the certificates, we don't use ca-certificates at all, we use a $company 
CA.

The above is just a part of what we end up injecting into d-i. So even though 
adding something like the curl udebs would come handy, at this point we still 
need to build a custom media.

Just my two cents, and not on behalf of my employer.

Cheers,
-- 
Raphael Geissert

Bug#845633: ftp.debian.org: RM: custom-printf -- RoM; FTBFS; abandoned upstream

[Scott Kitterman]

On Fri, 25 Nov 2016 13:30:37 +0100 Hilko Bengen  wrote:
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org
> 
> please remove custom-printf. It has been abandoned upstream and has been
> replaced by ppx_custom_printf which is not yet in the archive.
> custom-printf can no longer be built because libsexplib-camlp4-dev is no
> longer available (see #843317).
> 
Similarly here:

Checking reverse dependencies...
# Broken Depends:
janest-core: libcore-ocaml-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 powerpc]

# Broken Build-Depends:
janest-core: libcustom-printf-camlp4-dev
janest-core-extended: libcustom-printf-camlp4-dev
janest-core-kernel: libcustom-printf-camlp4-dev


Please remove the moreinfo tag once these have been addressed.

Scott K

Bug#845247: astyle: duplicates last character for files without final lineend form stdin

[Matteo Cypriani]

Control: tag 769524 pending
Control: forcemerge 769524 -1

P.S.: this is a duplicate of #769524.


pgp1rVHks2anm.pgp
Description: PGP signature

Bug#836599: RE: Bug#836599: shark: FTBFS on mips/mipsel: test errors

[Ghislain Vaillant]

On Tue, 18 Oct 2016 11:36:52 + Dejan Latinovic 
 wrote:

Control: tags -1 + patch
Control: user -1 debian-m...@lists.debian.org
Control: usertags -1 mips-patch


Hi Ghislain,

I have updated the patch that reduces optimization level with requested 
information, Fix-build-on-MIPS.patchý.
Do you want me to add anything else?

Maybe it would be enough to apply only this patch, as the second one was needed 
for
one of my local machines that may have lower performance than Debian's build 
servers.

I will monitor the status of reported issues and ask for patch removal when the 
time comes.


Regards,
Dejan



I have applied your patch and launched a test build on debomatic [1].

The good news is that it indeed fixes the build, but a few tests do 
timeout, including the one you mentioned:


The following tests FAILED:
 60 - Trainers_LinearSvmTrainer (Timeout)
139 - ObjFunct_NegativeLogLikelihood (Timeout)
140 - ObjFunct_SvmLogisticInterpretation (Timeout)

I'll mark them as slow and push the update. Hopefully this should be 
enough to fix this FTBFS bug.


Thanks again for working on this.

[1] 
http://debomatic-mips.debian.net/distribution#unstable/shark/3.1.3+ds1-2/buildlog


Ghis

Bug#845632: ftp.debian.org: RM: pa-test -- RoM; FTBFS; abandoned upstream

[Scott Kitterman]

On Fri, 25 Nov 2016 13:30:20 +0100 Hilko Bengen  wrote:
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-CC: debian-ocaml-ma...@lists.debian.org
> 
> Hi,
> 
> please remove pa-test. It has been abandoned upstream and has been
> replaced by ppx_assert which is not yet in the archive. pa-test can no
> longer be built because libsexplib-camlp4-dev is no longer available
> (see #843316).

rdepends and reverse-build-depends will have to be dealt with first:

Checking reverse dependencies...
# Broken Depends:
janest-core: libcore-ocaml-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 powerpc]

# Broken Build-Depends:
janest-core: libpa-test-camlp4-dev
janest-core-extended: libpa-test-camlp4-dev
janest-core-kernel: libpa-test-camlp4-dev
ocaml-re2: libpa-test-camlp4-dev

Please have those removed or updated to not use libpa-test-camlp4-dev and 
remove the moreinfo tag once that's done.

Scott K

Bug#817653: rlpr: diff for NMU version 2.05-4.1

[Andrey Rahmatullin]

Control: tags 817653 + patch
Control: tags 817653 + pending

Dear maintainer,

I've prepared an NMU for rlpr (versioned as 2.05-4.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -u rlpr-2.05/debian/control rlpr-2.05/debian/control
--- rlpr-2.05/debian/control
+++ rlpr-2.05/debian/control
@@ -3,11 +3,11 @@
 Priority: optional
 Maintainer: Ari Pollak 
 Standards-Version: 3.6.2
-Build-Depends: debhelper (>= 4.2.21), autotools-dev
+Build-Depends: debhelper (>= 10), autotools-dev
 
 Package: rlpr
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: A utility for lpd printing without using /etc/printcap
  Rlpr makes it possible (or at the very least, easier), to print files
  on remote sites to your local printer, and vice versa.  The rlpr
diff -u rlpr-2.05/debian/compat rlpr-2.05/debian/compat
--- rlpr-2.05/debian/compat
+++ rlpr-2.05/debian/compat
@@ -1 +1 @@
-4
+10
diff -u rlpr-2.05/debian/changelog rlpr-2.05/debian/changelog
--- rlpr-2.05/debian/changelog
+++ rlpr-2.05/debian/changelog
@@ -1,3 +1,11 @@
+rlpr (2.05-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper compat level 10 (Closes: #817653).
+  * Add explicit debian/source/format.
+
+ -- Andrey Rahmatullin   Sat, 26 Nov 2016 00:18:06 +0500
+
 rlpr (2.05-4) unstable; urgency=low
 
   * Update config.{sub,guess} on configure (Closes: #535718)
only in patch2:
unchanged:
--- rlpr-2.05.orig/debian/source/format
+++ rlpr-2.05/debian/source/format
@@ -0,0 +1 @@
+1.0


signature.asc
Description: PGP signature

Bug#845247: astyle: duplicates last character for files without final lineend form stdin

[Matteo Cypriani]

Control: tag -1 pending

Hi Martin,
Thanks for your report. This is apparently fixed in astyle 2.05.1, which
will be uploaded shortly.
Cheers,
  Matteo


pgpBh8K7zpi31.pgp
Description: PGP signature

Bug#842040: Please add https support

[Martin Michlmayr]

* Rick Thomas  [2016-11-24 21:28]:
> >> So how do we move forward here? Exclude wget-udeb from the orion5x-qnap
> >> image and otherwise include it by default?
> > 
> > That should work.
> 
> Are there other machines that have equally sever size restrictions?

I don't think so.
-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#845577: RM: hyphen-?? -- RoQA; binary packages now built by hyphen-indic

[Adrian Bunk]

Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9
Control: retitle -1 RM: hyphen-as -- RoQA; binary package now built by  
src:hyphen-indic
Control: retitle -2 RM: hyphen-bn -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -3 RM: hyphen-gu -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -4 RM: hyphen-hi -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -5 RM: hyphen-kn -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -6 RM: hyphen-mr -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -7 RM: hyphen-pa -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -8 RM: hyphen-ta -- RoQA; binary package now built by 
src:hyphen-indic
Control: retitle -9 RM: hyphen-te -- RoQA; binary package now built by 
src:hyphen-indic

As discussed on IRC, I am splitting this into one bug per source package.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845614: RFS: acorn/4.0.3-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi
(resending from the correct email)

>https://mentors.debian.net/debian/pool/main/a/acorn/acorn_4.0.3-1.dsc

http://debomatic-amd64.debian.net/distribution#unstable/acorn/4.0.3-1/buildlog

FTBFS


>(2) upstream moved forward very fast and uses rollup to compile itself,
>but we don't have rollup yet, and rollup needs acorn (and itself!), so
>I'm using my node-es6-module-transpiler and sed-patch things so they
>work ; I could check running "acorn foo.js" works for most files in
>/usr/lib/nodejs (some give errors, but can still be tokenized, so
>nothing too worrying).
>
>The ultimate goal is to get rollup up and running, boostrapping it with
>node-es6-module-transpiler. I'm not there yet...
ok, but it needs to build... what about building stages?

look e.g. to gcc bootstrapping, or compilers in general
(note: I don't have knowledge on this topic)


cheers,
G.

Bug#845628: devscripts: DEBUILD_LINTIAN_HOOK no more works (at least if it contains shell meta characters)

[James McCoy]

On Fri, Nov 25, 2016 at 06:09:02PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2016-11-25 at 12:32:18 +0100, Axel Beckert wrote:
> > Package: devscripts
> > Version: 2.16.9
> > File: /usr/bin/debuild
> 
> > since the recent slimming of debuild, DEBUILD_LINTIAN_HOOK no more works
> > for me.
> > 
> > I've set
> > 
> >   DEBUILD_LINTIAN_HOOK="if [ -d %p-%u ]; then cd %p-%u; duck; elif [ -d %p 
> > ]; then cd %p; duck; else exit 1; fi; true"
> > 
> > This now leads to error messages like this one:
> > 
> >   dpkg-buildpackage: error: if [ -d aiccu-20070115 ]; then cd 
> > aiccu-20070115; duck; elif [ -d aiccu ]; then cd aiccu; duck; else exit 1; 
> > fi; true gave error exit status 1
> > 
> > This happens despite the directory is named "aiccu".
> > 
> > I suspect that while classic debuild passed the string in
> > $DEBUILD_LINTIAN_HOOK to "sh -c" to interpret shell meta characters, the
> > slimmed debuild (or dpkg-buildpackage's --hook-check) no more does.
> 
> The problem actually seems to be that dpkg-buildpackage always runs
> the hooks from inside the source tree, but debuild used to run some
> hooks from inside the tree and some from one level up.

Yes, that does seem to be the issue.

- dpkg-buildpackage hook, in tree
- clean hook, in tree
- dpkg-source hook, in tree
- build hook, in tree
- binary hook, in tree
- dpkg-genchanges hook, in tree
- final-clean hook, in tree
- lintian hook, parent
- signing hook, parent
- post-dpkg-buildpackage, parent

> I think
> starting after the changes generation? But I've not dug very deep.
> I also notice this is not documented neither in debuild nor
> dpkg-buildpackage man pages. I'll fix that on the dpkg side.

I'll add some documentation about the debuild hooks, as well.

> I'm not sure how we should handle this, w/o breaking both interfaces.
> Perhaps it would not be that "onerous" (ehem) to prepend a "cd ..;" for
> the hooks that debuild expects to run a level up (yeah I know… :).

The debuild hooks should probably start being deprecated in Buster so
this confusion isn't permanent.  In the meantime, "cd ..;" seems like
the least intrusive option.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#842472: ITA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)

[Thaddeus H. Black]

Control: retitle -1 ITA: w3-recs -- Recommendations of the World Wide Web 
Consortium (W3C)
Control: owner -1 !
Control: stop

Thanks for your work on this package, Colin.  It does not look
as though any other competent person were stepping forward to
maintain the package, so I will adopt it.



signature.asc
Description: Digital signature