Bug#781007: network-manager has an 128 max connections limit
Package: network-manager Version: 0.9.10.0-6 Severity: important OK, this may sound weird but... I have noticed some odd behavior, with Network Manager not showing one of my GSM providers on the tray icon at random. Then today, I wanted to edit one of my connections to change the DNS server list and hit Edit connections (which spawns nm-connection-editor) and could not find it. Repeated invocations of nm-connection-editor showed different connections being listed -- I even got the connection I wanted at some point. I initially thought it was an NM GUI bug, so I tried both nmtui and nmcli and the same thing happened: every time I called them I could see a list of connections but somewhat different every time. Then... I thought of counting them: it seems that nmcli c |wc -l consistently reports back 129 (header line + 128 connections). Saving + diffing the output, though, seems to indicate that I get a different list of 128 saved connections every time I call it (I have lots of them as this includes a lot of random hotspots I've picked up while travelling). This is quite an annoying limitation and manifests quite badly in a hard to debug way. I could see this being triaged as serious as well -- the only reason I didn't is that probably not a lot of people have 128 connections saved. I'd prefer if I didn't list my connections here for privacy reasons, but do let me know if there's anything you want to run on the system itself for debugging purposes. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765577: (no subject)
severity 765577 serious
thanks
On Wed, Feb 25, 2015 at 03:24:08PM +, Filippo Giunchedi wrote:
FWIW we're running into the same bug with jessie installer, passing
'debug' at boot apparently is enough to not trigger the race with good
success rate.
Filippo and I both work for the Wikimedia Foundation, where this is
affecting us on dozens of systems.
I tried to debug this extensively and had a chat with Marco d'Itri on
IRC. It's both mine Marco's opinion that this is an RC bug, thus
elevating this to serious. Unfortunately, Marco told me that he won't
able to tackle this and suggested to reply to this bug report so that
the other udev maintainers can help out.
The result of my own investigation is (not speaking for Marco):
It's clear that there's some race condition happening here both because
there are reports of it happening sporadically (not in my case, though)
and because setting d-i to debug mode fixes it.
Therefore, the operating theory is that multiple events for the same
add event are triggered. This race is supposed to be handled, as:
a) write_net_rules takes a lock before writing anything -- it's also
evident this happens, as the duplicate entries have ethNs that are
numerically ascending and not the same for the same card.
b) 75-persistent-net-generator.rules is supposed to be idempotent, as it
bails out early (3rd line) for interfaces that already have a NAME set.
For the ones that don't, it also sets NAME right after the
write_net_rules invocation.
However this still leaves room for a race: write_net_rules is *not*
idempotent and hence if 75-persistent-net-generator.rules gets called
twice in very quick succession, before write_net_rules gets a chance to
finish and name the interface, then an interface will be named twice,
with a different name (and hence, eth0 will be renamed to e.g. eth2).
It's still unknown to me why this is a regression.
I've tried the following, under /lib/debian-installer/start-udev:
1) Adding a udevadm settle || true right after the udevadm trigger.
2) Adding a sleep 15 before udevadm trigger
3) Adding a sleep 15 (or 3) *after* udevadm trigger.
Surprisingly, of these three, only (3) worked around the bug.
Another less arbitrary/racy workaround I suggesed was a grep near the
top of write_net_rules' write_rule() function. Since write_rule()
operates under a lock, this would completely eliminate any kind of race
here. I pitched this to Marco but he wasn't thrilled with the idea -- he
said he'd prefer finding the root cause. I've done the change and tested
it anyway, though, and it successfully aleviates this issue:
diff --git a/debian/extra/write_net_rules b/debian/extra/write_net_rules
index 4379792..fbd1230 100644
--- a/debian/extra/write_net_rules
+++ b/debian/extra/write_net_rules
@@ -60,6 +60,9 @@ write_rule() {
local name=$2
local comment=$3
+ # workaround potential races, #765577
+ if grep -q -F $match $RULES_FILE then return; fi
+
{
if [ $PRINT_HEADER ]; then
PRINT_HEADER=
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765577: (no subject)
On Wed, Mar 18, 2015 at 06:52:14PM +0100, Michael Biebl wrote:
I'm with Marco here. Before adding any workarounds, we need to
understand what the underlying problem is. Otherwise we are adding cruft
which nobody understands anymore a few years from now.
Since I can't reproduce the issue and already have trouble keeping up
with other bug reports, further investigation needs to be done by
someone else.
Well, the root cause IMO is that 75-persistent-net-generator.rules is
inherently susceptible to races. It's my understanding that it's valid
for events to be triggered multiple times -- there are multiple places
in d-i that udevadm trigger is called, including start-udev (as
shipped by udev-udeb) which would trigger another set of add events
beyond the original hotplug one.
This is why write_net_rules operates under a lockfile too (again, AIUI).
It's just that this doesn't fix the race, just limits the race window
significantly but not entirely (as it makes write_net_rules idempotent,
but not 75-persistent-net-generator.rules).
The reason this is found in current jessie might just be that udev got
faster, or more udevadm triggers were added in other parts of the
installer etc.
In any case, if you need more input from a buggy system, feel free to
let me know and I'll try my best to get back to you with more details.
Oh, my original patch was buggy for many reasons, here's the updated
version:
diff --git a/debian/extra/write_net_rules b/debian/extra/write_net_rules
index 4379792..95939b8 100644
--- a/debian/extra/write_net_rules
+++ b/debian/extra/write_net_rules
@@ -117,6 +117,12 @@ fi
basename=${INTERFACE%%[0-9]*}
match=$match, KERNEL==\$basename*\
+# detect a race and abort, cf. #765577
+if [ -f $RULES_FILE ] grep -q -F $match $RULES_FILE; then
+ unlock_rules_file
+ exit 0
+fi
+
if [ $INTERFACE_NAME ]; then
# external tools may request a custom name
COMMENT=$COMMENT (custom name provided by external tool)
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#775795: puppet: Service's debian provider assumes SysV init
Package: puppet Version: 3.7.2-1 Severity: serious Hi, Puppet has an abstraction concept called provider for its types. The Service type, one of puppet's basic types, is implemented by multiple different providers, depending on the underlying init system. There is the init provider, which implements SysV init semantics, systemd upstart which implement systemd and upstart semantics respectively, etc. The default provider on each system is assigned using facter rules, apparently relying on operatingsystem and osfamily facts. On Debian systems (i.e. on $::operatingsystem == debian), the default provider is debian; this is a separate provider that inherits the init provider but overrides a few methods to add invoke-rc.d support. The systemd provider, on the other hand, is default only for osfamily archlinux and for osfamily redhat operatingsystemmajrelease 7. This is obviously broken behavior -- puppet shouldn't make assumptions about the init system a system runs purely from its OS version. That is mostly tracked upstream with PUP-2023[1]. This is especially broken for jessie default installs, which are systemd now. Service definitions -probably amongst the most used ones- are assuming init.d semantics, unless provider = systemd is supplied as an argument. The only reason puppet is not completely broken on jessie is that most packages still ship an init.d script alongside a system service file and LSB init-functions make sure those init.d scripts call systemctl instead. However, this means that Service (without an explicit provider) is broken for at least those two use cases: - enable = false/true doesn't work for packages that ship a systemd unit file, - Service doesn't work at all with user-supplied systemd units or for (custom, mostly) packages that do not ship init.d scripts. This is borderline important serious in my mind, but it is a regression for Wheezy and it should probably be fixed in time for jessie, so I'm setting this to an RC severity. This could be potentially worked around by setting systemd as the default provider for kernel == Linux operatingsystem == Debian operatingsystemmajrelease = 8. This would be a hack, of course, as jessie optionally supports booting with SysV as well so a more dynamic/runtime check will be a better but more complicated fix. Regards, Faidon 1: https://tickets.puppetlabs.com/browse/PUP-2023 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775638: gdnsd: FTBFS in jessie: dh_auto_test: make -j1 test returned exit code 2
reassign 775638 geoip-database 20141027-1 retitle 775638 IPv6 database is corrupt severity 775638 grave thanks Hi, thanks On Sun, Jan 18, 2015 at 01:44:44AM +0100, Lucas Nussbaum wrote: During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): snip Checking basic database load on file /usr/share/GeoIP/GeoIP.dat ... OK Checking basic database load on file /usr/share/GeoIP/GeoIPv6.dat ... Load-only test on file '/usr/share/GeoIP/GeoIPv6.dat' failed w/ exit status 134; Test Output: info: Loading configuration from '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/config' info: plugin_geoip: map 'my_prod_map': Processing GeoIP database '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' error: plugin_geoip: map 'my_prod_map': Error traversing GeoIP database, corrupt? error: plugin_geoip: map 'my_prod_map': (Re-)loading geoip database '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' failed! fatal: plugin_geoip: map 'my_prod_map': cannot continue initial load This is a test suite failure, reporting that geoip-database's GeoIPv6.dat is corrupt. It looks like something's fishy there, after checking with MaxMind's own geoiplookup6 tools: $ dpkg-query -W geoip-database geoip-database 20141009-1 $ geoiplookup6 www.maxmind.com GeoIP Country V6 Edition: HK, Hong Kong $ geoiplookup6 2001::1 GeoIP Country V6 Edition: IP Address not found $ dpkg-query -W geoip-database geoip-database 20141027-1 $ geoiplookup6 www.maxmind.com $ geoiplookup6 2001::1 $ I've verified that gdnsd builds fine with geoip-database 20141009-1, which corresponds with the above output. it seems that geoip-database 20141027-1 ships a corrupt, IPv6 database. Reassigning bumping severity. Best 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#775189: mate-session spawns gnome-keyring unconditionally
Package: mate-session-manager Version: 1.8.1-5 Severity: serious Hi, Since upstream commit[1] 8a20baf39f781184d6126e0947e9fd4d9a115fab, mate-session-manager spawns gnome-keyring-daemon, with no option to turn it off, or pass arguments to it (such as --components). While this is bad in itself, it gets worse: keyring is spawned *after* the regular user-configured autostart programs are run. gnome-keyring's default set of components includes a GPG a SSH agent and rightfully exports SSH_AUTH_SOCK and GPG_AGENT_INFO. Therefore, even if the user has configured their desktop to spawn the (more featureful and arguably more secure OpenSSH) ssh-agent or gpg-agent, it is impossible to use it, as gnome-keyring-daemon clobbers the these two environmental variables. In other words, mate-session indirectly unconditionally clobbers environmental variables that in no way belong to it and actively preventing programs that own the namespace from using them. This is a severity: serious issue, IMO. Note that e.g. gdm3's default PAM configuration uses pam_gnome_keyring which calls gnome-keyring-daemon with the --daemonize --login options. This starts the daemon but does not initialize it; mate-sessions's execution with --start is what initializes it and exports these variables into the session's environment. Finally, note that MATE's default session autostart includes multiple GNOME Keyring entries, a different one for each keyring component, that can be individually be turned off and on. This is what GNOME used to do (maybe still does?) as well. I've yet to understand why mate-session also spawns it from its code as well. Regards, Faidon 1: https://github.com/mate-desktop/mate-session-manager/commit/8a20baf39f781184d6126e0947e9fd4d9a115fab -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735521: Bug#764841: please use pam_exec to display dynamic motd
On Sun, Oct 12, 2014 at 02:39:31PM -0700, Steve Langasek wrote: I don't think it's too late for jessie. It should be discussed on debian-devel, so that we can all get on the same page, and it needs agreement from the relevant maintainer about who should ship /etc/update-motd.d/00-header (whether it's base-files, or something else). I took the liberty of summarizing the situation and spawning a debian-devel thread per your advice, 20141231142036.ga16...@tty.gr / https://lists.debian.org/debian-devel/2014/12/msg00368.html. Happy new year to all :) Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772641: apt: E: Setting TIOCSCTTY for slave fd fd failed when run as a session leader
Dear apt maintainers, On Thu, Dec 11, 2014 at 01:35:27AM +0100, David Kalnischkies wrote: Attached is a patch which hopefully does exactly this. It is against experimental, but that shouldn't matter (expect for the testcase I think). I have run it on Linux amd64 (and armel) hardware as well as on a kfreebsd kvm, so I have some hope that it isn't regessing, but it would be nice if you could try it with puppet just to be sure that we are really fixing the problem completely or if I have justed resolved the problem in the setsid testcase. Since David's patch works and this is an severity: serious/RC bug that affects multiple people, how would you like to proceed? I see that while David is not listed as an Uploader, he has a track record of contributing to apt and has even signed off the latest upload. I'd be happy to either sponsor an upload by David or NMU with his patch. David, what do you think? Let me know. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773026: screen does not lock on suspend (jessie regression)
Package: gnome-screensaver Version: 3.6.1-2 Severity: grave Tags: security patch Dear maintainer, After upgrading my desktop from wheezy to jessie (w/ GNOME Flashback mode), I was surprised to find that closing the lid of my laptop suspended the system, but upon resume the screen was not locked and no password prompt was needed to actually resume working on my screen. Suffice to say, I think that's a security issue and thus, release critical. I investigated this quite a bit; it looks like with jessie's version, GNOME doesn't use ConsoleKit anymore, but the alternative codepath for this, namely handling systemd-login events, has been turned off by passing --without-systemd to configure, over two years ago, with no justification in the changelog. Even with systemd support, though, it seems that in the (very old) upstream version only Lock events are being processed, not suspend (PrepareForSleep) ones (like gnome-shell does). gnome-screensaver is abandoned upstream, so I assume the API plans changed along the way over the past two and a half years. Fortunately, Ubuntu has prepared a patch for this and a) is trivial enough, b) has been released with several Ubuntu versions and hence is tested in the wild. While at it, I also ported another couple of Ubuntu patches that while not strictly needed, help considerably in this use case (namely, a) adding support for non-systemd Linux systems and b) not leaking screen contents on resume). Attached you will find a patch for the package to address this. The total debdiff is: configure.ac |2 +- src/gs-listener-dbus.c | 33 +++-- src/gs-listener-dbus.h |1 + src/gs-manager.c |2 +- src/gs-monitor.c | 16 5 files changed, 50 insertions(+), 4 deletions(-) ...and is easily readable and understood, as well as widely tested. I would definitely recommend including this in jessie. Best, Faidon diff -Nurp gnome-screensaver-3.6.1/debian/changelog gnome-screensaver-3.6.1-suspendlock/debian/changelog --- gnome-screensaver-3.6.1/debian/changelog 2014-09-11 23:26:14.0 +0300 +++ gnome-screensaver-3.6.1-suspendlock/debian/changelog 2014-12-13 13:03:22.112670213 +0200 @@ -1,3 +1,20 @@ +gnome-screensaver (3.6.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Reenable support for locking the screen on suspend. +- Build with systemd support by passing --with-systemd=auto to configure + and build-depending on libsystemd-login-dev. Use auto and a + [linux-any] dependency to keep compatibility with non-Linux systems. +- 00git_logind_check.patch from Ubuntu/upstream, to make this dependent on + just logind, not systemd-as-pid1, as recommended by systemd upstream + Debian systemd maintainers. Drops libsystemd-daemon-dev build-dep. +- 31_lock_screen_on_suspend.patch from Ubuntu, to listen for logind's + PrepareForSleep signal, similarly to gnome-shell's behavior. +- 14_no_fade_on_user_switch.patch from Ubuntu, as to not fade on screen + lock. Prevents leaking of the screen contents on resume from suspend. + + -- Faidon Liambotis parav...@debian.org Sat, 13 Dec 2014 11:32:25 +0200 + gnome-screensaver (3.6.1-2) unstable; urgency=medium * Team upload diff -Nurp gnome-screensaver-3.6.1/debian/control gnome-screensaver-3.6.1-suspendlock/debian/control --- gnome-screensaver-3.6.1/debian/control 2014-12-13 12:36:01.941262458 +0200 +++ gnome-screensaver-3.6.1-suspendlock/debian/control 2014-12-13 13:02:25.484828745 +0200 @@ -19,8 +19,7 @@ Build-Depends: cdbs, libgtk-3-dev (= 3.0.0), libgnome-desktop-3-dev (= 3.1.91), libgnomekbd-dev (= 2.91.91), -# libsystemd-login-dev [linux-any], -# libsystemd-daemon-dev [linux-any], + libsystemd-login-dev [linux-any], libxklavier-dev, libx11-dev, libxt-dev, diff -Nurp gnome-screensaver-3.6.1/debian/control.in gnome-screensaver-3.6.1-suspendlock/debian/control.in --- gnome-screensaver-3.6.1/debian/control.in 2014-09-11 23:21:50.0 +0300 +++ gnome-screensaver-3.6.1-suspendlock/debian/control.in 2014-12-13 13:02:17.124852278 +0200 @@ -15,8 +15,7 @@ Build-Depends: cdbs, libgtk-3-dev (= 3.0.0), libgnome-desktop-3-dev (= 3.1.91), libgnomekbd-dev (= 2.91.91), -# libsystemd-login-dev [linux-any], -# libsystemd-daemon-dev [linux-any], + libsystemd-login-dev [linux-any], libxklavier-dev, libx11-dev, libxt-dev, diff -Nurp gnome-screensaver-3.6.1/debian/patches/00git_logind_check.patch gnome-screensaver-3.6.1-suspendlock/debian/patches/00git_logind_check.patch --- gnome-screensaver-3.6.1/debian/patches/00git_logind_check.patch 1970-01-01 02:00:00.0 +0200 +++ gnome-screensaver-3.6.1-suspendlock/debian/patches
Bug#772523: preseeding get_domain using DHCP is broken
Package: netcfg Version: 1.125 Severity: important Hi, I'm trying to preseed d-i to run a fully automated installation, using jessie beta2. I'm trying to use a DHCP config, with the hostname being set from reverse DNS and the domain set by the DHCP server using the domain-name DHCP option (isc-dhcp's option domain-name). What currently happens is that I'm getting a priority=high input prompt for the domain name, prefilled with the DHCP domain name. FWIW, I've verified that the udhcpc lease file contains the domain name and that a manual invocation of udhcpc results in /tmp/domain_name being prefilled with my domain. The log output is: netcfg[342]: DEBUG: State is now 1 netcfg[342]: DEBUG: State is now 2 netcfg[342]: DEBUG: State is now 5 debconf: -- GET netcfg/hostname netcfg[342]: DEBUG: Using DNS to try and obtain default hostname netcfg[342]: DEBUG: Getting default hostname from rDNS lookup of autoconfigured address 10.64.16.201 netcfg[342]: DEBUG: Hostname found: d-i-test.eqiad.wmnet netcfg[342]: DEBUG: d-i-test.eqiad.wmnet is a valid FQDN netcfg[342]: DEBUG: We have a real FQDN debconf: -- SET netcfg/get_hostname d-i-eqiad netcfg[342]: DEBUG: Preseeding domain from global: eqiad.wmnet debconf: -- SET netcfg/get_domain eqiad.wmnet debconf: -- INPUT high netcfg/get_hostname debconf: -- GET netcfg/get_hostname netcfg[342]: DEBUG: State is now 5 debconf: -- INPUT high netcfg/get_domain What I think happens is: 0) netcfg_activate_dhcp gets called; state is AUTOCONFIG. netcfg_autoconfig() gets called, and in turn netcfg_dhcp(). udhcpc is started, gets a lease and writes the domain to DOMAINFILE. netcfg_dhcp() reads the domain name from /tmp/domain_name, sets domain to eqiad.wmnet and have_domain to 0. 1) Multiple states transition. DHCP State is now HOSTNAME (5). preseed_hostname_from_fqdn() is getting called, with globals have_domain=1, domain=eqiad.wmnet. This sets netcfg/get_domain to eqiad.wmnet and netcfg/get_hostname to the non-FQDN part of the hostname (d-i-test). 2) netcfg_get_hostname() gets called, with accept_domain=1, which sets the global have_domain=0 at the top, but never sets it back to 1, as it only does so if netcfg/get_hostname is an FQDN, which it isn't anymore. 3) DHCP State is now DOMAIN (6). netcfg_get_domain() gets called with have_domain=0 and prompts. Looking at the code, it looks like *removing* the domain name from my DHCP config entirely would work, as d-i would then fallback to splitting the FQDN into a domain part as well. The whole behavior seems like very buggy to me; specifically, (2) seems flawed, as it unconditionally sets have_domain to 0 and only sets it back under certain specific conditions (= FQDN), entirely ignoring all the work that preseed_hostname_from_fqdn() does. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771922: keyboard handling broken with jessie's gnome-settings-daemon
Package: gnome-flashback Version: 3.8.1-7 Severity: grave Hi, First of all, there's a number of severity: normal/important bugs reported against the gnome-ssession-fallback package that mention keyboard shortcuts issues (#727047, #730831, #731245, #731418, #727046, #730096). My investigation shows that are partly related to each other but in aggregate indicative of a more serious issue, hence this new severity: grave super-bug. Apologies for the extra spam, feel free to merge if you think that's better. Second, I'm far from a GNOME developer or expert and the information below is just the result of a day's investigation into GNOME's code, bug tracking system and git history. Take everything I say with a grain of salt and please double-check :) So: the following things are broken in GNOME Flashback mode in today's jessie: 1) Keyboard layout switching 2) Non-metacity (i.e. g-s-d) keyboard shortcuts (e.g. Ctrl+Alt+L to lock screen) 3) Custom keybindings as configured by the control center 4) Power keys 5) Media keys (volume, play/pause) I think that at least (1) (2), as well as the combination of all these (plus the unrelated #734822, which is fixed by gnome-flashback 3.14 as found in experimental) makes the package unusable for most users and hence unsuitable for a release with jessie. The cause for this seems to be a general upstream trend of moving off functionality from gnome-settings-daemon and into gnome-shell. This became an issue in Debian with the inclusion of GNOME 3.14 in jessie. Upstream g-s-d commit b0cee1df30b4945f524611f354ff164d4a383262 (media-keys: Refer key grabbing to the shell, BZ #693016) removed media keys support, 326ee9f9a102a58941473e08fbe6221e70369f7f (keyboard: Remove input sources handling, BZ #736436) removed input source switching support and finally 66c975cd90736e32f20ffd36846301d68e7a08e7 (common: Remove unused keygrab code) removed the keygrab code entirely. There's a number of other commits that touch e.g. media-keys code too. This is deliberate, as GNOME proper doesn't really care about Flashback at this point. gnome-flashback's upstream is aware and trying to fix those issues in Flashback it self. Current master has cfce8742780e8be335cf19dd49a993cc0ea63b13 (libkey-grabber: initial version) the very hackish 670c310e8eaf89e895da96e62edc2a724c4ec068 (own org.gnome.Shell, see BZ #739534[1] for why this is very hackish and also indicative of GNOME proper's attitude to Flashback :/). I backported both of the aforementioned two commits to both jessie's and experimental's gnome-flashback (the former needed a bit of a porting work, the latter applies cleanly). Media keys custom keybindings functionality was restored, albeit without an OSD; keyboard layout switching was not, however. All in all, I'm not sure what the proper solution would be -- I'm hoping that you, as maintainers, may have a really bright solution :) As I see it, deviating significantly from upstream and reverting big g-s-d commits doesn't sound like a great strategy to me, especially this late in the jessie cycle. I think the most sensible approach at this point would be to get in touch with Flashback upstream and figure out the remaining bits (input sources, media keys, OSD). Then, stack patches against Flashback 3.14 (not 3.8) and beg the release team to make a big freeze exception on the basis that the alternative of removing Flashback from jessie entirely would be a big regression from Wheezy. Doesn't sound to me like something that has many chances of success, but Flashback is fairly self-contained and might be considered important enough. Let me know if you need any further clarifications or help from me. I'm pretty bummed at this point. This sucks :( Regards, Faidon 1: https://bugzilla.gnome.org/show_bug.cgi?id=739534 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734822: gnome-session-flashback: NM, Power and Volume applets don't start anymore
reassign 734822 gnome-flashback 3.10.0-1 severity 734822 serious thanks On Fri, Jan 10, 2014 at 03:51:56AM +0100, Christoph Anton Mitterer wrote: A while since ago, NM applet didn't anymore start with GNOME classic (this was already before 3.8 and gnome-session-flashback)... but since then, neither the volume, nor the battery/power applet show's up anymore. At least the sound applet is fixed with experimental's gnome-flashback/gnome-session-flashback (3.14.0-3). I don't think that a desktop session with no (option for) volume, battery/power or network management control is very useful for the majority of users and I don't think it would reasonable to release jessie with Flashback in this state, so I'm bumping this to serious/RC. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734822: gnome-session-flashback: NM, Power and Volume applets don't start anymore
On Wed, Dec 03, 2014 at 04:28:33PM -, Dmitry Shachnev wrote: Control: tags -1 +moreinfo On Wed, 3 Dec 2014 16:46:40 +0200, Faidon Liambotis wrote: I don't think that a desktop session with no (option for) volume, battery/power or network management control is very useful for the majority of users and I don't think it would reasonable to release jessie with Flashback in this state, so I'm bumping this to serious/RC. * NM-applet works fine for me. Its autostart file (nm-applet.desktop) was fixed some time ago, so it is now correctly autostarted. * For volume management use mixer applet from gnome-applets package. * For power control use battstat applet from gnome-applets package. What actually does not work for you? I've been running Flashback from jessie, experimental and my own patched version (see #771922) so forgive me for mixed feedback :( The way I see it on *stock* jessie versions now: * NM-applet shows up but crashes every now and then when I click on it. I guess this an NM bug regardless; I'll debug further and file it against NM when I have more information. * There is a sound icon on my notification area that has no icon, though (it's just gray). There are two trivial commits in upstream gnome-flashback that I suspect fix this (a7a54573453ac5d600f2988f58003a0177e7ba40 d8679b7ccff2dd3452c59e30ce2c421f333a19f6). The sound applet from gnome-applets works but I haven't found a way to remove the other, ghost icon from the notification area. * Yes, the battery applet from gnome-applets works. This isn't the old native GNOME 2.x notification area battery icon, but works just fine so I guess it's a non-issue. Thanks for the quick response, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771922: keyboard handling broken with jessie's gnome-settings-daemon
On Wed, Dec 03, 2014 at 06:18:45PM -, Dmitry Shachnev wrote: Please do not forget that the whole gnome-flashback (source) package fixes a lot of problems with gnome-panel. If we remove src:gnome-flashback from testing, that will leave gnome-panel users without: - Wallpaper; - Mouse cursor; - End Session dialogs. You may say that gnome-panel should be removed as well, but please do not forget that there are 8 other source packages depending on it, so they should get removed as well in that case. Yeah, that's a good point. This affects the Flashback mode as a whole... I think the best solution will be to leave things as-is. But if you convince the Release Team that removing 10 packages (or backporting 800 lines of code to add keyboard grabber) is a good idea, I will be fine with that. I don't think this is fit for release as-is. Are you referring to the two patches I posted? If so, I wish it was that simple; those a) are a hack, since they provide org.gnome.Shell, b) only fix media keys custom keybindings, not layout switching/input sources, c) even for media keys, there is no OSD, for e.g. volume. In any case, though, let's agree on the problem first. This is currently a severity: grave bug, i.e. release critical. Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768979: ITP: geoipupdate -- MaxMind GeoIP/GeoIP2 database updates
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org * Package name: geoipupdate Version : 2.1.0 Upstream Author : MaxMind, Inc. * URL : https://github.com/maxmind/geoipupdate * License : GPL Programming Lang: C Description : MaxMind GeoIP/GeoIP2 database updates The GeoIP Update program performs automatic updates of GeoIP2 and GeoIP Legacy binary databases, as supplied by MaxMind. These are typically paid products; for the free GeoLite databases, the packages geoip-database or geoip-database-contrib can be installed instead. This package replaces the geoipupdate functionality that used to be part of the geoip-bin package but was removed starting with 1.6.0, following upstream's split of the packages. The geoip-bin maintainer, Patrick Matthäi, is already aware of the plans for this ITP. Compared to geoip-bin, this will add GeoIP2 support, as supported by libmaxminddb, #741199. Finally, since the only purpose of this package is to fetch paid, binary databases from MaxMind, it will uploaded to the contrib section of the archive. 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#768984: ITP: python-maxminddb -- Python module for reading the MaxMind DB format
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org * Package name: python-maxminddb Version : 1.0.0 Upstream Author : MaxMind, Inc. * URL : https://github.com/maxmind/MaxMind-DB-Reader-python * License : Apache-2.0 Programming Lang: Python, C Description : Python module for reading the MaxMind DB format This is a Python module for reading MaxMind DB files. The module includes both a pure Python reader and an optional C extension. MaxMind DB is a binary file format that stores data indexed by IP address subnets (IPv4 or IPv6). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768979: Thanks and geoipupdate for free GeoLite users
On 11/11/14 02:42, Gregory Oschwald wrote: Thanks so much for packaging all of these! You're very welcome :) FWIW, I've also submitted an ITP for the Python bindings, #768984. I don't have any plans for the rest of the language binaries for now. All three packages are essentially done (modulo your recommendations below) and in Debian's git: http://anonscm.debian.org/cgit/collab-maint/geoipupdate.git http://anonscm.debian.org/cgit/collab-maint/libmaxminddb.git http://anonscm.debian.org/cgit/collab-maint/python-maxminddb.git Although it is poorly advertised, geoipupdate can actually be used with the free GeoLite databases, e.g., with the GeoIP.conf file: UserId 99 LicenseKey ProductIds 506 533 I think it would be reasonable to use this as a default in a general package. The GeoLite2 databases should work too with the product IDs of GeoLite2-City and GeoLite2-Country, but there appears to be an issue with the deployment of them for geoipupdate currently. Hopefully in the future we will clean up that fake UserId/LicenseKey, but even as it stands, this is preferable for most people to using a homemade script for downloading as it only downloads if the file has changed, verifies the MD5s before deploy, and safely moves the verified files over the old files. Oh wow, that is indeed great (and indeed poorly advertised :). I wasn't aware of this at all. We could replace geoip-database-contrib with this entirely. Two questions: 1) Where can I find the product IDs for the rest of the GeoLite databases? Ideally we'd list all of them, at least commented-out. 2) Is there an ETA for fixing the GeoLite2 products on the server? I could wait for this before I make an upload. Thanks for the amazingly quick feedback :) 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#741199: RFP: libmaxminddb -- library for working with MaxMind DB files
retitle 741199 ITP: libmaxminddb -- library for working with MaxMind DB files owner 741199 ! thanks This is now the de facto format for the GeoIP (and GeoLite) databases. CC'in the geoip maintainer in case he wants to take this RFP as this is basically the continuation of what he is maintining. I'm interested in doing this and I have preliminary packages. I checked with Patrick and he is okay with this plan. I'll put packaged up in collab-maint soon, in case Patrick or others are interested as well. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764513: pmacct: New major upstream release
Package: pmacct Severity: normal Hi, pmacct 1.5.0 was released over a month ago, on Aug 28th. It's a major new release with tons of new features. As not even the 0.14.x point releases were packaged for Debian, jessie currently has 0.14.0, released over two years ago (Apr 2012). It'd be a shame to miss the (very close, ~2 weeks) deadline. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746592: Upgrade/backport mailman as package has been made unusable by DMARC
On Thu, May 01, 2014 at 07:21:27PM +0100, juichenieder-deb...@yahoo.co.uk wrote: http://wiki.list.org/display/DEV/DMARC The way I see it, this bug report is for two different things: 1) Package a new upstream release. The current one is 2.1.18, a minor update to 2.1.16 (released on October, 2013; followed by 2.1.17 in the meantime) that unstable currently has. 2.1.18 provides a better solution to the DMARC problem, a problem that affects the vast majority of the mailman users running public mailing lists (as they're bound to have e.g. Yahoo! subscribers) and is going to affect even more of them as the time passes. The package update seems trivial and the fact that it hasn't been done since November 2013 (2.1.17 release date) suggests to me to that the package is poorly maintained. Dear maintainer, have you thought about RFHing the package? Would you be okay with me NMUing the package outside the regular NMU rules to update to a new upstream release? 2) A backport of the current jessie version to wheezy-backports. As far as I know, it's highly unusual for backport requests to be tracked in the main BTS, but if the maintainer doesn't mind, I won't :) Anyone can do the backport, as long the maintainer is okay with it. I'd be happy to do it, but I'd like to see (1) done first as to not waste my time with backporting an 9-month old piece of software. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/06/14 23:15, Ian Jackson wrote: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. Considering: - The technical committee has decided that Jessie is going to have a default init system and that would be systemd, - Testing a package's support for an alternative init systems is a complicated manual process that requires non-trivial modifications, such as switching init systems and rebooting or maintaining VMs, - Upstart has a popcon install count of 99, - Debian maintainers are not required to care about derivatives, - Even for those of us that do care about Ubuntu, upstart's future in Ubuntu (and in general) is unclear given Mark Shuttleworth's blog post[1] that was posted immediately after tech-ctte's systemd decision, - Unlike, say, openrc or sysvinit, there are no Debian release architectures that would specifically benefit from upstart in the jessie timeframe. - Upstart's failure mode for a package's lack of an upstart job is to execute the corresponding SysV init script and hence is not a regression, ...I'm having a hard time convincing myself to treat potential upstart bugs as anything but very low priority wishlist bugs. I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. If the committee feels differently about this, I think it'd be useful to express this in a more clarified manner and possibly incorporate this into policy. For what it's worth, the current wording of contin[uing] to support, merging reasonable contributions and without a compelling reason leaves a lot of room for interpretation and changes nothing for me compared to the previous resolution or the status quo before it. Regards, Faidon 1: http://www.markshuttleworth.com/archives/1316 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741686: linux-image-3.13-1-amd64: systemd-udevd kills long running mptsas module initailization, resulting in kernel oops
Hi, This regression is fairly complicated and it's high impact, as mptsas is being used to drive fairly popular controllers, including the entry-level ones in several generations of Dell PowerEdge servers. We've been debugging this for a while now over at Ubuntu's Launchpad[1] and the issue has been subsequently been raised on both the linux-scsi[2] systemd mailing lists[3]. In essence, there are four different behaviors/bugs here: 1) The kthread_create() semantics have changed in 3.13 with 786235ee by making kthreads killable. Not a bug on its own, but it's a breaks previously working userspace configuration kind of bug. Ubuntu has reverted this patch for trusty as a workaround. 2) mptsas, to probe the SAS bus, spawns a kthread that takes more than 30s to complete. The consensus on the list AIUI is that it's a bug and it should not take that long. 3) systemd-udev by default sends SIGKILL to kthreads that have been running for more than 30s. systemd developers do not consider this a bug but an intended behavior and refuse to fix this issue. Adding OPTIONS+=event_timeout=120 to the udev config would probably workaround this. 4) Unrelated to the bug at hand, mptsas is buggy in the error handling codepath, when the kthread spawning fails. It tries to clean up by dereferencing a NULL pointer and hence the kernel oopses, while otherwise it'd just continue running, just without any mptsas devices present. I've made an analysis of the buggy codepath on comment #27 on the LP bug above. This has always been a bug, it's just that that codepath was untested until now. The end result is that this regression is somewhere in the limbo land between kernel/systemd for the two features (1)/(2) that are valid on their own but reveal a regression in combination with (3) and each other. Issue (2) seems like a real bug and the root cause here, but one that probably can't be easily fixed in a point release -- I don't think it hasn't even been fixed in master yet. Issue (4) is easily fixable but it's orthogonal and not going to solve the real problem here. It will just downgrade this from an oops to just a system with no disk drives but an otherwise working kernel. Regards, Faidon 1: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705 2: https://lkml.org/lkml/2014/3/23/42 3: http://lists.freedesktop.org/archives/systemd-devel/2014-March/018007.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727085: Taking over packaging in Debian.
On 03/04/14 00:01, David Martínez Moreno wrote: Don't act as we have some hidden agenda, please. There are several things that I'm putting work on like dropping support for the forked libevent HTTP server, using alternatives for the php5-cli/cgi binaries to be able to replace them, no init scripts for now, compiling folly statically (or at the very least not as a different package), getting rid of third-party stuff, releasing proper tarballs in hhvm.com, merging the nightly packages with my work, and those are off the top of my head. \o/ This list is awesome David, as is the rest of your work so far. Let's document this and others under debian/TODO. Thanks for this and apologies to you, Paul team for not having made much progress on this since we last spoke. I took a look at the collab-maint repository and submitted a bunch of commits -- I had already prepared a very similar list of Build-Depends myself in the early work I had locally, so I merged mine into yours and fixed some other collateral issues I found. Please review! Thanks again and I hope we can find ways to collaborate to make an awesome HHVM package in Debian :) Best, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740231: Please package new upstream release
Package: muffin Version: 1.7.3-1 Severity: normal Debian currently has version 1.7.3, released 11 months ago. Upstream has released 12(!) versions in the meantime, with the latest one, 2.0.5 having been released approx. 3 months ago. Clearly, this is suboptimal for our users; you should probably start keeping up with upstream releases or orphan your package. (new upstream releases are usually wishlist, but I consider it so far behind that I think it warrants a normal bug; feel free to adjust to your preferences, though) Best, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739930: Please switch to -latomic atomics for wider arch portability
Hi Adam, On Sun, Feb 23, 2014 at 06:10:42PM -0700, Adam Conrad wrote: * link-atomic.patch: Switch from __sync to __atomic to support more arches. * Switch back to arch:any instead of the Debian maintainer's shorter list. So, this patch should be almost upstreamable, depending on who their intended target is. If they need to support __sync on non-Linux, they could wrap __sync and __atomic blocks in ifdef/ifndef magic to test for linux or perhaps specific GCC versions. Thanks for the patch. I had suggested the same and discussed it with Magnus (upstream) too among other options[1], but the __atomic functions are GCC 4.7+, which would break builds with e.g. precise and are hence unattractive for upstream inclusion. Magnus has on his plans to rethink atomic operations and independently of that switch to autoconf, so we could perhaps make this more reasonable than a bunch of #ifdefs that would break with weird error messages under certain combinations of GCC version/architecture :) I'll poke him again. Thanks for your bug report. Faidon 1: Another one would be limiting the queue size to 4GB on 32-bit architectures (i.e. switch from uint64_t to long), which wouldn't be such a big deal considering librdkafka's use cases. -- 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
On 01/05/14 05:44, Jordan DeLong wrote: On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote: Question is, does Folly maintain ABI compatibility? If it changes from time-to-time, how often? Yeah, it doesn't attempt to maintain ABI backward compatability, and we haven't done much about tracking when we break source-level backward compatability either. (As Sara said, we don't version it currently... unless you count the submodule in hhvm ;) There are changes probably a few times a week, although I'd suspect few of the changes that aren't to new components (usually in folly/experimental) actually break source backward compat. I do think it'd be nice to have folly packages some day, but mostly the value there would be making it easier to use folly (in other C++ projects). I don't think it's going to be all that helpful for people who just want to use hhvm: it's largely a header-only library, so even if there are nice folly-dev packages with .h's and .a's, I'd hope a pre-built hhvm package wouldn't depend on a folly package being installed, since it makes more sense to statically link it. (Actually there's probably not much point to having a non-development folly package containing .so's for most reasonable use cases w/ the library as it is today---maybe if it grows significantly in the non-header-only portion in the future, but probably not anytime soon.) Thanks a lot for the clarifications, Jordan and Sara. These seem to confirm my (educated :) guesses about folly's release model. László, given the above, are you going to inform the ftp-masters to REJECT the package from NEW right away? 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#727085: Now we don't depend on the weird libevent patch
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 p...@fb.com 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#727085: Now we don't depend on the weird libevent patch
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#727085: Now we don't depend on the weird libevent patch
On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote: My opinion for releases follows. Do one if there's an important bugfix, new feature added, etc. In short, if there's a reason. On the other hand, there's no problem with releasing every two weeks, it's just not common. It matches with Debian standards, meaning that normally ten days needed for unstable - testing migration. Two weeks is probably too often for Debian but time-based releases in general (rather than important bugfix) are fairly common. I think the original idea of accumulating multiple sprints into one community release is a great path forward. The proposal for 8-week releases sounds just fine to me. Looking a bit further ahead, Debian will release a new stable in something like a year from now, and will have to support whatever happens to be in testing by November 6th, for at least the release of next stable + one year (i.e. for about 3-4 years), without the ability to bump into newer HHVM versions. Some upstreams tend to release some LTS releases for such uses, potentially labeling one of their incremental releases as LTS. This isn't a prerequisite, but it's good to actually have some longer stable/security management in mind when planning your release schedule. Lastly, Laszlo, we should talk about how I can help with packaging. Do you have a packager position there, at FB? :) At least ATM I've two places to work for. At Debian I've more than a hundred packages and twenty to do. Especially that I have to work more or less constant from 31st 06:00 am to 2nd 04:20 pm. Will be hard, thus I'll start again with HHVM next year. Well, noone really forced you to ITP this :) You definitely seem to have your hands full, there's no need for you to take on more than you're able to handle. If you're too busy, I can just takeover this ITP, just say so. Now my previous package section for HHVM, which I've named hiphop-php (to match the PHP policy of Debian, but will re-check that): Which section of the policy mandates that? I'd be very suprised if the existing PHP policy covers alternative interpeters. -- cut -- HipHop VM (HHVM) is a new open-source virtual machine designed for executing s/a new/an/ (redundant for the description) programs written in PHP. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. HipHop VM (and before it HPHPc) has realized 5x increase in throughput for Facebook compared with Zend PHP 5.2. HipHop is most commonly run as a standalone server, replacing both Apache and modphp. The last two lines are incorrect considering the new FastCGI mode of operation, which AIUI will be the only one actually offered by the package, as the embedded standalone webserver requires patches to libevent. I think packaging for Debian is a good step. Then Ubuntu maintainers will pick it up and as I know, Mint based on Ubuntu, they will have it as well. Ubuntu automatically syncs from Debian, there's no need for Ubuntu maintainers to do anything. And yes, there's tons of other Debian Ubuntu derivatives that also regularly sync from those two. 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#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Not really, in my opinion. I think it's a valid rejection reason for anything that is not the reference PHP implementation published and copyrighted by the PHP Group. Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion but you're not a member of the Debian project and you're certainly not the decision maker for DFSG-freeness. The maintainer (and, possibly, sponsoring Debian Developer) is the first line of defense, and ultimately the decision is up to the ftp-master team[1] as part of the power of processing the NEW queue and accepting packages into Debian, a power that is delegated from the project leader. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. There is zero evidence suggesting that HHVM is not going to be accepted in Debian for the licensing reasons that you stated and there is, in fact, evidence to the contrary. Please avoid suggesting so -or if you do, explain that you're not part of the decision process- and possibly frightening perfectly good upstreams, or asking them to do more work, especially when they've proved themselves to be very willing to collaborate with us. Regards, Faidon 1: https://wiki.debian.org/Teams/FTPMaster -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730506: librdkafka: FTBFS: Various -Werror
tags 730506 + upstream confirmed pending thanks Hi Roland, On Mon, Nov 25, 2013 at 10:28:33PM +0100, Roland Stigge wrote: librdkafka FTBFS on most architectures like this (powerpc): Thanks for the report. I had already seen the build failures and raised the issue with the upstream author. He has prepared a branch[1] with fixes for me to test with. I'm going to perform a build on porterboxes before we tag/release to make sure we don't do another round of build failures. Thanks, Faidon 1: https://github.com/edenhill/librdkafka/tree/debcompfix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714210: DRBD 8.3 userland incompatible with 8.4 kernel modules
On Wed, Jun 26, 2013 at 10:50:20PM +0200, Jonas Meurer wrote: as the subject already mentions, DRBD 8.3 userland in jessie/testing is incompatible with DRBD 8.4 kernel modules from the 3.9 linux package. DRBD kernel modules are at 8.4 branch in upstream linux kernel since kernel release 3.8. Ubuntu already ships DRBD 8.4 userland for this reason within Raring (13.04). Please consider to upgrade DRBD userland to 8.4. For now DRBD is unusable in Debian sid/unstable and jessie/testing. Is DRBD maintained at all or should it be orphaned? It's broken in unstable for a while, with no maintainer reply whatsoever in this (severity: grave) bug which exists since June or any of the other bugs, including a severity: serious one. Please either act on it or orphan it, this situtation isn't doing our users any service at all. 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#725210: embeds multiple libraries, at least two of which undistributable
Package: asterisk Version: 1:11.5.1~dfsg-2 Severity: serious I was surprised and initially happy to see Asterisk 11 uploaded into sid. My happiness quickly diminished when I saw that the upload contains the embedded pjproject as-is, despite this issue having been flagged for months now and being the sole blocker for an upload since the release of Asterisk 11 eleven months ago. There are several policy violations here: - Contains a convenience copy of pjproject under res/pjproject (§4.13) - pjproject itself contains convenience copies of several libraries under res/pjproject/third_party/ some of which already packaged in Debian (§4.13) - All of the above are completely undocumented in d/copyright (§12.5) - Not only they are undocumented, but it looks like no audit has happened on them whatsoever. From a very cursory look, at least res/pjproject/third_party/milenage/ res/pjproject/third_party/g7221/ seem to completely lack license information other than the occasional All right reserved, which makes them undistributable by Debian or anyone else. (§2.3) I'm baffled on how a DD could ever upload this into the archive, esp. since these issues were widely known and discussed beforehand. Please refrain from making such uploads in the future, as it's both a disgrace to Debian's standards and a legal risk. 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#725118: please package new upstream version
Package: jq Version: 1.2-8 Severity: wishlist Hi, Version 1.3 has been released since May 5th, i.e. 5 months ago. Please package the new upstream release. Let me know if you need a sponsor, I'd be happy to help you with that. 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#720392: package hardcodes database information
Package: rddmarc Version: 1.1.3-1 Severity: grave $ grep connect /usr/bin/dmarcfail db = MySQLdb.connect(user='dmarc',passwd='xxx',db='dmarc', use_unicode=True) $ grep -A 1 connect /usr/bin/rddmarc my $dbh = DBI-connect(DBI:mysql:database=dmarc, xxx, xxx) or die Cannot connect to database\n; No, xxx wasn't added by me. Yes, there are no configuration options whatsoever. Additionally, contrary to the package's description, mkdmarc is not shipped, neither is the schema in e.g. examples. Seriously? 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#711274: kexec-tools: please support mips and mipsel architectures
On Thu, Jun 06, 2013 at 12:59:03AM +0200, Aurelien Jarno wrote: Upstream kexec-tools supports the mips and mipsel architectures, but the debian package doesn't list them in the debian/control file, so the package is not built there. Could you please apply the following patch to fix this issue: I can confirm that 1:2.0.3-1 builds installs and works as intended on my mips box with Linux 3.10. Best, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710710: asterisk: bump version to 11 (LTS release)
On Thu, Jun 20, 2013 at 04:18:01PM +1000, Mark Purcell wrote: I do not see this as a showstopper to uploading. sflphone also includes an embedded copy of pjproject. There is merit in having one master version of pjproject in Debian for a whole slew of reasons, and I therefore support the efforts under #708122. I disagree. That's a direct policy violation, section 4.13 Convenience copies. Moreover, it's a double one at that, since pjproject itself has its own embedded convenience copies of a number of libraries under the third_party directory, including libraries which are packaged separately in Debian (srtp, portaudio, …). There was a thread on the asterisk-dev mailing list during which both myself, Tzafrir Daniel Pocock intervened as well as the Fedora maintainers. Asterisk upstream is aware of the issue this presents and they're working on cleaning up pjproject and making it shared library/distro friendly. I think their efforts is at https://github.com/asterisk/pjproject/. Someone from pkg-voip should evaluate that, find the issues there and package it, to be used by Asterisk, sflphone, python-sipsimple and whatever other project uses pjproject. 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#712107: ITP: nutcracker -- Fast, light-weight proxy for memcached and Redis
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org * Package name: nutcracker Version : 0.2.5 (TBA) Upstream Author : Twitter, Inc. * URL : https://github.com/twitter/twemproxy * License : Apache-2.0 Programming Lang: C Description : Fast, light-weight proxy for memcached and Redis nutcracker, also known as twemproxy (pronounced two-em-proxy), is a fast and lightweight proxy for the memcached and Redis protocols. It was primarily built to reduce the connection count on backend caching servers, but it has a number of features, such as: * Maintains persistent server connections to backend servers. * Enables pipelining of requests and responses. * Supports multiple server pools simultaneously. * Shard data automatically across multiple servers. * Supports multiple hashing modes including consistent hashing and distribution. * High-availability by disabling nodes on failures. * Observability through stats exposed on stats monitoring port. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711872: as root, build succeeds but tests do not - no 'gdnsd' user
severity 711872 minor thanks On Mon, Jun 10, 2013 at 03:43:37PM +0100, Alexander Clouter wrote: The tests fail to start as the 'gdnsd' user does not exist on a fresh system at build time (might be worth changing the tests to use the 'nobody' user? patch enclosed): This is actually the case only if you run the build as root. The package builds fine if you build it from an unprivileged users' environment, including nobody. That's also the case with Debian's autobuild network, which is why the package has built successfully on all releaseable architectures[1]. You should never build packages as root as this is dangerous for your system. Nevertheless, this is indeed a minor bug that should be fixed. Thanks, Faidon 1: https://buildd.debian.org/status/package.php?p=gdnsd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711811: ITP: foreman -- manage Procfile-based applications
On 06/10/13 03:46, Per Andersson wrote: * Package name: foreman Version : 0.63.0 Upstream Author : David Dollar da...@dollar.io * URL : http://github.com/ddollar/foreman * License : MIT Programming Lang: Ruby Description : manage Procfile-based applications Foreman is a manager for Procfile-based applications. Its aim is to abstract away the details of the Procfile format, and allow you to either run your application directly or export it to some other process management format. There's a more popular/more complicated piece of software called Foreman[1], for which there's an RFP already[2], as well as a component of that, foremancli, already in Debian. Upstream provides a package too, although you could argue it isn't our problem if there's a naming conflict. Nevertheless, I think it'd be best to avoid a package naming conflict between the two apparently completely unrelated applications. Oh, and BTW, you should probably explain what a Procfile is on the long description of your package as it's not immediately obvious. Regards, Faidon 1: http://www.theforeman.org/ 2: http://bugs.debian.org/663101 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710390: git-overlay mode is broken due to internal API changes
Package: git-buildpackage Version: 0.6.0~git20130506 Severity: serious Hi, Building a package with overlay=True fails with the following backtrace: Traceback (most recent call last): File /usr/bin/git-buildpackage, line 5, in module sys.exit(main(sys.argv)) File /usr/lib/python2.7/dist-packages/gbp/scripts/buildpackage.py, line 524, in main export_source(repo, tree, source.changelog, options, tmp_dir, output_dir) File /usr/lib/python2.7/dist-packages/gbp/scripts/buildpackage.py, line 148, in export_source if source.is_native(): AttributeError: 'ChangeLog' object has no attribute 'is_native' Commit 45c2346 seems to have removed the is_native() method from the ChangeLog object to avoid accidental usage. It seems that the overlay mode triggers a codepath which wasn't updated, probably because of the ambiguity of the argument: the argument is called source but export_source passes source.changelog, as you can see from the above backtrace. 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#710271: ITP: librdkafka -- library implementing the Apache Kafka protocol
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org * Package name: librdkafka Version : 0.8.0 Upstream Author : Magnus Edenhill mag...@edenhill.se * URL : https://github.com/edenhill/librdkafka * License : BSD-2-clause Programming Lang: C Description : library implementing the Apache Kafka protocol librdkafka is a C implementation of the Apache Kafka protocol, containing both Producer and Consumer support. . More information about Apache Kafka can be found at http://kafka.apache.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681809: udev: partuuid/partlabel symlinks not created
tags 681809 - fixed-upstream
On Mon, Jul 16, 2012 at 10:02:51PM +0200, Marco d'Itri wrote:
tag 681809 fixed-upstream
thanks
On Jul 16, Sam Morris s...@robots.org.uk wrote:
The relevant udev rules may be found at line 126 of
60-persistent-storage.rules:
I think this was fixed in udev 180.
So, Sage Weil (from the Ceph project) investigated this further and
pinpointed this to a Debian-specific bug rather than an upstream one.
The partuuid/partlabel rules are after the:
# probe filesystem metadata of disks
KERNEL!=sr*, IMPORT{program}=/sbin/blkid -o udev -p $tempnode
line which defines the environment for the rules to work.
Apparently, just moving the partuuid rule to the end fixes this bug.
So, this won't be fixed by a newer upstream in unstable. It also sounds
like an obvious bug with an easy fix, so it might be worth it bringing
this to stable too.
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681809: udev: partuuid/partlabel symlinks not created
On Mon, Jul 16, 2012 at 10:02:51PM +0200, Marco d'Itri wrote: On Jul 16, Sam Morris s...@robots.org.uk wrote: The relevant udev rules may be found at line 126 of 60-persistent-storage.rules: I think this was fixed in udev 180. Are you referring to 1b9e13e2e2c4755752e1e9fd8ff4399af7329ab8[1] aka 178~10? If so, it should be easy to either s/ID_// the rules.d file or backport that trivial patch. I guess I'm about a month late for wheezy now, but if you do an SPU for other reasons, it might be worth it to fix this too. Thanks, Faidon 1: http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=1b9e13e2e2c4755752e1e9fd8ff4399af7329ab8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
On Fri, May 10, 2013 at 10:23:04AM -0400, Jon Bernard wrote: This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. I don't completely follow, can you give some clarification? Also, can you include a link to where I can see the britney information you're referencing? This bug report was originally found on liburcu/0.7.4-1. The ltt-control upload send a mail to 688779-close@ and this marked the bug as fixed in ltt-control/2.1.0~rc4-2. But it wasn't found on that package in the first place, so this was essentially no-op. You can see this on the top of this bug report: Found in version liburcu/0.7.4-1 Fixed in version ltt-control/2.1.0~rc4-2 Since the bug was found in a version of liburcu and wasn't fixed (or unfound) in subsequent liburcu version, the BTS considers the bug as still present in the most recent version of liburcu. You can clearly see this on the dot graph in the top right side of the bug page. You can also see how this will prevent the migration of liburcu to testing (britney's excuses): http://qa.debian.org/excuses.php?package=liburcu The solution is to either mark the bug as fixed in a newer version of liburcu (by mailing -done@ with e.g. Version: 0.7.6-1) or to inform control@: notfound liburcu/0.7.4-1 found ltt-control/2.1.0~rc4-1 thanks Cheers, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619642: ITP: libjs-extjs4 - cross-browser JavaScript library, version 4
On Mon, Nov 21, 2011 at 11:28:46PM +0100, Laszlo Boszormenyi wrote: owner 619642 ! I'm packaging JSDuck which needs ExtJS 4, I'm wondering what the status of this ITP is. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705037: FTBFS on sparc
On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. BTW, it also looks like upstream has a generic implementation (gcc.h) for barriers and atomic operations. They seem to be using this only for ia64 and not on unknown architectures (probably to be on the safe side), but it might just be okay on the rest of the architectures as well. If that's the case there's probably no need to actually disable liburcu everywhere else. But you should confirm this on a per-architecture basis with your upstream :-) 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#705037: FTBFS on sparc
On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote: I suspect the buildd (schroeder in this case) has a 32bit userland and thus has a HOSTTYPE of sparc instead of sparc64. I should be a one-line patch, but the only available sparc test machine (smetana) is sparc64 and so I don't have the ability to test this. It bothers me to make an upload simply to see if the sparc build machine will succeed. How would you handle this situation? The sparc Debian port is 32-bit userland, this has nothing to do with the buildd. The (upcoming) sparc64 port will be a separate, 64-bit userland port. It's currently residing on debian-ports.org and buildds are already building new uploads; it seems liburcu 0.7.6-1 built fine there: http://buildd.debian-ports.org/status/package.php?p=liburcusuite=sid Both schroeder and smetana have a 64-bit kernel, in fact I don't think the sparc port has a 32-bit kernel at all anymore. smetana has all the build dependencies to build liburcu on the sid chroot, if you want to experiment. Note that this isn't something that has recently changed, so this doesn't explain why sparc used to work with previous liburcu versions but stopped working. This probably has something to do with a liburcu upstream change, you should track this down. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. Yes, you raise an excellent point here. I will make this change. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Also a good point, thank you for the suggestions. Great, thanks, looking forward to these changes. 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#705037: FTBFS on sparc
On Mon, Apr 15, 2013 at 01:15:38PM -0400, Jon Bernard wrote: On the buildd machines that I cannot test on, autoconf sets $host_cpu to 'sparc' instead of 'sparc64'. This caused me to assume they had a 32bit kernel. On the machine that I can test on (smetana), autoconf sets $host_cpu correctly to 'sparc64' - and so liburcu builds and runs fine there. The buildd machines are distinctly different from smetana. I think this is because the buildds set the personality to be 32-bit as to always build for 32-bit sparc ports, no matter the running kernel of the buildd. This is just an interpretation of the effect I'm seeing, I can't back this up with a pointer to the code :) I think using $host_cpu for what liburcu uses it is flawed in this sense (also, host? why not target?). I could be wrong though, I don't claim to be an expert on such things. I'd suggest contacting the porter people and in particular the sparc porters. I had previously mapped 'sparc' to 'sparc64' to fix this, which caused everything to build successfully. But without testing, I didn't feel it was the correct thing to do, so I removed the patch. This is why the build stopped working - not due to upstream changes. Yeah, I think this is the wrong way to go. The current sparc port only support 64-bit kernels, so it'd probably work on all cases, but it's not right to use 64-bit asm on a 32-bit userland port. Without access to one of those machines to test on, I have two options: I have access to schroeder and can assure you that there's no difference whatsoever between the two. But try running linux32 dpkg-buildpackage if you want to emulate this. BTW, configure.ac seems to make some assumptions about ARM optimization falgs; I'm unsure if these are correct for Debian, you should double-check if you haven't already. 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#705037: FTBFS on sparc
Package: liburcu Version: 0.7.6-1 Severity: serious Hi, Your package seems to be marked Architecture: any but seems to FTBFS on multiple architectures, some of them even release architectures. mipsel has already been marked as Not-For-Us. One of them is sparc which built for 0.6.7-1 but has failed on 0.7.6-1 since Jan 20th with: In file included from urcu/static/wfqueue.h:33:0, from wfqueue.c:25: ./urcu/uatomic.h:23:2: error: #error Cannot build: unrecognized architecture detected. This would prevent your package from entering testing, should the release happen and testing unfroze. From what I see, fixing sparc shouldn't be a big deal. kfreebsd-* which also FTBFS could be a bit less trivial to fix but still doable as a maintainer's job. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. 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#688779: liburcu1: shlibs too weak
On Tue, Sep 25, 2012 at 12:04:59PM -0400, Aaron M. Ucko wrote: Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. 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#703607: Please include Cypress PS/2 Trackpad driver in linux-image-3.2.0-*
On Sun, Mar 24, 2013 at 06:20:01PM +, Ben Hutchings wrote: Control: severity -1 important This is a bit off-topic, but I'm not sure it warrants a different bug report (feel free to clone): I recently had to support a friend who bought a Dell E6230 and installed Wheezy, but couldn't get the touchpad working (it was detected as a regular PS2 Mouse). The E6230 is a May 2012 release laptop, otherwise identical to the E6220, which had a regular ALPS touchpad with support backported to wheezy in the first days of the freeze. It turns out that the E6230 has a Rushmore ALPS touchpad. Support for those was exists in upstream by 1302bac33d9e88cd43e482191a806998f3ed43cc, committed Feb 13, will be in 3.9. cd401204873101245287afc07271b39c79194d9c is probably part of that series too. The support is hence bleeding-edge, but the E6230/E6430/E6530 laptops are out for quite some time and are very popular -- it's basically the 12/14/15 inch Latitudes that are on sale now. I tried backporting that patch and failed miserably. I'm not sure how much more work would it be to apply them and if they'll be accepted into Debian if they have to pull a dozen more commits, esp. this late in the cycle. I'll let you be the judge of that, I was impressed you changed this to important :) FWIW, I built psmouse.ko straight of 3.9 and the touchpad works as a charm on that laptop. I can also do more extensive testing with a 3.2 + patches, albeit with a bit of an increased turnaround as I don't own that laptop. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698968: openssl: s_client support SNI
On Fri, Jan 25, 2013 at 10:15:21PM +0100, Kurt Roeckx wrote: Package: openssl Version: 1.0.1c-4 Severity: wishlist It would be nice that s_client would use SNI, or would have an option to use it. I'm pretty sure that's the -servername argument, present since ages ago. 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#699148: unblock: celery/2.5.3-2
On Fri, Mar 01, 2013 at 12:13:06AM -0800, Christoph Egger wrote: Michael Fladischer mich...@fladi.at writes: On 2013-02-28 21:27, Adam D. Barratt wrote: Any news on an upload? 2.5.3-3 is prepared in SVN but paravoid (my sponsor on celery) seems to be busy. Uploaded JFYI, r23622 | fladi-guest | 2013-03-01 07:46:25 + (Fri, 01 Mar 2013) | 2 lines i.e. 40 minutes ago, after I sent a mail to Michael :) But thanks for handling that, appreciated. 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#700337: ITP: kibana -- is a user friendly way to view your log data.
On Tue, Feb 19, 2013 at 07:31:38PM +, Jose Manuel dos Santos Calhariz wrote: Thanks for packaging this. Kibana is not very useful on its own though, do you happen to also intend on packaging logstash? No, I don't. That's sad. Why not? I have a kibana package prepared for a review, Can you be my sponsor? I guess I could, although I'm not familiar much with Ruby packaging. Have you tried contacting more experienced people from the Ruby team? 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#700337: ITP: kibana -- is a user friendly way to view your log data.
On 11/02/2013 11:12 πμ, Jose Calhariz wrote: * Package name: kibana Thanks for packaging this. Kibana is not very useful on its own though, do you happen to also intend on packaging logstash? 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#696171: Default suite is still set to squeeze
Package: ganeti-instance-debootstrap
Version: 0.11-1
Severity: normal
Hi,
$ grep SUITE /usr/share/ganeti/os/debootstrap/common.sh
: ${SUITE:=squeeze}
I believe this should be updated for the wheezy release. Note that
debootstrap also supports symbolic names, so stable would be the safe
choice here, at least for Debian.
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#696133: wheezy version Recommends squeeze's Xen kernel
Package: ganeti2 Version: 2.5.2-1 Severity: normal Hi, ganeti2 2.5.2-1 with which apparently wheezy is going to be released, seems to recommends a 2.6.32 Xen kernel as an alternative to to qemu-kvm, which is of course not available in wheezy: # grep-aptavail -P -s Version,Recommends ganeti2 Version: 2.5.2-1 Recommends: drbd8-utils (= 8.0.7), qemu-kvm | xen-linux-system-2.6.32-5-xen-amd64 | xen-linux-system-2.6.32-5-xen-686, ganeti-instance-debootstrap, ndisc6 I suggest that this be changed to xen-linux-system-amd64 as I see no reason in depending on a specific kernel version. 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#695677: domain within a function produces syntax error (wheezy regression)
Package: ferm
Version: 2.1-3
Severity: important
Tags: fixed-upstream
Hi,
ferm 2.1 and onwards rejects the following stanza as invalid syntax
(missing brace):
@def SERVICE($proto, $port) = {
domain (ip ip6) chain INPUT {
proto $proto dport $port ACCEPT;
}
}
SERVICE(tcp, smtp);
The syntax above is perfectly fine according to the DSL specification
and was accepted by ferm 2.0.7. I know of multiple large installations
that use squeeze, ferm and that feature heavily and the wheezy upgrade
is going to break the firewall set for them (hence the severity).
I've found and fixed the bug and my patch has been merged into
upstream's git as commit 392e58, to be included in 2.1.2.
The patch basically a one-liner that can be cleanly applied to 2.1. I
think it warrants an upload and freeze exception, according to the
current freeze rules.
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694173: ITP: gdnsd -- authoritative domain name server
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org * Package name: gdnsd Version : 1.6.9 Upstream Author : Brandon L Black * URL : https://github.com/blblack/gdnsd * License : GPLv3 Programming Lang: C Description : authoritative domain name server gdnsd is an Authoritative-only DNS server. The initial g stands for Geographic, as gdnsd offers a plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover. gdnsd has a strong focus on high performance, low latency service. It does not offer any form of caching or recursive service, and does not support DNSSEC. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666974: installs to /dev/sda when grub-installer/bootdev = /dev/sdb
On Tue, Apr 03, 2012 at 11:24:25AM +1000, Vincent McIntyre wrote: When I specify in my preseeding file: d-i partman-auto/disk string /dev/sdb d-i grub-installer/bootdev string /dev/sdb grub-installer ignores me and installs to /dev/sda. partman-auto does the right thing. In some cases this can result in an unbootable system. Indeed, I've experienced this and can confirm the bug. It can also lead in errors in the installation process: I had a preseeding configuration in which sda should stay empty and the operating system should be installed in an entirely different disk; grub-installer tried to install grub on sda, but sda had no partioning table or MBR whatsoever, which made it fail with an error. I've read grub-installer's source though and realized I can work around it if I set grub-installer/only_debian to false, as this skips directly to step 2 which then obeys the preseeded bootdev properly. 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#692461: unblock radsecproxy/1.6.2-1
Package: release.debian.org
Severity: normal
Hi,
Please unblock radsecproxy 1.6.2-1. It's a security upload, complementing
1.4-1+squeeze1 and fixing two CVEs. Security team is aware and has reviewed the
upstream fixes for those -- in fact, the second vulnerability was found by
Raphael during the review.
radsecproxy (1.6.2-1) unstable; urgency=high
* Urgency set to high for a security release.
* New upstream release, fixing two security issues:
- When verifying clients, don't consider config blocks with CA settings
('tls') which differ from the one used for verifying the certificate
chain (RADSECPROXY-43, CVE-2012-4523). Reported by Ralf Paffrath.
- Fix the issue with verification of clients when using multiple 'tls'
config blocks for DTLS too (RADSECPROXY-43, CVE-2012-4566). Reported by
Raphael Geissert.
* Drop most of debian/patches/fix_manpages, merged upstream.
Here's the annotated diffstat between 1.6-1 and 1.6.2-1, excluding
configure.ac, config.{guess,sub} and (already-applied, source/format 3.0)
debian/patches:
diff --exclude=.pc --exclude='patches' --exclude='config*' -Nurp \
radsecproxy-1.6/ radsecproxy-1.6.2/ | diffstat
debian/changelog | 14 ++
AUTHORS|1 +
ChangeLog | 19 ++-
README |2 +-
radsecproxy.conf.5.xml | 19 +++
Version updates documentation. Note that the manpage change is needed
as it explains some of the circumstances around the security fix.
aclocal.m4 |4 ++--
AC_AUTOCONF_VERSION 2.65 - 2.68. I realize that this, along the
configure.ac update, maybe unfortunate during the freeze, but it was the
only one that stood out and seems safe enough, so I opted against a
1.6-2 with everything else but this.
tls.c | 28 +++-
Fix for CVE-2012-4523.
dtls.c |4 +++-
Fix for CVE-2012-4566.
tools/naptr-eduroam.sh |4 ++--
Two minor one-liners; that script is only shipped in doc/examples/
anyway.
9 files changed, 71 insertions(+), 24 deletions(-)
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692467: stat.h referenced but missing
Package: libbind-dev Version: 1:9.8.4.dfsg-1 Severity: important Hi, $ grep stat.h /usr/include/isc/file.h #include isc/stat.h $ ls /usr/include/isc/stat.h ls: cannot access /usr/include/isc/stat.h: No such file or directory stat.h seems to be relatively new, it doesn't seem to be referenced from squeeze's isc/file.h. I'm not sure how common is the use of isc/file.h and hence how much this affects the usefulness of libbind-dev and the severity of this bug, setting it as important for now. I encountered this while trying to package a new package that i intend to upload, so I'd like to see this fixed. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692483: ITP: dnsperf -- DNS server performance testing tool
Package: wnpp Severity: wishlist Owner: Faidon Liambotis parav...@debian.org Control: block -1 by 692467 * Package name: dnsperf Version : 2.0.0.0 Upstream Author : Nominum, Inc. * URL : http://www.nominum.com/support/measurement-tools/ * License : ISC Programming Lang: C Description : DNS server performance testing tool dnsperf is a DNS server performance testing tool. It is primarily intended for measuring the performance of authoritative DNS servers, but it can also be used for measuring caching server performance in a closed laboratory environment. . Also included is resperf, a similar tool that is more suitable for testing caching servers resolving against the live Internet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636534: Bug#683555: subversion: not working at all SASL context error
reassign 683555 libsasl2-2 forcemerge 636534 683555 forwarded 636534 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3589 tags 636534 + fixed-upstream severity 636534 important thanks On Thu, Aug 02, 2012 at 01:59:36AM +0900, Norbert Preining wrote: due to a broken laptop I had to switch to an old one. After upgrading from a about 2 year old system, suddenly my svn is completely broken wrt to svn:// URLs. ALl trials (co, up, ...) terminate with the same error: $ svn up Updating '.': svn: E170001: Unable to connect to a repository at URL 'svn://u...@server.org/some/path' svn: E170001: Could not create SASL context: generic failure: No such file or directory $ The same happens with svn+ssh://... on svn.debian.org So, I was bitten by this as well. It seems that this bug is breaking Subversion on upgrades on systems that don't have a correct hostname. Having a broken hostname is of course bad, but this shouldn't stop Subversion from working, esp. since it's a regression from squeeze. It appears that it's not that uncommon: we had two separate bug reports with multiple reporters in Debian, there's a similar openSUSE¹ bug, a similar MacPorts bug² etc. It also affects more than Subversion; KMail Kontact have been explictly mentioned. So, I'm bumping the severity to important -- I also considered serious/RC, but I'll leave that up to the maintainer. The issue seems to have been fixed upstream with commit 8fc14fd702897e652a38384af2f55e51752e8c15, as mentioned in the upstream bug report³, so I think it'd be great if this ended up backported into wheezy. Thanks, Faidon ¹: https://bugzilla.novell.com/show_bug.cgi?id=771983 ²: https://trac.macports.org/ticket/34861 ³: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3589 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683834: vim-puppet: puppet is unavailable in vim-addons (missing source files)
severity 683834 serious tags 683834 + patch thanks Hi, I'm bumping the severity to serious, since this makes the vim-puppet package unusable for me and -I guess- all users (bypassing vim-addon-manager isn't really a solution). Below you'll find a trivial but untested patch that fixes the issue -- and while at it, also adds ftplugin to the files shipped by vim-puppet. Thanks, Faidon --- a/vim-puppet.yaml +++ b/vim-puppet.yaml @@ -2,5 +2,6 @@ description: Syntax highlighting for puppet files: - ftdetect/puppet.vim + - ftplugin/puppet.vim - indent/puppet.vim - syntax/puppet.vim --- a/vim-puppet.install +++ b/vim-puppet.install @@ -1,3 +1,5 @@ debian/vim-puppet.yaml /usr/share/vim/registry ext/vim/ftdetect/puppet.vim /usr/share/vim/addons/ftdetect +ext/vim/ftplugin/puppet.vim /usr/share/vim/addons/ftplugin ext/vim/syntax/puppet.vim /usr/share/vim/addons/syntax +ext/vim/indent/puppet.vim /usr/share/vim/addons/indent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686636: Please backport virtio-scsi to wheezy
Package: linux Version: 3.2.23-1 Severity: wishlist Virtio SCSI a new driver/transport for block storage for paravirtualized systems. It replaces the older limited in many ways virtio-blk and is implemented by basically passing through SCSI over virtio. Hence devices appear as regular SCSI devices like /dev/sda instead of /dev/vda, SCSI passthrough can be easily implemented, multiple LUNs can be supported without provisioning a PCI card for each etc. http://wiki.qemu.org/Features/VirtioSCSI On the host side, virtio-scsi is supported by qemu(-kvm) = 1.1 (in wheezy) or by a kernel vhost driver for LIO which is still experimental and merged in v3.6 as a staging driver. virtio-scsi is the guest driver for supporting such devices, i.e. it's needed in a guest system configured with one or more virtio-scsi devices. It was first included in Linux v3.4 with some features/bugfixes in v3.6: 59057fb [SCSI] virtio-scsi: Add vdrv-scan for post VIRTIO_CONFIG_S_DRIVER_OK LU 365a715 [SCSI] virtio-scsi: hotplug support for virtio-scsi 2bd37f0 [SCSI] virtio-scsi: split scatterlist per target bce750b [SCSI] virtio-scsi: release sg_lock after add_buf 139fe45 [SCSI] virtio-scsi: split locking per vq b5ee8f2 [SCSI] virtio-scsi: unlock during kick e4594bb [SCSI] virtio_scsi: fix TMF use-after-free 4fe74b1 [SCSI] virtio-scsi: SCSI driver for QEMU based virtual machines (the last two are v3.4, the rest are v3.6) I believe it's important for wheezy to support being a guest in such configurations, as I expect virtio-scsi to be gradually adopted during the wheezy lifecycle. The driver is mostly self-contained and straightforward to backport (I wouldn't ask otherwise): The above commits cherry-picked against v3.2.28 result in the following: drivers/scsi/Kconfig|8 + drivers/scsi/Makefile |1 + drivers/scsi/virtio_scsi.c | 803 + drivers/virtio/virtio.c |5 +- include/linux/virtio.h |1 + include/linux/virtio_ids.h |1 + include/linux/virtio_scsi.h | 123 + 7 files changed, 941 insertions(+), 1 deletion(-) The v3.6 could be risky, considering they haven't been released yet and haven't seen much testing. If you prefer merging just v3.4's 4fe74b1/e4594bb instead, the stat is: drivers/scsi/Kconfig|8 + drivers/scsi/Makefile |1 + drivers/scsi/virtio_scsi.c | 596 + include/linux/virtio_ids.h |1 + include/linux/virtio_scsi.h | 114 +++ 5 files changed, 720 insertions(+) Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679309: supports only PCSC (regression from squeeze)
Package: opensc Version: 0.12.2-3 Severity: important opensc, until v0.12, had a feature where you could pick at runtime which reader driver you want to use (pcsc, openct, ctapi). The configuration runtime option was called reader_drivers and it was a list of drivers and their order. In v0.12.0 upstream made this into a build-time option. NEWS say: * OpenSC uses a single reader driver, specified at compile time. There was an upstream bug report in favor of doing that: http://www.opensc-project.org/opensc/ticket/216 in which they mentioned Debian several times and someone even provided unofficial packages. Apparently their plan all along was that distributions (Debian included) should build multiple variants of libopensc, one for each driver, and ship multiple conflicting library packages, for users to pick (crazy, I know). However, this obviously didn't happen in Debian -- but the runtime to build-time conversion patch was not disabled either. This means that the current Debian packages only work with PCSC and have no way of using OpenCT (or the less popular CT-API) instead. My Aladdin eToken doesn't work with PCSC (Generic read error or something) and it worked fine with squeeze OpenCT, so I consider this a regression (hence marking it as important). I guess others will be at the same position as mine. 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#669643: ITP: bugzilla4 -- web-based bug tracking system
On Thu, May 03, 2012 at 10:47:31AM -0400, Mark A. Hershberger wrote: Have you checked why bugzilla3 used to be in Debian, and got removed (see #638705). Thanks for the info. I was not aware of that. I did wonder why it wasn't being packaged. It looks like the main thing to be addressed is finding a co-maintainer. As discussed in private with Mark (he's a coworker), I will serve as his comaintainer sponsor for this package. Moreover, I'm adding the security team to the loop, since bugzilla3 was removed per their request. We know that bugzilla has had a troubled history in Debian, so we'll be careful. One area in particular that was problematic was a strained relationship with upstream (aiui, the result of having an unmaintained vulnerable package in Debian for some time); Mark has already been in some contact with them. If you still have reservations, feel free to raise them â before we upload this (soonish) would work better :) Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669427: apt segfaults on s390x
Package: apt Version: 0.9.1 Severity: serious apt 0.9.1 currently segfaults on the zelenka (our s390/s390x porterbox) sid_s390x chroot. Downgrading apt to 0.8.15.10 makes it work again. Backtrace follows, even though it probably isn't that helpful, since apt doesn't have a debugging symbols package from what I could see. For your convienience, I went on and installed apt's build-deps on sid_s390x so that you rebuild and debug. Let me know if you need anything else. Thanks, Faidon #0 0x0229f386 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) () from /usr/lib/s390x-linux-gnu/libstdc++.so.6 #1 0x020fa17a in IsDuplicateDescription(pkgCache::DescIterator, HashSumValue128 const, std::string const) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #2 0x020ff8b4 in pkgCacheGenerator::MergeListVersion(pkgCacheGenerator::ListParser, pkgCache::PkgIterator, std::string const, pkgCache::VerIterator*) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #3 0x02100034 in pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser, pkgCache::VerIterator*) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #4 0x021664ec in debPackagesIndex::Merge(pkgCacheGenerator, OpProgress*) const () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #5 0x020f7390 in ?? () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #6 0x020fae6a in pkgCacheGenerator::MakeStatusCache(pkgSourceList, OpProgress*, MMap**, bool) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #7 0x020ee74e in pkgCacheFile::BuildCaches(OpProgress*, bool) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #8 0x020eec02 in pkgCacheFile::Open(OpProgress*, bool) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #9 0x8001f03e in ?? () #10 0x02096b22 in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12 #11 0x8000cc4e in ?? () #12 0x023bea40 in __libc_start_main (main=optimized out, argc=optimized out, ubp_av=optimized out, init=0x80029440, fini=0x8002943c, rtld_fini=0x2010778, stack_end=0x3da2630) at libc-start.c:228 #13 0x8000cf82 in ?? () -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669427: apt segfaults on s390x
severity 669427 important thanks On Thu, Apr 19, 2012 at 09:12:09PM +0200, Mehdi Dogguy wrote: apt 0.9.1 currently segfaults on the zelenka (our s390/s390x porterbox) sid_s390x chroot. Downgrading apt to 0.8.15.10 makes it work again. Does it also segfault on s390? (s390x is not a release arch yet so it doesn't warrant an RC severity, unless the maintainer thinks so). Good point, didn't think much about that at the time, sorry. It seems to work on s390, downgrading. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666129: Please update to a newer upstream release
Package: libpam-google-authenticator Version: 20110413.68230188bdc7-1.1 Severity: wishlist Hi, I would like to have a newer version of google-authenticator in the archive; the version currently in Debian is almost a year old and several new features have been added to upstream's trunk (it's unfortunate that upstream doesn't believe in releases…). In particular, I was interested in having counter-based HOTP instead of TOTP, since the box I want to use libpam-google-authenticator in doesn't have an RTC and relying into not having network outages (for NTP) is a no-go for this. I was happy to see that upstream supports this, only to be disappointed that this isn't in Debian :-) If you're busy, I can certainly help with the upload and do an NMU, although I'm afraid I don't have the time or will to help with the maintenance in general. Thanks, and thank you for packaging google-authenticator. 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#664606: additional information
On 03/19/12 13:28, Simon Josefsson wrote: Some even further information, as I seen that others have identified the problem, see for example: http://yate.null.ro/mantis/view.php?id=295 There exists a libilbc library with a clear license here: https://github.com/dekkers/libilbc It is labeled as a drop-in replacement for the non-free code in RFC 3591. The iLBC code in RFC 3591 was freed when the company that original authored it (GIPS) was acquired by Google. See e.g. https://datatracker.ietf.org/ipr/1649/ There are multiple people who have extracted this code from the RFC and either included it as-is in their source trees or created libraries out of it. I didn't check the one you pointed at, but I'm fairly sure it'll be the exact same code. The best solution (but I'm not speaking as a maintainer, since I haven't been doing that for the VoIP team for quite some time) would be to package one of these libraries and port all the software the uses it to use that. Licensing-wise it won't make a big difference (besides a proper debian/copyright), but it'll help to reduce code duplication and security response. Best 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#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon
Carlos, On 02/13/12 17:29, Carlos Vicente wrote: Hopefully this module will stimulate development of new Route Registry tools written in Perl. An example of Route Registry tools can be found by googling for RAToolset which is now known as the IRRToolset. The RAToolset was originally developed by ISI, http://www.isi.edu/, and is now maintained by RIPE, http://www.ripe.net/. This is a really old description. IRRToolset has long moved under ISC's umbrella¹ where is dying a slow death… There's even an ITP for it (with packages prepared) but I've hesitated to upload since it seems to be abandoned upstream. Regards, Faidon ¹: http://www.isc.org/software/irrtoolset -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656218: libnss-myhostname: Package's description is outdated
Package: libnss-myhostname Version: 0.3-3 Severity: normal It seems that version 0.3 of libnss-myhostname changed its behavior and introduced an important feature: the module now first returns all locally configured public IP addresses and only if none are found it fallbacks to 127.0.0.2 (or, in Debian, 127.0.1.1). The package's long description should be updated to include that; I'm using normal as the severity and not minor, since this is a quite important change and may fool users into thinking that this need of theirs is not covered by the package. Your opinion may vary :) FWIW, the diff from upstream's README reads: - gethostname(2). A lot of software relies on that the local host name is - resolvable via DNS to an IPv4 or IPv6 address. When using dynamic - hostnames this is usually achieved by patching /etc/hosts which however - is suboptimal since it requires a writable /etc file system and is - fragile because the file might also be edited by the administrator. - nss-myhostname simply returns the IPv4 address 127.0.0.2 (wich is on - the local loopback) and the IPv6 address ::1 (which is the local host) - for whatever system hostname is configured locally. Patching - /etc/hostname is thus no longer necessary. + gethostname(2). Various software relies on an always resolvable local + host name. When using dynamic hostnames this is usually achieved by + patching /etc/hosts at the same time as changing the host name. This + however is not ideal since it requires a writable /etc file system and + is fragile because the file might be edited by the administrator at the + same time. nss-myhostname simply returns all locally configure public + IP addresses, or -- if none are configured -- the IPv4 address + 127.0.0.2 (wich is on the local loopback) and the IPv6 address ::1 + (which is the local host) for whatever system hostname is configured + locally. Patching /etc/hosts is thus no longer necessary. 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#653332: thin is unmaintained
On Mon, Dec 26, 2011 at 10:04:32PM -0800, Ryan Niebur wrote: On Tue, Dec 27, 2011 at 04:44:31AM +0200, Faidon Liambotis wrote: The package in its current version works for me. However, I believe it is unsuitable for a release (and hence inclusion in testing) as it's clearly lacking a maintainer. I'd suggest either to start working on it, or O/RFH it. okay, I will do this. Do what? I haven't seen a move to either direction. 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#653332: thin is unmaintained
Package: thin Version: 1.2.4-1.1 Severity: serious Hi, I noticed that the package thin hasn't been maintained properly. It hasn't had a maintainer upload since September 2009 when 1.2.4-1 was uploaded; during that time, upstream released 1.2.6 (Feb 2010), 1.2.7 (March 2010), 1.2.8 (February 2011) 1.3.0 (November 2011); it had an NMU (by yours truly) in January 2011 just to keep in the squeeze release; it has a bug (+patch) open to update it to newer Ruby packaging rules (#652090) with no maintainer reply. The package in its current version works for me. However, I believe it is unsuitable for a release (and hence inclusion in testing) as it's clearly lacking a maintainer. I'd suggest either to start working on it, or O/RFH it. 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#647535: cheese: Wrong colours and artefacts on image
reassign 647535 libv4lconvert0 0.8.5-5 close 647535 0.8.5-6 thanks On Mon, Nov 14, 2011 at 12:11:00PM +0100, Gregor Jasny wrote: could you please check if libv4l-0.8.5-6 fixes the issue for you and close this bug if it does so? Yes it does! Reassigning and closing, thanks for the immediate response. 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#647535: cheese: Wrong colours and artefacts on image
On Thu, Nov 03, 2011 at 04:56:19PM +, Jonathan McCrohan wrote: Cheese does not display the image from my Logitech E2500 (idVendor=046d, idProduct=089d) webcam correctly. The image is correctly displayed in other applications such as VLC, guvcview and the Google Talk Plugin. I believe the same bug has also been found in Ubuntu [1]. [1] https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/838739 I'm also experiencing this bug. One of the suggestions in the Ubuntu bug report was to try a libv4l-0 from a libv4l PPA and that indeed solved the problem for me too. I then went to compare the PPA's libv4l with the Debian one; to my surprise, the source packages were (almost) identical. After having a closer look, it seems that the Debian package (and, presumably, Ubuntu's Oneiric binaries) are built against libjpeg8, while the PPA one against libjpeg62. It seems that libv4lconvert uses libjpeg and the libjpeg62-libjpeg8 transition messed it up. I have no idea, however, if it's libjpeg8's fault or if the callers (libv4lconvert? cheese?) are misusing it, esp. since the bug seems to affect some applications and not others (like gstreamer-properties) and only at certain resolutions. Therefore, I'm just Cc'ing all the relevant maintainers and hope that you work it out :-) Best 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#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library
Hi Sam, Hope you're well. Are you planning on putting the packaging efforts for this on git somewhere (e.g. collab-maint?). If so, I'd be happy to contribute, if help is needed, either now or when the merging effort with radsecproxy starts. Best 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#630730: marked as done (linux-image-2.6.32: GSO IPv6 issues)
found 630730 linux-2.6/2.6.32-38
thanks
I've checked with -38 and the fix doesn't seem to be there (i.e. I'm
still experiencing the effects). I'm looking at the source package and
even though the patches are in debian/patches, they do not seem to be
included from a series file.
I'm also checking SVN and specifically r18053, and it seems that the
patches were moved from features/all/{e1000e,igdb} to bugfix/all, the
lines for the former were removed from series/36 but no lines were added
on series/37 or anywhere else...
Best 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#327585: [Pkg-openldap-devel] Bug#327585: slapd: perl backend failed to load XS (unknown symbols)
On Mon, Oct 17, 2011 at 05:37:17PM -0700, Steve Langasek wrote: As Russ has said earlier in the bug thread, the *right* fix is to fix perl on i386 so that everything is linked against libperl. All other solutions are workarounds, not fixes. As *you* :) pointed out later (#60) in the bug thread —and I can confirm— this is not i386-specific. Perl XS modules are not linked against libperl in other arches as well, at least amd64. The patch proposed in message #139 carries side effects, because it will cause openldap to open all modules with RTLD_GLOBAL. This increases the risk of a symbol collision causing openldap to crash (the precise issue that libltdl was switched to RTLD_LOCAL to avoid), and even if that doesn't result in a bug now, it might do so in the future. So I'm not thrilled about this patch. Ouch. No chance into getting this to spu then… But it seems to be the best we can do short of the perl fix, on which there's been no movement. So I'll go ahead and apply this patch. Thanks for the effort! Best 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#327585: slapd: perl backend failed to load XS (unknown symbols)
On Sun, Jan 09, 2011 at 05:36:46AM +0200, Faidon Liambotis wrote: Everything but trivial perl scripts fail using slapd's back-perl, probably for the reasons stated in this bug. If I were opening the bug, I'd surely use a much more severe severity, but since the maintainers have commented and haven't done that, I'll refrain from doing so. The symptoms are the same and LD_PRELOADing libperl fixes the problem. However, this is on amd64 (and perl links to libperl) so, if I understood correctly, this contradicts Russ' analysis. Any reason not to apply the patch from #139 which allegedly fixes the issue? Ping? 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#644212: linux-image-2.6.32-5-amd64: kernel BUG at kernel/exit.c:1035: invalid opcode: 0000
On Tue, Oct 04, 2011 at 03:29:50AM +0100, Ben Hutchings wrote: On Tue, 2011-10-04 at 03:51 +0300, Faidon Liambotis wrote: Package: linux-2.6 Version: 2.6.32-35 Severity: normal The stack trace can be seen below; if it matters, note that the machine a) is running under KVM, b) has relatively high CPU I/O load c) it's the first time it has BUGed, although it has been running with 2.6.32 since April and with 2.6.32-35 since early August. [...] Well this is pretty damn weird. This BUG message means that the scheduler reselected a task to run after it exited (i.e. it was a zombie). I can't find any related bug reports or fixes. I'm afraid we are unlikely to be able to progress this unless it is reproducible. Yeah, I figured it was weird... I don't think I'll be able to reproduce this, it wasn't even triggered by user action (the process that crashed it is a daemon) — and as I said, it's the first time it's being doing this in quite a while. If you have any ideas on how to reproduce it or get more info, I'm all ears :-) The machine is, surprisingly, still up and running although I'll have to reboot it (just to be safe) soon. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644212: linux-image-2.6.32-5-amd64: kernel BUG at kernel/exit.c:1035: invalid opcode: 0000
Package: linux-2.6 Version: 2.6.32-35 Severity: normal The stack trace can be seen below; if it matters, note that the machine a) is running under KVM, b) has relatively high CPU I/O load c) it's the first time it has BUGed, although it has been running with 2.6.32 since April and with 2.6.32-35 since early August. Thanks, Faidon -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011 ** Command line: root=/dev/vda1 ro rootflags=data=writeback ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [0.751641] alloc irq_desc for 28 on node -1 [0.751643] alloc kstat_irqs on node -1 [0.751729] virtio-pci :00:04.0: irq 28 for MSI/MSI-X [0.752803] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.753517] vda: vda1 vda2 [0.754483] uhci_hcd: USB Universal Host Controller Interface driver [0.755860] uhci_hcd :00:01.2: PCI INT D - Link[LNKD] - GSI 10 (level, high) - IRQ 10 [0.757165] uhci_hcd :00:01.2: setting latency timer to 64 [0.757179] uhci_hcd :00:01.2: UHCI Host Controller [0.757848] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [0.759001] uhci_hcd :00:01.2: irq 10, io base 0xc020 [0.759766] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [0.760578] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.761610] usb usb1: Product: UHCI Host Controller [0.762233] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 uhci_hcd [0.762898] usb usb1: SerialNumber: :00:01.2 [0.763658] usb usb1: configuration #1 chosen from 1 choice [0.764460] hub 1-0:1.0: USB hub found [0.765041] hub 1-0:1.0: 2 ports detected [0.916627] ata2.01: NODEV after polling detection [0.917011] ata2.00: ATAPI: QEMU DVD-ROM, 0.12.5, max UDMA/100 [0.918368] ata2.00: configured for MWDMA2 [0.919950] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 0.12 PQ: 0 ANSI: 5 [0.933123] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray [0.933745] Uniform CD-ROM driver Revision: 3.20 [0.934503] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.939428] sr 1:0:0:0: Attached scsi generic sg0 type 5 [1.076048] usb 1-1: new full speed USB device using uhci_hcd and address 2 [1.256318] kjournald starting. Commit interval 5 seconds [1.256403] EXT3-fs: mounted filesystem with writeback data mode. [1.454962] usb 1-1: New USB device found, idVendor=0627, idProduct=0001 [1.49] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.456141] usb 1-1: Product: QEMU USB Tablet [1.456642] usb 1-1: Manufacturer: QEMU 0.12.5 [1.457125] usb 1-1: SerialNumber: 1 [1.457714] usb 1-1: configuration #1 chosen from 1 choice [2.217844] udev[363]: starting version 164 [2.433325] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [2.437711] ACPI: Power Button [PWRF] [2.473528] processor LNXCPU:00: registered as cooling_device0 [2.475711] processor LNXCPU:01: registered as cooling_device1 [2.480173] processor LNXCPU:02: registered as cooling_device2 [2.481195] processor LNXCPU:03: registered as cooling_device3 [2.482051] processor LNXCPU:04: registered as cooling_device4 [2.482870] processor LNXCPU:05: registered as cooling_device5 [2.547790] piix4_smbus :00:01.3: SMBus Host Controller at 0xb100, revision 0 [2.789415] input: PC Speaker as /devices/platform/pcspkr/input/input3 [2.819982] parport_pc 00:05: reported by Plug and Play ACPI [2.820917] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [2.825668] usbcore: registered new interface driver hiddev [2.848259] input: QEMU 0.12.5 QEMU USB Tablet as /devices/pci:00/:00:01.2/usb1/1-1/1-1:1.0/input/input4 [2.849733] generic-usb 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU 0.12.5 QEMU USB Tablet] on usb-:00:01.2-1/input0 [2.850898] usbcore: registered new interface driver usbhid [2.851578] usbhid: v2.6:USB HID core driver [2.934005] Error: Driver 'pcspkr' is already registered, aborting... [3.143200] Adding 524280k swap on /dev/vda2. Priority:-1 extents:1 across:524280k [3.262849] EXT3 FS on vda1, internal journal [3.265337] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5 [5.316689] ip_tables: (C) 2000-2006 Netfilter Core Team [5.398364] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [5.399658] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [5.400773] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or [5.437435] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. [5.474827] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 14.745708] eth0: no IPv6 routers present [ 1110.094839] hrtimer:
Bug#629067: libactionpack-ruby: libactionpack update breaks redmine
reassign 629067 libactionpack-ruby found 629067 rails/2.3.5-1.2+squeeze0.1 severity 629067 grave thanks On Fri, Jun 03, 2011 at 12:26:27PM +0200, Vincent-Xavier JUMEL wrote: Package: libactionpack-ruby Version: 2.3.5-1.2+squeeze0.1 Severity: normal libactionpack update breaks redmine user view if hide_mail is not enabled. Redmine renderer fails on an inexistant html_safe method Workaround : change user preference to hidden mail psql update user_preference set hide_mail = 't' where hide_mail = 'f' ; This was reassigned to ruby-actionpack-2.3 (present only in wheezy+) but it's not really obvious why — no explanative mail was sent to the BTS and the bug report remains unanswered. If it affects another package in wheezy, then it should probably be cloned/reassigned instead. I'm reassigning it back and changing this severity: this was a security update that broke an unrelated package (redmine) *in stable*. This is /not/ acceptable according to the security team's guidelines. You could say that either the fix should be adapted or that the call sites (redmine) should be fixed. I'd vote for the first, though, since we can't really know what else has been broken by this change (in the archive, let alone user-installed applications...) In any case, I'm adding redmine maintainers the security team to the Cc in case they have something useful to add. 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#630730: linux-image-2.6.32: GSO IPv6 issues
On Fri, Aug 26, 2011 at 01:10:25AM +0300, Faidon Liambotis wrote: After talking with Ben on IRC, I've prepared and sent a -longterm tree submission for the two commits. I'll update the bug report when I get a reply. I just got a reply that the patches were accepted to the stable review queue. 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#639855: snoopy: Some package history has been lost
Package: snoopy Version: 1.8.0-2 Severity: important It seems that during the handoff the new maintainer, something weird happened regarding the package's history. More specifically, debian/changelog lists version 1.8.0-1 with the previous changelog entry being 1.3-13. However, lenny included 1.3-15, with -14, -14.1 and -15 including various fixes, some of them being re-done in 1.8.0-1 (like the removal of linda overrides). What's worse, though, is that most were not, resulting in having the current version missing various fixes, mostly translations (a *lot* of them). What's *even* worse, is that someone did the Russian translation back then (#488133), it was uploaded with -14.1, was dropped with the handoff and someone did it *again*, from scratch, for the latest version (#637754), wasting the efforts of the translators. You can also see the effects of this on the BTS' graphs where you can easily see the fork to the two versions and how bugs are still open on the current version, although resolved/archived. 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#638976: ITP: python-gitdb -- a pure-Python git object database
On 08/23/11 15:56, Marco Túlio Gontijo Silva wrote: Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: python-gitdb Version : 0.5.4 Upstream Author : Sebastian Thiel byron...@gmail.com * URL : http://github.com/gitpython-developers/gitdb * License : BSD Programming Lang: Python Description : a pure-Python git object database The project's website says: “IO of git-style object databases - Phased out and merged into GitPython” And it seems GitPython is already in the archive as python-git. I'd be also curious to see how these compare to dulwich. 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#630730: linux-image-2.6.32: GSO IPv6 issues
forwarded 630730 sta...@kernel.org thanks On Thu, Jul 28, 2011 at 04:48:58PM +0200, Faidon Liambotis wrote: What's the status of this? Have the patches been forwarded to -longterm maintainers? (is that Greg KH?); if not, I'd be happy to do it for you. After talking with Ben on IRC, I've prepared and sent a -longterm tree submission for the two commits. I'll update the bug report when I get a reply. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596488: insserv: unbound should be added to $named
unarchive 596488 found 596488 1.4.6-1 submitter 596488 debian-ad...@lists.debian.org thanks Hi, This bug also affects squeeze and in fact we, DSA, were bitten by this on the Debian infrastructure. We run unbound as a local resolver on most hosts and this bug, combined with the parallel dependency-based booting results in some difficult to debug problems during reboots, e.g. by starting Apache2/mod_perl before the resolver. We believe that the (one-line) fix should be backported to a stable point release. Release team members seemed to agree after briefly discussing it with them in person but you should probably also check with them. Best 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#630730: linux-image-2.6.32: GSO IPv6 issues
On Tue, Jun 21, 2011 at 08:32:04PM -0700, David Miller wrote: From: Ben Hutchings b...@decadent.org.uk Date: Wed, 22 Jun 2011 04:20:13 +0100 David, these look like good candidates for longterm updates. What do you think? Sure but I don't do submissions for the longterm stuff, I only work on the -stable trees that Greg is actively maintaining. What's the status of this? Have the patches been forwarded to -longterm maintainers? (is that Greg KH?); if not, I'd be happy to do it for you. Best 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#591329: host objects: ignore ipv6 addresses in ipv4 context and vice versa
Martin, On Mon, Aug 02, 2010 at 10:31:06AM +0200, martin f krafft wrote: All of my hosts are IPv4 and IPv6 connected. Hence, every host has at least one address in each of the (ip ip6) domains. I'd really like to be able to think about a host as a single entity and thus would love to see the concept of host objects in ferm. In general, however, a host object needs not be more than a variable: @def $MYHOST = (77.109.139.85 2001:1620:2018:2::4d6d:8b55); Unfortunately, this does not work: daddr $MYHOST ACCEPT; causes the following rules to be created in both (ip ip6) domains: -A in-new --destination 77.109.139.85 --jump ACCEPT -A in-new --destination 2001:1620:2018:2::4d6d:8b55 --jump ACCEPT I am thinking that all that is needed is a simple domain-specific regexp to filter only the applicable addresses when expanding variable arrays in an address context. Unfortunately, I couldn't figure out where this is happening in 15 minutes of studying the code. I raised the same issue on the mailing list (unaware of your bug report!), see the thread starting from: http://foo-projects.org/pipermail/ferm/2011-July/59.html Max implemented *two* solutions to the problem that are now on ferm's git. Have a look at the implementation there to see if that satisfies your use case. 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#591229: modify reject-with arguments in ip6 domain
On Sun, Aug 01, 2010 at 01:22:19PM +0200, martin f krafft wrote: A line like REJECT reject-with icmp-port-unreachable; should be expanded to --jump REJECT --reject-with icmp6-port-unreachable to work with ip6tables. I know this is silly netfilter crap, but it would be nice and convenient for the user if you did a s/icmp-/icmp6-/ in the ip6 domain on reject-with arguments. Unaware of this bug report as well (silly that I am), I implemented the above (a bit differently) and submitted it to ferm's mailing list: http://foo-projects.org/pipermail/ferm/2011-July/74.html (hasn't been merged yet) 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#591230: late evaluation of variables
On Sun, Aug 01, 2010 at 01:23:43PM +0200, martin f krafft wrote: I cannot use @if @eq($DOMAIN, ip6) because variables are evaluated when ferm parses the file, not when it actually diverts into the domains. Hence it would be better if some (all) variables were evaluated on use, not during parsing. This has been fixed in upstream commit 729e3ed18bd07b313eaa7d7884fb75f8423747e2, individual evaluation of rules for each domain. (not yet in a release) It has been done as one of the approaches for solving issues like the one you described here with #591329. 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#577701: ferm: what does %TRUSTED_HOSTS mean?
On Tue, Apr 13, 2010 at 08:26:10PM +0200, Marc Haber wrote: the manpage, in the chapter Parameters, there is mention of %TRUSTED_HOSTS. This is either undocumented (% doesn't appear in any other place in the manpage), or a typo, meaning $TRUSTED_HOSTS. It's the latter; fixed by yours truly and merged upstream, commit 27be17ec7a6abc96b83855b08fe539405d635124. 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#526350: celery ITP: ping?
Ping? Any progress on this? I'm also interested. It seems that there has been progress on SVN; last commit, however, was over 3 months ago. I can assist in reviewing and sponsoring the package, if needed. 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#580972: multipath-tools: unnecessary call to multipath in /etc/udev/rules.d/z60_multipath.rules
On Mon, May 10, 2010 at 06:08:56PM +0200, Guido Günther wrote: Hi Apollon, On Mon, May 10, 2010 at 12:57:07PM +0300, Apollon Oikonomopoulos wrote: Multipathd itself has uevent support, which is what the first rule is used for. However, the second rule is redundant and useful only in the case of block devices showing up during boot, between /etc/init.d/multipath-tools-boot and /etc/init.d/multipath-tools. Furthermore, it causes major system load whenever a bulk of new LUNs are added to a running system. In our case, adding 10 LUNs with 8 paths each causes the system load to rocket to 70-80 for 25s, while 80 multipath processes are racing to coallesce the multipaths. Disabling the second rule causes the whole process to finish in less than 2 seconds while multipathd itself handles the uevents generated by the kernel. It should be noted that upstream do not include the second rule in their sample rulefile[1]. Thus, the second rule should be removed or at least check whether multipathd is running before executing /sbin/multipath. This is also necessary for the initramfs since we don't run multipathd there. Testing if multipathd is runnning looks like a good option though. It'd be even nicer if we could only run that rule if the former one fails. Ping? From experience, this is quite a serious issue on large multipath setups, the problem being in a Debian-specific modification that can easily be fixed. 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#580972: multipath-tools: unnecessary call to multipath in /etc/udev/rules.d/z60_multipath.rules
Ritesh, On Mon, May 02, 2011 at 04:09:19AM +0530, Ritesh Raj Sarraf wrote: I've recently taken up multipath maintenance from Guido. I noticed, hence the ping :) I totally agree with the large number of LUNs rescan issue. It will bring your machine down immediately. What I'd like you to confirm is is if this issue is seen on squeeze/sid? The bug report is against the version in lenny where I'm not sure what adverse effects this change could bring. Workaround for lenny could be to simply comment that rule. If you see this problem with sid, please confirm on this bug report. I'd like to fix this. Meanwhile I'll see if I can reproduce this issue in my sid setup. The udev rules that calls /sbin/multipath *in addition* to notifying multipathd via uevent is still there, so yes, I confirm that the issue persists. 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#573551: affects squeeze, package has only been updated in testing
On Wed, Mar 23, 2011 at 09:26:41PM -0400, micah anderson wrote: The proposed fix is similar to what you and Faidon have suggested, along with some tests. Unless someone screams really soon, this is going to be the upstream change, so take a second and have a look: https://github.com/MaxMartin/puppet/commit/be5c00cc9687e73dad15455f8429f0c2ab5667e5 That patch seems to only fix disable, no? Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
