Bug#963594: ITP: golang-github-jsimonetti-rtnetlink -- low-level access to the Linux rtnetlink API
Hi Benjamin, sorry for not answering your pings before! Thanks for taking this on! It was indeed a bit stalled on my side :( Cheers, Leo On Tue, Jan 11, 2022 at 2:23 PM Benjamin Drung wrote: > > Hi, > > On Wed, 24 Jun 2020 09:49:04 +0200 "Leo Antunes" > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Leo Antunes > > Control: block 963592 by -1 > > > > * Package name: golang-github-jsimonetti-rtnetlink > > Version : 0.0~git20200505.3ee32e7-1 > > Upstream Author : Jeroen Simonetti > > * URL : https://github.com/jsimonetti/rtnetlink > > * License : Expat > > Programming Lang: Go > > Description : Package rtnetlink provides low-level access to > the Linux rtnetlink API. > > > > Package rtnetlink allows the kernel's routing tables to be read and > > altered. Network routes, IP addresses, Link parameters, Neighbor > setups, > > Queueing disciplines, Traffic classes and Packet classifiers may all > be > > controlled. It is based on netlink messages. > > . > > A convenient, high-level API wrapper is available using package rtnl > > (https://godoc.org/github.com/jsimonetti/rtnetlink/rtnl). > > . > > The base rtnetlink library explicitly only exposes a limited low- > level > > API to rtnetlink. It is not the intention (nor wish) to create an > > iproute2 replacement. > > Since there were no progress on this ticket, I just high-jacked it (to > be able to drop the vendored libs in prometheus-node-exporter). > rtnetlink is uploaded to the NEW queue and published on > https://salsa.debian.org/go-team/packages/golang-github-jsimonetti-rtnetlink > Please add yourself to the Uploaders. > > -- > Benjamin Drung > > Senior DevOps Engineer and Debian & Ubuntu Developer > Compute Platform Operations Cloud > > IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland > E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 > > Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning > Kettler, Arthur Mai, Britta Schmidt, Achim Weiß > Aufsichtsratsvorsitzender: Markus Kadelke > > > Member of United Internet >
Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40
On Tue, Sep 28, 2021 at 12:27 AM Samuel Henrique wrote: > I gave you permission to that repo (best I can do on my side), and I > set an expiration date of the end of this year, until then you will > end up in the salsa group and inherit permissions so it should be > good. Perfect, thanks! > Awesome, I can do that. Alternatively, I can also push your changes > myself, if you push them to your own repo and give me a go ahead. Just pushed to the main repo. Please take a look and let me know if it works! Cheers
Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40
On Fri, Sep 24, 2021 at 10:07 PM Samuel Henrique wrote: > Leo, from my side you're free to push your changes whenever you want. I will as soon as someone gives me access to the repo ;) Just requested access to the Gnome group, but that may take a while. > Let's try to coordinate things, feel free to perform changes to the > packaging, I will wait until I get your ack to go ahead (if there's > any work left to be done). I'm not a gnome-extension expert, so I'll push my changes so that the package is at least gpb-buildable, and you can then maybe check that the build makes sense and upload it yourself if you want. Cheers Leo
Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40
On Tue, 21 Sep 2021 19:57:39 +0100 Samuel Henrique wrote: > Awesome, I was trying to add the upstream and pristine-tar branches to > the repo but it's not looking good so far. I think I managed to convert it to a gbp project successfully. Take a look here: https://salsa.debian.org/costela/gnome-shell-extension-system-monitor Basic steps (in a freshly cloned salsa repo): git checkout --orphan upstream git rm -rf . git commit --allow-empty -m 'initial upstream commit' git checkout -f master gbp import-orig ../ gbp dch Both upstream and pristine-tar branches look clean (do not branch from master) and we can keep the repo's history. Jonathan, Samual, does that seem ok to you? Unfortunately the branch-creation involved in the process can't really be proposed via MR, so if this seems ok, one of us would have to "just do it" ;) Cheers, Leo
Bug#981153: [Pkg-rust-maintainers] Bug#981153: cargo: Please package new upstream (blocks Firefox 85)
On Fri, 5 Feb 2021 17:17:25 +0100 Geert Stappers wrote: > Where can I find more information about "relax-cargo-deb.patch"? > I did get the clue 'ubuntu', can I get a deep link? Here you go: https://bazaar.launchpad.net/~mozillateam/firefox/firefox.groovy/view/head:/debian/patches/relax-cargo-dep.patch Cheers, Leo
Bug#945158: if laptop lid is closed during suspend, gdm session is reset upon resume (NVIDIA?)
Hi, I've been seeing the same behavior for the past few weeks (months?), but didn't get around to debugging it. Symptoms match pretty exactly: closing the lid leads to a logout (session crash?); suspending via power button does not. Superficially, this seems considerably more likely to be related to gdm/gnome-screensaver/gnome-session than to systemd. Just installed a new system, restored a few user config files from backup (including ~/.config/dconf) and the issue popped up again. My suggestion would be to reopen and reassign this to a gnome package, so we can keep digging. BTW: my setup is a pretty vanilla wayland gnome session on an intel card. Cheers, Leo
Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files
Hi Paul, On Sun, Dec 15, 2019 at 5:44 AM Paul Wise wrote: > We started using libpst at work and I just got approval to adopt the > package. I'll start by adding myself to uploaders and committing some > packaging updates to the Debian git repository. Are you OK with me > adopting the package and do you want to co-maintain the package? I'd be very glad to finally hand this over to someone with the time this little package deserves! Feel free to just take it over completely. If and when the occasion presents itself, I'm sure we'll find a quick way for me to start helping again. Cheers, Leo
Bug#933820: WIP
Hi Lee, Unfortunately this stalled a bit since my request to join the DMPT[0] apparently went under the radar. I'll ping the lists and see if I can get the ball rolling again. Cheers, Leo [0] https://lists.debian.org/debian-python/2019/08/msg00152.html On Sun, Dec 8, 2019 at 4:03 PM Lee Garrett wrote: > > Hi Leo! > > On Sun, 4 Aug 2019 03:41:05 +0200 "Leo \"Costela\" Antunes" > wrote: > > FYI, some WIP is on: https://salsa.debian.org/costela/hcloud-python > > This will hopefully be moved to the python-modules group eventually. > > > > Cheers > > is there any progress on the ITP of python3-hcloud? It sounds like a > useful package to me. :) > > Greetings, > Lee
Bug#933820: WIP
FYI, some WIP is on: https://salsa.debian.org/costela/hcloud-python This will hopefully be moved to the python-modules group eventually. Cheers
Bug#907501: Acknowledgement (ITP: golang-docker-go-docker -- official go SDK for docker)
FYI: the current version doesn't build because it relies on unreleased code in golang-github-docker-distribution-dev. WIP can be found here: https://salsa.debian.org/costela/golang-docker-go-docker On Tue, Aug 28, 2018 at 10:00 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 907501: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-de...@lists.debian.org > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > w...@debian.org > > If you wish to submit further information on this problem, please > send it to 907...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 907501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#731534: RFP: chapel -- imperative programming language with focus on parallelism
Package: wnpp Severity: wishlist * Package name: chapel Version : 1.8.0 Upstream Author : Cray Inc. * URL : http://chapel.cray.com * License : BSD Programming Lang: C Description : imperative programming language with focus on parallelism Chapel is an emerging parallel programming language whose design goal is to make parallel programming more productive, from high-end supercomputers to commodity clusters and multicore desktops and laptops. . Chapel supports a multithreaded execution model via high-level abstractions for data parallelism, task parallelism, concurrency, and nested parallelism. . Chapel supports global-view data aggregates with user-defined implementations, permitting operations on distributed data structures to be expressed in a natural manner. In contrast to many previous higher-level parallel languages, Chapel is designed around a multiresolution philosophy, permitting users to initially write very abstract code and then incrementally add more detail until they are as close to the machine as their needs require. Chapel supports code reuse and rapid prototyping via object-oriented design, type inference, and features for generic programming. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726624: gnome-shell: notifications not working
Package: gnome-shell Version: 3.8.4-4 Severity: important Dear Maintainer, Notifications seem not to be working, and testing them with notify-send (from libnotify-bin) causes the following JS error in .xsession-errors: - JS ERROR: !!! Exception was: Error: Wrong type object; string expected JS ERROR: !!! message = 'Wrong type object; string expected' JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/ui/messageTray.js' JS ERROR: !!! lineNumber = '1348' JS ERROR: !!! stack = '([object Object])@/usr/share/gnome-shell/js/ui/messageTray.js:1348 wrapper([object Object])@/usr/share/gjs-1.0/lang.js:213 ([object Object])@/usr/share/gjs-1.0/lang.js:154 ([object Object])@/usr/share/gjs-1.0/lang.js:248 ([object Object])@/usr/share/gnome-shell/js/ui/messageTray.js:1886 wrapper([object Object])@/usr/share/gjs-1.0/lang.js:213 ([object Object],[object Object])@/usr/share/gnome-shell/js/ui/messageTray.js:1983 wrapper([object Object],[object Object])@/usr/share/gjs-1.0/lang.js:213 ([object Object])@/usr/share/gnome-shell/js/ui/messageTray.js:1880 wrapper([object Object])@/usr/share/gjs-1.0/lang.js:213 ([object Array],17582,[object Object],:1.55,null)@/usr/share/gnome-shell/js/ui/notificationDaemon.js:349 wrapper([object Array],17582,[object Object],:1.55,null)@/usr/share/gjs-1.0/lang.js:213 ([object Array],null)@/usr/share/gnome-shell/js/ui/notificationDaemon.js:451 ([object GObject_Object],[object GObject_Object])@/usr/share/gjs-1.0/overrides/Gio.js:91 ' - This also affects other programms sending notifications, like rhythmbox, which locks up when trying to notify. Cheers -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.16.1-1 ii evolution-data-server3.8.5-2 ii gdm3 3.8.4-2 ii gir1.2-accountsservice-1.0 0.6.34-2 ii gir1.2-caribou-1.0 0.4.12-1 ii gir1.2-clutter-1.0 1.14.4-3 ii gir1.2-freedesktop 1.36.0-2+b1 ii gir1.2-gcr-3 3.8.2-4 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.36.0-2+b1 ii gir1.2-gmenu-3.0 3.8.0-2 ii gir1.2-gnomebluetooth-1.03.8.1-2 ii gir1.2-gnomedesktop-3.0 3.8.4-2 ii gir1.2-gtk-3.0 3.8.5-1 ii gir1.2-ibus-1.0 1.5.3-7 ii gir1.2-mutter-3.03.8.4-2 ii gir1.2-networkmanager-1.00.9.8.0-5 ii gir1.2-nmgtk-1.0 0.9.8.4-1 ii gir1.2-pango-1.0 1.32.5-5+b1 ii gir1.2-polkit-1.00.105-4 ii gir1.2-soup-2.4 2.42.2-6 ii gir1.2-telepathyglib-0.120.22.0-1 ii gir1.2-telepathylogger-0.2 0.8.0-2 ii gir1.2-upowerglib-1.00.9.22-1 ii gjs 1.36.1-2 ii gnome-bluetooth 3.8.1-2 ii gnome-icon-theme-symbolic3.8.2.2-2 ii gnome-settings-daemon3.8.5-2 ii gnome-shell-common 3.8.4-4 ii gnome-themes-standard3.8.4-1 ii gsettings-desktop-schemas3.8.2-2 ii libatk-bridge2.0-0 2.10.0-1 ii libatk1.0-0 2.10.0-2 ii libc62.17-93 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcamel-1.2-43 3.8.5-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libclutter-1.0-0 1.14.4-3 ii libcogl-pango12 1.14.0-3 ii libcogl121.14.0-3 ii libcroco30.6.8-2 ii libdbus-1-3 1.6.16-1 ii libdbus-glib-1-2 0.100.2-1 ii libecal-1.2-15 3.8.5-2 ii libedataserver-1.2-173.8.5-2 ii libegl1-mesa [libegl1-x11] 9.1.7-1 ii libgck-1-0 3.8.2-4 ii libgcr-base-3-1 3.8.2-4 ii libgdk-pixbuf2.0-0 2.28.2-1 ii
Bug#722930: #722930: gdm3: Greeter does not start in gdm3 3.8
[cross-posting to #724731 - didn't want to take the liberty of merging them, though they do look awfully similar] I think I might have made some progress: In libgjs0c's version in sid, at /usr/share/gjs-1.0/overrides/GLib.js, line 199, there is the following snippet: // g_variant_get_string has length as out argument return variant.get_string()[0]; However the sid version of glib has different semantics for that function [0]. The version of libgjs0c in experimental correctly removes the [0] and seems to avoid the issue. So changing libgjs0c's dependencies to more strictly match glib's version should solve the first part of the problem. Nevertheless, in my case this still wasn't the whole issue, as now gnome-shell seems to start (calendar and the system menu are showing), but still no sign of the greeter. But this may of course be a different issue. I'll keep looking after some long overdue sleep... ;) Cheers [0] https://developer.gnome.org/glib/2.36/glib-GVariant.html -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715483: incron: permission check too naive: doesn't work with ACLs
Package: incron Version: 0.5.10-1 Severity: normal Dear Maintainer, incron's UserTable::MayAccess is too naive and reinvents the wheel when checking permissions on a watched dir. Since it only manually checks for uid/gid matching, it silently ignores folders that can actually be accessed according to the set ACLs (thought it does warn about access denied while reloading the incrontab). For instance, the current handling of /media is done with per-user subdirs which all belong to root:root, but get ACLs set appropriately for the actual intended owner. This means incrontabs handling removable media don't work. I'm not sure why /media gets handled like this, but I hope you agree incron's inability to deal with ACLs is a problem regardless of this particular case's merits. Cheers -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages incron depends on: ii adduser 3.113+nmu3 ii libc6 2.17-7 ii libgcc1 1:4.8.1-5 ii libstdc++6 4.8.1-5 ii lsb-base4.1+Debian12 incron recommends no packages. incron suggests no packages. -- Configuration Files: /etc/incron.allow [Errno 13] Permission denied: u'/etc/incron.allow' /etc/incron.deny [Errno 13] Permission denied: u'/etc/incron.deny' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704895: transmission: doesn't open magnet links when clicked in iceweasel
Hi,
On 07/04/13 12:49, bruno wrote:
when I click on magnet links in iceweasel, they don't get opened in
transmission; iceweasel says there's no protocol associated with that
kind of link. I checked transmission's trac, and it says that since
version 1.80 it should set the appropriate gnome preferences [1].
I checked my preferences with
gconf -R /desktop/gnome/url-hanlders/magnet
and nothing was set. I set them by hand and now it works. I suppose
debian's transmission doesn't do the right thing when it gets launched.
This is a bit weird. The version of Iceweasel in Wheezy should be able
to fetch handlers from GIO (AFAIU the code). Could you please compile
and run the attached little test program?
$ gcc `pkg-config --cflags --libs gio-unix-2.0 gconf-2.0` -o
test_handlers test_handlers.c
$ ./test_handlers magnet
Could you also please make a few tests with other protocol handlers? For
instance: vnc if you have vinagre installed, or ghelp if you have yelp,
or one of the many media protocols supported by totem. It should only be
a matter of typing in the protocol in the addressbar with a random
non-existent address, just to check if iceweasel starts the responsible
program (and if you manage to do this, please also note the output of
./test_handlers for the tested protocols).
I'll upload a new version to unstable with the GConf info as well, just
as a stopgap measure, but I believe this problem should be looked into a
bit further, since AFAICT Iceweasel shouldn't need the GConf info to
handle protocols.
[1] https://trac.transmissionbt.com/wiki/MagnetLinks
This page mentions transmission 1.80. Back then I believe there was no
GIO support in iceweasel, so the suggested solution was indeed the only
option. However, I don't think this is the case for the versions in
wheezy or newer (but I'm of course open to corrections from anyone more
familiar with iceweasel's code).
Cheers
--
Leo costela Antunes
[insert a witty retort here]
#include stdio.h
#include gconf/gconf.h
#include gconf/gconf-client.h
#include gio/gdesktopappinfo.h
int main(int argc, char *argv[]){
if(argc 2){
printf(must specify protocol as first argument\n);
return 1;
}
GAppInfo *app_info = g_app_info_get_default_for_uri_scheme(argv[1]);
if(app_info == NULL){
printf(no GIO handler found!\n);
} else {
printf(GIO handler: %s\n, g_app_info_get_commandline(app_info));
}
GConfClient *mClient = gconf_client_get_default();
GError *err = NULL;
char key[100];
sprintf(key, /desktop/gnome/url-handlers/%s/command, argv[1]);
gchar* gconf_handler = gconf_client_get_string(mClient, key, err);
if(err || !gconf_handler){
printf(no GConf handler found!\n);
} else {
printf(GConf handler: %s\n, gconf_handler);
}
return 0;
}
Bug#687022: found also with libm4ri
Hi, On 07/01/13 16:32, Niels Thykier wrote: This missing + in the regex has been fixed in Lintian 2.5.11 (experimental)[1]; though my question remains if we should really re-order those regexes. I believe you are right. The idea is to find a link with either of the two formats: libwhatever.so - libwhatever-X.so libwhatever.so - libwhatever.so.X So the two regexes really should be mutually exclusive. However, our package (libevent) actually does the following: libevent.so - libevent-2.0.so.2.0.21 My question is: is this worth inclusion in lintian as an acceptable format, or should I just add an override and be done with it? FWIW, after a cursory look at the list of tagged packages, there are at least a couple of other libs using the same format (libdirectfb, libnet6, probably others). Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703658: binwalk: doesn't clean up legacy config files
Hi, On 21/03/13 23:48, Christoph Anton Mitterer wrote: In some version the config files in /etc/binwalk were dropped, but not automatically removed. The directory itself was subsequentally also left over on a purge. The problem was the rewrite in python, which moved everything into the pyshared directory. I intend on fixing this for the upload of 1.1, but I unfortunately can't commit to a timeframe. Upstream is very receptive of patches and would probably accept a suggestion to move these back into /etc, so if anyone wants to step up before I get around to it, feel free to send patches upstream! Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636372: transmission: diff for NMU version 2.03-2.1
On 29/01/13 23:44, Laurent Bigonville wrote: But you are correct, some changes from the 2 NMU (mbiebl one and mine) have disappeared. Leo: Any reasons the changes regarding the build-dependencies (zlib and libcurl) have been dropped? Nope, it just went totally under the radar since the bugs got closed with the NMUs, even if they never made it to the archive. I'm preparing an upload now to remedy that. Thanks for the work and the heads-up! Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#700234: CVE request: Transmission can be made to crash remotely
Hey guys, On 13/02/13 08:51, Salvatore Bonaccorso wrote: A CVE was assigned to this now: CVE-2012-6129. Thanks for all the work! I'm unfortunately seriously swamped at least until next Wednesday and would really appreciate an NMU (and if it's not asking too much, that the NMU changes be committed to the collab-maint repo) Thanks again and sorry for the uselessness! :/ Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491723: StatusNet package upload?
[taking Andreas out of the loop, hope this is fine] Hi, On 28/01/13 22:04, Daniel Pocock wrote: Leo, Brenda, can either of you let us know about this package? Oh man... at one point I really thought I would get this package in good shape, but after Roland's poke I merged from upstream and noticed there were a LOT of changes which made my packaging work pretty much useless, so it got put way back in the TODO list. My mistake for not updating the bug to reflect this! Please consider this package free for the taking! Evan, I notice in the bug trail you are a DD too, so maybe you would like to upload yourself if you think it is ready? If nobody else was able to, I was going to consider sponsoring it myself. As I said, the latest work in the git repo [0] is unfortunatelly very out-of-date with regards to recent changes upstream, so I don't think it can just be uploaded as-is. I imagine someone with a bit more time and dedication than myself could get it in shape in a few hours/days. Please feel free to give it a try! If pkg-xmpp is not optimal for the package, do you think it might be worthwhile forming another group for maintaining this and maybe similar packages or add-ons? IMHO a different group sounds more appropriate, but the pkg-xmpp people should probably be asked if their interested. Better some slightly-off-topic team working on it than nobody at all! ;) Cheers [0] http://anonscm.debian.org/gitweb/?p=collab-maint/statusnet.git -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666514: transmission-daemon 2.52-3 still segfaulting
Hi, On 29/01/13 13:38, Matthieu Maury wrote: Dear Maintainer, The current version (2.52-3) of the transmission-daemon, still suffer from the segfaulting described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666514#5 Could you please install transmission-dbg and provide a backtrace of the crash under gdb? Thanks! -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684687: transmission-daemon: Version 2.71
On 04/12/12 23:10, Albireo wrote: Hi, at the moment the version available in Sid is still 2.52 (Squeeze has 2.03 and Wheezy has been frozen with 2.52 too), the patch is available only in experimental. Is there any plan to release this version at least in unstable? Having it in Wheezy and the new unstable (when they'll be released) would be great, too. I find it very unlikely that such a small cosmetic patch be accepted by the release team for Wheezy (the whole 2.71 version is even less likely). As for unstable, the patch will reach it as soon as we release Wheezy, since I'd like to keep the possibility of uploading fixes for wheezy through unstable. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692615: transmission: non-free files in upstream tarball (The Software shall be used for Good, not Evil)
Hi, This has been fixed upstream by replacing JSON_parser.* with jsonsl. The solution for wheezy depends on whether the release-team accepts such a potentially disruptive change. For more info, see: https://lists.debian.org/debian-release/2012/11/msg00531.html Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690468: unblock: libpst/0.6.54-4.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libpst
The updated package fixes #687879, the policy violation of missing
/usr/share/doc/readpst directory, which was replaced by a symlink.
Debdiff output is attached.
unblock libpst/0.6.54-4.1
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root
/usr/lib/debug/.build-id/08/748e536800a6dee75025e548e1974fddee40c6.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/14/2e058929c514976724d4e444c280f5dd864763.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/14/4c2b251c5b0959b6b5999559ac2b119ad05fac.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/5f/5dbf629070ebfdf06a2576ada5f3e75fe2267f.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/a2/69abcdbd49a71e0f73066c494e4049c1aa9eaf.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/fb/1886139f0938b2e82f690b1dda25261ceda6a8.debug
Files in first .changes but not in second
-
-rw-r--r-- root/root
/usr/lib/debug/.build-id/00/cf60cabd3f9ab4f2a7430276ae496cf2d2e35e.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/26/4265c69bc7b2c3ba2ecbd7a4a5cb899aec8910.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/88/08c30ebdf40f66397f7df62134abfeee3c5eab.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/88/7ea7a1b4d45613efb7e4530774987d5b17654a.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/d5/7055aa2b69233acf3ac6056a553d5aca036451.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/ee/718078f41d822058f294e1bc5f55f6c807018f.debug
Control files of package libpst-dev: lines which differ (wdiff format)
--
Depends: libpst4 (= [-0.6.54-4)-] {+0.6.54-4.1)+}
Version: [-0.6.54-4-] {+0.6.54-4.1+}
Control files of package libpst4: lines which differ (wdiff format)
---
Version: [-0.6.54-4-] {+0.6.54-4.1+}
Control files of package libpst4-dbg: lines which differ (wdiff format)
---
Depends: libpst4 (= [-0.6.54-4),-] {+0.6.54-4.1),+} pst-utils
Version: [-0.6.54-4-] {+0.6.54-4.1+}
Control files of package pst-utils: lines which differ (wdiff format)
-
Version: [-0.6.54-4-] {+0.6.54-4.1+}
Control files of package readpst: lines which differ (wdiff format)
---
Version: [-0.6.54-4-] {+0.6.54-4.1+}
Bug#690468: unblock: libpst/0.6.54-4.1
On 14/10/12 18:53, Adam D. Barratt wrote: Already done earlier today; see #690440. Ha! Someone could have CC'd me on that! ;) Thanks anyway and sorry for the noise! Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#689095: Forces user to agree to terms of usage before running
Hi, On 29/09/12 03:43, Josh Triplett wrote: Transmission has started popping up a modal dialog on startup containing some terms of usage, with buttons for Quit and I Agree. Interesting, this went totally under my radar. Software in Debian main should not include click-through licenses or terms of usage. Please remove this dialog. While I understand this can be annoying, I don't think this goes against policy and/or the DFSG, so I'm not comfortable with differing from upstream just to deal with a one-time annoyance. Do you have any specific policy/DFSG section in mind? The only point that makes sense to me would be DFSG #7, but this seems more like a disclaimer than an additional license, so I don't believe it applies. We could try bringing this to d-legal just to be on the safe side. Feel like taking this up upstream? Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#689095: Forces user to agree to terms of usage before running
Hi, In the version of the transmission bittorrent client in wheezy there is a disclaimer popup displayed on the first run, basically telling the user your responsibility, but with an agree button which may make it look more like an additional license. My questions: 1) does this qualify as breaking point 7 of the DFSG? (or, in fact, any other point I may have overlooked). If yes, would renaming the button to something like I understand improve the situation? 2) upstream probably does this to try and shift liability. Obviously IANAL, but does this even make sense? Do we have any precedence to convince upstream to drop this annoyance on the grounds that it's useless? (and here I'm hoping it *is* useless) 3) this may be a question for -devel, but do we have a public stand on click-through disclaimers or even EULAs? Somewhere we could point upstream for the pros/cons/consequences of such things? Thanks! -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#689095: [debian-policy] Prohibit click-through licenses or disclaimers
Hey, Josh, next time please keep me CC on such emails to avoid uncoordinated work. I hadn't seen this and also wrote -legal for insight (and CCd you), which might be a bit redundant. On 15/10/12 00:23, Jonathan Nieder wrote: I think we can justify this under the grounds that if a large portion of the archive starts to imitate this feature of Transmission then it would lead to a poor user experience. Playing devil's advocate for a bit, I don't think there are that many packages dealing with such touchy subjects as peer-to-peer file transfer, where we see governments budging to lobbyists and blaming basically everyone involved, including software. That being said: IANAL, but I personally don't believe this sort of click-through disclaimer does any good. It's just that this sort of what-if argument doesn't seem strong enough for a case where upstream believes it has legitimate grounds for worrying. I'm surprised that the maintainer seems to be looking for support to raise this upstream before just asking them why the change was made, though. Don't most platforms' user interface guidelines discourage unnecessary dialogs already? I believe my hesitation is explained in my mail to -legal [0]: judging by my previous exchanges with upstream about non-technical and non-clear-cut issues, it's better to come fully armed with as many arguments as possible, otherwise there's a big chance of it being dismissed outright. I don't think interface guidelines would be enough do dissuade them of their liability disclaimer, if they believe it really mitigates anything. Perhaps it would be possible to put the disclaimer in the main window when there are no downloads running, so users would have an opportunity to learn about what the law permits that way. I guess it all comes down to this: if this sort of disclaimer really mitigates liability (IMHO unlikely), then it probably has to keep this users MUST read it format. Otherwise we can just get rid of it completely. Making it less intrusive would diminish its worth as a disclaimer and therefore miss the point entirely. (again: I'm arguing this from the point of view I expect upstream to take) Cheers [0] https://lists.debian.org/debian-legal/2012/10/msg2.html -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#689095: [debian-policy] Prohibit click-through licenses or disclaimers
[since this is getting a bit too transmission-specific, I took the liberty of removing the -policy bug CC] On 15/10/12 02:00, Josh Triplett wrote: On the other hand, upstream might just intend it as a warning for the benefit of users, rather than just a means of reducing liability for the developers. In that case, it need not consist of a click-through to have some useful benefit. True. But I guess this is just speculation on both our parts. Perhaps it would be possible to put the disclaimer in the main window when there are no downloads running, so users would have an opportunity to learn about what the law permits that way. That seems like a good idea to me, and unobtrusive. The only problem I see: many users will launch Transmission for the first time when they click on a torrent link in a web browser or file manager, which will launch Transmission and immediately pop up the dialog to start a torrent; once the user starts that torrent, the disclaimer wouldn't display. However, what about a disclaimer sitting below the last torrent, always at the bottom of the list? Though I don't have any opinion on the particular solutions, I'll just wait a bit to see if the -legal post results in any suggestions before forwarding this upstream. Then we'll take it from there. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687022: lintian: regex error in dev-pkg-without-shlib-symlink
Package: lintian Version: 2.5.10.1 Severity: normal Tags: patch Hi, The attached patch fixes two small issues affecting the dev-pkg-without-shlib-symlink check: 1) a missing '+' in the regex for libtool-style filenames 2) the order of regex substitutions: the first one would never match since it assumed the second had already been performed. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.22-7.1 ii bzip2 1.0.6-4 ii diffstat 1.55-3 ii file 5.11-2 ii gettext0.18.1.1-9 ii hardening-includes 2.2 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libarchive-zip-perl1.30-6 ii libc-bin 2.13-35 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdigest-sha-perl 5.71-1 ii libdpkg-perl 1.16.8 ii libemail-valid-perl0.190-1 ii libipc-run-perl0.92-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii locales2.13-35 ii man-db 2.6.2-1 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-13 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.22-7.1 ii dpkg-dev 1.16.8 ii libhtml-parser-perl3.69-2 pn libperlio-gzip-perlnone ii libtext-template-perl 1.45-2 ii lzma 9.22-2 ii man-db 2.6.2-1 ii xz-utils [lzma]5.1.1alpha+20120614-1 -- no debconf information --- orig/checks/shared-libs 2012-09-08 16:34:47.0 +0200 +++ new/checks/shared-libs 2012-09-08 16:33:31.0 +0200 @@ -231,10 +231,10 @@ } } -# libtool -release variant -$link_file =~ s/-[\d\.]\.so$/.so/o; # determine shlib link name (w/o version) $link_file =~ s/\.so.+$/.so/o; +# libtool -release variant +$link_file =~ s/-[\d\.]+\.so$/.so/o; # shlib symlink may not exist. # if shlib doesn't _have_ a version, then $link_file and $shlib_file will
Bug#686010: transmission-gtk crashed with SIGSEGV in g_type_check_instance_cast()
Hi, On 27/08/12 17:45, kedakun@gmail.com wrote: Package: transmission-gtk Version: 2.52-3 Are you able to reliably replicate this issue? Are there any specific actions leading to it? It might also help to install transmission-dbg to get a bit more info. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683380: CVE-2012-4037
Hi, On 31/07/12 11:40, Moritz Muehlenhoff wrote: Please see http://seclists.org/fulldisclosure/2012/Jul/348 This was assigned CVE-2012-4037 Since we're in freeze, please contact upstream for an isolated fix (or grab it from the 2.60-2.61) and fix this using an backported patch instead of updating to 2.61. Thanks for the heads-up. Working on it. Can you please also check, whether stable is affected? It seems to be affected, but backporting the fix is less trivial. I may need some help for that (especially with the testing). Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683387: unblock: transmission/2.52-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package transmission Latest upload has a backported fix for a security vulnerability[0] Cheers [0] http://seclists.org/fulldisclosure/2012/Jul/348 unblock transmission/2.52-3 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681729: unblock: transmission/2.52-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package transmission The new version includes a fix backported from the version in experimental. The bug[0] still hasn't been reported in Debian, but I'm confident it would affect many users during the life-time of wheezy. And since the backported patch[1] is pretty straightforward, I believe it's worth unblocking at this early freeze-stage. unblock transmission/2.52-2 Cheers [0] https://trac.transmissionbt.com/ticket/4888 [1] https://trac.transmissionbt.com/changeset/13310 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
Hi, Hope you guys don't mind if I just jump in here and try to cool down the discussion, since it's getting kinda flamy. * Goswin von Brederlow wrote: That was 10 month ago. A revised patch came in December, still 6 month for you to do something. Your first response was Fri, 29 Jun 2012 23:27:51 +0930. There is only one person to blame for not applying the patch or raising concerns about it in a timely fashion and that is you. Ron mentioned he took over the package a few weeks back [0], so this blame shifting isn't really accurate (not to mention it's IMHO a bit too confrontational to be constructive; though I understand you were reacting to a equally confrontational comment from the previous email). To get some distance and perspective I'd suggest referring this to the release-team: if they see the possible downfall as an acceptable trade-off for the multi-arch release goal, then go ahead with the patching, uploading and fixing bugs as they appear. Otherwise leave it be. Cheers [0] http://packages.qa.debian.org/liba/libao/news/20120602T121911Z.html -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677729: gnome-shell: org.gnome.desktop.a11y.keyboard.enable ignored for SlowKeys
Package: gnome-shell Version: 3.4.1-6 Severity: normal Hi, It seems gnome-shell ignores the org.gnome.desktop.a11y.keyboard.enable setting and activates SlowKeys by holding Shift down for 8 seconds even if it's disabled. According to [0], this should only happen if the named setting is enabled. Since my desktop is not a fresh install, I imagine this could be caused by some rogue dconf/gconf entry, but I couldn't find anything suspicious myself. Cheers [0] http://library.gnome.org/users/gnome-help/3.4/a11y-slowkeys.html.en -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-1 ii gconf-service3.2.5-1 ii gir1.2-accountsservice-1.0 0.6.21-4 ii gir1.2-atk-1.0 2.4.0-2 ii gir1.2-caribou-1.0 0.4.2-2 ii gir1.2-clutter-1.0 1.10.6-1 ii gir1.2-cogl-1.0 1.10.2-3 ii gir1.2-coglpango-1.0 1.10.2-3 ii gir1.2-folks-0.6 0.6.9-1 ii gir1.2-freedesktop 1.32.1-1 ii gir1.2-gconf-2.0 3.2.5-1 ii gir1.2-gcr-3 3.4.1-3 ii gir1.2-gdesktopenums-3.0 3.4.2-1 ii gir1.2-gdkpixbuf-2.0 2.26.1-1 ii gir1.2-gee-1.0 0.6.4-2 ii gir1.2-gkbd-3.0 3.4.0.2-1 ii gir1.2-glib-2.0 1.32.1-1 ii gir1.2-gmenu-3.0 3.4.2-1 ii gir1.2-gnomebluetooth-1.03.4.1-1 ii gir1.2-gtk-3.0 3.4.2-1 ii gir1.2-json-1.0 0.14.2-1 ii gir1.2-mutter-3.03.4.1-4 ii gir1.2-networkmanager-1.00.9.4.0-5 ii gir1.2-pango-1.0 1.30.0-1 ii gir1.2-polkit-1.00.105-1 ii gir1.2-soup-2.4 2.38.1-2 ii gir1.2-telepathyglib-0.120.18.1-2 ii gir1.2-telepathylogger-0.2 0.4.0-1 ii gir1.2-upowerglib-1.00.9.16-3 ii gjs 1.32.0-2 ii gnome-bluetooth 3.4.1-1 ii gnome-icon-theme-symbolic3.4.0-2 ii gnome-settings-daemon3.4.2-3 ii gnome-shell-common 3.4.1-6 ii gnome-themes-standard3.4.2-1 ii gsettings-desktop-schemas3.4.2-1 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.10.2-7 ii libcairo21.10.2-7 ii libcamel-1.2-29 3.2.2-3 ii libcanberra0 0.28-4 ii libclutter-1.0-0 1.10.6-1 ii libcogl-pango0 1.10.2-3 ii libcogl9 1.10.2-3 ii libcroco30.6.5-1 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-2 0.98-1 ii libebook-1.2-12 3.2.2-3 ii libecal-1.2-10 3.2.2-3 ii libedataserver-1.2-153.2.2-3 ii libedataserverui-3.0-1 3.2.2-3 ii libffi5 3.0.10-3 ii libfolks25 0.6.9-1 ii libgck-1-0 3.4.1-3 ii libgconf-2-4 3.2.5-1 ii libgcr-3-1 3.4.1-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgee2 0.6.4-2 ii libgirepository-1.0-11.32.1-1 ii libgjs0b [libgjs0-libmozjs185-1.0] 1.32.0-2 ii libgl1-mesa-glx [libgl1] 8.0.3-1 ii libglib2.0-0 2.32.3-1 ii libgnome-keyring03.4.1-1 ii libgnome-menu-3-03.4.2-1 ii libgstreamer0.10-0 0.10.36-1 ii libgtk-3-0 3.4.2-1 ii libical0 0.48-2 ii libjson-glib-1.0-0 0.14.2-1 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-3 ii libmutter0 3.4.1-4 ii
Bug#655191: gnokii-cli: too restrictive file permissions on statoverrides
Hi, Sorry for the belated reply. On 09/01/12 06:31, Guillem Jover wrote: This packages sets permissions via dpkg-statoverrrides for a binary, but those are too restrictive for no real reason (see debian-policy §10.9). Those should be: 4754 /usr/sbin/mgnokiidev I'm not sure I understand the problem: this is already the mode being set by dpkg-statoverride. Could you maybe shed a bit more light on the issue? Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677750: RFH: gnokii -- Datasuite for mobile phone management
Package: wnpp Severity: normal Hi, I haven't had the need to use gnokii for years and am currently a bit too swamped with Real Life™ to dedicate the necessary time to its packaging, even though it's relatively low-maintenance. If there's anyone out there who still uses gnokii and has the time to lend a hand, your help would be really appreciated! Cheers Leo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655191: gnokii-cli: too restrictive file permissions on statoverrides
Hi! On 16/06/12 19:58, Guillem Jover wrote: So, the problem is that the old statoverrides did not get fixed on installed systems, which makes the installed file to still have the too restrictive permissions, but fixing those might possibly stomp over user settings, so I'm not sure what'd be the best way to fix this, if at all... OTOH I guess it would be pretty “safe” to only fix the permissions if they match they previous ones, something like this could do it: if ! dpkg-statoverride --list /usr/sbin/mgnokiidev /dev/null || [ `dpkg-statoverride --list /usr/sbin/mgnokiidev` = root gnokii 4750 /usr/sbin/mgnokiidev]; then dpkg-statoverride --update --add root gnokii 4754 /usr/sbin/mgnokiidev fi This sounds good and I probably should have done something like this in the original fix, but given the fact that the fix is already in squeeze, I don't think it's worth it introducing further workarounds now. However, I'll keep this bug open as reference to people that might bump into the same issue. Thanks for the heads-up! Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677800: transition: gnokii
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, Libgnokii has had an soname bump and needs a small transition. There are only two affected source packages: - kdepim (builds cleanly with version in experimental) - gnome-phone-manager (FTBFSs with glib.h: No such file or directory; couldn't find the cause with a cursory look; #677799) Cheers PS.: really sorry, this transition should have been done months ago, but after the last upload to experimental I completely forgot about it! Ben file: title = gnokii; is_affected = .depends ~ libgnokii6 | .depends ~ libgnokii7; is_good = .depends ~ libgnokii7; is_bad = .depends ~ libgnokii6; -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677800: transition: gnokii
On 16/06/12 22:36, Cyril Brulebois wrote: more than a month after this mail, it looks like it's really too late: https://lists.debian.org/debian-devel-announce/2012/05/msg4.html Oh, that was sort of an important mail to miss... Well, tough luck. Thanks anyway. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676403: RM: tedia2sql -- ROM; abandoned upstream; non-usable in wheezy
Package: ftp.debian.org Severity: normal Hi, This package was already unnusable when squeeze got released (see #600877), hence it's absence from that release. It's been RFA since then without any takers, has a very low popcon (cur: 87), still doesn't work with current dia and there is already another package which fulfills its role (libparse-dia-sql-perl). Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676406: RM: libcwiimote -- ROM; abandoned upstream; no-reverse-deps
Package: ftp.debian.org Severity: normal This library was only packaged because of wiipresent (RFP #543277), which I never got around to packaging. It has no reverse deps and upstream's last commit was 2,5 years ago. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627989: Polite poke
Hi, Is there any problem with the proposed patch? And is there a rough timeframe for uploading a fixed package? I've been hit by the same issue and it would be nice to have this fix in wheezy. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675807: override: pst-utils:utils/optional, libpst4:libs/optional
Package: ftp.debian.org Severity: normal libpst4_0.6.54-3_amd64.deb: package says priority is optional, override says extra. pst-utils_0.6.54-3_amd64.deb: package says priority is optional, override says extra. I mistakenly uploaded my takeover package with source prio:extra. Please update override file. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512909: Please upload fork
Hi Jordi, On 01/06/12 15:10, Jordi Mallach wrote: The GNOME team wants to upload a PST-enabled evolution before wheezy. It'd be awesome if you could upload what you have in collab-maint so everyone can benefit. It probably needs some update by now, but what you describe in the bug report looks ok to me, and libpst is clearly abandoned in Debian. You might want to fish in the Ubuntu package for more changes. Thanks for the heads-up! And wow, almost exacly one year after my suggestion... :) I'm taking a look at the package now and will upload a new version to DELAYED in a few minutes/hours, to give Joe one last chance to chime in. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640331: bug probably closed in version 12
Hi, Just a quick FYI to help with triaging: this bug seems to have been solved in version 12[0]. There was another related bug which more explicitly mentioned the problem I experienced with the Delicious extention, explaining what sort of API (mis)usage might have led to the memleaks, but I unfortunately can't find it again. Cheers [0] https://bugzilla.mozilla.org/show_bug.cgi?id=695480 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673707: Please enable hardening build flags
Hi, On 20/05/12 23:09, Touko Korpela wrote: Package: libevent Version: 2.0.19-stable-1 Severity: important Hardened build flags are a release goal for Wheezy. Because this library deals with network connections, it would be good if hardening was enabled during build. I think this package qualifies library accessible from the network part of release goal. Sorry for late report and feel free to downgrade but if it's not too much trouble then I would like to see it enabled. Just FYI: just uploaded a version with the flags enabled. Lintian still has two false positives warning of missing stack protection, but I believe this may be #673112, since the logs show both affected libraries being built with the right flags. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670866: desktop-base: please manage login-background through update-alternatives
Package: desktop-base Version: 6.0.7 Severity: normal Hi, Title says it all. Should be done for all the reasons listed by Michael Biebl in #607075 [0]. Plus, the current file where this is managed isn't even a conf-file, so AFAICT this can't be changed in a way that won't be overwritten with an upgrade. Cheers [0] http://bugs.debian.org/607075 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages desktop-base depends on: ii librsvg2-common 2.36.1-1 desktop-base recommends no packages. Versions of packages desktop-base suggests: pn gnome | kde-standard | xfce4 | wmaker none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668533: latexila: please upload 2.4.0
Package: latexila Version: 2.2.2-1 Severity: wishlist Hi, Subject says it all, actually :) Incidentally, it seems upstream started packaging only xz starting with this version, so the watch file might probably need a fix as well. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668533: latexila: please upload 2.4.0
On 12/04/12 17:07, Tanguy Ortolo wrote: No problem, glad to see that a new version is out. Just give me a little time since I am being quite busy. No hurry! I just thought you might have missed it because of the watch file failing silently. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491723: debian/copyright for statusnet
On 23/03/12 22:25, Roland Mas wrote: I was somewhat bored and I wanted to play with config-edit stuff; since I'm also eager to see statusnet enter Debian officially, I spent some time reading copyright notices and transcribing them. Here's what git produced (I have no idea if it's actually useful as is, but at least there's a patch in there): Thanks a lot for the work! I also needed a poke to go back to working on this, so I'll take a look at the patch this week and try to get the missing pieces in place for an upload soon-ish. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663341: scrobbler: should probably create session file with mode 0640
Package: rhythmbox-plugins
Version: 2.95-1
Severity: normal
Tags: patch
Dear Maintainer,
Since the Last.fm session file[0] includes a session key for API usage,
it would probably make sense to create it mode 0640 instead of 0644.
Even though the API doesn't AFAIK provide access to sensitive
information (thus severity:normal), it can still be misused.
The attached patch should be all that's needed.
[0] ~/.local/share/rhythmbox/audioscrobbler/sessions
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages rhythmbox-plugins depends on:
ii gir1.2-gconf-2.0 3.2.3-3
ii gir1.2-glib-2.0 1.31.20-1
ii gir1.2-gtk-3.0 3.2.3-1
ii gir1.2-peas-1.0 1.2.0-1
ii gir1.2-rb-3.02.95-1
ii gir1.2-webkit-3.01.6.3-2
ii libatk1.0-0 2.2.0-2
ii libc62.13-27
ii libcairo-gobject21.10.2-7
ii libcairo21.10.2-7
ii libclutter-1.0-0 1.8.4-1
ii libclutter-gst-1.0-0 1.4.6-1
ii libclutter-gtk-1.0-0 1.0.4-1
ii libcogl-pango0 1.8.2-1
ii libcogl5 1.8.2-1
ii libdmapsharing-3.0-2 2.9.14-1
ii libdrm2 2.4.30-1
ii libffi5 3.0.10-3
ii libfontconfig1 2.8.0-3.1
ii libfreetype6 2.4.8-1
ii libgconf2-4 3.2.3-3
ii libgdk-pixbuf2.0-0 2.24.1-1
ii libgirepository-1.0-11.31.20-1
ii libgl1-mesa-glx [libgl1] 7.11.2-1
ii libglib2.0-0 2.30.2-6
ii libgnome-keyring03.2.2-2
ii libgpod4 0.8.2-6
ii libgrilo-0.1-0 0.1.18-1
ii libgstreamer-plugins-base0.10-0 0.10.36-1
ii libgstreamer0.10-0 0.10.36-1
ii libgtk-3-0 3.2.3-1
ii libgudev-1.0-0 175-3.1
ii libimobiledevice21.1.1-3
ii libjson-glib-1.0-0 0.14.2-1
ii liblircclient0 0.9.0~pre1-1
ii libmtp9 1.1.2-2
ii libmusicbrainz3-63.0.2-2
ii libmx-1.0-2 1.4.2-1
ii libnotify4 0.7.4-1
ii libpango1.0-01.29.4-3
ii libpeas-1.0-01.2.0-1
ii librhythmbox-core5 2.95-1
ii libsoup-gnome2.4-1 2.36.1-1
ii libsoup2.4-1 2.36.1-1
ii libtdb1 1.2.9+git20120207-1
ii libtotem-plparser17 2.32.6-3
ii libusb-0.1-4 2:0.1.12-20
ii libx11-6 2:1.4.4-4
ii libxcomposite1 1:0.4.3-2
ii libxdamage1 1:1.1.3-2
ii libxext6 2:1.3.0-3
ii libxfixes3 1:5.0-4
ii libxi6 2:1.4.5-1
ii libxml2 2.7.8.dfsg-7
ii python 2.7.2-10
ii python-gnomekeyring 2.32.0+dfsg-1
ii python-mako 0.6.2-1
ii python2.72.7.3~rc1-1
ii rhythmbox2.95-1
ii zeitgeist-core 0.8.2-1
ii zlib1g 1:1.2.6.dfsg-2
Versions of packages rhythmbox-plugins recommends:
ii nautilus-sendto 3.0.1-2
rhythmbox-plugins suggests no packages.
-- no debconf information
From: Leo 'costela' Antunes cost...@debian.org
Subject: scrobbler: should probably create session file with mode 0640
Since the Last.fm session file includes a session key for API usage, it
would probably make sense to create it mode 0640 instead of 0644.
Index: rhythmbox-2.95/plugins/audioscrobbler/rb-audioscrobbler-account.c
===
--- rhythmbox-2.95.orig/plugins/audioscrobbler/rb-audioscrobbler-account.c 2012-01-10 12:46:03.0 +0100
+++ rhythmbox-2.95/plugins/audioscrobbler/rb-audioscrobbler-account.c 2012-03-10 15:05:37.454014561 +0100
@@ -408,7 +408,7 @@
g_free (file_path);
error = NULL;
- g_file_replace_contents (out_file, data, data_length, NULL, FALSE, G_FILE_CREATE_NONE, NULL, NULL, error);
+ g_file_replace_contents (out_file, data, data_length, NULL, FALSE, G_FILE_CREATE_PRIVATE, NULL, NULL, error);
if (error != NULL) {
rb_debug (error saving session: %s, error-message);
g_error_free (error);
Bug#663017: ITP: transmission-remote-cli -- ncurses interface for the Transmission BitTorrent daemon
On 08/03/12 13:59, Jonathan McCrohan wrote: Shouldn't it be included in the transmission-cli package instead? I guess it could be included in transmission-cli. I thought transmission-remote-cli would be better suited to its own package because it a third-party transmission tool, and not part of the transmission project itself [1]. I agree it's probably better to have its own package. I also have an ITP for transmission-remote-gtk, which is in a similar situation. That being said: I haven't checked the source, but I'm a bit curious about its use of transmission-remote. Does it depend on specific input/output formats? Did upstream at some point declare a stable API for using transmission-remote in scripts? I'm just worried this might be a small nightmare to maintain in the long run... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659175: transmission-gtk: segfault immediately after start
tag 659175 unreproducible moreinfo -- Hi, On 08/02/12 22:45, Andrew O. Shadura wrote: (gdb) run Starting program: /usr/bin/transmission-gtk [Thread debugging using libthread_db enabled] [New Thread 0xb628f870 (LWP 3252)] Program received signal SIGSEGV, Segmentation fault. Could you please try this with transmission-dbg installed, so we resolve the symbols previous to the segfault? Also, I'll upload 2.50 to unstable in a few minutes, so please check if an upgrade solves the problem. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659117: transmission-gtk: segfaults when torrent properties are opened/closed
tag 659117 unreproducible moreinfo -- Hi, On 08/02/12 15:16, Simon Wenner wrote: I have non-deterministic segfaults if I open and close the property window of a torrent. To reproduce it I have to open and close a property window about 5 to 10 times. It's probably a race condition. Since this problem seems to happen while garbage collecting, this may be one of the bugs solved with the 2.50 release. I'll upload it to unstable in a few minutes, so please check if the problem persists. The backtrace is attached. If an upgrade doesn't help the issue, please install transmission-dbg and provide another trace. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661070: transmission-daemon conflict with transmission-gtk. Noone works.
tag 661070 wontfix severity 661070 important -- Hi, Sorry, but I disagree this is a bug. On 24/02/12 00:45, Aurélio A. Heckert wrote: When i installed transmission-daemon i think i could use transmission-gtk as on of this interfaces what was worst then a false idea. The description of transmission-daemon states: For the associated transmission-remote, see the package transmission-cli. and the description for transmission-gtk states: This package contains the GTK *stand-alone* client. (emphasis added) So I believe it's pretty clear transmission-gtk and transmission-daemon aren't meant to be used together. Have you checked transmission-remote-gtk[0]? Might be what you're looking for. Unfortunately I still haven't gotten around to packaging it though... transmission-gtk stop to work when i install transmission-daemon and the transmission-daemon also does not works. The log only says could not connect to tracker, to all torrents. But rtorrent works perfectly. This could be caused by using the same peer-port on both programs, but I haven't checked if the tracker connection also uses this port. Either way it should only impact one of them (the one started last), so if you're experiencing this on both simultaneously it may be something else entirely. They also was using the same default port for the web interface (what is not a bug), and there i see they was managing a different list of torrents. Transmission-daemon runs as a dedicated system-user, so it seems impractical to implement a solution where both share the same downloads. I am however very open to suggestions on this point, so if you have an idea how to make this work in a sane fashion, just let me know! Since I believe this bug stemmed more from a misunderstanding of how transmission works than from the fact that the daemon and the gtk interface don't play well together, I'm tagging it as wontfix. I do however believe there might be a legitimate use-case for it, so if this is really what you wanted, just let me know and we can try to find the problem. Cheers [0] http://code.google.com/p/transmission-remote-gtk/ -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660654: ITP: binwalk -- tool for searching binary images for embedded files and executable code
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: binwalk Version : 0.4.2 Upstream Author : Craig Heffner heffne...@gmail.com * URL : http://code.google.com/p/binwalk/ * License : Expat Programming Lang: C Description : tool for searching binary images for embedded files and executable code Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images. Binwalk uses the libmagic library, so it is compatible with magic signatures created for the Unix file utility. . Binwalk also includes a custom magic signature file which contains improved signatures for files that are commonly found in firmware images such as compressed/archived files, firmware headers, Linux kernels, bootloaders, filesystems, etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659917: transmission: Transmission unable to update its blocklist
Hey Krzysztof, On 14/02/12 23:03, Krzysztof Klimonda wrote: Transmission developers have stopped hosting level1 blocklist file which broke blocklist updates for older Transmission releases (versions = 2.10 are not affected as they allow changing the blocklist url. Yeah, thanks for reporting this. I had made a mental note about dealing with this when I noticed the change in newer versions, but completely forgot. It can be fixed in a number of ways: - Debian can start hosting level1 blocklist (and update them daily from some other blocklist provider) - We can point transmission to another blocklist provider - We can disable this option in the menu To fix this as quickly as possible, I could put it on my personal server and redirect some debian.net address to it (like blocklist.debian.net or something). Depending on the load, this could remain for the lifetime of squeeze or lucid. However, how would this blocklist be updated? Should I just regularly wget another blocklist from some other server and gunzip it? How about directly using this URL: http://list.iblocklist.com/?list=bt_level1fileformat=p2parchiveformat= (would probably be a good idea to ask beforehand) Cheers, KK I'm gonna start calling you just KK (kay-kay), because every single time I have to write your name, I have to recheck my spelling about 3-4 times! :) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631018: [RFC] libevent 2.0 transition
On 17/12/11 12:14, Julien Cristau wrote: - transmission: #650812 That bug is fixed, but migration is still blocked by #642538. Sorry, this is actually fixed in the package, but I left the bug open because I wanted to find a proper fix for upstream (the debian patch turned out to be a bad solution for the general case). Will mark as fixed to get things going. Once transmission is fixed in testing I'll probably look at removing the remaining packages. Huge thanks for all the work! Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651820: kdepim: either remove gnokii build-dep or enable use (and test new version :) )
Source: kdepim Version: 4:4.4.11.1+l10n-1 Severity: minor Dear Maintainers, As I checked packages that depended on libgnokii to suggest testing with the new version in experimental (new soname), I noticed kdepim build-deps on libgnokii-dev, but it seems like none of the generated bin-packages actually depend on it. If I overlooked something and gnokii actually *is* used, then please test kdepim with the new version in experimental, otherwise please remove the spurious build-dep. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631018: [RFC] libevent 2.0 transition
Hi, On 07/12/11 19:02, Julien Cristau wrote: - getstream: #622278 - honeyd: #632765 - ladvd: #650670 - python-event: #632763 - transmission: #650812 I'm also the maintainer here, but the version currently in experimental is blocked by a build-dep on libminiupnpc-dev (= 1.6) (which is also only in experimental). I guess the quickest way to fix this would be uploading an older version of transmission which already builds with libevent 2, but doesn't need libminiupnpc 1.6. - gearmand: #650825 These still need some action. Anyone? I'm unfortunatelly a bit swamped to deal with the other issues, but I'll try to get to them as soon as practicable. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491723: Status.net Debian Package
Just a FYI: The package is almost ready, the only thing missing before I can do an official upload is the debian/copyright file. There's a lot of manual work involved and I can't seem to find the time to sit down and do it (and honestly, the motivation isn't exactly brimming for this specific kind of work! ;) ). If anyone would like to give it a final push, I'd really appreciate the help! Feel free to take a look at the current code at: git://git.debian.org/~costela/statusnet.git Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650465: git-buildpackage: small manpage fix: s/version/%(version)s/
On 30/11/11 08:24, Guido Günther wrote: In the --debian-tag part of the manpage, the default is mentioned as debian/version. This could probably be replaced with debian/%(version)s so it's clearer what format should be used when replacing it. That makes sense. Care enough to send a patch? Sure, will do it later today. But just to be sure I'm not overseeing something: all manpages containing version can probably be changed as well, right? After all, they all use Python's string formatting, at least AFAICT... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650465: git-buildpackage: small manpage fix: s/version/%(version)s/
Package: git-buildpackage Version: 0.5.32 Severity: minor Hi, In the --debian-tag part of the manpage, the default is mentioned as debian/version. This could probably be replaced with debian/%(version)s so it's clearer what format should be used when replacing it. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts 2.11.2 ii git [git-core] 1:1.7.7.3-1 ii git-core 1:1.7.7.3-1 ii python 2.7.2-9 ii python-dateutil 1.5-1 ii python2.62.6.7-4 ii python2.72.7.2-7 Versions of packages git-buildpackage recommends: ii cowbuilder0.65 ii pristine-tar 1.15 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647679: miniupnpc: please upload new upstream version (1.6)
Package: miniupnpc
Version: 1.5-2
Severity: wishlist
Tags: patch
Hi,
Please upload 1.6 to the archive.
The new version has API changes, so it might be a good idea to test it
in experimental for a while (I actually only need it in experimental
anyway).
I also attached the patches made while working on it myself. If they
look good to you, just git apply them. As a bonus I fixed the watch
file, so now you can just git-import-orig --uscan (with the right
--*-branch options, since you use non-standard branch names).
Cheers
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From dfec0c048fafe4e408a70f474912719585664cdb Mon Sep 17 00:00:00 2001
From: Leo 'costela' Antunes cost...@debian.org
Date: Sat, 5 Nov 2011 01:47:28 +0100
Subject: [PATCH 1/6] debian/watch: add filename mangle to correct download
---
debian/watch |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/debian/watch b/debian/watch
index e49bfd6..546a009 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
version=3
-http://miniupnp.free.fr/files/download.php\?file=miniupnpc-(\d\.\d.*).tar.gz
+
+opts=filenamemangle=s/.*file=([^]*)/$1/ \
+ http://miniupnp.free.fr/files/download.php\?file=miniupnpc-(\d\.\d.*).tar.gz
--
1.7.7.1
From 98b25a3dcfe1c8646f8f47818c6df9d9dd9679b2 Mon Sep 17 00:00:00 2001
From: Leo 'costela' Antunes cost...@debian.org
Date: Sat, 5 Nov 2011 02:41:11 +0100
Subject: [PATCH 2/6] =?UTF-8?q?update=20soname=205=E2=86=928?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
debian/control |6 +++---
debian/libminiupnpc5.shlibs |1 -
debian/libminiupnpc8.shlibs |1 +
debian/rules|6 +++---
4 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 debian/libminiupnpc5.shlibs
create mode 100644 debian/libminiupnpc8.shlibs
diff --git a/debian/control b/debian/control
index 7dbe35e..ebed66d 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,7 @@ Description: UPnP IGD client lightweight library client
.
This package is an example client for the library.
-Package: libminiupnpc5
+Package: libminiupnpc8
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Recommends: minissdpd
@@ -49,7 +49,7 @@ Description: UPnP IGD client lightweight library
Package: libminiupnpc-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, ${shlibs:Depends}, libminiupnpc5 (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libminiupnpc8 (= ${binary:Version})
Recommends: minissdpd
Description: UPnP IGD client lightweight library development files
The UPnP protocol is supported by most home adsl/cable routers and Microsoft
@@ -64,4 +64,4 @@ Description: UPnP IGD client lightweight library development files
sample program is around 20KB. The miniupnp daemon is much smaller than any
other IGD daemon and is ideal for using on low memory device for this reason.
.
- This package contains development files needed to build using libminiupnpc5
+ This package contains development files needed to build using libminiupnpc
diff --git a/debian/libminiupnpc5.shlibs b/debian/libminiupnpc5.shlibs
deleted file mode 100644
index 727e9f4..000
--- a/debian/libminiupnpc5.shlibs
+++ /dev/null
@@ -1 +0,0 @@
-libminiupnpc 5 libminiupnpc5
diff --git a/debian/libminiupnpc8.shlibs b/debian/libminiupnpc8.shlibs
new file mode 100644
index 000..ec4f766
--- /dev/null
+++ b/debian/libminiupnpc8.shlibs
@@ -0,0 +1 @@
+libminiupnpc 8 libminiupnpc8
diff --git a/debian/rules b/debian/rules
index 03d30d8..12a8e78 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,12 +28,12 @@ install: build
dh_prep
$(MAKE) install PREFIX=$(CURDIR)/debian/miniupnpc
# Move the library in its corresponding separate package folder.
- mkdir -p $(CURDIR)/debian/libminiupnpc5/usr
- mv $(CURDIR)/debian/miniupnpc/usr/lib $(CURDIR)/debian/libminiupnpc5/usr
+ mkdir -p $(CURDIR)/debian/libminiupnpc8/usr
+ mv $(CURDIR)/debian/miniupnpc/usr/lib $(CURDIR)/debian/libminiupnpc8/usr
# Move the include files
mkdir -p $(CURDIR)/debian/libminiupnpc-dev/usr/lib
mv $(CURDIR)/debian/miniupnpc/usr/include $(CURDIR)/debian/libminiupnpc-dev/usr
- mv $(CURDIR)/debian/libminiupnpc5/usr/lib/libminiupnpc.so $(CURDIR)/debian/libminiupnpc-dev/usr/lib
+ mv $(CURDIR)/debian/libminiupnpc8/usr/lib/libminiupnpc.so $(CURDIR)/debian/libminiupnpc-dev/usr/lib
binary-indep: build install
--
1.7.7.1
From f211eb835db1ac80bd8a9cd86f13ea4d1b63e173 Mon Sep 17 00:00:00 2001
From: Leo 'costela' Antunes cost...@debian.org
Date: Sat, 5 Nov 2011 02:56:33 +0100
Subject: [PATCH 3/6] debian/rules: add build-arch and build-indep targets to
shut lintian up
---
debian/rules |4
Bug#586590: compiz: crash to metacity when tooltip is larger than width of screen
Just FYI, this is also an issue with nouveau. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642538: debian's build script for Transmission should invoke qmake /after/ building libtransmission
Hi Charles,
On 26/09/11 00:18, Charles Kerr wrote:
Would you also accept a patch to the build system, so that it doesn't check
for the existence of the libutp.a file to decide whether to link against it
(instead looking for something generated during the configure phase, like a
Makefile)?
Probably so, if the patch was straightforward.
The attached patch is as straightforward as it gets! :)
I just built 2.33 with it and found no issues (libutp gets built and
tr-qt links against it). I'd appreciate if someone could build it on a
non-Debian system, just to make sure there are no side-effects.
Should I forward this to the trac?
Cheers
--
Leo costela Antunes
[insert a witty retort here]
Index: repo/qt/qtr.pro
===
--- repo.orig/qt/qtr.pro 2011-07-04 16:48:11.454477073 +0200
+++ repo/qt/qtr.pro 2011-09-26 10:25:24.063146592 +0200
@@ -19,7 +19,7 @@
INCLUDEPATH = $${EVENT_TOP}/include $${INCLUDEPATH}
INCLUDEPATH += $${TRANSMISSION_TOP}
LIBS += $${TRANSMISSION_TOP}/libtransmission/libtransmission.a
-exists( $${TRANSMISSION_TOP}/third-party/libutp/libutp.a ) {
+exists( $${TRANSMISSION_TOP}/third-party/libutp/Makefile ) {
LIBS += $${TRANSMISSION_TOP}/third-party/libutp/libutp.a
}
LIBS += $${TRANSMISSION_TOP}/third-party/dht/libdht.a
Bug#642929: (no subject)
Hi, I´m not entirely sure this is the same problem, but it seems likely: /etc/X11/xinit/xinput.d/scim-immodule checks for immodules in /usr/lib*/gtk-2.0 (and the equivalent for Qt), ignoring the multi-arch paths and consequently missing /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so. AFAICT this seems to be a left-over from fixing #640629. The quick fix should be just a two-liner, but it might warrant a better look at these scripts. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642538: debian's build script for Transmission should invoke qmake /after/ building libtransmission
Hi Charles, On 23/09/11 17:56, Charles Kerr wrote: I think this issue can be solved by changing that script s.t. it defers invoking qmake until just before the qt client is built (that is, after libtransmission, daemon, etc. have been built.) This sounds reasonable, but would you also accept a patch to the build system, so that it doesn't check for the existence of the libutp.a file to decide whether to link against it (instead looking for something generated during the configure phase, like a Makefile)? I only looked at the problem briefly, but this seems doable and would keep the logical separation between the configure and build steps. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640331: iceweasel 6.0 - huge ram use
Hi, On 13/09/11 15:56, niky 45 wrote: actualy, i don't think it's firebug. mainly, because i haven't it installed. Yeah, as I said in my previous email: I jumped the gun. this is what is shown on about:support (see attachment) The only extension we're both using is Adblock Plus, but I just ruled it out as the culprit: I've been running the same session for around 10 hours now and no memory spike whatsoever. The only extension I disabled is the del.icio.us one, but since you don't even have it installed, I'd venture a guess and say it's probably either a common API used by the del.icio.us extension and some other one you have enabled, or some freaky interaction between extensions (which would be a lot harder to find). Unfortunately my XUL-fu is as good as nonexistent, so I'm afraid I can't really help out much further, at least not until someone with more insight points me in the right direction. Keeping my xul-newbie hat on, I'd still not rule out the possibility of a problem on Firefox's side, since this could be a leak inside a specific API being used by extensions. But this is moot until the actual problem is found. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640331: iceweasel 6.0 - huge ram use
Hi again, On 11/09/11 21:47, Leo 'costela' Antunes wrote: After a bit of testing, it seems Firebug is the culprit. Damn, think I spoke too soon. Took longer than usual, but eventually memory usage spiked again. I'll keep testing with other plugins and post the results. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640331: iceweasel 6.0 - huge ram use
Hi, After a bit of testing, it seems Firebug is the culprit. This could be a fluke, but since I've left Iceweasel open for a couple of hours the results seem clear enough. Niky, was Firebug one of the plugins you had enabled? Unfortunately I'm not using the packaged version of Firebug, so I'm not sure I should reassign the bug before confirming it also applies to it. Could someone with with the packaged version please give it a try? Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639738: pidgin-awayonlock: Please allow use with plain xscreensaver
severity 639738 wishlist tag 639738 wontfix -- Hi Jonas, On 29/08/11 21:35, Jonas Smedegaard wrote: As subject says, please allow use with plain xscreensaver. Unfortunately, AFAICT xscreenshot doesn't support any way of notifying other applications that it got activated. The only work-around for this would be a polling solution, which sounds way less-than-optimal (not to mention I'm not even sure there's anything I *could* poll). However, if you've got a suggestion on how I could deal with it, just let me know and I'll try putting something together. And patches welcome applies as usual, of course! :) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638828: libnatpmp1: shouldn't provide libnatpmp0
Package: libnatpmp1 Version: 20110808-1 Severity: critical Justification: breaks other packages (see #638824) Hi, Making libnatpmp1 provide libnatpmp0 means packages in practice ignore the soname bump, which is obviously wrong. First, the package doesn't provide libnatpmp.so.0, which is the obvious part, but secondly, a new ABI-incompatible version of a library doesn't provide a previous ABI, so this is also conceptually wrong. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638824: transmission-gtk: libnatpmp dependency problems
Hi, On 22/08/11 11:02, Witold Baryluk wrote: Maybe this is actually problem with libnatpmp1 claiming it is providing libnatpmp0? Yes, this is definitely an issue with libnatpmp. I've already reported a bug against it explaining the issue[0]. BTW. There is 2.33 already, so it is good time to upload it :) Yup, I'm aware of that. It's been sitting in an almost-ready state on my home-pc for a while. :) Just didn't get around to uploading it. Cheers [0] http://bugs.debian.org/638828 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637986: transmission: Failed open a *.torrent file, if Transmission is already running
Hi, On 16/08/11 13:02, Pavel Sugrobov wrote: If I open a .torrent file when Transmission is closed, then Transmission opens automatically and a download window pops up. Everything goes ok in this case. But if Transmission is already running and I try to open a .torrent file, then I receive an error message complaining that Transmission is already opened. In this case, no download window pops up and I'm not able to add the new torrent to the download list. Could you please try the version in experimental? I believe this is one of the many issues fixed since 2.03, but I can't seem to find the actual upstream bug report for it. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635556: transmission-daemon: cpu usage goes 100% when download reaches other peers
Hi, On 27/07/11 01:18, Мурашин Борис wrote: I’m fighting this setting download limits so my transmission-daemon slightly slower than most other peers and always have parts to download. Cause otherwise my 2-core box becomes pretty unusable (transmission-remote goes dead at all). Transmission 2.03 is 1 year outdated, maybe it’s time to upgrade? At least 2.13 will compile on stable release (newer ones depend on libevent=2.10) Can you please test this with the version in experimental? I currently unfortunately don't have the time to maintain a backport and keeping different versions in stable, unstable AND experimental is a bit too much work (so I'm currently keeping unstable as close to stable as possible, while doing what should be unstable in experimental). I understand this isn't optimal, but it's the best I can do right now. On a related note, the version I'll be uploading shortly (2.33-1) includes the possibility to fiddle with scheduling knobs through start-stop-daemon options (in /etc/default/transmission-daemon). This may help you tweak transmission-daemon's performance to not get in the way of other things in your system. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638853: fail2ban: use iptables-new by default for ssh jail
Package: fail2ban Version: 0.8.5-1 Severity: wishlist Hi, After reading through #350746, I wonder why iptables-new isn't used by default for the ssh jail. I understand and agree with the arguments about possible interactions with other protocols and thus the reason for not using it per default for all jails, but at least for ssh, where it's clear new auth attempts will use new connections, this shouldn't have any sensible drawbacks while decreasing the annoyance-factor of locking yourself out of your own server (like I just did, while playing with the pubkeys used by automatic backups :D). Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638853: fail2ban: use iptables-new by default for ssh jail
On 22/08/11 15:43, Yaroslav Halchenko wrote: have you seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438901 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438901#15 in particular? That's a very good point. I'm gonna try cooking up a version of iptables-multiport which wraps the actionban with a check to see if there's a utmp entry from that IP. Would you accept something like this to be included like iptables-new currently is? It would deal with the annoying part without hitting this particular issue (I'd probably test this on at least one server for a while before submitting anyway). Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621953: camorama: diff for NMU version 0.19-2.2
Hi, On 10/08/11 10:54, Alessio Treglia wrote: I've prepared an NMU for camorama (versioned as 0.19-2.2). The diff is attached to this message. Thanks for taking the time. This package is definitely in need of some care. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631018: [RFC] libevent 2.0 transition
[please CC] Hi, On 19/06/11 16:30, Leo 'costela' Antunes wrote: I uploaded a new version of libevent to experimental which I'd like to migrate to unstable as soon as possible. Since I'm the new guy helping out with libevent and since this would be my first bigish transition, I'd like to run it by the release team to make sure I'm not stepping on anyone's toes. snip Now I intended to write to -devel with all affected maintainers CC'd, requesting further testing and input and after all have ack'd the problems and have solutions in place, I'd go ahead with the upload to unstable. Does this sound like a reasonable plan? Did I miss something important? I didn't get an explicit answer about this, so I thought I might ask more directly: is it ok if I simply upload the new libevent to unstable? FYI, from all the starting FTBFSs, more than half have been dealt with or acknowledged by the respective maintainers: beanstalkd: fixed ladvd: fixed forked-daapd: version in experimental drops dependency python-event: (no answer to #632763) memcached: (no answer to #632764) lua-event: fixed honeyd: (no answer to #632765) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631018: [RFC] libevent 2.0 transition
On 08/08/11 22:05, Julien Cristau wrote: On Mon, Aug 8, 2011 at 13:03:29 +0200, Leo 'costela' Antunes wrote: I didn't get an explicit answer about this, so I thought I might ask more directly: is it ok if I simply upload the new libevent to unstable? No, it's not. Ok, fair enough. So is there anything I can do to help get things going? (assuming I *could* help) Please don't take this as pressure. I just didn't see libevent popping up in the list of planned transitions[0], so I thought it would be best to ask instead of simply assuming I had to wait. Cheers [0] http://release.debian.org/transitions/ -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633398: rhythmbox stopped including rb-client
Package: rhythmbox Version: 2.90.1~20110329-1 Severity: normal Tags: experimental Hi, It seems the rhythmbox package stopped including the rhythmbox-client binary somewhere between 0.13 and 2.90. I'm aware that it has been commented out upstream (and in fact doesn't even build if uncommented), so I assume the changes for 2.90 still haven't been ported to all parts of the code. I would however be nice if the new version didn't migrate to unstable until this is fixed, since I imagine I'm not the only one relying on rb-client for keybindings and such. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rhythmbox depends on: ii dbus1.4.12-4 simple interprocess messaging syst ii gconf2 2.32.4-1 GNOME configuration database syste ii gnome-icon-theme3.0.0-4 GNOME Desktop icon theme ii gstreamer0.10-alsa [gst 0.10.35-1GStreamer plugin for ALSA ii gstreamer0.10-gconf [gs 0.10.30-1GStreamer plugin for getting the s ii gstreamer0.10-plugins-b 0.10.22-2GStreamer plugins from the bad s ii gstreamer0.10-plugins-b 0.10.35-1GStreamer plugins from the base ii gstreamer0.10-plugins-g 0.10.30-1GStreamer plugins from the good ii gstreamer0.10-x 0.10.35-1GStreamer plugins for X11 and Pang ii libatk1.0-0 2.0.1-2 ATK accessibility toolkit ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.4.12-4 simple interprocess messaging syst ii libdbus-glib-1-20.94-4 simple interprocess messaging syst ii libfontconfig1 2.8.0-3 generic font configuration library ii libfreetype62.4.4-2 FreeType 2 font engine, shared lib ii libgconf2-4 2.32.4-1 GNOME configuration database syste ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgnome-media0 2.30.0-1 runtime libraries for the GNOME me ii libgstreamer-plugins-ba 0.10.35-1GStreamer libraries from the base ii libgstreamer0.10-0 0.10.35-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libgudev-1.0-0 171-2GObject-based wrapper library for ii libice6 2:1.0.7-2X11 Inter-Client Exchange library ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libpango1.0-0 1.28.4-1 Layout and rendering of internatio ii libpython2.62.6.7-2 Shared Python runtime library (ver ii libsm6 2:1.2.0-2X11 Session Management library ii libsoup-gnome2.4-1 2.34.2-2 HTTP library implementation in C - ii libsoup2.4-12.34.2-2 HTTP library implementation in C - ii libtotem-plparser17 2.32.5-2 Totem Playlist Parser library - ru ii libxml2 2.7.8.dfsg-3 GNOME XML library ii media-player-info 14-1 Media player identification files ii python-gnome2 2.28.1-3 Python bindings for the GNOME desk ii python-gst0.10 0.10.21-2.1 generic media-playing framework (P ii python-gtk2 2.24.0-2 Python bindings for the GTK+ widge ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages rhythmbox recommends: ii avahi-daemon 0.6.30-5Avahi mDNS/DNS-SD daemon ii gstreamer0.10-plugins-ug 0.10.18-1 GStreamer plugins from the ugly ii gvfs-backends1.8.2-1 userspace virtual filesystem - bac ii notification-daemon 0.5.0-3 daemon to displays passive pop-up ii rhythmbox-plugins0.12.8-3plugins for rhythmbox music player ii yelp 2.30.1+webkit-1 Help browser for GNOME Versions of packages rhythmbox suggests: pn gnome-codec-install none (no description available) ii gnome-control-center 1:2.30.1-3 utilities to configure the GNOME d ii gstreamer0.10-plugins-bad 0.10.22-2 GStreamer plugins from the bad s pn rhythmbox-plugin-cdrecorder none (no description available) pn rhythmbox-plugin-coherencenone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632762: FTBFS with libevent 2.0 in experimental
Package: beanstalkd Version: 1.4.6-1 Severity: normal Hi, After testing in a clean pbuilder, your package failed to build with the version of libevent in experimental (2.0.*). You can find a log of the build attempt attached. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-checkbuilddeps: Unmet build dependencies: fiu-utils (= 0.13-3) W: Unmet build-dependency in source dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package beanstalkd dpkg-buildpackage: source version 1.4.6-1 dpkg-buildpackage: source changed by Serafeim Zanikolas s...@debian.org dpkg-source --before-build beanstalkd-1.4.6 dpkg-checkbuilddeps: Unmet build dependencies: fiu-utils (= 0.13-3) dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: This is currently a non-fatal warning with -S, but dpkg-buildpackage: warning: will probably become fatal in the future. fakeroot debian/rules clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/home/debian/tmp_libevent_compat_test/beanstalkd-1.4.6' dh_testdir mv beanstalkd.spec beanstalkd.spec_ dh_auto_clean mv beanstalkd.spec_ beanstalkd.spec make[1]: Leaving directory `/home/debian/tmp_libevent_compat_test/beanstalkd-1.4.6' dh_clean dpkg-source -b beanstalkd-1.4.6 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building beanstalkd using existing ./beanstalkd_1.4.6.orig.tar.gz dpkg-source: info: building beanstalkd in beanstalkd_1.4.6-1.debian.tar.gz dpkg-source: info: building beanstalkd in beanstalkd_1.4.6-1.dsc dpkg-genchanges -S ../beanstalkd_1.4.6-1_source.changes dpkg-genchanges: including full source code in upload dpkg-source --after-build beanstalkd-1.4.6 dpkg-buildpackage: full upload (original source is included) - Copying COW directory forking: rm -rf /home/debian/PBUILDER/build//cow.31933 forking: cp -al /home/debian/PBUILDER/base-experimental.cow /home/debian/PBUILDER/build//cow.31933 I: removed stale ilistfile /home/debian/PBUILDER/build//cow.31933/.ilist forking: chroot /home/debian/PBUILDER/build//cow.31933 cowdancer-ilistcreate /.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ' - Invoking pbuilder forking: pbuilder build --debbuildopts --debbuildopts --buildplace /home/debian/PBUILDER/build//cow.31933 --buildresult /home/debian/PBUILDER/result/ --debbuildopts --no-targz --internal-chrootexec chroot /home/debian/PBUILDER/build//cow.31933 cow-shell /home/debian/tmp_libevent_compat_test/beanstalkd_1.4.6-1.dsc I: Running in no-targz mode I: using fakeroot in build. I: Current time: Sat Jun 18 18:05:04 CEST 2011 I: pbuilder-time-stamp: 1308413104 I: copying local configuration ccache: failed to create /tmp/buildd/.ccache (No such file or directory) dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation) I: Mounting /var/cache/apt/archives I: Mounting /var/cache/pbuilder/ccache I: policy-rc.d already exists I: Setting up ccache I: Installing the build-deps - Attempting to satisfy build-dependencies - Creating pbuilder-satisfydepends-dummy package Package: pbuilder-satisfydepends-dummy Version: 0.invalid.0 Architecture: amd64 Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder This package was created automatically by pbuilder to satisfy the build-dependencies of the package being currently built. Depends: debhelper (= 7.0.50~), autotools-dev, libtool, libevent-dev (= 1.4.1), fiu-utils (= 0.13-3), procps, net-tools, python-minimal dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'. Selecting previously deselected package pbuilder-satisfydepends-dummy. (Reading database ... 11993 files and directories currently installed.) Unpacking pbuilder-satisfydepends-dummy (from .../pbuilder-satisfydepends-dummy.deb) ... dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring anyway as you requested: pbuilder-satisfydepends-dummy depends on debhelper (= 7.0.50~); however: Package debhelper is not installed. pbuilder-satisfydepends-dummy
Bug#632763: FTBFS with libevent 2.0 in experimental
Package: python-event Version: 0.3+svn60-3 Severity: normal Hi, After testing in a clean pbuilder, your package failed to build with the version of libevent in experimental (2.0.*). You can find a log of the build attempt attached. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-checkbuilddeps: Unmet build dependencies: python-all-dev python-all-dbg W: Unmet build-dependency in source dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package python-event dpkg-buildpackage: source version 0.3+svn60-3 dpkg-buildpackage: source changed by Luciano Bello luci...@debian.org dpkg-source --before-build python-event-0.3+svn60 dpkg-source: warning: unknown information field 'Provides' in input data in general section of control info file dpkg-checkbuilddeps: Unmet build dependencies: python-all-dev python-all-dbg dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: This is currently a non-fatal warning with -S, but dpkg-buildpackage: warning: will probably become fatal in the future. fakeroot debian/rules clean dpatch deapply-all 01_avoid_event_sigcb not applied to ./ . rm -rf patch-stamp patch-stampT debian/patched dh_testdir python setup.py clean; found system libevent for linux2 running clean rm -f build-stamp rm -f *.pyc *.pyo dh_clean install-stamp build-stamp \ install-python2.6 install-python2.7 build-python2.6 build-python2.7 \ install-debug-python2.6 install-debug-python2.7 build-debug-python2.6 build-debug-python2.7 dpkg-source -b python-event-0.3+svn60 dpkg-source: warning: unknown information field 'Provides' in input data in general section of control info file dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-source: info: using source format `1.0' dpkg-source: info: building python-event using existing python-event_0.3+svn60.orig.tar.gz dpkg-source: info: building python-event in python-event_0.3+svn60-3.diff.gz dpkg-source: warning: executable mode 0755 of 'debian/patches/01_avoid_event_sigcb.dpatch' will not be represented in diff dpkg-source: info: building python-event in python-event_0.3+svn60-3.dsc dpkg-genchanges -S ../python-event_0.3+svn60-3_source.changes dpkg-genchanges: warning: unknown information field 'Provides' in input data in general section of control info file dpkg-genchanges: not including original source code in upload dpkg-source --after-build python-event-0.3+svn60 dpkg-source: warning: unknown information field 'Provides' in input data in general section of control info file dpkg-buildpackage: source only, diff-only upload (original source NOT included) - Copying COW directory forking: rm -rf /home/debian/PBUILDER/build//cow.10479 forking: cp -al /home/debian/PBUILDER/base-experimental.cow /home/debian/PBUILDER/build//cow.10479 I: removed stale ilistfile /home/debian/PBUILDER/build//cow.10479/.ilist forking: chroot /home/debian/PBUILDER/build//cow.10479 cowdancer-ilistcreate /.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ' - Invoking pbuilder forking: pbuilder build --debbuildopts --debbuildopts --buildplace /home/debian/PBUILDER/build//cow.10479 --buildresult /home/debian/PBUILDER/result/ --debbuildopts --no-targz --internal-chrootexec chroot /home/debian/PBUILDER/build//cow.10479 cow-shell /home/debian/tmp_libevent_compat_test/python-event_0.3+svn60-3.dsc I: Running in no-targz mode I: using fakeroot in build. I: Current time: Sat Jun 18 23:31:47 CEST 2011 I: pbuilder-time-stamp: 1308432707 I: copying local configuration ccache: failed to create /tmp/buildd/.ccache (No such file or directory) dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation) I: Mounting /var/cache/apt/archives I: Mounting /var/cache/pbuilder/ccache I: policy-rc.d already exists I: Setting up ccache I: Installing the build-deps - Attempting to satisfy build-dependencies - Creating pbuilder-satisfydepends-dummy package Package: pbuilder-satisfydepends-dummy Version: 0.invalid.0 Architecture: amd64 Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org Description: Dummy package to satisfy dependencies with aptitude
Bug#632764: FTBFS with libevent 2.0 in experimental
Package: memcached
Version: 1.4.5-1
Severity: normal
Hi,
After testing in a clean pbuilder, your package failed to build with
the version of libevent in experimental (2.0.*).
You can find a log of the build attempt attached.
Cheers
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package memcached
dpkg-buildpackage: source version 1.4.5-1
dpkg-buildpackage: source changed by David Martínez Moreno en...@debian.org
dpkg-source --before-build memcached-1.4.5
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp config.log
rm -f debian/memcached.init
# Add here commands to clean up after the build process.
[ ! -f Makefile ] || /usr/bin/make distclean
dh_quilt_unpatch
No patch removed
dh_clean
dpkg-source -b memcached-1.4.5
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
dpkg-source: info: using source format `1.0'
dpkg-source: info: building memcached using existing memcached_1.4.5.orig.tar.gz
dpkg-source: info: building memcached in memcached_1.4.5-1.diff.gz
dpkg-source: info: building memcached in memcached_1.4.5-1.dsc
dpkg-genchanges -S ../memcached_1.4.5-1_source.changes
dpkg-genchanges: including full source code in upload
dpkg-source --after-build memcached-1.4.5
dpkg-buildpackage: source only upload (original source is included)
- Copying COW directory
forking: rm -rf /home/debian/PBUILDER/build//cow.18330
forking: cp -al /home/debian/PBUILDER/base-experimental.cow /home/debian/PBUILDER/build//cow.18330
I: removed stale ilistfile /home/debian/PBUILDER/build//cow.18330/.ilist
forking: chroot /home/debian/PBUILDER/build//cow.18330 cowdancer-ilistcreate /.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i '
- Invoking pbuilder
forking: pbuilder build --debbuildopts --debbuildopts --buildplace /home/debian/PBUILDER/build//cow.18330 --buildresult /home/debian/PBUILDER/result/ --debbuildopts --no-targz --internal-chrootexec chroot /home/debian/PBUILDER/build//cow.18330 cow-shell /home/debian/tmp_libevent_compat_test/memcached_1.4.5-1.dsc
I: Running in no-targz mode
I: using fakeroot in build.
I: Current time: Sat Jun 18 23:34:39 CEST 2011
I: pbuilder-time-stamp: 1308432879
I: copying local configuration
ccache: failed to create /tmp/buildd/.ccache (No such file or directory)
dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
I: Mounting /var/cache/apt/archives
I: Mounting /var/cache/pbuilder/ccache
I: policy-rc.d already exists
I: Setting up ccache
I: Installing the build-deps
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (= 6), libevent-dev, quilt (= 0.46-7)
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously deselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11993 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from .../pbuilder-satisfydepends-dummy.deb) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring anyway as you requested:
pbuilder-satisfydepends-dummy depends on debhelper (= 6); however:
Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on libevent-dev; however:
Package libevent-dev is not installed.
pbuilder-satisfydepends-dummy depends on quilt (= 0.46-7); however:
Package quilt is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
bsdmainutils{a} debhelper{a} diffstat{a} file{a} gettext{a}
gettext-base{a} groff-base{a} html2text{a} intltool-debian{a}
libcroco3{a}
Bug#632765: FTBFS with libevent 2.0 in experimental
Package: honeyd Version: 1.5c-8 Severity: normal Hi, After testing in a clean pbuilder, your package failed to build with the version of libevent in experimental (2.0.*). You can find a log of the build attempt attached. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-checkbuilddeps: Unmet build dependencies: libpcap0.8-dev | libpcap-dev libdumbnet-dev ( 1.8) libpcre3-dev rrdtool W: Unmet build-dependency in source dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package honeyd dpkg-buildpackage: source version 1.5c-8 dpkg-buildpackage: source changed by Javier Fernandez-Sanguino Pen~a j...@debian.org dpkg-source --before-build honeyd-1.5c dpkg-checkbuilddeps: Unmet build dependencies: libpcap0.8-dev | libpcap-dev libdumbnet-dev ( 1.8) libpcre3-dev rrdtool dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: This is currently a non-fatal warning with -S, but dpkg-buildpackage: warning: will probably become fatal in the future. fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp fix-doc stamp-h.in config.log [ ! -f Makefile ] || /usr/bin/make distclean rm -f doc/*.gif rm -f webserver/server.pyc test -r /usr/share/misc/config.sub \ cp -f /usr/share/misc/config.sub config.sub test -r /usr/share/misc/config.guess \ cp -f /usr/share/misc/config.guess config.guess dh_clean dpkg-source -b honeyd-1.5c dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-source: info: using source format `1.0' dpkg-source: info: building honeyd using existing honeyd_1.5c.orig.tar.gz dpkg-source: info: building honeyd in honeyd_1.5c-8.diff.gz dpkg-source: warning: the diff modifies the following upstream files: README aclocal.m4 analyze.c arp.c command.c condition.c config.c config.guess config.sample config.sub configure configure.in contrib/README contrib/base.sh contrib/honeydsum-v0.3/CHANGELOG contrib/honeydsum-v0.3/README contrib/honeydsum-v0.3/honeydsum.conf contrib/honeydsum-v0.3/honeydsum.pl contrib/telnet/cmds.txt contrib/telnet/faketelnet.pl contrib/telnet/msgs.txt contrib/unix/general/pop/POP.emulator/README contrib/unix/general/pop/POP.emulator/email.guest contrib/unix/general/pop/POP.emulator/email.msiddall contrib/unix/general/pop/POP.emulator/pop.password contrib/unix/general/pop/emulate-pop3.sh contrib/unix/general/pop/pop3.sh contrib/unix/general/rpc/bportmapd contrib/unix/general/rpc/hosts/debian contrib/unix/general/rpc/hosts/openbsd-2.8 contrib/unix/general/rpc/hosts/solaris-2.7 contrib/unix/general/smtp.pl contrib/unix/general/smtp.sh contrib/unix/general/snmp/.snmp contrib/unix/general/snmp/192.168.1.130.snmp contrib/unix/general/snmp/192.168.1.135.snmp contrib/unix/general/snmp/192.168.1.140.snmp contrib/unix/general/snmp/README contrib/unix/general/snmp/buildSNMPConfig.pl contrib/unix/general/snmp/default.snmp contrib/unix/general/snmp/fake-snmp.pl contrib/unix/general/snmp/linux-2.4.snmp.tpl contrib/unix/general/snmp/windows2000.snmp.tpl contrib/unix/general/telnet/cmds.txt contrib/unix/general/telnet/faketelnet.pl contrib/unix/general/telnet/msgs.txt contrib/unix/linux/ftp.sh contrib/unix/linux/suse7.0/apache.sh contrib/unix/linux/suse7.0/bo.sh contrib/unix/linux/suse7.0/cyrus-imapd.sh contrib/unix/linux/suse7.0/dat/wuftpd.files contrib/unix/linux/suse7.0/discard.sh contrib/unix/linux/suse7.0/echo.sh contrib/unix/linux/suse7.0/fingerd.sh contrib/unix/linux/suse7.0/ident.sh contrib/unix/linux/suse7.0/lpd.sh contrib/unix/linux/suse7.0/qpop.sh contrib/unix/linux/suse7.0/rpc.sh contrib/unix/linux/suse7.0/sendmail.sh contrib/unix/linux/suse7.0/squid.sh contrib/unix/linux/suse7.0/ssh.sh contrib/unix/linux/suse7.0/syslogd.sh contrib/unix/linux/suse7.0/telnetd.sh contrib/unix/linux/suse7.0/wuftpd.sh contrib/unix/linux/suse8.0/apache.sh contrib/unix/linux/suse8.0/cyrus-imapd.sh contrib/unix/linux/suse8.0/dat/proftpd.files contrib/unix/linux/suse8.0/fingerd.sh contrib/unix/linux/suse8.0/ident.sh contrib/unix/linux/suse8.0/lpd.sh contrib/unix/linux/suse8.0/proftpd.sh contrib/unix/linux/suse8.0/qpop.sh contrib/unix/linux/suse8.0/sendmail.sh contrib/unix/linux/suse8.0/squid.sh contrib/unix/linux/suse8.0/ssh.sh
Bug#632691: RFC: calling lrelease automatically in qmake mode
Package: debhelper Version: 8.9.0 Severity: wishlist [CC'ing original qmake module author for input] Hi, Would it be feasible to automatically call lrelease[0] if we find a TRANSLATIONS variable in any *.pro file? If the idea sounds reasonable I could try to come up with a patch (though my perl-foo is considerably rusty). The main problem I can think of is how to build a clean function, since lrelease doesn't seem to provide an easy way to remove all generated *.qm files. Cheers [0] http://doc.qt.nokia.com/latest/linguist-manager.html -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debhelper depends on: ii binutils 2.21.52.20110703-1 The GNU assembler, linker and bina ii dpkg-dev 1.16.0.3 Debian package development tools ii file 5.04-5+b1 Determines file type using magic ii html2text 1.3.2a-15 advanced HTML to text converter ii man-db2.6.0.2-1 on-line manual pager ii perl 5.12.4-1 Larry Wall's Practical Extraction ii perl-base 5.12.4-1 minimal Perl system ii po-debconf1.0.16+nmu1tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556501: Bug#622796: Bug#556501 closed by Leo Costela cost...@debian.org (Bug#556501: fixed in transmission 2.31-1)
Hi Julien, On 01/07/11 22:46, Julien Cristau wrote: any chance we could get those bugs fixed in sid soonish? The migration of transmission to sid depends on the libevent transition[0], which I'll also be doing. Unfortunately I'm a few days behind schedule. I've had a draft email to -devel open on my laptop for 3-4 days now, about a call-for-testing and a few other issues mentioned in the transition bug. As soon as that's cleared out, transmission goes to sid. When I finally get around to sending the aforementioned email (hopefully over the weekend) please feel free to jump into the discussion! Cheers [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631018 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630884: transmission: missing completeness graph inside torrent details
tag 630884 wontfix forwarded 630884 https://trac.transmissionbt.com/ticket/4325 -- Hi, On 18/06/11 13:14, Sandro Tosi wrote: from [1] at Where can I find more detailed information on my torrents? paragraph there's a nice Completeness graph showing what's already downloaded, what's missing and so on. Transmission installed from debian repo misses it: could you please enable it? Sorry to let you down, but from my talks with upstream, that particular feature has been removed for a looong time (apparently way before the 2.2* version, for which this documentation was made) and has very little chance of coming back. I did, however, ask that the image be updated in the docs, so that at least no one else will be tempted by it! :) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630789: ITP: transmission-remote-gtk -- GTK remote control for the Transmission BitTorrent client
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: transmission-remote-gtk Version : 0.5.1 Upstream Author : Alan Fitton a...@eth0.org.uk * URL : http://code.google.com/p/transmission-remote-gtk/ * License : GPL-2+ Programming Lang: C Description : GTK remote control for the Transmission BitTorrent client [from the site:] transmission-remote-gtk is a GTK application for remote management of the Transmission BitTorrent client via its RPC interface. * remotely add (file/url), start, stop, remove, remove delete, verify, reannounce torrents. * works as a .torrent handler (eg. from a web browser). * set torrent properties such as speed, seed, peer limits, file priorities, add/edit/remove trackers. * change remote settings like global limits, download directory, and connectivity preferences. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512909: about the new libpst fork
Hi Joe,
I realize you've been libpst's upstream for a while and the Debian
maintainer before that, so I hope this doesn't sound ungrateful, but
don't you think it might be a good idea incorporating the changes made
by the suggested fork[0]? Are there reasons not to do it?
I prepared some packages at[1] and it seems to solve at least one big
issue of working with newer Outlook 2003 files (with the bonus that 2003
folders with special characters seem to get generated correctly).
Hopefully this doesn't come off as me trying to steal your package or
anything, but if you don't have anything against it I'd upload it in the
coming days (but not before hearing from you, of course). Whether this
would be an NMU, an adoption or co-maintenance is also up to you.
Noteworthy changes:
- build libpst{,-dev,-dbg}
- rename readpst's binary package to pst-utils: since we now build
libpst, and the package includes more utilities than just readpst, I
felt a rename was in order.
The package is so simple you can certainly review it in a couple of minutes.
Cheers
PS.: Another less elegant option would be uploading the fork with a
different source-name, in case you still wish to keep developing your
version further.
[0] http://www.five-ten-sg.com/libpst
[1] git://git.debian.org/git/collab-maint/libpst.git
--
Leo costela Antunes
[insert a witty retort here]
Bug#630334: libnatpmp-dev: shouldn't recommend minissdpd
On 14/06/11 09:40, Thomas Goirand wrote: FYI, the package currently doesn't build in SID, due to the --no-undefined option in GCC. I'm discussing with upstream prior to another upload (of maybe, an up-to-date version). Great! Thanks a lot for the heads-up! Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630334: libnatpmp-dev: shouldn't recommend minissdpd
Package: libnatpmp-dev Version: 20101211-1 Severity: minor Tags: experimental Hi, A -dev package recommending a daemon seems a bit too much. Maybe downgrading to suggests? (IMHO lib packages in general should do neither, except for some very particular corner-cases, but this doesn't seem to be one of those) Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnatpmp-dev depends on: ii python2.6.6-14 interactive high-level object-orie Versions of packages libnatpmp-dev recommends: pn minissdpd none (no description available) libnatpmp-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630335: libnatpmp-dev: should depend on libnatpmp0 (broken .so link)
Package: libnatpmp-dev Version: 20101211-1 Severity: normal Tags: experimental Hi, Title seems pretty self-explanatory :) Incidentaly: do you think this package will make it to unstable any time soon? Been thinking of compiling one of my packages (also currently hanging in experimental) against it. Cheers -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnatpmp-dev depends on: ii python2.6.6-14 interactive high-level object-orie Versions of packages libnatpmp-dev recommends: pn minissdpd none (no description available) libnatpmp-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623998: transmission-gtk: saves dynamic binary state under .config
severity 623998 minor forwarded 623998 https://trac.transmissionbt.com/ticket/4419 -- On 25/04/11 09:55, Ian Zimmerman wrote: This package seems to save all of its state in the directory ~/.config/transmission. It should only put configuration files there, with other state saved somewhere under ~/.local. The current way makes it hard to share true configuration files among multiple machines. Agreed, but adjusting the severity, as this doesn't really impair the usage of transmission. Cheers PS.: the forwarded bug was held for moderation, so the link might not work for the next few hours/days. -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591658: closed by Leo Costela cost...@debian.org (Bug#591658: fixed in gnokii 0.6.30+dfsg-1)
Hi, On 24/04/11 13:15, Tony wrote: I have tried out this by installing the sid version on my squeeze system. It worked OK. However, I don't think this should be marked as closed until there is a working version in stable. Any idea when this will be? True, the bug should remain open while there's an affected version around. I'm not entirely sure why that doesn't seem to be the case here. Unfortunately, I'm currently really swamped and don't think I'll have the time to bissect the commit that solved this issue and apply it to the stable version. I'm not sure such a patch would even be accepted as a stable update, but I *am* pretty sure that the whole new version will only be in stable when it gets released, ~2 years from now (just guessing). However, if the sid package could be installed without pulling in other dependencies from sid (I haven't checked), this means it should be pretty easy to make a backport, as soon as the sid version enters testing. Let me know if that would be enough for your case. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623982: RFA: camorama
Package: wnpp Severity: normal Camorama hasn't really been maintained since 2007 and has been largely supplemented by cheese[0]. It's been in the bottom of my priorities list for a while, so it's only fair it gets taken care of, by someone who has a genuine interrest in it (assuming there is someone out there who fits this role). Cheers Leo costela Antunes [0] http://packages.qa.debian.org/c/cheese.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621833: System users: removing them
On 12/04/11 22:43, Scott Kitterman wrote: Also, we need to provide a way for sysadmin to know they can safely remove a stale system user. If we could do that, we could just remove them automatically and not bother the sysadmin. Not necessarily. We can't be sure there aren't any files lying around (at least not efficiently enough) to cause problems with UID reuse etc, but we may inform the admin that at least from the packaging point of view, the user/group isn't needed anymore. He can then decide to take appropriate action if he feels the house-keeping is necessary. It could simply be a matter of using the User Name/Comment field to write something like formerly used by package X; may be removed. Admittedly not strictly necessary, but nice for those cases where you check your /etc/passwd a few years later and ask yourself where that user came from. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
