Bug#665435: cups: too much memory consumption in default configuration (swaps out, brings print server to a crawl)

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix

Le samedi, 24 mars 2012, 01.21:49 Jonathan Nieder a écrit :
> Jonathan Nieder wrote:
> > With "RIPCache 16m" in /etc/cups/cupsd.conf the system seems to be
> > sane again and printing is still working fine.
> 
> I think that might even make a good default.  Alternatively, how about
> this patch (untested)?

There was a patch doing that in Debian packages before 1.5.0 (aka in the 
Squeeze version):

http://patch-tracker.debian.org/patch/series/view/cups/1.4.4-7+squeeze3/default-ripcache-size-auto.dpatch

It got removed in cups 1.5.0 with the following rationale:

 * debian/patches/default-ripcache-size-auto.patch: Dropped, as once,
   Ghostscript 9.04 is ignoring the cache size value as it crashes
   easily otherwise (Ghostscript upstream bug #691586) and second, CUPS
   defaults to more reasonable 128 MB (now only used for imagetops).

Now, 128Mb is arguably a lot of memory, but I think that assuming that 
this much can be allocated is a reasonable expectation that CUPS makes 
there. Also, there is a documented (as you pointed out, in cupsd.conf's 
help) way to modify this value.

I'm therefore hereby marking this bug as +wontfix, with the hope that 
the above rationale satisfies you.

Cheers,

OdyX

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

Bug#712936: iceweasel: can't print to file in the $HOME folder

[Vincent Lefevre]

Control: found -1 24.2.0esr-1
Control: severity -1 important

I'm raising this bug to important, because though there's a very
easy workaround, by default Iceweasel seems to really print the
print to PDF (a box shortly appears) and gives no error messages.
In case of a temporary page (not cached), if the user closes it
without checking that the PDF file is there, the contents are
definitively lost!

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#674520: cups ignores "Allow From @IF(eth0)" entries in /etc/cups/cupsd.conf

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://cups.org/str.php?L4328
Control: tags -1 +upstream

Hi Stefan, and thanks for your bugreport,

I have now reported your bug on the upstream bugtracker and will wait 
for comments from upstream before including your patch.

Thanks for your contributions!

Cheers, OdyX

Le vendredi, 25 mai 2012, 10.09:26 Stefan Gottwald a écrit :
> If /etc/cups/cupsd.conf is configured with something like this
> 
> 
> Order Deny,Allow
> Deny From All
> Allow From @IF(eth0)
> Allow From @IF(eth2)
> 
> 
> the "Allow From @IF(...)" lines will be ignored.


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

Bug#734173: linux-image-3.12-1-686-pae: After upgrade to 3.12, need to toogle a switch in alsamixer to use the mike

[Michael Schmitt]

Package: src:linux
Version: 3.12.6-2
Severity: minor

Dear Maintainer,

as stated in the subject and the switch I need to toogle is the one to enable
recording from the microphone, named "Microphone Capture". It is always enabled,
but after resume I have to switch it off and back on, otherwise the microphone
does not work.

Soundchip is "Audio device: Intel Corporation NM10/ICH7 Family High Definition
Audio Controller [8086:27d8]" onboard an Asus P5LD2-SE mainboard. Driver used
is hda-intel

regards
Michael

-- Package-specific info:
** Version:
Linux version 3.12-1-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

** Command line:
BOOT_IMAGE=/vmlinuz-3.12-1-686-pae root=/dev/mapper/storage1-root ro quiet

** Not tainted

** Kernel log:
[35831.927895] delay: estimated 192, actual 336
[35831.932853] delay: estimated 480, actual 336
[35836.272023] delay: estimated 192, actual 336
[35836.276789] delay: estimated 480, actual 336
[35837.061782] delay: estimated 480, actual 336
[35837.113723] delay: estimated 192, actual 336
[35837.117776] delay: estimated 480, actual 336
[35838.274474] delay: estimated 144, actual 336
[35838.277762] delay: estimated 528, actual 336
[35839.472991] delay: estimated 192, actual 336
[35840.233706] delay: estimated 192, actual 336
[35840.237733] delay: estimated 480, actual 336
[35860.501996] delay: estimated 50, actual 338
[35860.503454] delay: estimated 626, actual 338
[35860.571394] delay: estimated 194, actual 338
[35860.575454] delay: estimated 482, actual 338
[35997.095421] delay: estimated 98, actual 338
[35997.097569] delay: estimated 578, actual 338
[35997.112248] delay: estimated 50, actual 338
[35997.113567] delay: estimated 626, actual 338
[35997.189492] delay: estimated 194, actual 338
[35997.193564] delay: estimated 482, actual 338
[35997.205656] delay: estimated 146, actual 338
[35997.209564] delay: estimated 530, actual 338
[35998.399643] delay: estimated 50, actual 338
[35998.401550] delay: estimated 626, actual 338
[35998.478174] delay: estimated 146, actual 338
[35998.481548] delay: estimated 530, actual 338
[36003.117953] delay: estimated 98, actual 338
[36003.120488] delay: estimated 578, actual 338
[36003.157159] delay: estimated 146, actual 338
[36003.160487] delay: estimated 530, actual 338
[36170.765167] delay: estimated 146, actual 338
[36170.769166] delay: estimated 530, actual 338
[36170.817656] delay: estimated 0, actual 338
[36170.817671] delay: estimated 722, actual 338
[36170.917254] delay: estimated 146, actual 338
[36170.921161] delay: estimated 530, actual 338
[36170.933857] delay: estimated 146, actual 338
[36170.937162] delay: estimated 530, actual 338
[36171.164696] delay: estimated 194, actual 338
[36171.169158] delay: estimated 482, actual 338
[36731.293191] delay: estimated 2, actual 338
[36731.293372] delay: estimated 674, actual 338
[36731.546907] delay: estimated 98, actual 338
[36731.549373] delay: estimated 578, actual 338
[36731.580941] delay: estimated 2, actual 338
[36731.581369] delay: estimated 674, actual 338
[36731.597231] delay: estimated 2, actual 338
[36731.597368] delay: estimated 674, actual 338
[36731.616824] delay: estimated 194, actual 338
[36731.621372] delay: estimated 482, actual 338
[36731.634138] delay: estimated 146, actual 338
[36731.637369] delay: estimated 530, actual 338
[36731.701465] delay: estimated 0, actual 338
[36731.701480] delay: estimated 722, actual 338
[36731.786678] delay: estimated 98, actual 338
[36731.789369] delay: estimated 578, actual 338
[36731.802904] delay: estimated 98, actual 338
[36731.805368] delay: estimated 578, actual 338
[36732.122964] delay: estimated 98, actual 338
[36732.125363] delay: estimated 578, actual 338
[36732.824622] delay: estimated 194, actual 338
[36732.829354] delay: estimated 482, actual 338
[37064.017808] retire_capture_urb: 11 callbacks suppressed
[37064.060188] delay: estimated 146, actual 338
[37064.063727] delay: estimated 530, actual 338
[37064.083827] delay: estimated 146, actual 338
[37064.087730] delay: estimated 530, actual 338
[37064.269962] delay: estimated 50, actual 338
[37064.271729] delay: estimated 626, actual 338
[37064.300275] delay: estimated 146, actual 338
[37064.303729] delay: estimated 530, actual 338
[37398.911970] delay: estimated 95, actual 336
[37398.914046] delay: estimated 575, actual 336
[37892.946123] delay: estimated 194, actual 338
[37892.951093] delay: estimated 482, actual 338
[38325.566421] delay: estimated 98, actual 338
[38325.568992] delay: estimated 578, actual 338
[38325.580355] delay: estimated 194, actual 338
[38325.585201] delay: estimated 482, actual 338
[38325.617138] delay: estimated 0, actual 338
[38325.617151] delay: estimated 722, actual 338
[38325.829088] delay: estimated 146, actual 338
[38325.833591] delay: estimated 530, actual 338
[38327.320840] delay: estimated 2, actual 338
[38327.320966] delay: estimated 674, actual 338
[38327.629665] delay: e

Bug#734154: debian-installer: touchpad driver missing

[Andreas Cadhalpun]

On 04.01.2014 16:02, Cyril Brulebois wrote:

Andreas Cadhalpun  (2014-01-04):

I just meant, that the touchpad cannot move the cursor, although
evdev is loaded.


Might be a kernel or driver bug. Can you please attach Xorg log and
kernel log from the installer?


I attached Xorg.0.log and syslog, but I found no related error messages 
in them.

Also I realized that the left mouse button at least is working.



syslog.tar.xz
Description: application/xz


Xorg.0.log.tar.xz
Description: application/xz

Bug#447026: xbindkeys: blocks keyboard if started from .xsession

[Philippe Brochard]

This bug is hopefully fixed upstream in the 1.8.6 version with the
Nicolas Boichat bugfix applied.

Best regards,

Philippe


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Josselin Mouette]

Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
> Uoti Urpala writes ("Bug#727708: init system discussion status"):
> > Your earlier wording sounds
> > like it was talking about the former ("installable") and Ian's proposal
> > definitely was (explicitly mentioning package fields), but the "fully
> > working" you use now sounds like it's about the latter.
> 
> Thanks for pointing this out.  My proposal is too weak in this
> respect.  I intended to make the stronger statement.

> I think systemd-ui is part of the systemd init system so falls into
> the exception.  Of course that means that nothing else should depend
> (functionally or in package dependencies) on it.

There is no way that, for example, some of the GNOME control center
applets will work at all without systemd.

It is already hard enough to imagine that we would have to ship packages
without the appropriate dependencies on systemd; expecting them to have
the same functional coverage without it is simply insane.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#204847: cupsys-client: ifupdown hook scripts allow convenient (en|dis)abling of print queues

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix

Hi Thomas,

Apparently its been more than 10 years since you reported this bug 
against cups!

Le dimanche, 10 août 2003, 14.24:00 Thomas Hood a écrit :
> Here follow two very simple scripts that are designed to be placed in
> /etc/network/if-up.d/ and /etc/network/if-down.d/ .  When present,
> these scripts cause the printer queues named on a "cups-printers"
> line in an iface stanza in /etc/network/interfaces to be enabled
> after the relevant interface is ifupped and disabled before the
> relevant iface is ifdowned. 

I think this is nowadays solved in a better way using avahi network 
discovery and automatic printers setup. In any case, I don't intend to 
include these hooks, therefore marking this bug as +wontfix. That said, 
I must admit that I find the trick quite smart and I might have used it 
a decade ago!

Cheers,

OdyX

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

Bug#734174: openssh-server: SELinux errors in syslog

[Benoit Friry]

Package: openssh-server
Version: 1:6.4p1-2
Severity: normal

Bonjour,

I have enabled SELinux in permissive mode.

When I connect and logoff, I get the following lines in auth.log:

Jan  4 16:26:44 tc2 sshd[18138]: Accepted password for benoit from 
[some_ipv6_address] port 58739 ssh2
Jan  4 16:26:44 tc2 sshd[18138]: pam_unix(sshd:session): session opened for 
user benoit by (uid=0)
Jan  4 16:26:44 tc2 sshd[18138]: pam_selinux(sshd:session): conversation failed
Jan  4 16:26:44 tc2 sshd[18138]: pam_selinux(sshd:session): No response to 
query: Would you like to enter a security context? [N] 
Jan  4 16:26:44 tc2 sshd[18138]: pam_selinux(sshd:session): Unable to get valid 
context for benoit
Jan  4 16:26:44 tc2 sshd[18140]: error: ssh_selinux_getctxbyname: Failed to get 
default SELinux security context for benoit
Jan  4 16:26:44 tc2 sshd[18138]: error: ssh_selinux_getctxbyname: Failed to get 
default SELinux security context for benoit
Jan  4 16:26:44 tc2 sshd[18138]: error: ssh_selinux_setup_pty: 
security_compute_relabel: Invalid argument
Jan  4 16:26:46 tc2 sshd[18140]: Received disconnect from [some_ipv6_address] 
11: disconnected by user
Jan  4 16:26:46 tc2 sshd[18138]: pam_unix(sshd:session): session closed for 
user benoit

"sestatus -v" gives (among other lines):
/usr/sbin/sshd  
unconfined_u:system_r:sshd_t:SystemLow-SystemHigh

I did not try in enforcing mode.

I restart sshd with run_init:
# run_init /etc/init.d/ssh restart

Remote connection now leads to:

Jan  4 16:27:00 tc2 sshd[18270]: Accepted password for benoit from 
[some_ipv6_address] port 58753 ssh2
Jan  4 16:27:00 tc2 sshd[18270]: pam_unix(sshd:session): session opened for 
user benoit by (uid=0)
Jan  4 16:27:00 tc2 sshd[18270]: pam_selinux(sshd:session): pam: 
default-context=unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh 
selected-context=uncfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh 
success 1
Jan  4 16:27:02 tc2 sshd[18272]: Received disconnect from [some_ipv6_address] 
11: disconnected by user
Jan  4 16:27:02 tc2 sshd[18270]: pam_unix(sshd:session): session closed for 
user benoit

No more error messages!

"sestatus -v" gives (among other lines):
/usr/sbin/sshd  system_u:system_r:sshd_t:SystemLow-SystemHigh

As far as I understand, this means that in order to have proper behaviour sshd
should be started with something equivalent of run_init at boot time.

This bug may concern boot/init packages more than openssh-server.

Merci,
Benoit

*** End of the template - remove these lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.17.5
ii  libc6 2.17-97
ii  libcomerr21.42.8-1
ii  libgssapi-krb5-2  1.11.3+dfsg-3+nmu1
ii  libkrb5-3 1.11.3+dfsg-3+nmu1
ii  libpam-modules1.1.3-9
ii  libpam-runtime1.1.3-9
ii  libpam0g  1.1.3-9
ii  libselinux1   2.2.1-1
ii  libssl1.0.0   1.0.1e-6
ii  libwrap0  7.6.q-24
ii  lsb-base  4.1+Debian12
ii  openssh-client1:6.4p1-2
ii  procps1:3.3.4-2
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20130608-1
ii  xauth 1:1.0.7-1

Versions of packages openssh-server suggests:
pn  molly-guard  
pn  monkeysphere 
ii  openssh-blacklist0.4.1+nmu1
ii  openssh-blacklist-extra  0.4.1+nmu1
ii  rssh 2.3.4-4
ii  ssh-askpass  1:1.2.4.1-9
pn  ufw  

-- debconf information:
  ssh/encrypted_host_key_but_no_keygen:
  ssh/vulnerable_host_keys:
  ssh/disable_cr_auth: false
* ssh/use_old_init_script: true


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734175: ITP: fonts-woowa-hanna -- Baedal-Minjok Hanna Korean font

[Changwoo Ryu]

Package: wnpp
Owner: Changwoo Ryu 
Severity: wishlist

* Package name: fonts-woowa-hanna
  Version : 1.000
  Upstream Author : Woowa Brothers 
* URL : http://www.woowahan.com/?page_id=3985
* License : SIL Open Font License 1.1
  Programming Lang: N/A
  Description : Baedal-Minjok Hanna Korean font

 Baedal-Minjok Hanna font is a decorative Korean font family which
 looks old styled and crude. The design is intended to make it like
 store sign of 1960-70s South Korean streets.
 .
 This font is initially designed for Baedal-Minjok mobile phone app
 and released under the SIL Open Font License.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#726763: gnome should depend on systemd-shim | systemd-sysv

[Andreas Cadhalpun]

Control: reassign 726763 gnome-settings-daemon 3.8.5-2
Control: severity 726763 important

Hi,

I tested systemd-shim and, using it, suspend etc. from GNOME menus work 
agin with sysvinit/upstart.


So to resolve this bug, GNOME should depend on:
systemd-shim | systemd-sysv

This ordering ensures that installing GNOME does not switch the init 
system, but since it works with systemd as PID 1, the dependency can 
also be satisfied by systemd-sysv.


The best place to add this new dependency seems the 
gnome-settings-daemon, since it directly depends on systemd, which is 
not enough to provide the necessary working dbus interfaces.
Since gdm3 depends on gnome-settings-daemon, this will solve the issue 
in gdm3 menus as well.


I think that according to policy [1] systemd-shim should be Priority: 
optional and not extra, because gnome-settings-daemon is optional and 
packages must not depend on packages with lower priority.


Furthermore I changed the severity to important as I think this bug has 
a 'major effect on the usability' [2].


Best regards,
Andreas

1: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
2: http://www.debian.org/Bugs/Developer.html


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734176: gkrellm: Filter Net interfaces

[Christophe Troestler]

Package: gkrellm
Version: 2.3.5-5
Severity: wishlist

Hi,

When using docker  many ethernet interfaces are
created.  It would be desirable to be able to filter those out (they
all start with "veth") or possibly show them but not remember them in
the configuration list (have a config per regexp).

Thanks,
C.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10.25 (SMP w/8 CPU cores)
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 /bin/dash

Versions of packages gkrellm depends on:
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-97
ii  libcairo21.12.16-2
ii  libfontconfig1   2.11.0-2
ii  libfreetype6 2.5.1-1
ii  libgcrypt11  1.5.3-3
ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
ii  libglib2.0-0 2.36.4-1
ii  libgnutls-openssl27  2.12.23-8
ii  libgnutls26  2.12.23-8
ii  libgtk2.0-0  2.24.22-1
ii  libice6  2:1.0.8-2
ii  libntlm0 1.4-1
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpangocairo-1.0-0  1.36.0-1+b1
ii  libpangoft2-1.0-01.36.0-1+b1
ii  libsm6   2:1.2.1-2
ii  libx11-6 2:1.6.2-1

gkrellm recommends no packages.

gkrellm suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#304504: cupsys-bsd: Add Printer Options to lpr / lp man pages

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://cups.org/str.php?L4329
Control: tags -1 +upstream

Hi Christopher,

Apparently its been more than 8 years since you reported this bug 
against cups!

Le mercredi, 13 avril 2005, 08.51:30 Christopher Swingley a écrit :
> It would be convenient to have the printer options (all those things
> available with -o option) listed in the manual page.  I've attached a
> patch against lpr.1 that could be applied.  The same code could
> probably be inserted into the lp manual page.

I have now reported your bug on the upstream bugtracker and will wait 
for comments from upstream before including your patch.

Thanks for your contributions!

Cheers, 

OdyX

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

Bug#734177: dash: Fails to report fatal errors on stderr

[Roger Leigh]

Package: dash
Version: 0.5.7-3+nmu1
Severity: important

zsh -c "echo test > /dev/full"
zsh:echo:1: write error: no space left on device

bash -c "echo test > /dev/full"
bash: line 0: echo: write error: No space left on device

dash -c "echo test > /dev/full"
[nothing]
echo $?
1

Both bash and zsh inform the user why the operation failed, and
of course also return the error status.  dash does return an
error status, but it does not inform the user what the cause of
the error was, which can lead to much confusion.

Example: #684607
Here we have a failure in a subsidiary script which causes a
failure, but without any reporting of the error we only know
that there was a problem, but are left completely in the dark
about what the problem was and have no idea how to rectify it.

Please could you consider printing an error like bash or zsh
when such errors are encountered, including strerr(errno) or
equivalent?


Many thanks,
Roger

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  debianutils  4.4
ii  dpkg 1.17.5
ii  libc62.17-97

dash recommends no packages.

dash suggests no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733462: cups: lpr man page should list job options

[Didier 'OdyX' Raboud]

Control: reassign -1 cups-bsd
Control: forcemerge 304504 -1

Le dimanche, 29 décembre 2013 12.06:13, vous avez écrit :
> The lpr man page contains the following documentation on setting job
> options:
> 
> -o option[=value]
> Sets a job option.
> 
> But it does not list the job options. The man page should document the
> job options or provide a reference to where they can be found. If
> providing a reference it would still be useful to list the more
> commonly used job options.

This has already been reported (with a patch) as #304504, which I just 
reported upstream.

Cheers,
OdyX

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

Bug#734178: compile cache confused about file identity

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: normal

The automatic cache of compiled versions of scripts in guile-2.0
identifies scripts mainly by name, and partially by mtime.  This is not
actually sufficient: it is easily misled by a pathname that refers to
different files at different times.  Test case:

$ echo '(display "aaa\n")' >t13
$ echo '(display "bbb\n")' >t14
$ guile-2.0 t13
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t13
;;; compiled 
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t13.go
aaa
$ mv t14 t13
$ guile-2.0 t13
aaa

You can see that the mtime is not fully used here: the cache is misapplied
even if there is a delay of seconds between the creations of the two
script files.  The cache's mtime check will only notice a mismatch if
the script currently seen under the supplied name was modified later
than when the previous script was *compiled*.

Obviously, in this test case the cache could trivially distinguish the
two script files by looking at the inode numbers.  On its own the inode
number isn't sufficient, but exact match on device, inode number, and
mtime would be far superior to the current behaviour, only going wrong
in the presence of deliberate timestamp manipulation.  As a bonus, if
the cache were actually *keyed* by inode number and device, rather than
by pathname, it would retain the caching of compilation across renamings
of the script.

Or, even better, the cache could be keyed by a cryptographic hash of the
file contents.  This would be immune even to timestamp manipulation, and
would preserve the cached compilation even across the script being copied
to a fresh file or being edited and reverted.  This would be a cache
worthy of the name.  The only downside is the expense of computing the
hash, but I expect this is small compared to the expense of compilation.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724013: Acknowledgement (Gui is not shown)

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

To reproduce login on the console and run

xinit /usr/bin/clementine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQEcBAEBCAAGBQJSyDV+AAoJEAqeKp5m04HLvQkH/j5aFj63f9MTy5as45BzFlwM
/odhZB4cPBDyvAKWYV+ovuEA2k9zg93zA6MkMUAKbMz4O3iAm18eNmgnRFdFmHRR
UoLdrWy9dMS4iHxixbzVdIbHzC7H4UqKVItSgXsiGRlwhKHlghDZIA9Yn3mbsgl5
yRoof5DBdBmfO4lTTnb67kgh3WnOW1i9wTPOb8IpOggc2YrXfGrHs3V2awBgkD5W
B3h6oEziX4QZxtLYbrcXsWNd6A5MYthSDXFrrlTSNzdDktDi+MFVajD7mbMbikMr
JGg19ZOHwVw/qG+Jt4zhe1alFS3qeDwmSe5AE8txaz3Ff0HXSKPVXfKqconFZaE=
=5X95
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690473: Chroot setup failed: stage=setup-start

[Roger Leigh]

block 684607 by 690473
thanks

On Sun, Oct 14, 2012 at 08:59:27PM -0700, Jonathan Nieder wrote:
> tags 690473 + upstream patch
> quit
> 
> Hi Roger,
> 
> Roger Leigh wrote:
> 
> > dash:
> > $ echo foo > /dev/full
> > [nothing]
> 
> How about something like this patch?

Many thanks for the patch.

Gerrit, did anything ever happen in debian or upstream for this?  It
would be really nice to have a solution here, either a specific one
like Jonathan proposes or even better a generic one which covers
more error cases as mentioned by Jilles Tjoelker.


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#734180: mailman: missing dependency on lsb-release for test suite (debian/tests/control)

[Antonio Terceiro]

Package: mailman
Severity: normal

Hello,

The test suite declared in debian/tests/control is missing a dependency
on lsb-release.

After adding lsb-release to the dependency list, I got the test suite to
run on a clean unstable chroot (the tests failed, but I didn't
investigate further).

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#734166: gdb-mingw-w64: cross architecture 32bit/64bit debugging is not working on i386/x68_64

[Stephen Kitt]

Hi Tobias,

On Sat, 04 Jan 2014 14:54:59 +0100, Tobias Schlemmer
 wrote:
> Even though gdb-mingw-64 installs x86_64-mingw32-gdb and
> i386-w64-mingw64-gdb either of them is not working (at least on x86_64).
> 
> In particular, gdb refuses to connect to the corresponding gdbserver as the
> architectures i368 and i386:x68_64 look incompitible to it.

Could you explain exactly what you're trying to do?

Here's how I use gdbserver:
* on the Windows host
gdbserver localhost:2345 c:\windows\system32\notepad.exe
* on the Linux host
i686-w64-mingw32-gdb
(gdb) target remote 192.168.1.6:2345
(gdb) cont
and Notepad starts properly.

(Obviously for real I'd start the executable I'm interested in and point
Linux gdb at it as well.)

My 64-bit Windows machine isn't here so I can't check that just now, but it
worked the last time I used it.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#734179: pinentry-curses: Fails to display multiline prompts

[Guilhem Moulin]

Package: pinentry-curses
Version: 0.8.3-1
Severity: important

Dear Maintainer,

Since the upgrade to 0.8.3-1 pinentry-curses is no longer able to show
multiline prompts. This is problematic when used with gpg-agent, since for
instance the key ID that is being unlocked is no longer visible.

Here is a minimal example:

pinentry-curses --lc-ctype=en_US.UTF8 --ttyname=$(tty) <%22%0A4096-bit RSA key, 
ID 0xC27306B86774D6F7,%0Acreated 2012-11-05 (main key ID 0x39278DA8109E6244).%0A


Cheers,
-- 
Guilhem.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (800, 'testing'), (700, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pinentry-curses depends on:
ii  libc62.17-97
ii  libncurses5  5.9+20130608-1
ii  libtinfo55.9+20130608-1

pinentry-curses recommends no packages.

Versions of packages pinentry-curses suggests:
pn  pinentry-doc  

-- no debconf information


signature.asc
Description: Digital signature

Bug#734163: subversion: corrupted data

[Vincent Lefevre]

Control: severity -1 important

with potential security problems for users who have the printing
feature of the terminal enabled.

On 2014-01-04 10:21:53 -0500, James McCoy wrote:
> This is purely a display issue, so I'm downgrading the severity.

OK, but I'm raising it to important since it managed to break the
status of one of my terminals: the semi-graphics characters could
no longer be displayed correctly until I typed "reset" (I wonder
how it could do that). So, apparently, it can send arbitrary
escape sequences to the terminal!

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#578393: cups: Dymo label printer is not listet, but GPL driver exists

[Didier 'OdyX' Raboud]

Control: reassign -1 wnpp
Control: retitle -1 RFP: dymo-cups-drivers -- Cups drivers for Dymo
labelwriter
Hi Jonas,

as has been pointed in the #640246 bug, this is essentially a "Request
for Package", which I consider covered by the (later) request to package 
dymo-cups-drivers, #640246.

I'm therefore hereby merging the two bugs. I might eventually take a
shot at getting these drivers packaged, but don't count on it.

Cheers, OdyX

Le lundi, 19 avril 2010, 16.53:16 Jonas Stein a écrit :
> The readme says:
> 
> ==
> The DYMO SDK for Linux contains Linux drivers for the LabelWriter and
> LabelManager product lines. The drivers conform to the CUPS (Common
> Unix Printing System) standard. The SDK also includes documentation,
> driver source code and examples of use.
> 
> http://www.dymo.com/media/Software/dymo-cups-drivers-1.2.0.tar.gz

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

Bug#611068: ikiwiki: Create index pages for empty directories in underlays

[Simon McVittie]

tags 611068 + upstream patch
thanks

On Mon, 09 Apr 2012 at 15:54:33 +0100, Simon McVittie wrote:
> forwarded 611068 
> http://ikiwiki.info/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed/

Any thoughts on this? I've been using both proposed branches on my own wikis
for some time.

Thanks,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#687072: xbmc-bin: invalid pointer on munmap_chunk()

[Balint Reczey]

tags 687072 unreproducible moreinfo
thanks

Hi Mircea,

On 09/09/2012 12:38 PM, Mircea Gherzan wrote:
> Package: xbmc-bin
> Version: 2:11.0~git20120510.82388d5-1+b1
> Severity: normal
> 
> Stack trace:
> 
> Thread 1 (Thread 0x7f712d719700 (LWP 2829)):
> #0  0x7f713e2b6475 in *__GI_raise (sig=) at
> .../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x7f713e2b96f0 in *__GI_abort () at abort.c:92
> #2  0x7f713e2f032b in __libc_message (do_abort=,
> fmt=) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> #3  0x7f713e2f9b76 in malloc_printerr (action=3, str=0x7f713e3d0690
> "munmap_chunk(): invalid pointer", ptr=) at malloc.c:
> #4  0x7f713e8e1818 in std::string::reserve(unsigned long) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5  0x7f713e8e1aa5 in std::string::append(char const*, unsigned long) ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #6  0x0091a793 in CDVDOverlayCodecTX3G::Decode(unsigned char*, int,
> double, double) ()
I have checked CDVDOverlayCodecTX3G::Decode and there is nothing
obviously wrong with it.
Based on the stack trace I suspect there was a memory allocation issue
somewhere else in the code where the memory pointed to by the reported
invalid pointer has been freed.
Could you please test latest version from unstable?
If the issue still exists please run xbmc under valgrind to let us able
to find the place where the invalid free occurs.

Cheers,
Balint




signature.asc
Description: OpenPGP digital signature

Bug#734156: how-can-i-help: "no such file to load -- debian_version" after upgrade of ruby-debian package

[Lucas Nussbaum]

@ Armin: you install to 'apt-get install ruby'

Hi Debian-Ruby,

The bug report below is interesting. The user has ruby1.8 installed, that
provides ruby-interpreter. As a result, h-c-i-h Depends' line is satisfied:
Depends: ruby | ruby-interpreter, ruby-debian, ruby-json

However, since ruby-debian no longer has support for ruby1.8, h-c-i-h can't use
ruby1.8.

I'm not sure of how to address this situation. For now, I'll just drop
|ruby-interpreter. But the overall handling of dependencies when switching Ruby
versions seems fragile. And there are 578 occurences of "Depends: ruby
| ruby-interpreter" in the archive, which scares me a bit.

Maybe ruby-defaults should provide a symlink to the default ruby version
that we could use in shebangs (#!/usr/bin/ruby-debian-default)? That
would allow to ensure that hcih really runs with ruby1.9.3 even if the
user used update-alternatives to switch to another version.

Lucas

On 04/01/14 at 13:09 +0100, Armin Haas wrote:
> Package: how-can-i-help
> Version: 1
> Severity: normal
> 
> Dear Maintainer,
> 
> upon upgrading the ruby-debian package from 0.3.8+b1 to 0.3.8+b2
> I got the following error message:
> 
> /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- 
> debian_version (LoadError)
> from 
> /usr/lib/ruby/vendor_ruby/debian.rb:24
> from /usr/bin/how-can-i-help:20:in 
> `require'
> from /usr/bin/how-can-i-help:20
> E: Problem executing scripts DPkg::Post-Invoke '[ ! -e 
> /usr/bin/how-can-i-help ] || /usr/bin/how-can-i-help'
> E: Sub-process returned an error code
> 
> The upgrade of ruby-debian iteslf was not afected (according to apt-check).
> 
> Cheers
> 
> Armin
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.12-1-686-pae (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages how-can-i-help depends on:
> ii  ruby-debian 0.3.8+b2
> ii  ruby-json   1.8.0-1+b1
> ii  ruby1.8 [ruby-interpreter]  1.8.7.358-9
> 
> how-can-i-help recommends no packages.
> 
> how-can-i-help suggests no packages.
> 
> -- no debconf information
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734184: (no subject)

[Andreas Tille]

Package: autodocktools
Version: 1.5.7~rc1~cvs.20130519-1
Severity: grave
Justification: renders package unusable

Hi,

as Stephen P. Molnar reported here

   
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-January/024278.html

(Stephen, it would be better to fire up the reportbug tool as I did
right now rather than writing an e-mail to the list since reportbug tool
creates some potentially relevant system information - see below.) there
is a problem with autodocktools which I can reproduce on my system.  The
status window says:

Python 2.7.6 (default, Dec  6 2013, 20:05:37) 
[GCC 4.8.2] on linux2
Type "copyright", "credits" or "license()" for more information.
 No Subprocess 
>>> Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/AutoDockTools/__init__.py", line 433, 
in runADT
title=title, withShell= not interactive, verbose=False, gui=gui)
  File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 1029, in 
__init__
text='Dashboard', font=('Helvetica', '', 10), padx=3, pady=0)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 2779, in __init__
Widget.__init__(self, master, 'radiobutton', cnf, kw)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 2039, in __init__
(widgetName, self._w) + extra + self._options(cnf))
TclError: expected integer but got ""


I somehow have the feeling that the problem is caused by incompatible
Tcl/Tk versions.  If nobody in Debian Med team has any clue we might
perhaps get some useful hint from upstream (in CC).

Kind regards

   Andreas.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages autodocktools depends on:
ii  mgltools-molkit 1.5.7~rc1~cvs.20130519-1
ii  mgltools-pmv1.5.7~rc1~cvs.20130519-1
ii  mgltools-support1.5.7~rc1~cvs.20130519-1
ii  mgltools-viewerframework1.5.7~rc1~cvs.20130519-1
ii  mgltools-volume 1.5.7~rc1~cvs.20130519-1
ii  python  2.7.5-5
ii  python-pil.imagetk [python-imaging-tk]  2.2.1-3

Versions of packages autodocktools recommends:
ii  mgltools-pyautodock   1.5.7~rc1~cvs.20130519-1
ii  mgltools-utpackages   1.5.7~rc1~cvs.20130519-1
ii  mgltools-webservices  1.5.7~rc1~cvs.20130519-1

Versions of packages autodocktools suggests:
ii  autodock   4.2.5.1-3
pn  autodock-vina  
pn  ballview   
pn  mgltools-cadd  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734183: mupdf: usage with compressed pdf-files

[Jörg-Volker Peetz]

Package: mupdf
Version: 1.3-1
Severity: wishlist

Dear Kan-Ru Chen,

I'd like to suggest to replace the link /usr/bin/mupdf -> mupdf-x11 by a little
script (similar to /usr/bin/xpdf from the xpdf-package) in order to be able to
use mupdf also with compressed pdf-files. Please find attached a script which I
use on my system for this purpose. Maybe it can be a useful enhancement for the
package.

Best regards,
Jörg-Volker.
#!/bin/sh
# Copyright (c) 2001 Alcove (Yann Dirson ) - 
http://www.alcove.com/
# Copyright (C) 2011 Michael Gilbert 
# Copyright (C) 2011 Osamu Aoki 
# Copyright (C) 2013 Jörg-Volker Peetz 
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .

set -e

file=""
cmd="mupdf-x11"
while [ "$#" -gt "0" ]; do
case "$1" in
-p|-r|-b)
cmd="$cmd $1 "$2"" && shift ;;
*)
test -f "$1" && file="$1" && break ||
( echo "error: \"$1\" file not found" && false ) ;;
esac
shift
done

tmp=$(tempfile -s .pdf)
case "$file" in
*.gz|*.Z)  zcat "$file" > "$tmp" && exec 3< "$tmp" && file="/dev/fd/3";;
*.xz) xzcat "$file" > "$tmp" && exec 3< "$tmp" && file="/dev/fd/3";;
*.bz2)bzcat "$file" > "$tmp" && exec 3< "$tmp" && file="/dev/fd/3";;
esac
rm -f "$tmp"

if [ "$file" = "" ]; then
exec $cmd || true
elif [ "$title" = "" ]; then
exec $cmd "$file" || true
fi

Bug#701141: NMUing to add extra tools to libnss3-tools

[Daniel Kahn Gillmor]

I'm uploading the same NMU of NSS now as 3.15.3.1-1.1, adding several
useful utilities to libnss3-tools (http://bugs.debian.org/701141).

The changes are available in git (including a signed tag) at:

 git://lair.fifthhorseman.net/~dkg/nss

They should be able to be directly pulled into the pkg-mozilla
repository by anyone with write permissions to that repo.

Hope this is helpful!

Regards,

--dkg


pgpAgKZi4c9KM.pgp
Description: PGP signature

Bug#701807: [PATCH] video playback enhancements for Linux part1: vdpau

[Balint Reczey]

tags 701807 moreinfo
thanks

Hi Dominic,

Thank you for the patch. Could you please refresh it and test it on
latest unstable version (2:12.3+dfsg1-3)?
I would like to give a few weeks to 12.3 in unstable and testing, but
if Gotham does not get releases soon, I'm open to giving it a try.

Cheers,
Balint

On 02/27/2013 12:55 PM, Dominic Evans wrote:
> Package: xbmc
> Version: 2:12.0~git20130127.fb595f2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Please consider using quilt to import this Linux-specific patch into
> debian/packages/ (it has been backported from upstream master) and
> delivering it to experimental for users to test. Other distros such as
> OpenElec already have this patch applied and it has been shown to
> significantly improve rendering on Linux for nvidia-vdpau-driver
> users.
> 
> * Performace improvements
> Separate threads for deinterlacing, opengl interoperation, frame
> buffering in renderer. This maximizes time for decoding and
> deinterlacing.
> 
> * Improved deinterlacing
> The advanced methods now use 4 past and 2 future fields, instead of 2
> past and 1 future. I have stutter free playback of 1080i@50,
> temporal/spacial deinterlacing on ION2
> 
> * Fix stuttering caused by overwrite (early reuse) of video surfaces
> 




signature.asc
Description: OpenPGP digital signature

Bug#734185: [zsync] HTTP range requests are broken

[Aiko Barz]

Package: zsync
Version: 0.6.2-1
Severity: normal

--- Please enter the report below this line. ---

Example file size: 380476
Requested range by zsync: bytes=0-380927

So, the client asked for a part of the file that lies beyond the end of 
the file. Most web servers ignore this behavior like nginx:


Request:
GET /20121009-165404.jpg HTTP/1.1
User-Agent: zsync/0.6.2
Host: tumbleweed:80
Referer: http://tumbleweed:80/20121009-165404.jpg.zsync
Range: bytes=0-380927
Connection: close

Reply:
HTTP/1.1 206 Partial Content
Server: nginx/1.2.1
Date: Sat, 04 Jan 2014 15:44:01 GMT
Content-Type: image/jpeg
Content-Length: 380476
Last-Modified: Fri, 03 Jan 2014 14:03:32 GMT
Connection: close
Content-Range: bytes 0-380475/380476

But from my understanding, this might also result in 416 reply:
416 Requested Range Not Satisfiable

--- System information. ---
Architecture: amd64
Kernel: Linux 3.12-1-amd64

Debian Release: jessie/sid
500 unstable ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (>= 2.7) | 2.17-97


Package's Recommends field is empty.

Package's Suggests field is empty.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Ian Jackson  writes:
> Bdale Garbee writes ("Bug#727708: init system discussion status"):
>> Russ Allbery  writes:

>>> My inclination would be to give maintainers technical advice to accept
>>> integrations with either existing synchronization protocols, but leave
>>> it as technical advice rather than the binding part of the decision.

>> I strongly agree.

> OK, I would be quite happy to say that we would like each daemon package
> to implement at least one non-forking startup protocol, but that we
> won't force this on maintainers.

> Would that suit you both ?

I may have lost the thread here, but that doesn't sound quite right.
Wouldn't we want to say that each daemon package should implement the
native non-forking startup protocol for the default init system, and we
would like the maintainer to merge patches for other startup protocols if
active maintainers of other init systems ask for this?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734186: [strongswan-nm] The configuration of strongswan in Gnome3 fails partly. Starting the VPN fails partly too.

[Aiko Barz]

Package: strongswan-nm
Version: 5.1.0-3
Severity: normal

--- Please enter the report below this line. ---

1) Configuration
I did not figure out how to setup a strongswan connection within the 
Gnome3 Network Manager toolkit in the top right corner. I worked around 
this by using the classic "nm-connection-editor".


2) Startup
The connections initialization fails right away. However, when doing
sudo /usr/lib/ipsec/charon-nm
first in a terminal, everything works fine.

--- System information. ---
Architecture: amd64
Kernel: Linux 3.12-1-amd64

Debian Release: jessie/sid
500 unstable ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6 (>= 2.4) | 2.17-97
libdbus-glib-1-2 (>= 0.78) | 0.100.2-1
libglib2.0-0 (>= 2.14.0) | 2.36.4-1
libnm-glib-vpn1 (>= 0.7.999) | 0.9.8.0-5
libnm-util2 (>= 0.7.0) | 0.9.8.0-5
libstrongswan | 5.1.0-3
strongswan-ike | 5.1.0-3


Recommends (Version) | Installed
=-+-===
network-manager-strongswan | 1.3.0-1


Package's Suggests field is empty.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734187: gnome-documents: Failed to start gnome-documents

[Thomas Bechtold]

Package: gnome-documents
Version: 3.10.0-1
Severity: important

Dear Maintainer,

I tried to start gnome-documents from command line and got the following
error:

$ gnome-documents 

(gjs-console:31267): Gjs-WARNING **: JS ERROR: Error: Requiring GdPrivate, 
version 1.0: Typelib file for namespace 'Zpj', version '0.0' not found
@/usr/share/gnome-documents/js/application.js:38
@/usr/share/gnome-documents/js/main.js:22
@:1


(gjs-console:31267): Gjs-WARNING **: JS ERROR: Error: Requiring GdPrivate, 
version 1.0: Typelib file for namespace 'Zpj', version '0.0' not found
@/usr/share/gnome-documents/js/application.js:38
@/usr/share/gnome-documents/js/main.js:22
@:1


(gjs-console:31267): Gjs-WARNING **: JS ERROR: Error: Requiring GdPrivate, 
version 1.0: Typelib file for namespace 'Zpj', version '0.0' not found
@/usr/share/gnome-documents/js/application.js:38
@/usr/share/gnome-documents/js/main.js:22
@:1

JS_EvaluateScript() failed


Cheers,

Tom

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (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

Versions of packages gnome-documents depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gir1.2-evince-3.03.10.0-1+b1
ii  gir1.2-gdata-0.0 0.14.0-2
ii  gir1.2-gnomedesktop-3.0  3.10.1-2
ii  gir1.2-goa-1.0   3.10.0-2
ii  gir1.2-gtk-3.0   3.10.2-1
ii  gir1.2-tracker-0.16  0.16.2-1+b1
ii  gir1.2-webkit-3.02.2.3-1
ii  gjs  1.38.1-1
ii  libc62.17-97
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libevdocument3-4 3.10.0-1+b1
ii  libevview3-3 3.10.0-1+b1
ii  libgdata13   0.14.0-2
ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
ii  libglib2.0-0 2.38.2-1
ii  libgnome-desktop-3-8 3.10.1-2
ii  libgtk-3-0   3.10.2-1
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpangocairo-1.0-0  1.36.0-1+b1
ii  libzapojit-0.0-0 0.0.3-2
ii  tracker  0.16.2-1+b1

Versions of packages gnome-documents recommends:
ii  gnome-user-guide  3.8.2-1
ii  unoconv   0.6-5

gnome-documents suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

[Guido Günther]

Hi Felix,
On Fri, Jan 03, 2014 at 10:58:14PM +0100, Felix Geyer wrote:
> I've ported and tested the libvirt AppArmor support from the Ubuntu package.
> 
> The only difference in the profiles is this addition to 
> usr.lib.libvirt.virt-aa-helper:
>   /etc/libnl-[0-9]/classid r,
> 
> It can be enabled by setting this in /etc/libvirt/qemu.conf:
> security_driver = "apparmor"

Can you please work on upsreaming this? I don't see why this should be
in the Debian package. Who is going to maintain this policies in the
future?
Cheers,
 -- Guido

> 
> Cheers,
> Felix
> 
> PS: Could you please enable parallel building: dh $@ 
> --builddirectory=$(DEB_BUILDDIR) --parallel.
> That makes test-building so much more fun ;)

> diff -Nru libvirt-1.2.0/debian/apparmor/libvirt-qemu 
> libvirt-1.2.0/debian/apparmor/libvirt-qemu
> --- libvirt-1.2.0/debian/apparmor/libvirt-qemu1970-01-01 
> 01:00:00.0 +0100
> +++ libvirt-1.2.0/debian/apparmor/libvirt-qemu2013-11-12 
> 18:47:24.0 +0100
> @@ -0,0 +1,140 @@
> +# Last Modified: Wed Jul  8 09:57:41 2009
> +
> +  #include 
> +  #include 
> +  #include 
> +
> +  # required for reading disk images
> +  capability dac_override,
> +  capability dac_read_search,
> +  capability chown,
> +
> +  # needed to drop privileges
> +  capability setgid,
> +  capability setuid,
> +
> +  # this is needed with libcap-ng support, however it breaks a lot of things
> +  # atm, so just silence the denial until libcap-ng works right. LP: #522845
> +  deny capability setpcap,
> +
> +  network inet stream,
> +  network inet6 stream,
> +
> +  /dev/net/tun rw,
> +  /dev/tap* rw,
> +  /dev/kvm rw,
> +  /dev/ptmx rw,
> +  /dev/kqemu rw,
> +  @{PROC}/*/status r,
> +  owner @{PROC}/*/auxv r,
> +  @{PROC}/sys/vm/overcommit_memory r,
> +
> +  # For hostdev access. The actual devices will be added dynamically
> +  /sys/bus/usb/devices/ r,
> +  /sys/devices/**/usb[0-9]*/** r,
> +
> +  # WARNING: this gives the guest direct access to host hardware and specific
> +  # portions of shared memory. This is required for sound using ALSA with 
> kvm,
> +  # but may constitute a security risk. If your environment does not require
> +  # the use of sound in your VMs, feel free to comment out or prepend 'deny' 
> to
> +  # the rules for files in /dev.
> +  /{dev,run}/shm r,
> +  /{dev,run}/shmpulse-shm* r,
> +  /{dev,run}/shmpulse-shm* rwk,
> +  /dev/snd/* rw,
> +  capability ipc_lock,
> +  # spice
> +  /usr/bin/qemu-system-i386-spice rmix,
> +  /usr/bin/qemu-system-x86_64-spice rmix,
> +  /run/shm/ r,
> +  owner /run/shm/spice.* rw,
> +  # 'kill' is not required for sound and is a security risk. Do not enable
> +  # unless you absolutely need it.
> +  deny capability kill,
> +
> +  # Uncomment the following if you need access to /dev/fb*
> +  #/dev/fb* rw,
> +
> +  /etc/pulse/client.conf r,
> +  @{HOME}/.pulse-cookie rwk,
> +  owner /root/.pulse-cookie rwk,
> +  owner /root/.pulse/ rw,
> +  owner /root/.pulse/* rw,
> +  /usr/share/alsa/** r,
> +  owner /tmp/pulse-*/ rw,
> +  owner /tmp/pulse-*/* rw,
> +  /var/lib/dbus/machine-id r,
> +
> +  # access to firmware's etc
> +  /usr/share/kvm/** r,
> +  /usr/share/qemu/** r,
> +  /usr/share/bochs/** r,
> +  /usr/share/openbios/** r,
> +  /usr/share/openhackware/** r,
> +  /usr/share/proll/** r,
> +  /usr/share/vgabios/** r,
> +  /usr/share/seabios/** r,
> +  /usr/share/ovmf/** r,
> +
> +  # access PKI infrastructure
> +  /etc/pki/libvirt-vnc/** r,
> +
> +  # the various binaries
> +  /usr/bin/kvm rmix,
> +  /usr/bin/qemu rmix,
> +  /usr/bin/qemu-system-arm rmix,
> +  /usr/bin/qemu-system-cris rmix,
> +  /usr/bin/qemu-system-i386 rmix,
> +  /usr/bin/qemu-system-m68k rmix,
> +  /usr/bin/qemu-system-mips rmix,
> +  /usr/bin/qemu-system-mips64 rmix,
> +  /usr/bin/qemu-system-mips64el rmix,
> +  /usr/bin/qemu-system-mipsel rmix,
> +  /usr/bin/qemu-system-ppc rmix,
> +  /usr/bin/qemu-system-ppc64 rmix,
> +  /usr/bin/qemu-system-ppcemb rmix,
> +  /usr/bin/qemu-system-sh4 rmix,
> +  /usr/bin/qemu-system-sh4eb rmix,
> +  /usr/bin/qemu-system-sparc rmix,
> +  /usr/bin/qemu-system-sparc64 rmix,
> +  /usr/bin/qemu-system-x86_64 rmix,
> +  /usr/bin/qemu-system-x86_64-spice rmix,
> +  /usr/bin/qemu-alpha rmix,
> +  /usr/bin/qemu-arm rmix,
> +  /usr/bin/qemu-armeb rmix,
> +  /usr/bin/qemu-cris rmix,
> +  /usr/bin/qemu-i386 rmix,
> +  /usr/bin/qemu-m68k rmix,
> +  /usr/bin/qemu-mips rmix,
> +  /usr/bin/qemu-mipsel rmix,
> +  /usr/bin/qemu-ppc rmix,
> +  /usr/bin/qemu-ppc64 rmix,
> +  /usr/bin/qemu-ppc64abi32 rmix,
> +  /usr/bin/qemu-sh4 rmix,
> +  /usr/bin/qemu-sh4eb rmix,
> +  /usr/bin/qemu-sparc rmix,
> +  /usr/bin/qemu-sparc64 rmix,
> +  /usr/bin/qemu-sparc32plus rmix,
> +  /usr/bin/qemu-sparc64 rmix,
> +  /usr/bin/qemu-x86_64 rmix,
> +
> +  # for save and resume
> +  /bin/dash rmix,
> +  /bin/dd rmix,
> +  /bin/cat rmix,
> +  /etc/pki/CA/ r,
> +  /etc/pki/CA/* r,
> +  /etc/pki/libvirt/ r,
> +  /etc/pki/libvirt/** r,
> +
> +  # for rbd
> +  /etc/ceph/ceph.conf 

Bug#734188: ITP: folly -- library of C++11 components designed with practicality and efficiency in mind

[Laszlo Boszormenyi (GCS)]

Package: wnpp
Severity: wishlist
Owner: Laszlo Boszormenyi (GCS) 

* Package name: folly
  Version : git snapshot
  Upstream Author : Facebook, Inc.
* URL : https://github.com/facebook/folly
* License : Apache-2.0
  Programming Lang: C++
  Description : library of C++11 components designed with practicality and 
efficiency in mind
 
 It complements (as opposed to competing against) offerings such as Boost
 and of course std. In fact, we embark on defining our own component only
 when something we need is either not available, or does not meet the needed
 performance profile.
 Performance concerns permeate much of Folly, sometimes leading to designs
 that are more idiosyncratic than they would otherwise be (see e.g.
 PackedSyncPtr.h, SmallLocks.h). Good performance at large scale is a
 unifying theme in all of Folly.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734161: systemd service files

[Russ Allbery]

Dirk Heinrichs  writes:

> I once wrote systemd service files for the KDC and Admin Server for
> Exherbo. Maybe they can be used as a starting point.

Some comments on these, since I've been spending a bunch of time looking
at systemd lately for some reason.

> [Unit]
> Description=Kerberos 5 Admin Server
> After=syslog.target network.target

After=syslog.target isn't necessary with systemd in Debian, since syslog
uses socket activation.

It would be very nice to do without After=network.target.  The question is
what happens if kadmind is started before the network is fully up (if, for
instance, IPv6 address negotiation is still in progress).  That, in turn,
is a question of whether kadmind listens to wildcard addresses, or if it
tries to bind to all local addresses (for kpasswd, for instance), and if
the latter, whether it handles new addresses coming up after it's started.

> [Service]
> PIDFile=/run/kadmind.pid
> ExecStart=/usr/sbin/kadmind -P /run/kadmind.pid

Type=simple
ExecStart=/usr/sbin/kadmind -nofork $DAEMON_ARGS

would be better, assuming there isn't some problem with -nofork mode of
which I'm unaware.  For Debian, we'll also need:

EnvironmentFile=/etc/default/krb5-admin-server

There's also the RUN_KADMIND flag in /etc/default/krb5-admin-server.  My
preferred solution to this is what I did with lbcd: on upgrade of the
package, have postinst call update-rc.d krb5-admin-server disable if
RUN_KADMIND is set to false, and then document (in NEWS) that people
should just use update-rc.d krb5-admin-server disable going forward.  This
is the correct way to disable a service and works with all supported init
systems.

> [Unit]
> Description=Kerberos 5 Key Distribution Center
> After=syslog.target network.target

Similar comments here about both of these.

> [Service]
> PIDFile=/run/krb5kdc.pid
> EnvironmentFile=/etc/conf.d/krb5kdc.conf
> ExecStart=/usr/sbin/krb5kdc -P /run/krb5kdc.pid $KDC_ARGS

In Debian:

PIDFile=/var/run/krb5-kdc.pid
EnvironmentFile=/etc/default/krb5-kdc
ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $KDC_ARGS

In both cases, it would be good to send upstream patches to support socket
activation and then add socket units, since that will make it way easier
for the administrator to configure the listening sockets.  krb5kdc could
use a "don't fork" option so that the PID file workaround isn't required.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Steven Chamberlain]

Commenting as a porter, the decision on default init system might affect
me something like this:

If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arches.  I'm really grateful of Dimitri's work on this already.

But if GNU/Linux defaults to systemd, I'd say that's far too big, too
specialised around Linux, and likely to be a moving target to either
port it or maintain something compatible.

In that case, we may have to do the best we can with one of the other
init systems.  I'd wonder if it's still worth porting Upstart if few
systems would be using it, or packages having Upstart jobs.  I have good
feelings about OpenRC (which Gentoo already uses as an alternative
alongside systemd), or keeping plain sysvinit might even be still viable
for jessie only.

On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote:
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?

This aspect is most crucial to the ports.  At the very least, we'd need
to be able to get patches applied to fix startup issues on our init
system, even if the maintainer doesn't test or want to support this.  In
the worst case, we might have to give up on getting something like GNOME
working usefully without systemd, and thus not be able to ship it on
non-Linux ports.

Policy may need to explain whether hard systemd requirement is
permissible, if it should be expressed in package dependencies, or what
it should do otherwise (e.g. refuse to start, fail with error message,
fall back to something with reduced functionality).

If policy requires keeping functional sysvinit scripts around for
jessie, and/or (more controversially) can discourage the use of specific
non-portable functionality - which I think would be things like "expect
fork" or socket activation - I'm not necessarily saying this is a good
idea, but it would obviously work in our favour.

If non-Linux ports end up running and testing daemons on an alternate
init system *anyway*, I'd love for that work to benefit GNU/Linux users
who dislike the chosen default init system and want to use what we're
using instead.  And vice-versa, anyone running such a system and
finding/fixing startup issues, would likely be helping the ports.

[please keep me in Cc if responding directly to anything I said here]

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



signature.asc
Description: OpenPGP digital signature

Bug#734161: systemd service files

[Russ Allbery]

Russ Allbery  writes:

> In Debian:

> PIDFile=/var/run/krb5-kdc.pid
> EnvironmentFile=/etc/default/krb5-kdc
> ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $KDC_ARGS

This should be:

ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $DAEMON_ARGS

Sorry, cut and paste error.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Cory]

On 01/04/2014 11:21 AM, Steven Chamberlain wrote:

Commenting as a porter, the decision on default init system might affect
me something like this:

If GNU/Linux defaults to Upstart, it's likely in porters' interest to
get that working as well as possible so we can keep consistency with
Linux arches.  I'm really grateful of Dimitri's work on this already.

But if GNU/Linux defaults to systemd, I'd say that's far too big, too
specialised around Linux, and likely to be a moving target to either
port it or maintain something compatible.

In that case, we may have to do the best we can with one of the other
init systems.  I'd wonder if it's still worth porting Upstart if few
systems would be using it, or packages having Upstart jobs.  I have good
feelings about OpenRC (which Gentoo already uses as an alternative
alongside systemd), or keeping plain sysvinit might even be still viable
for jessie only.

On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote:

I wonder if folks could clarify what status they expect secondary init
systems to have in Debian?

This aspect is most crucial to the ports.  At the very least, we'd need
to be able to get patches applied to fix startup issues on our init
system, even if the maintainer doesn't test or want to support this.  In
the worst case, we might have to give up on getting something like GNOME
working usefully without systemd, and thus not be able to ship it on
non-Linux ports.

Policy may need to explain whether hard systemd requirement is
permissible, if it should be expressed in package dependencies, or what
it should do otherwise (e.g. refuse to start, fail with error message,
fall back to something with reduced functionality).

If policy requires keeping functional sysvinit scripts around for
jessie, and/or (more controversially) can discourage the use of specific
non-portable functionality - which I think would be things like "expect
fork" or socket activation - I'm not necessarily saying this is a good
idea, but it would obviously work in our favour.

If non-Linux ports end up running and testing daemons on an alternate
init system *anyway*, I'd love for that work to benefit GNU/Linux users
who dislike the chosen default init system and want to use what we're
using instead.  And vice-versa, anyone running such a system and
finding/fixing startup issues, would likely be helping the ports.

[please keep me in Cc if responding directly to anything I said here]

Thanks,
Regards,
If Debian go's with systemd they need to use systemd 207 as its 
supported in RHEL 7 so we know it's going to be supported for around 10 
years also why does Debian have systemd 204 in it's repos?? systemd 207 
is way better



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Ian Jackson]

Anthony Towns writes ("Bug#727708: init system other points, and conclusion"):
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?

Thanks for bringing up this point so very clearly.

I agree entirely with the thrust of your argument.  I would very much
like to support multiple init systems.  Because you can only have one
init system at once (unlike databases, but like MTAs and webservers),
I think it's reasonable that our goal should be that pretty much every
program should at least basically work with every init system, and
that most programs will work well with all of them.

For non-forking startup protocols, I think we should (for jessie+1
perhaps) define a supported set of protocols.  Every daemon package
should implement one of the supported set, and every init system
(including sysvinit if anyone cares to continue to maintain it) should
implement all of them (whether via some kind of compatibility shim or
otherwise).

For the per-init-system job/unit/whatever files, if we can't come up
with some kind of meta format or compatibility converter(s), I would
actually prefer to require every daemon maintainer to supply two or
perhaps three such task specification files.

For admin tools and the like (eg systemd-ui or the gnome control
panel) I think it's OK for some of the functionality not to be fully
available with every init system.  This is particularly true if the
functionality is for manipulating features that aren't available in
the unsupported systems.

If it's just a case that the admin tool doesn't know how to talk to
the relevant feature, or the admin tool's model makes assumptions
about the underlying init system, then Debian should welcome
contributions of the missing pieces, in whatever is the appropriate
form for those pieces.  That might be (for example) simply glue code,
or it might be replacement UI elements which appear when the other
init system is in use.  Those pieces might be in the same or separate
packages, however is most technically and socially convenient.

> Forced to make a choice, should Debian go for smoother/tighter
> integration between apps, or more choice for users/sysadmins? I'd
> expect Debian to choose the latter; though Ubuntu, Red Hat and
> possibly Fedora might choose the former.

For the wellbeing of the whole free software community, and
particularly for our downstreams, we should be aiming for flexibility.

Ia.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson  writes:
> > Would that suit you both ?
> 
> I may have lost the thread here, but that doesn't sound quite right.
> Wouldn't we want to say that each daemon package should implement the
> native non-forking startup protocol for the default init system, and we
> would like the maintainer to merge patches for other startup protocols if
> active maintainers of other init systems ask for this?

It seems daft to go around making two (or perhaps three or more)
patches to every daemon when one patch to each daemon, and a couple of
compatibility modes in the init systems, would suffice.

There is no technical reason why systemd can't support raise(SIGSTOP)
and no technical reason why upstart can't support sd_notify.  I hereby
volunteer to implement support for sd_notify in upstart if it's
chosen.  It looks like it should take about an afternoon.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734189: renameutils: Non-ASCII chars are represented as octal escape sequences

[Dmitry Alexandrov]

Package: renameutils
Version: 0.12.0-1
Severity: normal

On UTF-8 locale qmv (or qcp) represents non-ASCII characters as octal
escape sequences. E. g.:

$ ls
10 £  file  файл
$ qmv

In editor (any) I will see:

10 \302\243 10 \302\243
filefile
\321\204\320\260\320\271\320\273\321\204\320\260\320\271\320\273

I can replace \302\243 with \342\202\254 for example and process will be
completed:

Plan is valid.

10 £ -> 10 €
Regular rename

10 £ -> 10 €

so it can be workarounded on editor side. But anyway.

-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (10, 'unstable'), (1, 
'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (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

Versions of packages renameutils depends on:
ii  libc6 2.13-38
ii  libreadline6  6.2+dfsg-0.1

renameutils recommends no packages.

renameutils suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Ian Jackson]

Steven Chamberlain writes ("Bug#727708: init system other points, and 
conclusion"):
> Policy may need to explain whether hard systemd requirement is
> permissible, if it should be expressed in package dependencies, or what
> it should do otherwise (e.g. refuse to start, fail with error message,
> fall back to something with reduced functionality).

Right.  In general I would prefer to see as good a support as is
feasible, in the particular case.

> If policy requires keeping functional sysvinit scripts around for
> jessie,

I think the TC is very likely to require this.  We haven't
specifically heard from everyone on this point but both Russ and I
(who disagree on several other important points) agree on it and none
of the other TC members have disagreed.

> and/or (more controversially) can discourage the use of specific
> non-portable functionality - which I think would be things like "expect
> fork" or socket activation - I'm not necessarily saying this is a good
> idea, but it would obviously work in our favour.

You are right that "expect fork" is nonportable in that sense.

I don't think socket activation is non-portable.  It would be
straightforward to write a wrapper program which set up the relevant
sockets and passed them to the daemon via either the systemd or
upstart socket activation protocols.  Such a wrapper could be used for
any daemon which needed it.  I guess the work involved would be a day
or two to produce something fully tested and documented.

The same is true for dbus activation, if I'm not mistaken, but I
haven't looked into this in any detail.

> If non-Linux ports end up running and testing daemons on an alternate
> init system *anyway*, I'd love for that work to benefit GNU/Linux users
> who dislike the chosen default init system and want to use what we're
> using instead.  And vice-versa, anyone running such a system and
> finding/fixing startup issues, would likely be helping the ports.

Yes, absolutely.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734190: Invalid Vcs-Svn entry in control file

[Simon Kainz]

Package: tclodbc
Version: 2.5.1-2
Severity: minor

Please drop "+ssh" protocol from debian/control::Vcs-* to make debcheckout
work everybody.

Debian Policy Manual 5.6.25 also states that the purpose of Vcs-* fields is to 
"indicate publicly accessible repositories" which is obviously not true by 
using svn+ssh:// protocol.

Regards,

Simon


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

[Stefano Rivera]

Hi Jonathan (2014.01.02_19:22:33_+0200)
> >  * having to support remote signing
> 
> It would be fair enough to stderr "not supported, please use the older
> tool in devscripts" and error 1 if such an argument was provided. That
> would be pragmatic if (as I suspect) -r is rarely used.

Aww. I'm a frequent user of -r.
I have better places to build big packages than on my lap, and I prefer
to keep my GPG key in as few places as possible.

But of course, this could be replaced by a new remote signing wrapper.
And, if popular enough, end up in devscripts...

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727085: Now we don't depend on the weird libevent patch

[GCS]

On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan  wrote:
>>checking whether the Boost::Thread library is available... yes
>>configure: error: Could not find a version of the library!
>
> It looks like it defaults to looking in /usr/bin instead of where lib
> boost is in sid. Try
>
> ./configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu/
 Thanks, it helped. I used $BOOST_LDFLAGS for testing, but that didn't
work. Anyway, folly is packaged and uploaded. HHVM is one small step
closer to be part of Debian.

Laszlo/GCS


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725097: ruby1.9.1: FTBFS with multiarchified Tcl/Tk

[Matthias Klose]

according to upstream's ext/tk/extconf.rb, ruby is not yet compatible with
Tcl/Tk 8.6.

Then I tried to build it with 8.6 as the default, and only build-depending on
tk8.5. which failed.

Here are the ugly hacks to build it with 8.5 as a non-default version, for 1.9
and 2.0.

http://launchpadlibrarian.net/161585999/ruby1.9.1_1.9.3.484-1ubuntu1_1.9.3.484-1ubuntu2.diff.gz
http://launchpadlibrarian.net/161583928/ruby2.0_2.0.0.353-1build1_2.0.0.353-1ubuntu1.diff.gz


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Sjoerd Simons  writes:

> Essentially this boils down to whether the logind interfaces will be
> available when using sysvinit. Most of the other interfaces (at least
> for current gnome as in experimental) would cause some functionality to
> either be missing or not work, but wouldn't yield a completely unusable
> system.

Thanks for that.  That's one of the key pieces of information that I was
wondering about, and I was just told I should probably talk to you since
you'd know.  :)

> Not having the logind interface is a lot harder to cope with and
> something that will not only impact Gnome. So essentially the most
> likely impact of using sysvinit _without_ a provider of the logind
> interface would be a non-usable Gnome desktop (and potentially even GDM
> to be unusable) on Jessie systems.

If we go with systemd, I think we have three options:

1. Allow packages that require logind to depend on systemd and require
   that it be used as the init system.  This is certainly the simplest for
   packaging applications that want to depend on logind, as well as for
   the systemd maintainers.  However, it means we lose the ability for
   users of at least those packages to be able to fall back on sysvinit if
   something goes wrong with systemd on their systems.  In the past, we've
   tried pretty hard to provide that capability when making a disruptive
   change of this kind.

2. Package logind separately from systemd, get it working with sysvinit.
   The problems with doing this, as I understand it, is that we'd not be
   able to upgrade such a separately-packaged logind beyond 204 for
   jessie.  I'm not sure how much impact that would have.  Also, it
   sounded to me like we would need to figure out who was going to do that
   work and maintain that package, including in the stable release.  If
   the current systemd maintainers are not interested in doing this, we
   absolutely shouldn't try to force them to do so.  Someone else would
   need to step forward to do this and figure out the right package
   relationships.  (Also, it would be good to maintain this separately so
   that the systemd maintainers could move forward with newer versions of
   systemd, including the logind built from its source.)

3. Get GNOME working at some level without logind.  I think it would be
   entirely acceptable for there to be some loss of functionality when
   GNOME is started in this way, such as no user switching and some
   configuration and control panels that rely on logind functionality not
   working.  But it would need to at least start and be basically
   functional for this to be a meaningful option.

None of these options are very appealing, but I think we have to pick one
of them.  I'm not seeing other options at the moment.

I think option 3 would be the most appealing for the project as a whole,
but I realize that's also the option that puts the most burden on GNOME
maintainers.  The only upside I can offer for that is that this would be
in the context of moving forward with systemd and would be a one-release
issue.  Post jessie, you'd be able to move forward with a standard
integration.

It's worth noting that option 3 is also what would be required if we
wanted to support GNOME on kFreeBSD.  I'm not sure if anyone is working on
that port or sufficiently interested in it to try to make it work, but
there may be some additional resources there.

Do you think there's a way that we could make option 3 work that the GNOME
maintainers would be comfortable with?

The systemd maintainers should definitely feel free to tell me if I'm
misunderstanding their feelings on option 2.

Do you think I should ask more generally on debian-devel if there are any
other maintainers in Debian that anticipate any problem with either
requiring sysvinit be supported as PID 1 for jessie, or with logind being
an optional component for jessie?

If we go with upstart as the default, obviously the situation is much
different, possibly including multiple different maintenance teams, and
would require packaging a broken-up version of systemd and building a
maintenance team around that.  It's basically option 2 with a bunch of
added disruption.  There are enough variables involved in that situation
that I hesitate to guess what it would look like.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727085: Now we don't depend on the weird libevent patch

[Faidon Liambotis]

On 01/04/14 19:54, László Böszörményi (GCS) wrote:

On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan  wrote:

checking whether the Boost::Thread library is available... yes
configure: error: Could not find a version of the library!


It looks like it defaults to looking in /usr/bin instead of where lib
boost is in sid. Try

./configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu/

  Thanks, it helped. I used $BOOST_LDFLAGS for testing, but that didn't
work. Anyway, folly is packaged and uploaded. HHVM is one small step
closer to be part of Debian.


Does folly have a stable ABI? I remember raising this with Paul some 
time ago and us deciding that embedding folly into the HHVM source would 
be the way to go, as there is really no stable interface between them.


Also, you're really supposed to file separate ITPs for separate packages 
(and file them *before* you make an upload).


Regards,
Faidon


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#711929: openarena: Became slower w/ the version.

[Jérémy Lal]

reassign 711929 ioquake3 1.36+u20130504+g42eeb75-2
thanks

I hope you won't mind...

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):

>> I may have lost the thread here, but that doesn't sound quite right.
>> Wouldn't we want to say that each daemon package should implement the
>> native non-forking startup protocol for the default init system, and we
>> would like the maintainer to merge patches for other startup protocols
>> if active maintainers of other init systems ask for this?

> It seems daft to go around making two (or perhaps three or more) patches
> to every daemon when one patch to each daemon, and a couple of
> compatibility modes in the init systems, would suffice.

Okay, it's possible that we just disagree here.  Having actually done it,
I don't see any reason not to implement both the upstart and systemd
readiness protocols in a typical daemon.  It's not at all hard, and in
most cases one is going to want to implement socket activation on the
systemd side anyway, which makes the readiness protocol mostly irrelevant.

Whether systemd upstream should support the SIGSTOP protocol is certainly
debatable, but I'm very reluctant to support an option that tries to force
the systemd maintainers to support the protocol indefinitely as a
Debian-specific fork.  This protocol is not widely used in Debian at the
moment, nor is it widely used upstream, and I think it would be a far
better use of our time to add support for the systemd protocol to upstart.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

[Russ Allbery]

Cory  writes:

> If Debian go's with systemd they need to use systemd 207 as its
> supported in RHEL 7 so we know it's going to be supported for around 10
> years also why does Debian have systemd 204 in it's repos?? systemd 207
> is way better

Because it's the last version before cgroup handling was changed, which
has implications for supporting logind under different init systems than
systemd.  So, in other words, moving systemd forward right now would force
various incompatibilities in an excessively disruptive way before we've
figured out how we want to handle them.

Regardless of how we decide this, we'll be figuring out how systemd could
move forward with newer versions, but it's wrapped up with the broader
discussion.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727085: Now we don't depend on the weird libevent patch

[GCS]

On Sat, Jan 4, 2014 at 6:58 PM, Faidon Liambotis  wrote:
> On 01/04/14 19:54, László Böszörményi (GCS) wrote:
>> Anyway, folly is packaged and uploaded. HHVM is one small step
>> closer to be part of Debian.
>
> Does folly have a stable ABI? I remember raising this with Paul some time
> ago and us deciding that embedding folly into the HHVM source would be the
> way to go, as there is really no stable interface between them.
 I can't answer this question. Still, I expect that HHVM will follow
ABI changes very fast. Paul?
Anyway, I think having a separate package and let users get knowledge
of that doesn't mean HHVM can't use an embedded copy if it needs to.
But it should be a separate package whenever it's possible.

> Also, you're really supposed to file separate ITPs for separate packages
> (and file them *before* you make an upload).
 ??? Please see its ITP[1]. I just noted the upload here. It's closed
by the changelog in the folly package if that will be accepted into
the archive.

Laszlo/GCS
[1] http://bugs.debian.org/734188


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson  writes:
> > Are the protocols offered by systemd and upstart each so plainly
> > reasonable, that we are willing to overrule a maintainer who feels they
> > protocol they are asked to support is too ugly or burdensome ?  Are such
> > a maintainer's objections so unreasonable ?
> 
> Ah, okay, I see what you're getting at.
> 
> I think they are.  Furthermore, I don't think there's any likely prospect
> that either will adopt a socket-based synchronization protocol other than
> systemd's, so saying that these aren't patches maintainers are required to
> take pretty much says that maintainers aren't required to integrate with
> the synchronization protocols.

In practice I think, given the political context, almost every daemon
maintainer (or upstream) will be willing to provide at least _one_ of
current the upstart and systemd protocols.

I don't see any value in insisting that every daemon maintainer should
support both, perhaps against their will, when supporting both
protocols in each of the perhaps six init systems will be much less
work overall.

> We could do that.  In general, I'd really prefer to defer to maintainers
> on what they're willing to integrate with.  [...]

So in that case you're saying you wouldn't want to overrule a
maintainer who declined to provide either of the currently available
protocols.  Which seems to be the opposite of what you say above.

> My inclination would be to give maintainers technical advice to
> accept integrations with either existing synchronization protocols,
> but leave it as technical advice rather than the binding part of the
> decision.

Of course formally all of this is just advisory, because no specific
example is here yet.  But I take you to mean that you don't want to
signal that we would overrule maintainers in particular circumstances.

Let us suppose that we don't say anything in particular about what
maintainers are expected to do.  (I'll also suppose WLOG that the TC
collectively votes for upstart as default.)

I would expect the following things to happen, then: upstart would get
sd_notify support; an upstart contributor send a patch adding an
upstart job for a daemon package which already supports systemd; the
daemon maintainer rejects the patch; the upstart contributor refers
the matter to us.

If we signal now what we would think of such a situation then this
will be less likely and if it does happen it will take much less long
to resolve.

(The same scenario might occur the other way round, although
currently the systemd maintainers have rejected the proposal to
support upstart's readiness protocol.)

> > It also includes the important point that it is up to the maintainer to
> > justify non-inclusion, not the other way around.
> 
> I guess the question here is how many conflicts we anticipate and whether
> it's worth being somewhat confrontational ourselves to head it off.  If
> there aren't conflicts in practice, we're just creating conflict without a
> need.  I don't think it matters a tremendous amount, though.

It is always easier and less personal to have these conversations in
the abstract, before particular people have got upset about the
specific question.

I really think we should decide in advance some ground rules for what
we would and would not be willing to force on a maintainer.

> > I don't agree.  Unless we either have a compatibility shim, or a policy
> > decision to transition, every package ought to be required to provide
> > something in the Debian menus.  Isn't this situation analogous to the
> > mime-support argument where we required a package to reinstate a mime
> > entry ?
> 
> Sorry, I didn't state my objection very well.  I wasn't talking about
> packages removing menu files.
> 
> Rather, your original wording to me sounds like introducing support for
> desktop files in Debian would violate this guidance unless the one
> introducing that support went through the Policy process first, even if
> the new support did not conflict with menus and did not break anything
> about menus.  That seems wrong.

Perhaps my wording needs improving.  The problematic step is not the
introduction of a parallel system.  The problematic steps are:

 * Stopping providing menu files in existing menu entry providers

 * Existing menu consumers stopping offering a way in the UI
   to access the Debian menu system menu

 * Justifying the above two steps on the grounds that menu is
   "obsolete"

All of these have happened, without a proper consideration of
(a) the goals of _all_ the users and admins who rely on or use the
Debian menu and how those goals can be met with the new arrangements
and (b) a proper transition plan.

No matter how creaky and obsolete the Debian menu system is (or is
thought to be in some quarters), that's not the way to go about
things.  It causes significant technical problems, and it's also very
rude.

We have unfortunately seen this same

Bug#725097: ruby1.9.1: FTBFS with multiarchified Tcl/Tk

[Sergei Golovan]

Hi Matthias,

On Sat, Jan 4, 2014 at 9:58 PM, Matthias Klose  wrote:
> according to upstream's ext/tk/extconf.rb, ruby is not yet compatible with
> Tcl/Tk 8.6.

Sad to hear that. But 8.5 stays with us for a while, so it's not a big deal.

>
> Then I tried to build it with 8.6 as the default, and only build-depending on
> tk8.5. which failed.
>
> Here are the ugly hacks to build it with 8.5 as a non-default version, for 1.9
> and 2.0.
>
> http://launchpadlibrarian.net/161585999/ruby1.9.1_1.9.3.484-1ubuntu1_1.9.3.484-1ubuntu2.diff.gz
> http://launchpadlibrarian.net/161583928/ruby2.0_2.0.0.353-1build1_2.0.0.353-1ubuntu1.diff.gz

I see, they are really ugly. I'll try to patch extconf.rb so it would
use versioned libraries in the multiarch directory.

Cheers!
-- 
Sergei Golovan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson  writes:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd.  There is little prospect of systemd
> > being "ported" to those systems.
> 
> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
> software and if someone wants to try to port it (or, possibly more likely,
> "port" it by writing something native that provides the same interfaces),
> they can.  Maybe upstream is right and it's untenable; maybe they're wrong
> and it's not as hard as they think.  I realize it's horribly unlikely for
> jessie, but still, as a matter of principle, I'd rather encourage the same
> software or at least the same interfaces across all of our ports.

Personally I think leaving this in makes the resolution look surreal
and out of touch.

> But, anyway, we can focus on the upstart position first and deal with that
> later.

OK.

> This seems fine to me, at least for right now.  I'm doing a bit of
> additional research right now to be sure that I understand the
> implications of this and may end up asking for any problems that anyone is
> aware of with this approach, just to be sure we're not missing something.

Right.  I looked at the reverse-dependencies of sysvinit in sid and
didn't see anything untoward.

> > I would like to be clear that maintainers don't need to take patches
> > that introduce embedded copies of sd_notify.
> 
> Oh, okay.  I had missed that aspect of things.  I think it's fine to be
> clear about that as long as we're not prohibiting via non-advice TC
> decision using an embedded copy (which feels like bug severity inflation
> to me).

OK.  But I will hold off editing 6C for this as we seem to be moving
in a different direction.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies

[Michael Vogt]

On Tue, Dec 31, 2013 at 11:58:17PM +0100, Julian Andres Klode wrote:
> On Tue, Dec 31, 2013 at 11:06:15PM +0100, Michael Vogt wrote:
[..]
> You really need to include the original copyright statement and the license
> here, otherwise you violate the license. If the original code does not
> include the license or a copyright statement above it, it might not be
> distributable at all, as the license clearly says:
> 
> The *above* copyright notice and *this permission notice* shall be included in
> all copies or substantial portions of the Software.
> 
> (I just added some emphasis)
> 
> I'd even say that including the copyright notice *below* the license terms
> is wrong, as the license clearly says *above*. But not including them is
> definitely wrong.
> 
> We don't want legal issues.

Indeed! The header was cargo-culted from the update-manager
test_pyflakes.py but I rewrote the file for python-apt completely so
we are clean here (and I fixed the comment). I will followup with the
update-manager test too.

Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

(Josh, is there some reason why you replied to the TC list directly
rather than the bug report ?  You should send your messages to the bug
so they are filed, displayed and archived there.  Thanks.)

Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> Clint Adams wrote:
> > As loath as I am to participate in this discussion, I have to ask
> > if your intent is to suddenly outlaw all the packages which depend
> > on runit.

Thanks for your intervention which is helpful.

> I think it'd be appropriate to allow dependencies on runit (or another
> package that contains an implementation of /sbin/init), as long as
> either the depending package doesn't depend on having /sbin/init be that
> init (which holds true for runit),

Right.

> *or* if an alternative package exists to integrate with the default
> init system.  For instance, git-daemon-run versus
> git-daemon-sysvinit versus a hypothetical git-daemon-systemd,

Personally I think this is a pretty nasty way for the git packages to
have done things, although I understand why.  But, regardless, I think
it's certainly fine from the init system compatibility point of view.

> ...  (Note that the latter would work better if upstart stopped
> conflicting with sysvinit, similar to how systemd can be installed
> without being init.)

There does seem to need to be some work there.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734191: RFS: libgeo-proj4-perl/1.04-1

[Bas Couwenberg]

Package: sponsorship-requests
Severity: normal

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "libgeo-proj4-perl"

 Package name: libgeo-proj4-perl
 Version : 1.04-1
 Upstream Author : Mark Overmeer 
 URL : https://metacpan.org/release/Geo-Proj4
 License : Artistic or GPL-1+
 Section : perl

It builds those binary packages:

  libgeo-proj4-perl - PROJ.4 library for cartographic projections

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

http://mentors.debian.net/package/libgeo-proj4-perl


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

  dget -x 
http://mentors.debian.net/debian/pool/main/libg/libgeo-proj4-perl/libgeo-proj4-perl_1.04-1.dsc

More information about Geo::Proj4 can be obtained from 
https://metacpan.org/release/Geo-Proj4.

Changes since the last upload:

  [ David Paleino ]
  * Drop unneeded debian/copyright line

  [ Bas Couwenberg ]
  * New upstream release.
  * Add myself to Uploaders.
  * Bump debhelper compatibility to 9.
  * Use metacpan.org instead of search.cpan.org.
  * Update to copyright-format 1.0 final.
  * Use canonical URLs for Vcs-* fields.
  * Bump Standards-Version to 3.9.5, changes: Vcs-* fields.
  * Restructure control file with cme fix dpkg-control.
  * Refresh patches.
  * Add lintian override for debian-watch-may-check-gpg-signature,
upstream doesn't provide signatures for verification.
  * Improve extended description.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734192: selinux-policy-default: Context unconfined_u:unconfined_r:mono_t:s0-s0:c0.c1023 would be invalid if enforcing

[Alberto Fuentes]

Package: selinux-policy-default
Version: 2:2.20131214-1
Severity: normal

I did a touch /.autorelabel after last update as suggested by NEWS

I get lots of these anyway:

[Sat Jan  4 16:03:27 2014] SELinux:  Context
unconfined_u:unconfined_r:mono_t:s0-s0:c0.c1023 would be invalid if enforcing

I have set it to permissive



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-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

Versions of packages selinux-policy-default depends on:
ii  libpam-modules   1.1.3-9
ii  libselinux1  2.2.1-1
ii  libsepol12.2-1
ii  policycoreutils  2.2.4-1
ii  python   2.7.5-5
ii  selinux-utils2.2.1-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.2-1
ii  setools  3.3.8-3

Versions of packages selinux-policy-default suggests:
pn  logcheck
ii  syslog-summary  1.14-2

-- Configuration Files:
/etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission 
denied: u'/etc/selinux/default/modules/active/file_contexts.local'

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723180: [PATCH] Revert "x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT"

[Andi Kleen]

On Fri, Jan 03, 2014 at 02:55:48PM +0100, Sebastian Andrzej Siewior wrote:
> where do I start. Let me explain what is going on here. The code
> sequence

Yes the IST stacks are needed for correctness, even in more cases than
the example below. You cannot just disable them, just because you don't
like them.

-Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
> Are you going to vote to overrule a maintainer who says 
> 
>   I have already implemented non-forking readiness protocol X and I
>   think support for all init systems in my daemon should be done via
>   one protocol.  Please do send me a patch for your init system Y task
>   file (and correponding packaging support) when init system Y has
>   support for protocol X.
> 
> ?
> 
> ISTM that if this situation arises it is due to a failure by the init
> system to be sufficiently accomodating.  I would vote to not overrule
> a maintainer in such a situation.

This might prompt of course the question of whether I would vote to
overrule the init system maintainer.

If it were the default init system, certainly.  But I would not want
to have the default init system be one where this was going to be
necessary.  The response from the upstart maintainers to the request
to support the systemd socket activation protocol convinces me this
isn't a problem for upstart.  We know it is a problem with systemd.

For a non-default init system it seems to me that this is a decision
for that init system's community.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730275: Bug#704032: Transition to boost 1.54

[Steve M. Robbins]

Hi Julien,

Thanks for the update!  Forwarding to the 1.53 removal request.

On January 4, 2014 02:52:38 PM you wrote:
> On Sun, Dec  1, 2013 at 16:43:07 +0100, Julien Cristau wrote:
> > On Sun, Jul 14, 2013 at 14:59:24 -0500, Steve M. Robbins wrote:
> > > Boost 1.54 is now in sid on all architectures, so we should transition
> > > to
> > > that.
> 
> Updated status update.
> 
> boost1.49 is being kept in testing by:
> - gnuradio
> - libkolabxml/ia64; should stop using --as-needed
> - libpwiz #731064
> - libzeep/sparc; FTBFS due to boost bug
> - mcrl2 #731067
> - pdns #726863 and #726945
> 
> boost1.53 no longer has any reverse deps in testing.  It can probably be
> removed from sid at this point.
> 
> Cheers,
> Julien


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

Bug#734194: bad reaction to out of disk space on server

[Joey Hess]

Package: offlineimap
Version: 6.5.4-2
Severity: normal

My imap server (running courier) ran out of disk space. offlineimap
then exhibited the following behaviors:

* Some messages began getting duplicated.
* Some folders started having uid validity problems. Deleting everything
  locally and running offlineimap twice on a folder was enough to cause
  a uuid validity problem to re-occur.

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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages offlineimap depends on:
ii  libjs-sphinxdoc  1.2+dfsg-1
ii  python   2.7.5-5
ii  python2.72.7.6-4

Versions of packages offlineimap recommends:
ii  python-sqlite  1.0.1-10

Versions of packages offlineimap suggests:
pn  doc-base 
pn  python-kerberos  

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#734193: selinux-policy-default: cowbuilder fail to create image

[Alberto Fuentes]

Package: selinux-policy-default
Version: 2:2.20131214-1
Severity: normal

Not sure if this is the relevant package for this bug

dpkg: error processing archive /var/cache/apt/archives/libboost-
iostreams1.54.0_1.54.0-4+b1_amd64.deb (--unpack):
cannot get security labeling handle: No such file or directory

I attach whole output

selinux is activated on permissive

This is the mount line of the partition:
/dev/mapper/box-root on / type ext4 (rw,relatime,seclabel,errors=remount-
ro,data=ordered)



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-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

Versions of packages selinux-policy-default depends on:
ii  libpam-modules   1.1.3-9
ii  libselinux1  2.2.1-1
ii  libsepol12.2-1
ii  policycoreutils  2.2.4-1
ii  python   2.7.5-5
ii  selinux-utils2.2.1-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.2-1
ii  setools  3.3.8-3

Versions of packages selinux-policy-default suggests:
pn  logcheck
ii  syslog-summary  1.14-2

-- Configuration Files:
/etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission 
denied: u'/etc/selinux/default/modules/active/file_contexts.local'

-- no debconf information
sudo cowbuilder --create
 -> Invoking pbuilder
  forking: pbuilder create --buildplace /var/cache/pbuilder/base.cow --mirror 
http://cdn.debian.net/debian --distribution sid --no-targz --extrapackages 
cowdancer 
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: Distribution is sid.
I: Current time: Sat Jan  4 15:18:33 CET 2014
I: pbuilder-time-stamp: 1388845113
I: Building the build environment
I: running debootstrap
/usr/sbin/debootstrap
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libaudit-common libaudit1 
libbz2-1.0 libcap2 libdb5.1 libsemanage-common libsemanage1 libslang2 
libustr-1.0-1 
I: Found additional base dependencies: binutils bzip2 cpp cpp-4.8 
debian-archive-keyring dpkg-dev g++ g++-4.8 gcc gcc-4.8 gnupg gpgv 
libapt-pkg4.12 libasan0 libatomic1 libc-dev-bin libc6-dev libcloog-isl4 
libdpkg-perl libgcc-4.8-dev libgdbm3 libgmp10 libgomp1 libisl10 libitm1 libmpc3 
libmpfr4 libquadmath0 libreadline6 libstdc++-4.8-dev libstdc++6 
libtimedate-perl libtsan0 libusb-0.1-4 linux-libc-dev make patch perl 
perl-modules readline-common xz-utils 
I: Checking component main on http://cdn.debian.net/debian...
I: Retrieving libacl1 2.2.52-1
I: Validating libacl1 2.2.52-1
I: Retrieving apt 0.9.14.2
I: Validating apt 0.9.14.2
I: Retrieving libapt-pkg4.12 0.9.14.2
I: Validating libapt-pkg4.12 0.9.14.2
I: Retrieving libattr1 1%3a2.4.47-1
I: Validating libattr1 1%3a2.4.47-1
I: Retrieving libaudit-common 1%3a2.3.2-3
I: Validating libaudit-common 1%3a2.3.2-3
I: Retrieving libaudit1 1%3a2.3.2-3
I: Validating libaudit1 1%3a2.3.2-3
I: Retrieving base-files 7.2
I: Validating base-files 7.2
I: Retrieving base-passwd 3.5.29
I: Validating base-passwd 3.5.29
I: Retrieving bash 4.2+dfsg-1
I: Validating bash 4.2+dfsg-1
I: Retrieving binutils 2.24-2
I: Validating binutils 2.24-2
I: Retrieving build-essential 11.6
I: Validating build-essential 11.6
I: Retrieving bzip2 1.0.6-5
I: Validating bzip2 1.0.6-5
I: Retrieving libbz2-1.0 1.0.6-5
I: Validating libbz2-1.0 1.0.6-5
I: Retrieving libcloog-isl4 0.18.1-3
I: Validating libcloog-isl4 0.18.1-3
I: Retrieving coreutils 8.21-1
I: Validating coreutils 8.21-1
I: Retrieving dash 0.5.7-3+nmu1
I: Validating dash 0.5.7-3+nmu1
I: Retrieving libdb5.1 5.1.29-7
I: Validating libdb5.1 5.1.29-7
I: Retrieving debconf 1.5.52
I: Validating debconf 1.5.52
I: Retrieving debconf-i18n 1.5.52
I: Validating debconf-i18n 1.5.52
I: Retrieving debian-archive-keyring 2012.4
I: Validating debian-archive-keyring 2012.4
I: Retrieving debianutils 4.4
I: Validating debianutils 4.4
I: Retrieving diffutils 1%3a3.3-1
I: Validating diffutils 1%3a3.3-1
I: Retrieving dpkg 1.17.5
I: Validating dpkg 1.17.5
I: Retrieving dpkg-dev 1.17.5
I: Validating dpkg-dev 1.17.5
I: Retrieving libdpkg-perl 1.17.5
I: Validating libdpkg-perl 1.17.5
I: Retrieving e2fslibs 1.42.9-2
I: Validating e2fslibs 1.42.9-2
I: Retrieving e2fsprogs 1.42.9-2
I: Validating e2fsprogs 1.42.9-2
I: Retrieving libcomerr2 1.42.9-2
I: Validating libcomerr2 1.42.9-2
I: Retrieving libss2 1.42.9-2
I: Validating libss2 1.42.9-2
I: Retrieving libc-bin 2.17-97
I: Validating libc-bin 2.17-97
I: Retrieving libc-dev-bin 2.17-97
I: Validating libc-dev-bin 2.17-97
I: Retrieving libc6 2.17-97
I: V

Bug#727085: Now we don't depend on the weird libevent patch

[Faidon Liambotis]

On Sat, Jan 04, 2014 at 07:07:15PM +0100, László Böszörményi (GCS) wrote:
Does folly have a stable ABI? I remember raising this with Paul some 
time

ago and us deciding that embedding folly into the HHVM source would be the
way to go, as there is really no stable interface between them.

I can't answer this question. Still, I expect that HHVM will follow
ABI changes very fast. Paul?
Anyway, I think having a separate package and let users get knowledge
of that doesn't mean HHVM can't use an embedded copy if it needs to.
But it should be a separate package whenever it's possible.


If the ABI isn't stable, HHVM is the least of your problems. Non ABI 
stable libraries have really no place in Debian: you have to bump the 
SONAME, rename the package, go through NEW, binNMU all reverse 
dependencies, go through a testing transition etc. every time and that's 
*if* you detect the ABI breakage and it doesn't get silently undetected 
crashing reverse dependencies (= RC bug).


Check with your upstream (Paul? someone else?) if they're guranteeing 
ABI, and preferrably also tag versions rather than packaging random git 
snapshots, *then* upload it. Otherwise it's a pretty pointless exercise 
and I'm sure it'll get REJECTed from NEW.


For HHVM, embedding the folly source as the upstream build does seems 
like the best course of action to me, especially since folly isn't a 
library that we expect to see wide adoption for other packages out 
there.



Also, you're really supposed to file separate ITPs for separate packages
(and file them *before* you make an upload).

??? Please see its ITP[1]. I just noted the upload here. It's closed
by the changelog in the folly package if that will be accepted into
the archive.


The reason ITPs exist and policy mandates that they are Cc'ed to 
debian-devel is so that all developers have a chance to raise issues 
(such as naming conflicts, ABI stability, package descriptions, previous 
work etc.).  Filing the ITP and uploading <= 30mins later is a really 
bad practice and doesn't really count, it feels like working around 
Policy to me. (it also hasn't even reached my debian-devel inbox yet, 
did you X-Debbugs-Cc it?)[1]


Regards,
Faidon

1: You're not the first person that I've told that :) cf.  
https://lists.debian.org/debian-devel/2013/06/msg00666.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697448: Re: xbmc: hangs on startup with no clue on why

[Balint Reczey]

tags 697448 confirmed
thanks

Hi Alex,

On 01/10/2013 02:24 PM, Alexandre Rossi wrote:
> found 697448 2:11.0~git20120510.82388d5-1
> thanks
> 
>> xbmc gives me a black screen (which replaces the root window
> background and
>> 100% CPU usage. There is no clue in the debug logs of what is
> happening or what is wrong.
> 
> The following command fixed the problem by not using libgl1-mesa-swx11
> $ sudo aptitude install libgl1-mesa-glx
> 
> Not sure if my hardware was too slow to software-render xbmc or if xbmc
> is not compatible with libgl1-mesa-swx11 .
It did not start for me either. Unfortunately there is no accepted way
of expressing that XBMC does not work with libgl1-mesa-swx11 using
dependencies.
Xbmc-bin already depends on libgl1-mesa-glx | libgl1, but libgl1 is
provided by libgl1-mesa-swx11, too.

I'll add a Breaks: libgl1-mesa-swx11 in the next upload which is not
fully compliant with Debian Policy, but it is the closest thing to what
needs to be expressed.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):

>> I think they are.  Furthermore, I don't think there's any likely
>> prospect that either will adopt a socket-based synchronization protocol
>> other than systemd's, so saying that these aren't patches maintainers
>> are required to take pretty much says that maintainers aren't required
>> to integrate with the synchronization protocols.

> In practice I think, given the political context, almost every daemon
> maintainer (or upstream) will be willing to provide at least _one_ of
> current the upstart and systemd protocols.

> I don't see any value in insisting that every daemon maintainer should
> support both, perhaps against their will, when supporting both protocols
> in each of the perhaps six init systems will be much less work overall.

>> We could do that.  In general, I'd really prefer to defer to
>> maintainers on what they're willing to integrate with.  [...]

> So in that case you're saying you wouldn't want to overrule a maintainer
> who declined to provide either of the currently available protocols.
> Which seems to be the opposite of what you say above.

Yes, I know, I'm being confusing.  I'm sorry about that.  It's because I'm
trying to balance two different goals, which are in conflict here.  One is
that I prefer to defer to maintainers on how to maintain their own
packages.  The other is that I think we all have some obligation to let
other people work on things they care about if it doesn't cause disruptive
impact on us.

I think the wording path that you're going down right now requires us to
take a firm stand one way or another, in advance, on what we're going to
tell the whole project to do.  I consider telling people what to do to be
an inherent problem, although sometimes an unavoidable one.  The more I
think about this, the more I prefer to give maintainers the technical
advice that they should integrate with any init system that is being
actively developed, provided that it doesn't have a negative impact on
their package, and leave it at that.

If we have to decide whether to override a maintainer on whether to
support a non-default init system, well, we'll have to decide that, and it
will be unpleasant.  But I'm not sure we need to proactively dive into
that unpleasantness.

> Of course formally all of this is just advisory, because no specific
> example is here yet.  But I take you to mean that you don't want to
> signal that we would overrule maintainers in particular circumstances.

Right.

> Let us suppose that we don't say anything in particular about what
> maintainers are expected to do.  (I'll also suppose WLOG that the TC
> collectively votes for upstart as default.)

> I would expect the following things to happen, then: upstart would get
> sd_notify support; an upstart contributor send a patch adding an upstart
> job for a daemon package which already supports systemd; the daemon
> maintainer rejects the patch; the upstart contributor refers the matter
> to us.

I'm not sure why you think the "daemon maintainer rejects the patch" part
of this is likely, particularly if upstart supports sd_notify, which makes
the patch basically trivial.

I don't think this is a likely conflict.  A much more likely conflict
would be that upstart is adopted as the default init system, a daemon is
patched to support raise(SIGSTOP), a systemd contributor submits a patch
to support sd_notify (or socket activation), and the daemon maintainer
rejects that patch.

I personally think that such a patch should be accepted.  But I don't know
that I'm willing to say in advance that we're going to try to force that
patch to be accepted.  So I'm good with offering technical advice to
accept such patches, but not with signaling that we're going to override
people who don't.

> It is always easier and less personal to have these conversations in the
> abstract, before particular people have got upset about the specific
> question.

> I really think we should decide in advance some ground rules for what we
> would and would not be willing to force on a maintainer.

I consider the TC, when working properly, to be like a court, not an
executive or legislature.  I therefore prefer focused and limited
decisions for the same reasons that court decisions try to err on the side
of being focused and limited.  That doesn't completely rule out your
point, of course; courts, particularly high courts, set these sorts of
guidelines for evaluating future cases all the time.  But I'm not seeing
it as obviously necessary here.

> No matter how creaky and obsolete the Debian menu system is (or is
> thought to be in some quarters), that's not the way to go about things.
> It causes significant technical problems, and it's also very rude.

I would be more comfortable with this argument if we had a working Policy
process that could reach these conclusions in a timely fashion.  It's been
obvious to me that desktop files are a bette

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson  writes:
> > It seems daft to go around making two (or perhaps three or more) patches
> > to every daemon when one patch to each daemon, and a couple of
> > compatibility modes in the init systems, would suffice.
> 
> Okay, it's possible that we just disagree here.  Having actually done it,
> I don't see any reason not to implement both the upstart and systemd
> readiness protocols in a typical daemon.  It's not at all hard, and in
> most cases one is going to want to implement socket activation on the
> systemd side anyway, which makes the readiness protocol mostly irrelevant.

The question isn't what you would prefer.  The question is this:

Are you going to vote to overrule a maintainer who says 

  I have already implemented non-forking readiness protocol X and I
  think support for all init systems in my daemon should be done via
  one protocol.  Please do send me a patch for your init system Y task
  file (and correponding packaging support) when init system Y has
  support for protocol X.

?

ISTM that if this situation arises it is due to a failure by the init
system to be sufficiently accomodating.  I would vote to not overrule
a maintainer in such a situation.

> Whether systemd upstream should support the SIGSTOP protocol is certainly
> debatable, but I'm very reluctant to support an option that tries to force
> the systemd maintainers to support the protocol indefinitely as a
> Debian-specific fork.

We have endless Debian-specific patches which are precisely there to
support additional protools which make packaging and integration
easier.  OK, nowadays there is less need of this because our technical
choices have been more widely recognised as good, but it is not
something we should be afraid of.

Support for raise(SIGSTOP) would be a small patch which Debian could
easily carry indefinitely if need be.

Consider for example the support for searching "whatever.d"
directories for configuration of one kind or another, which has been
added by many Debian maintainers first in their patches (and I bet
there are packages where that's still not upstream).

>  This protocol is not widely used in Debian at the
> moment, nor is it widely used upstream, and I think it would be a far
> better use of our time to add support for the systemd protocol to upstart.

I think we need to add both protocols to both daemons.  This is
because I want integration to be as easy and uncontroversial as
possible.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727085: Now we don't depend on the weird libevent patch

[Paul Tarjan]

> I can't answer this question. Still, I expect that HHVM will follow
>ABI changes very fast. Paul?
>Anyway, I think having a separate package and let users get knowledge
>of that doesn't mean HHVM can't use an embedded copy if it needs to.
>But it should be a separate package whenever it's possible.

We pin HHVM to certain git hashes. If there is a folly change we need
(which is rare) we will update the hash of the git submodule. I don't know
the details of how folly does backwards compatibility but if the hashes we
have correspond to folly package version, then you could just pin our hhvm
versions to folly versions, right?

+Jordan and Sara who know more about the folly process.

Paul


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):

>> Whether systemd upstream should support the SIGSTOP protocol is
>> certainly debatable, but I'm very reluctant to support an option that
>> tries to force the systemd maintainers to support the protocol
>> indefinitely as a Debian-specific fork.

> We have endless Debian-specific patches which are precisely there to
> support additional protools which make packaging and integration easier.
> OK, nowadays there is less need of this because our technical choices
> have been more widely recognised as good, but it is not something we
> should be afraid of.

I'm doubtful that either of us are going to convince the other on this
point.  I don't consider it comparable to the other examples you're
citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
choice.  Simple, yes, but that's not the same thing.

Anyway, it's not at all clear to me that we need to argue about this here.
If we adopt upstart, and a bunch of daemons are adapted to SIGSTOP, that's
obviously going to increase the utility of supporting SIGSTOP in systemd.
I would rather let the systemd maintainers discuss that situation with
upstream and reach their own conclusions given the dynamics of that
situation, which are difficult to predict in advance.  If we adopt
systemd, then I think it's fairly uncontroversial to ask maintainers to
adopt support for systemd's socket activation or, failing that,
notification protocol.

So, either way, I don't see the utility of making this kind of statement
now.

> I think we need to add both protocols to both daemons.  This is because
> I want integration to be as easy and uncontroversial as possible.

This is the sort of statement that carries one meaning when stated as a
personal opinion as an individual Debian contributor, and a completely
different meaning when included in a TC decision.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734195: RM: boost1.49 -- ROM; Obsolete

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal


Please remove boost1.49.  Boost 1.54 is in the archive (and is now the
default) and Boost 1.55 is in preparation for upload.

-Steve


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734115: libotr5: Please enable the bindnow hardening flag

[Ian Goldberg]

On Fri, Jan 03, 2014 at 11:23:44PM +0100, intrig...@debian.org wrote:
> Source: libotr
> Version: 4.0.0-2.2
> Severity: normal
> Tags: patch
> User: hardening-disc...@lists.alioth.debian.org
> Usertags: goal-hardening
> 
> Hi,
> 
> the attached patch completes the set of hardening flags used for
> libotr, by enabling the bindnow linker option.
> 
> Cheers,
> --
>   intrigeri
>   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
> 

> diff -Nru libotr-4.0.0/debian/rules libotr-4.0.0/debian/rules
> --- libotr-4.0.0/debian/rules 2012-08-24 17:23:35.0 +0200
> +++ libotr-4.0.0/debian/rules 2014-01-02 21:54:23.0 +0100
> @@ -19,7 +19,7 @@
>  
>   # Add here commands to configure the package.
>   ./configure --with-pic --prefix=/usr --mandir=/usr/share/man \
> - $(shell dpkg-buildflags --export=configure)
> + $(shell DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow dpkg-buildflags 
> --export=configure)
>  
>   touch configure-stamp

The existing configure.ac file includes:

if test x$enable_linker_hardening != xno; then
OTR_CHECK_LDFLAGS(-z relro -z now, "$all_ldflags_for_check", 
"$all_libs_for_check")
fi

Does this not already accomplish the same thing?
https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_BINDNOW_.28ld_-z_now.29

Thanks,

   - Ian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Ian Jackson  writes:

> The question isn't what you would prefer.  The question is this:

> Are you going to vote to overrule a maintainer who says 

>   I have already implemented non-forking readiness protocol X and I
>   think support for all init systems in my daemon should be done via
>   one protocol.  Please do send me a patch for your init system Y task
>   file (and correponding packaging support) when init system Y has
>   support for protocol X.

> ?

> ISTM that if this situation arises it is due to a failure by the init
> system to be sufficiently accomodating.  I would vote to not overrule
> a maintainer in such a situation.

I would rather not state an opinion on this at the moment, since I think
it's a difficult decision and will depend on the exact situation in Debian
at the time, the importance of the package, the disruption that might be
caused by it not supporting a different init system, and so forth.  It's
also going to matter quite a lot whether the one readiness protocol that
they implemented is one that's supported by the default init system, and
whether it's one supported by the init system used by the non-Linux ports.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733935: libltdl-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Control: found -1 2.4.2-1.6

I still see variation in the following file:

/usr/share/libtool/libltdl/Makefile.in

An example diff between i386 and amd64 is attached.

--
Jakub Wilk
diff -ur libltdl-dev_2.4.2-1.6_i386/usr/share/libtool/libltdl/Makefile.in 
libltdl-dev_2.4.2-1.6_amd64/usr/share/libtool/libltdl/Makefile.in
--- libltdl-dev_2.4.2-1.6_i386/usr/share/libtool/libltdl/Makefile.in
2014-01-02 20:30:24.0 +0100
+++ libltdl-dev_2.4.2-1.6_amd64/usr/share/libtool/libltdl/Makefile.in   
2014-01-02 21:30:57.0 +0100
@@ -87,7 +87,7 @@
 subdir = .
 DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
$(top_srcdir)/configure $(am__configure_deps) \
-   $(srcdir)/config-h.in lt__strl.c argz.c lt__dirent.c \
+   $(srcdir)/config-h.in lt__dirent.c lt__strl.c argz.c \
$(top_srcdir)/config/depcomp $(am__include_HEADERS_DIST) \
$(am__ltdlinclude_HEADERS_DIST) COPYING.LIB README \
config/compile config/config.guess config/config.sub \

Bug#734196: /usr/bin/fc-cache: Segmentation fault caused by font Aharoni Bold (ahronbd.ttf). Works in Wheezy, doesn't work in Jessie.

[Sam Lesher]

Package: fontconfig
Version: 2.11.0-2
Severity: normal
File: /usr/bin/fc-cache

* What led up to the situation?
I have a collection of fonts in my ~/.fonts folder.   One of the fonts is a
Hebrew font called "Aharoni Bold".  The file name is ahronbd.ttf.   This file
existed in my ~/.fonts folder for a Wheezy installation with XFCE.   I then
performed a distribution upgrade to Jessie.   When I logged in for the first
time, XFCE's panels wouldn't load.  They crashed and retried over and over.
Eventually I narrowed it down to a problem with my ~/.fonts folder, and later
to that specific font.


* What exactly did you do (or not do) that was effective (or ineffective)?
I remove and readded fonts to my ~/.fonts folder and ran "fc-cache -fv" until I
identified which font was causing the segmentation fault.


* What was the outcome of this action?
Removing that font resolved the issue.


* What outcome did you expect instead?
I expected the font to be handled properly as it is in Wheezy.

Here is a link that can be used to download the font in question:
http://fontzone.net/font-details/aharoni-bold

This issue is important because this font is also included in a default Windows
7/Windows 8 installation, so there may be many users who have copied their
fonts over from Windows and may encounter this problem.



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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fontconfig depends on:
ii  fontconfig-config  2.11.0-2
ii  libc6  2.17-97
ii  libexpat1  2.1.0-4
ii  libfontconfig1 2.11.0-2
ii  libfreetype6   2.5.1-1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> I consider the TC, when working properly, to be like a court, not an
> executive or legislature.

One of our roles is to rule on the content of policy.  That's much
more like a legislative role.

I think we should see what the other TC members think.

> > No matter how creaky and obsolete the Debian menu system is (or is
> > thought to be in some quarters), that's not the way to go about things.
> > It causes significant technical problems, and it's also very rude.
> 
> I would be more comfortable with this argument if we had a working Policy
> process that could reach these conclusions in a timely fashion.  It's been
> obvious to me that desktop files are a better (and, more importantly, more
> widely supported) representation of this information for over six years
> now, but given that I, as a Policy Editor, don't know how to effectively
> get there from here, I have a hard time blaming the GNOME and KDE
> maintainers for not knowing either.

The TC has been more-or-less functional for some time.  If the policy
process is not fit for purpose, or gets wedged due to lack of
consensus, or whatever, then the TC is the place where that can be
worked around.

The old excuse that our governance processes don't work is, I think,
no longer available in that case.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734184: (no subject)

[Stephen P. Molnar]

Thanks for your note, really a prompt reply.  I'll have to familiarize
myself with the reportbug tool.

Stephen P. Molnar, Ph.D.Life is a fuzzy
set
Foundation for Chemistry   Stochastic and
multivariate
www.FoundationForChemistry.com
(614)312-7528 (c)
Skype:  smolnar1

-Original Message-
From: Andreas Tille [mailto:ti...@debian.org] 
Sent: Saturday, January 04, 2014 11:55 AM
To: Debian Bug Tracking System
Subject: Bug#734184: (no subject)

Package: autodocktools
Version: 1.5.7~rc1~cvs.20130519-1
Severity: grave
Justification: renders package unusable

Hi,

as Stephen P. Molnar reported here

 
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-January/
024278.html

(Stephen, it would be better to fire up the reportbug tool as I did right
now rather than writing an e-mail to the list since reportbug tool creates
some potentially relevant system information - see below.) there is a
problem with autodocktools which I can reproduce on my system.  The status
window says:

Python 2.7.6 (default, Dec  6 2013, 20:05:37) [GCC 4.8.2] on linux2 Type
"copyright", "credits" or "license()" for more information.
 No Subprocess 
>>> Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/AutoDockTools/__init__.py", line
433, in runADT
title=title, withShell= not interactive, verbose=False, gui=gui)
  File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 1029,
in __init__
text='Dashboard', font=('Helvetica', '', 10), padx=3, pady=0)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 2779, in __init__
Widget.__init__(self, master, 'radiobutton', cnf, kw)
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 2039, in __init__
(widgetName, self._w) + extra + self._options(cnf))
TclError: expected integer but got ""


I somehow have the feeling that the problem is caused by incompatible Tcl/Tk
versions.  If nobody in Debian Med team has any clue we might perhaps get
some useful hint from upstream (in CC).

Kind regards

   Andreas.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (5, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages autodocktools depends on:
ii  mgltools-molkit 1.5.7~rc1~cvs.20130519-1
ii  mgltools-pmv1.5.7~rc1~cvs.20130519-1
ii  mgltools-support1.5.7~rc1~cvs.20130519-1
ii  mgltools-viewerframework1.5.7~rc1~cvs.20130519-1
ii  mgltools-volume 1.5.7~rc1~cvs.20130519-1
ii  python  2.7.5-5
ii  python-pil.imagetk [python-imaging-tk]  2.2.1-3

Versions of packages autodocktools recommends:
ii  mgltools-pyautodock   1.5.7~rc1~cvs.20130519-1
ii  mgltools-utpackages   1.5.7~rc1~cvs.20130519-1
ii  mgltools-webservices  1.5.7~rc1~cvs.20130519-1

Versions of packages autodocktools suggests:
ii  autodock   4.2.5.1-3
pn  autodock-vina  
pn  ballview   
pn  mgltools-cadd  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734197: binfmt-support: some issue while installing new version of binfmt-support.conf file.

[shirish शिरीष]

Package: binfmt-support
Version: 2.1.1-1
Severity: normal

Dear Maintainer,
I was upgrading binfmt-support to the one in testing and came across
the following :-

Setting up binfmt-support (2.1.1-1) ...
Installing new version of config file /etc/init/binfmt-support.conf ...
update-binfmts: warning: current package is openjdk-7, but binary
format already installed by openjdk-6
update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults

As far as the update-rc.d warning is concerned, have no idea why it's
there as using systemd.

But the more pressing problem to me seemed to be the second line.

update-binfmts: warning: current package is openjdk-7, but binary
format already installed by openjdk-6

I did have openjdk-6 long time back which is now updated/upgraded to
openjdk-7 and purged the old ones. Please lemme know if any more info.
is needed.

~$ aptitude search openjdk
p   openjdk-6-dbg-
Java runtime based on OpenJDK (debugging symbols)
p   openjdk-6-demo   -
Java runtime based on OpenJDK (demos and examples)
p   openjdk-6-doc-
OpenJDK Development Kit (JDK) documentation
p   openjdk-6-jdk-
OpenJDK Development Kit (JDK)
p   openjdk-6-jre-
OpenJDK Java runtime, using Hotspot JIT
p   openjdk-6-jre-headless   -
OpenJDK Java runtime, using Hotspot JIT (headless)
p   openjdk-6-jre-lib-
OpenJDK Java runtime (architecture independent libraries)
p   openjdk-6-jre-zero   -
Alternative JVM for OpenJDK, using Zero/Shark
p   openjdk-6-source -
OpenJDK Development Kit (JDK) source files
p   openjdk-7-dbg-
Java runtime based on OpenJDK (debugging symbols)
p   openjdk-7-demo   -
Java runtime based on OpenJDK (demos and examples)
p   openjdk-7-doc-
OpenJDK Development Kit (JDK) documentation
i   openjdk-7-jdk-
OpenJDK Development Kit (JDK)
i   openjdk-7-jre-
OpenJDK Java runtime, using Hotspot JIT
i A openjdk-7-jre-headless   -
OpenJDK Java runtime, using Hotspot JIT (headless)
i A openjdk-7-jre-lib-
OpenJDK Java runtime (architecture independent libraries)
p   openjdk-7-jre-zero   -
Alternative JVM for OpenJDK, using Zero/Shark
p   openjdk-7-source -
OpenJDK Development Kit (JDK) source files
p   uwsgi-plugin-jvm-openjdk-6   -
Java plugin for uWSGI (OpenJDK 6)
p   uwsgi-plugin-jvm-openjdk-7   -
Java plugin for uWSGI (OpenJDK 7)
p   uwsgi-plugin-jwsgi-openjdk-6 -
JWSGI plugin for uWSGI (OpenJDK 6)
p   uwsgi-plugin-jwsgi-openjdk-7 -
JWSGI plugin for uWSGI (OpenJDK 7)

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

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages binfmt-support depends on:
ii  init-system-helpers  1.13
ii  libc62.17-97
ii  libpipeline1 1.2.6-1
ii  lsb-base 4.1+Debian12

binfmt-support recommends no packages.

binfmt-support suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Dimitri John Ledkov]

On 4 January 2014 15:46, Josselin Mouette  wrote:
> Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit :
>> Uoti Urpala writes ("Bug#727708: init system discussion status"):
>> > Your earlier wording sounds
>> > like it was talking about the former ("installable") and Ian's proposal
>> > definitely was (explicitly mentioning package fields), but the "fully
>> > working" you use now sounds like it's about the latter.
>>
>> Thanks for pointing this out.  My proposal is too weak in this
>> respect.  I intended to make the stronger statement.
>
>> I think systemd-ui is part of the systemd init system so falls into
>> the exception.  Of course that means that nothing else should depend
>> (functionally or in package dependencies) on it.
>
> There is no way that, for example, some of the GNOME control center
> applets will work at all without systemd.
>
> It is already hard enough to imagine that we would have to ship packages
> without the appropriate dependencies on systemd; expecting them to have
> the same functional coverage without it is simply insane.
>

Can you please explain how a user-level application is dependent on
the system (root) init daemon be systemd-init? Especially since it's
expected to have sysvinit fully functional in Jessie.
Or is this to do with other, inferior to those currently in debian,
ways of e.g. setting up system-wide locales? Or does it depend on
other APIs, which have multiple alternative providers, e.g.
systemd-logind.

With a decision for systemd, are we by transitive means[1] mandating
usage of all other daemons present in the systemd source package and
overruling maintainers of existing functionality with alternative or
compatible APIs[2]?

If we are choosing, non-standartised systemd APIs[3], surely it should
be done as a runtime detection, rather than packaging level
dependency. Because there are multiple providers of the same APIs,
possible at different compatibility levels of systemd versioning and
until upgraded system is rebooted, only some implementations can start
and be already running. Although not supported officially, I do like
that stable can typically be fully functional since the dist-upgrade.
Also it is sad that systemd upstream is actively promoting for
everyone to execute runtime checks of "is systemd-init pid1, and
what's systemd version number", granted Martin Pitt did identify this
problem and fixed majority of opensource projects to check for the
requested/required functionality, instead of arbitrary transitive
checks of pid1. This in part enables to run systemd-logind without
systemd-init as pid 1.

Also which upstream are staying with? systemd upstream git history[4]
has only one branch, which is linear with linear version number
increments, without any stable release branches or other indications
of which patches are stable (or possibly security) bugfixes. Fedora 19
appears to be packaging patches from v204-stable branch which I can't
find anywhere public. Thankfully it's not a single giant patch as it's
done by RedHat for their kernels, but actually git am formatted series
of 116 patches[5].

The diffstat between:
- debian package and git v204 checkout is: 44 files, 246 +, 566 -
- fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
- rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
insertions(+), 1686 deletions(-)

Which is a significant chunk of fixes. Looking at some of them, they
are true gems like "don't truncate and loose multiline syslog
messages" which is not fixed in Debian at the moment. Can we please
not have journald by default in jessie, cause I don't want my syslog
truncated?!

In my opinion it is unwise to ship something into stable, ahead of
upstream doing so for their support customers (RedHat Enterprise
Linux). We've had a charming history of doing so with pulseaudio: with
default in 2007 in Fedora, shipped in stable Ubuntu 8.04 LTS in 2008,
where Lennart promote it as stable to Ubuntu Developers at first, and
later claiming that "Ubuntu didn't exactly do a stellar job. They
didn't do their homework." Redhat enterprice linux has shipped it
version 6 - in 2011 it seems. Pulseaudio did turn out ok, although
years later, after extensive usage by real customers base
(unfortunately Ubuntu customers first, and later RedHat's).

Fedora/RPM based distributions are significantly different, thus it is
inevitable that we'll have to maintain a fork of systemd for best
integration into Debian. This does not seem evident from the current
systemd maintainers, which file bugs to disable/remove/override debian
functionality and components with inferior systemd counterparts.

Now the questions is, what will RHELv7 ship? is it v204, v204-stable
(non-public git), v207-stable (non-public git), v208, v208-stable
(non-public git)? And what level of systemd is targetted to be
integrated into jessie?
At the moment RHEL beta 7 has systemd-207 with 95 long patch series.
This looks to me as in-flux state. How is systemd stable ma

Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

[Felix Geyer]

Hi,

On 04.01.2014 18:19, Guido Günther wrote:
> Hi Felix,
> On Fri, Jan 03, 2014 at 10:58:14PM +0100, Felix Geyer wrote:
>> I've ported and tested the libvirt AppArmor support from the Ubuntu package.
>>
>> The only difference in the profiles is this addition to 
>> usr.lib.libvirt.virt-aa-helper:
>>   /etc/libnl-[0-9]/classid r,
>>
>> It can be enabled by setting this in /etc/libvirt/qemu.conf:
>> security_driver = "apparmor"
> 
> Can you please work on upsreaming this? I don't see why this should be
> in the Debian package. Who is going to maintain this policies in the
> future?
> Cheers,
>  -- Guido

The upstream source already contains example profiles. It's generally not 
feasible to
maintain AppArmor profiles upstream because of distro differences and changes.

The profiles usr.sbin.libvirtd and usr.lib.libvirt.virt-aa-helper could be 
easily
maintained in a separate apparmor profile package. intrigeri proposed a
apparmor-profiles-extra package [1] that would be maintained by an AppArmor 
Debian team.
I am committed to maintain the libvirt profiles.

Having libvirt-qemu outside of libvirt is problematic because the AppArmor 
driver of
libvirt uses it to generate profiles for the VMs. When it's missing starting 
VMs will
fail (when the AppArmor driver is enabled).

Cheers,
Felix

[1] https://lists.ubuntu.com/archives/apparmor/2014-January/004876.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Steve Langasek]

On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
> > And the other is that IMO the proposed prescription for non-Linux ports
> > doesn't make sense for systemd.  There is little prospect of systemd
> > being "ported" to those systems.

> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
> software and if someone wants to try to port it (or, possibly more likely,
> "port" it by writing something native that provides the same interfaces),
> they can.  Maybe upstream is right and it's untenable; maybe they're wrong
> and it's not as hard as they think.  I realize it's horribly unlikely for
> jessie, but still, as a matter of principle, I'd rather encourage the same
> software or at least the same interfaces across all of our ports.

If it's "horribly unlikely for jessie", then it doesn't seem to me like
something that the TC should be telling porters they "should" do.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#734198: DDPO: Wrong link and wrong column for PU

[Bertrand Marc]

Package: qa.debian.org
Severity: normal

Dear Maintainer,

After an upload to stable proposed updates, a new link showed up on DDPO.

But this link showed up in the unstable column instead of the stable one. And 
it links to the new queue [1] instead of the pu queue [2].

Regards,
Bertrand

[1] http://ftp-master.debian.org/new.html
[2] https://release.debian.org/proposed-updates/stable.html

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

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:

>> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
>> software and if someone wants to try to port it (or, possibly more
>> likely, "port" it by writing something native that provides the same
>> interfaces), they can.  Maybe upstream is right and it's untenable;
>> maybe they're wrong and it's not as hard as they think.  I realize it's
>> horribly unlikely for jessie, but still, as a matter of principle, I'd
>> rather encourage the same software or at least the same interfaces
>> across all of our ports.

> If it's "horribly unlikely for jessie", then it doesn't seem to me like
> something that the TC should be telling porters they "should" do.

I thought that was already resolved?  I objected to the "should" in the
original language regarldess of which init system we choose, and Ian said
that he'd reworded it already to something akin to mine, which just says
that ports will use the same default init system if it has been ported,
otherwise yadda yadda.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734199: release.debian.org: wims-moodle removed, but no dependency on yui

[Georges Khaznadar]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney

Hello, maybe a bug from Britney : the package wims-moodle contains no
javascript and never used yui. It does not depend on it in any manner.

This may require some manual handling. I ignore which test in britney triggered
the automated removal.

Best regards,   Georges.

> FYI: The status of the wims-moodle source package
> in Debian's testing distribution has changed.
>
>   Previous version: 4.0-9
>   Current version:  (not in testing)
>   Hint: 
> # 692619,730104 in yui



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (650, 'stable'), (600, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734200: release.debian.org: grr removal from testing; did not depend on yui

[Georges Khaznadar]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney

Hello, the package grr has been removed from testing, but the hint given by
britney
is not valid: grr does not depend on yui in any way.

This may require a manual inspection.

Best regards,   Georges.

> FYI: The status of the grr source package
> in Debian's testing distribution has changed.
>
 >  Previous version: 1.9.7e~dfsg1-2
>   Current version:  (not in testing)
>   Hint: 
> # 692619,730104 in yui



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (650, 'stable'), (600, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734199: release.debian.org: wims-moodle removed, but no dependency on yui

[Adam D. Barratt]

On Sat, 2014-01-04 at 20:10 +0100, Georges Khaznadar wrote:
> Hello, maybe a bug from Britney

Nope. It's arguably a bug in the script which turns information from
UDD's auto-removals script in to removal hints, as the comments could
possibly be clearer.

> : the package wims-moodle contains no
> javascript and never used yui. It does not depend on it in any manner.

Actually, yes, it does. wims-moodle depends on moodle; moodle in turn
depends on libjs-yui3-min.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Steve Langasek]

On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> > ...  (Note that the latter would work better if upstart stopped
> > conflicting with sysvinit, similar to how systemd can be installed
> > without being init.)

> There does seem to need to be some work there.

That has already been resolved in unstable, with the split of sysvinit
contents out of the Essential: yes sysvinit into sysvinit-core.  (A
necessary precondition for switching to either systemd-sysv or upstart for
jessie.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#734200: release.debian.org: grr removal from testing; did not depend on yui

[Adam D. Barratt]

Control: merge 734199 -1

On Sat, 2014-01-04 at 20:15 +0100, Georges Khaznadar wrote:
> Hello, the package grr has been removed from testing, but the hint given by
> britney is not valid

britney doesn't "give hints". Also, the hint is perfectly valid.

> : grr does not depend on yui in any way.

Yes, it does. grr depends on ckeditor, which depends on yui.

> This may require a manual inspection.

As with your other report, the most it requires is the comments
clarifying.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734201: ITP: libbackpan-index-perl -- Perl interface to the BackPAN index

[Stefan Hornburg (Racke)]

Package: wnpp
Owner: Stefan Hornburg (Racke) 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libbackpan-index-perl
  Version : 0.42
  Upstream Author : Michael G Schwern
* URL : https://metacpan.org/release/BackPAN::Index
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl interface to the BackPAN index

BackPAN::Index downloads, caches and parses the BackPAN index into a local 
database for efficient querying.

This is needed for libgit-cpan-patch-perl (ITP #733922).

Regards
  Racke

-- 
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Tollef Fog Heen]

]] Russ Allbery 

> 2. Package logind separately from systemd, get it working with sysvinit.
>The problems with doing this, as I understand it, is that we'd not be
>able to upgrade such a separately-packaged logind beyond 204 for
>jessie.  I'm not sure how much impact that would have.  Also, it
>sounded to me like we would need to figure out who was going to do that
>work and maintain that package, including in the stable release.  If
>the current systemd maintainers are not interested in doing this, we
>absolutely shouldn't try to force them to do so.  Someone else would
>need to step forward to do this and figure out the right package
>relationships.  (Also, it would be good to maintain this separately so
>that the systemd maintainers could move forward with newer versions of
>systemd, including the logind built from its source.)

[...]

> The systemd maintainers should definitely feel free to tell me if I'm
> misunderstanding their feelings on option 2.

You are not.

I'd like to expand slightly that I'd be ok with having it part of the
systemd package as long as somebody shows up and commits to maintaining
that functionality long-term and with the explicit understanding of the
TC that if the necessary manpower to do that work disappears we will not
be holding to rest of the init system back.  It might be that packaging
up logind completely separately by such a person (or team) might be a
better approach (as you suggest).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> I thought that was already resolved?  I objected to the "should" in the
> original language regarldess of which init system we choose, and Ian said
> that he'd reworded it already to something akin to mine, which just says
> that ports will use the same default init system if it has been ported,
> otherwise yadda yadda.

I nicked your wording.  Mutatis mutandi, it would say:

 2. The default init(1) in jessie for non-Linux ports will be systemd
if it has been ported and confirmed by the porters to be working by
the time of the jessie release.  Failing this, the default init(1)
in jessie for non-Linux ports is left to the discretion of the
maintainers of that port.

[ However, the Technical Committee requests that, should systemd be
unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
porters agree on a single alternative init(1) implementation that
will be shared by both ports. ]

[ Non-use of systemd should not be a criterion for architecture
qualification status in jessie. ]

I think this is a daft thing to say.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734176: gkrellm: Filter Net interfaces

[Sandro Tosi]

Hello GKrellM developers,
I've just received this request from a Debian user and I'm forwarding it to you.

Regards,
Sandro

On Sat, Jan 4, 2014 at 5:07 PM, Christophe Troestler
 wrote:
> Package: gkrellm
> Version: 2.3.5-5
> Severity: wishlist
>
> Hi,
>
> When using docker  many ethernet interfaces are
> created.  It would be desirable to be able to filter those out (they
> all start with "veth") or possibly show them but not remember them in
> the configuration list (have a config per regexp).
>
> Thanks,
> C.
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.10.25 (SMP w/8 CPU cores)
> 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 /bin/dash
>
> Versions of packages gkrellm depends on:
> ii  libatk1.0-0  2.10.0-2
> ii  libc62.17-97
> ii  libcairo21.12.16-2
> ii  libfontconfig1   2.11.0-2
> ii  libfreetype6 2.5.1-1
> ii  libgcrypt11  1.5.3-3
> ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
> ii  libglib2.0-0 2.36.4-1
> ii  libgnutls-openssl27  2.12.23-8
> ii  libgnutls26  2.12.23-8
> ii  libgtk2.0-0  2.24.22-1
> ii  libice6  2:1.0.8-2
> ii  libntlm0 1.4-1
> ii  libpango-1.0-0   1.36.0-1+b1
> ii  libpangocairo-1.0-0  1.36.0-1+b1
> ii  libpangoft2-1.0-01.36.0-1+b1
> ii  libsm6   2:1.2.1-2
> ii  libx11-6 2:1.6.2-1
>
> gkrellm recommends no packages.
>
> gkrellm suggests no packages.
>
> -- no debconf information



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734202: transifex-client: new upstream version is available

[Sebastian Ramacher]

Package: transifex-client
Version: 0.9.1-1
Severity: wishlist

Hi,

while using the currently packaged version, transifex sent me a mail
informing me that there is new upstream version available. Please
consider packaging it. Thank you

Regards
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#734199: release.debian.org: wims-moodle removed, but no dependency on yui

[Adam D. Barratt]

On Sat, 2014-01-04 at 20:10 +0100, Georges Khaznadar wrote:
[stuff]

For the record, replying to this earnt me:


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  georg...@free.fr
SMTP error from remote mail server after RCPT TO::
host mx1.free.fr [212.27.48.6]: 550 5.2.1 This mailbox has been blocked due 
to inactivity


Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Steve Langasek]

On Sat, Jan 04, 2014 at 11:08:36AM -0800, Russ Allbery wrote:
> Steve Langasek  writes:
> > On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:

> >> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
> >> software and if someone wants to try to port it (or, possibly more
> >> likely, "port" it by writing something native that provides the same
> >> interfaces), they can.  Maybe upstream is right and it's untenable;
> >> maybe they're wrong and it's not as hard as they think.  I realize it's
> >> horribly unlikely for jessie, but still, as a matter of principle, I'd
> >> rather encourage the same software or at least the same interfaces
> >> across all of our ports.

> > If it's "horribly unlikely for jessie", then it doesn't seem to me like
> > something that the TC should be telling porters they "should" do.

> I thought that was already resolved?  I objected to the "should" in the
> original language regarldess of which init system we choose, and Ian said
> that he'd reworded it already to something akin to mine, which just says
> that ports will use the same default init system if it has been ported,
> otherwise yadda yadda.

Ah - sorry, I apparently missed that. 

On Sat, Jan 04, 2014 at 07:28:56PM +, Ian Jackson wrote:
> I nicked your wording.  Mutatis mutandi, it would say:

>  2. The default init(1) in jessie for non-Linux ports will be systemd
> if it has been ported and confirmed by the porters to be working by
> the time of the jessie release.  Failing this, the default init(1)
> in jessie for non-Linux ports is left to the discretion of the
> maintainers of that port.

> [ However, the Technical Committee requests that, should systemd be
> unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
> porters agree on a single alternative init(1) implementation that
> will be shared by both ports. ]

> [ Non-use of systemd should not be a criterion for architecture
> qualification status in jessie. ]

> I think this is a daft thing to say.

I don't have a problem with this version of the wording, with the "should"
removed.  While I think a systemd port is highly unlikely, I don't think it
hurts anything for the TC to express a preference for all ports to be on the
same page.

The probability of this *happening* for a particular option will influence
my vote, but I think it's a sound technical recommendation regardless.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#727708: init system discussion status

[Tollef Fog Heen]

]] Dimitri John Ledkov 

> Also which upstream are staying with? systemd upstream git history[4]
> has only one branch, which is linear with linear version number
> increments, without any stable release branches or other indications
> of which patches are stable (or possibly security) bugfixes.

That's generally communicated in the release announcements as well as on
the systemd-devel mailing list.

> Fedora 19 appears to be packaging patches from v204-stable branch
> which I can't find anywhere public. Thankfully it's not a single giant
> patch as it's done by RedHat for their kernels, but actually git am
> formatted series of 116 patches[5].

Were you unable to find
http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ?  It's where
Fedora has all of their packaging..

> Fedora/RPM based distributions are significantly different, thus it is
> inevitable that we'll have to maintain a fork of systemd for best
> integration into Debian. This does not seem evident from the current
> systemd maintainers, which file bugs to disable/remove/override debian
> functionality and components with inferior systemd counterparts.

Can you provide bug numbers for those allegations, please?

> [4] it appears that upstream git is used as packaging basis, instead
> of the tarball which has pre-generated documentation and loads of
> other files.

If you here are talking about the systemd packaging, it seems you've
misunderstood something.  What are you missing in the source package?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Josh Triplett]

On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
> (Josh, is there some reason why you replied to the TC list directly
> rather than the bug report ?  You should send your messages to the bug
> so they are filed, displayed and archived there.  Thanks.)

I don't subscribe to debian-ctte@; I read it via the list archives.
I've been replying using the "Reply to:" links at the bottom of mails,
and then manually copying and quoting the responses.  Those links reply
to debian-c...@lists.debian.org, so unless I manually edit the
destination (which I've done in a few cases where the destination was a
bug report), it ends up going to the list.

It'd be nice if those links paid attention to the
To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like
hitting the reply key in a mail client.  I'd also add my voice to the
set of people who have requested mbox archives in the past.

> Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
> > Clint Adams wrote:
> > > As loath as I am to participate in this discussion, I have to ask
> > > if your intent is to suddenly outlaw all the packages which depend
> > > on runit.
> 
> Thanks for your intervention which is helpful.
> 
> > I think it'd be appropriate to allow dependencies on runit (or another
> > package that contains an implementation of /sbin/init), as long as
> > either the depending package doesn't depend on having /sbin/init be that
> > init (which holds true for runit),
> 
> Right.
> 
> > *or* if an alternative package exists to integrate with the default
> > init system.  For instance, git-daemon-run versus
> > git-daemon-sysvinit versus a hypothetical git-daemon-systemd,
> 
> Personally I think this is a pretty nasty way for the git packages to
> have done things, although I understand why.  But, regardless, I think
> it's certainly fine from the init system compatibility point of view.

I'm not a big fan of its long insistence on runit (git-daemon-sysvinit
came much later), but I actually rather like the idea of putting init
scripts and systemdiwde configuration in a separate package from
daemons.  In the case of git, it makes sense because the daemon lives in
the "git" package, which shouldn't start a daemon.  More generally,
though, I wish more packages were split the way Apache is, with one
package containing the daemon and all supporting files, and the other
package containing the configuration for a systemwide daemon.  I've
found that particularly useful on many occasions.

> > ...  (Note that the latter would work better if upstart stopped
> > conflicting with sysvinit, similar to how systemd can be installed
> > without being init.)
> 
> There does seem to need to be some work there.

As I understand it, conflicting with sysvinit and not offering a package
that can be installed in parallel with it was an intentional decision on
the upstart maintainers' parts.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734198: DDPO: Wrong link and wrong column for PU

[Adam D. Barratt]

On Sat, 2014-01-04 at 20:05 +0100, Bertrand Marc wrote:
> After an upload to stable proposed updates, a new link showed up on DDPO.
> 
> But this link showed up in the unstable column instead of the stable one. And 
> it links to the new queue [1] instead of the pu queue [2].

I suspect this is a side-effect of the fact that uploads don't go
directly to proposed-updates. After the initial acceptance, dak installs
the package to a "policy queue" called "stable-new". In order for the
package to move from there to proposed-updates, a member of the release
team has to create a "comment" file relating to the upload, and then
rename it to match the convention required for dak to move the package
in to p-u.

As that latter step has not yet happened for libmicrohttpd (taking an
educated guess at the package involved), the package is still in
"stable-new", which may be confusing things.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org