Bug#890162: nautilus-image-manipulator: Please switch to python-gobject-2/python-gi
NMU welcome (I'm no longer active). Emilien Le ven. 10 janv. 2020 à 18:27, Sebastien Bacher < sebastien.bac...@canonical.com> a écrit : > tags 890162 patch > user ubuntu-de...@lists.ubuntu.com > usertags 890162 origin-ubuntu focal ubuntu-patch > > thank you > > The attached patch should fix the issue > >
Bug#866443: Info received (Replace with python-pil)
Please go ahead and NMU. Emilien Le sam. 26 janv. 2019 à 15:18, Bruno Kleinert a écrit : > Hi Emilien, > > please consider addressing this RC bug. > > Just to raise awareness: I plan to NMU with my previously attached > patch around week 7. > > Cheers - Bruno >
Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"
Yes, please do. (FYI I'm no longer a user of that software) Le ven. 11 nov. 2016 à 21:55, Sylvestre Ledru a écrit : > If you are OK, can I just upload it now? Thanks > > Le 11 nov. 2016 21:32, "Emilien Klein" a écrit : > > Ok, thanks. > > Le ven. 11 nov. 2016 20:52, Sylvestre Ledru a > écrit : > > Hello > > Because I am still facing this issue and this is causing this tool to be > useless, I uploaded as NMU with a 7 days delay. > > Sylvestre > Le 25/07/2016 à 14:14, Sylvestre Ledru a écrit : > > The attached patch fixed it. > > > > https://bugs.launchpad.net/subdownloader/+bug/1289949 provided a partial > > fix. I fixed the last issue in main.py > > > > My test didn't show other regressions but don't hesitate to double check > > (you should ;) > > > > Sylvestre > > > > > >
Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"
Ok, thanks. Le ven. 11 nov. 2016 20:52, Sylvestre Ledru a écrit : > Hello > > Because I am still facing this issue and this is causing this tool to be > useless, I uploaded as NMU with a 7 days delay. > > Sylvestre > Le 25/07/2016 à 14:14, Sylvestre Ledru a écrit : > > The attached patch fixed it. > > > > https://bugs.launchpad.net/subdownloader/+bug/1289949 provided a partial > > fix. I fixed the last issue in main.py > > > > My test didn't show other regressions but don't hesitate to double check > > (you should ;) > > > > Sylvestre > > > > > >
Bug#821656: Bumping severity of PHP 7.0 transition bugs to serious
Hi Georges, Do you have any time to look into this? I have also created a bug report at https://github.com/shaarli/Shaarli/issues/650 to see if any of the upstream developers are motivated to take this over. Best, Emilien ᐧ Emilien 2016-08-06 0:05 GMT+02:00 Petter Reinholdtsen : > Hi. > > Any news on migrating shaarli to PHP7? This package is used by the > FreedomBox, > and it would be a shame to have to drop shaarli support because the package > did not make it into testing / Stretch. > > -- > Happy hacking > Petter Reinholdtsen >
Bug#766919: [pkg-cinnamon] nautilus and open-terminal extension
Yes, please go ahead. Emilien
Bug#774382: Fwd: poor code quality in shaarli package, remove from Debian?
-- Forwarded message -- From: Emilien Klein Date: 2014-12-31 21:52 GMT-05:00 Subject: Re: poor code quality in shaarli package, remove from Debian? To: Paul Wise Cc : Debian Security , Georges Khaznadar , Julien Voisin , nodiscc Adding nodiscc in CC, the main pusher of the community fork. 2014-12-31 21:20 GMT-05:00 Paul Wise : > Hi folks, > > I was discussing the CVE issued for the shaarli package with the person > who found the issues (Julien, CCed) Can you link to that CVE? I will reported this upstream (github) to make the original upstream developer and the community fork developers aware of it. > and came to the conclusion that the > code is terrible, upstream maintenance has stopped and the package > should be removed from Debian entirely. Here is our IRC log: > > I'm quite sure that no one should use shaarli anyway. It's not > maintained, and the code is awful :/ > do you think it should be removed from Debian? > https://github.com/sebsauvage/Shaarli/ Last commit one year ago, > almost 100 issues, … > I think so, yes > https://github.com/sebsauvage/Shaarli/blob/master/index.php#L302 > seems reasonably well maintained in Debian, so I would suggest filing > a bug on the package itself about this > This is not even remotely funny. > it seems pointless but what would the downside be? > This is predictable > and > https://github.com/sebsauvage/Shaarli/blob/master/index.php#L440 looks like > an arbitrary redirect to me > Anyway, I don't care that much about this 2500LoC PHP script > there are several more instances of this in the code > yup The version currently packaged in Debian is from the [hopefully temporary] community fork [0], due to the inactivity on the side of the original developer. [0] https://github.com/shaarli/Shaarli We are working with the original developer to get things moving again [1], but he has indicated that he doesn't expect to be able to merge the community fork before spring. [1] https://github.com/sebsauvage/Shaarli/issues/191#issuecomment-68188141 The last "officially" released version is 0.0.41beta (don't ask about the versioning scheme... community fork going to 1.0 soon), the version in Debian called 0.0.42beta is the state as represented in HEAD of the official repo, but the fork is already almost 70 commits further, fixing bugs, merging pull requests made towards upstream. There is activity, as the users of Shaarli do demand that. Hence my original effort to package that in Debian. Since a large number of changes were made around/after the Jessie freeze, I am currently waiting for Jessie to be released to push for the release of a new community version, and package that in Debian. I would much rather have shaarli removed from Jessie for now, but kept in unstable/testing so that we can include the latest fixes from the community fork, and include a fix for the mentioned CVE. Is that an acceptable solution, security-wise? +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774382: Remove shaarli from Jessie
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Dear release team members, Per email discussion that will be forwarded to this bug report shortly, please remove the shaarli package from Jessie (but leave it in unstable). Thanks for your time. Please let me know if you have questions regarding this request. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773039: Unblock request sent to the Release team
> Unblock request sent to the Release team, see bug #773113. The unblock request was approved. signature.asc Description: OpenPGP digital signature
Bug#766919: nautilus and open-terminal extension
Hi Michael and the Cinnamon team, On 10/26/2014 09:50 PM, Emilien Klein wrote: > Hi Michael, > > 2014-10-26 14:22 GMT+01:00 Michael Biebl : >> Hi, >> >> a couple of days ago, we had a user stop by on #debian-gnome, who was >> confused because his nautilus had two "Open terminal" entries in the RMB >> context menu. >> >> The issue here is, that newer versions of nautilus have that feature >> built in and the user also had the nautilus-open-terminal package >> installed, resulting in the duplicated menu entry. > > Thanks for passing on the information and the result of your investigation. > >> Now that nautilus-open-terminal is no longer required to provide that >> functionality, we were wondering what to do about. >> >> Should the nautilus-open-terminal package be dropped from the archive >> and nautilus have a Conflicts: nautilus-open-terminal, so the package is >> removed on upgrades? >> Or as an alternative, nautilus-open-terminal could become an empty dummy >> package in jessie, which simply depends on a recent enough version of >> nautilus and in jessie+1 we simply drop the package. > > I'm not sure what might have been done in similar situations for other > packages: what is the cleanest way to deprecate a package whose > functionality is provided by another package? Whatever you recommend, > I'll work on that solution with e.g. the Nautilus packagers. Should we go with the alternative option proposed by Michael, making the package empty and dropping it in jessie+1? [snip] >> I've also CCed the cinnamon team. Not sure if their nautilus fork nemo >> would be affected by this and if they'd like to keep the extension for nemo. Cinnamon team, please confirm removing this Nautilus extension won't negatively impact nemo. Thanks, +Emilien signature.asc Description: OpenPGP digital signature
Bug#773039: Unblock request sent to the Release team
Unblock request sent to the Release team, see bug #773113. +Emilien signature.asc Description: OpenPGP digital signature
Bug#773113: unblock: shaarli/0.0.42~beta~dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team members, Please unblock package shaarli This package provides a web application. The application creates a data file and cached files in specific folders. Until version 0.0.42~beta~dfsg1-1, the package is not usable out of the box, as a 500 Internal Server Error is logged when accessing the page for the first time. The cause of that error is that the folders exist (they are created as part of the installation of the package), but are owned by user root instead of www-data, which is the user under which the Apache and nginx web servers run by default. In order to make the package usable without having to manually change the owner of these folders, I have released and uploaded to sid a new Debian version that sets the appropriate permissions on these folders. This is a great enhancement to the usability of the package, for which I would like to request an unblock for the package. This will ensure that Jessie users can use the sofware straight after installing it. You will notice that next to calling `chown` from debian/rules (what fixes this bug #773039), I have also made a change to the changelog, as I had noticed I had forgotten to document an important change in the last version (that the location we get the upstream tarball was changed). I trust that this change made to ensure proper documentation of the Debian package will not interfere with this unblock request. Thanks for your time. Please let me know if you have questions regarding this request. +Emilien Follows the debdiff against the package in testing: $ debdiff shaarli_0.0.42~beta~dfsg1-1.dsc shaarli_0.0.42~beta~dfsg1-2.dsc diff -Nru shaarli-0.0.42~beta~dfsg1/debian/changelog shaarli-0.0.42~beta~dfsg1/debian/changelog --- shaarli-0.0.42~beta~dfsg1/debian/changelog 2014-12-13 16:37:20.0 +0100 +++ shaarli-0.0.42~beta~dfsg1/debian/changelog 2014-12-13 16:53:18.0 +0100 @@ -1,6 +1,17 @@ +shaarli (0.0.42~beta~dfsg1-2) unstable; urgency=low + + * Fix permissions on cache and data folders (Closes: #773039) + * Fix previous changelog entry, indicating upstream change + + -- Emilien Klein Sat, 13 Dec 2014 16:40:35 +0100 + shaarli (0.0.42~beta~dfsg1-1) unstable; urgency=low * New upstream version + * d/control and d/watch: The upstream source was changed from Seb Sauvage's + inactive repository [0] to the community-maintained repository [1]. + [0] https://github.com/sebsauvage/Shaarli + [1] https://github.com/shaarli/Shaarli * d/control: - Depend on javascript-common to serve the JavaScript libraries - Update Standards-Version to 3.9.6 diff -Nru shaarli-0.0.42~beta~dfsg1/debian/rules shaarli-0.0.42~beta~dfsg1/debian/rules --- shaarli-0.0.42~beta~dfsg1/debian/rules 2014-12-13 16:37:20.0 +0100 +++ shaarli-0.0.42~beta~dfsg1/debian/rules 2014-12-13 16:40:17.0 +0100 @@ -17,6 +17,11 @@ chmod 644 debian/shaarli/usr/share/shaarli/inc/* chmod 644 debian/shaarli/usr/share/shaarli/tpl/* chmod 644 debian/shaarli/usr/share/shaarli/index.php + # Make the web server user the owner of the cache and data directories + chown www-data:www-data debian/shaarli/var/lib/shaarli/data + chown www-data:www-data debian/shaarli/var/cache/shaarli/cache + chown www-data:www-data debian/shaarli/var/cache/shaarli/pagecache + chown www-data:www-data debian/shaarli/var/cache/shaarli/tmp %: dh $@ --with apache2 unblock shaarli/0.0.42~beta~dfsg1-2 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769348: biomaj-watcher: Should /var/lib/tomcat8/shared exist?
TLDR: Please check if the "/var/lib/tomcat8/shared" folder is still used with Tomcat 8. I have applied the previously attached patch, the package builds fine, but when installing the .deb the following error occurs: Setting up biomaj-watcher (1.2.2-2) ... Updating Context.xml... Configuration complete cp: cannot create regular file ‘/var/lib/tomcat8/shared/biomaj.jar’: No such file or directory dpkg: error processing package biomaj-watcher (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: biomaj-watcher E: Sub-process /usr/bin/dpkg returned an error code (1) The cause of the issue is that there is no "shared" folder in /var/lib/tomcat8/ When creating that folder manually, the package installation/configuration completes succesfully. I wanted to test if that folder needed to exist, or if Tomcat 8 even looks at that location. Unfortunately, when accessing http://localhost:8080/BmajWatcher per d/README.Debian, I get a Tomcat 404 error message with a description that "The requested resource is not available." Since I have no experience with Tomcat, I haven't tried to go deeper in the configuration. Maybe you have a quick hint on how to configure Tomcat so that I could try to go further. But even if that page worked I'm not sure I could validate that the "shared" folder is used appropriately. Please validate that. +Emilien signature.asc Description: OpenPGP digital signature
Bug#736120: Update on bug#736120
Hi,
Using version 2.0.2 on a sid box, with the same key that I used in
post#2, I do get a different traceback, which seems unrelated:
Really sign key? [y/N] y
command: ['gpg', '--command-fd', '0', '--with-fingerprint',
'--list-options',
'show-sig-subpackets,show-uid-validity,show-unusable-uids,show-unusable-subkeys,show-keyring,show-sig-expire',
'--status-fd', '2', '--quiet', '--batch', '--fixed-list-mode',
'--no-tty', '--with-colons', '--use-agent', '--secret-keyring',
'/home/emilien/.gnupg/secring.gpg', '--homedir', '/tmp/pygpg-s5Sx9O',
'--sign-key', 'Stefano Zacchiroli ']
SKIPPED: [GNUPG:] KEYEXPIRED 1417438220
Traceback (most recent call last):
File "/usr/bin/monkeysign", line 41, in
u.main()
File "/usr/lib/python2.7/dist-packages/monkeysign/cli.py", line 70, in
main
self.sign_key()
File "/usr/lib/python2.7/dist-packages/monkeysign/ui.py", line 305, in
sign_key
if not self.tmpkeyring.sign_key(pattern, alluids):
File "/usr/lib/python2.7/dist-packages/monkeysign/gpg.py", line 482,
in sign_key
raise GpgRuntimeError(self.context.returncode, _('cannot select uid
for signing: %s') % e.found().decode('utf-8'))
monkeysign.gpg.GpgRuntimeError: [Errno 0] cannot select uid for signing:
[GNUPG:] KEYEXPIRED 1417438220
The weird thing is that neither my key (I just signed 3 other keys
without issues) nor the key that I'm signing have expired.
As I don't know if this traceback occurs before or after the place where
the original issue occurred, I can't really confirm if the issue is fixed.
Let me know if I can provide extra information for you to reproduce.
+Emilien
signature.asc
Description: OpenPGP digital signature
Bug#773039: shaarli: Unusable after install due to incorrect folder permissions out of the box
Package: shaarli
Version: 0.0.42~beta~dfsg1-1
Severity: serious
Justification: Policy 10.7.3
After installing shaarli from Testing on a new machine, a 500 Internal Server
Error is logged when accessing the page for the first time.
>From /var/log/nginx/error.log:
2014/12/13 14:39:27 [error] 10171#0: *29 FastCGI sent in stderr: "PHP message:
PHP Fatal error: Uncaught exception 'RainTpl_Exception' with message 'Cache
directory /var/cache/shaarli/tmp/doesn't have write permission. Set write
permission or set RAINTPL_CHECK_TEMPLATE_UPDATE to false. More details on
http://www.raintpl.com/Documentation/Documentation-for-PHP-developers/Configuration/'
in /usr/share/raintpl/inc/rain.tpl.class.php:321
Stack trace:
#0 /usr/share/raintpl/inc/rain.tpl.class.php(274):
RainTPL->compileFile('install', NULL, 'tpl/install.htm...',
'/var/cache/shaa...', '/var/cache/shaa...')
#1 /usr/share/raintpl/inc/rain.tpl.class.php(164):
RainTPL->check_template('install')
#2 /usr/share/shaarli/index.php(674): RainTPL->draw('install')
#3 /usr/share/shaarli/index.php(2107): pageBuilder->renderPage('install')
#4 /usr/share/shaarli/index.php(108): install()
#5 {main}
thrown in /usr/share/raintpl/inc/rain.tpl.class.php on line 321" while
reading response header from upstream, client: 127.0.0.1, server: _, request:
"GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host:
"127.0.0.1"
The permission on the /var/cache/shaarli/tmp folder is incorrectly set (root
instead of www-data, which is the user under which the Apache and nginx web
servers run by default).
In fact, the following folders should also be writable by www-data:
/var/lib/shaarli/data
/var/cache/shaarli/cache
/var/cache/shaarli/pagecache
The following fixes this issue:
sudo chown www-data:www-data /var/lib/shaarli/data /var/cache/shaarli/cache
/var/cache/shaarli/pagecache /var/cache/shaarli/tmp
Justification for severity "serious":
>From the bug severity description [0]:
serious
is a severe violation of Debian policy (roughly, it violates a must or required
directive), or, in the package maintainer's or release manager's opinion, makes
the package unsuitable for release.
In my opinion, a package should (as much as possible, i.e. not "must") work out
of the box. This is somewhat mentioned in section 10.7.3 of the Debian Policy
Manual [1]:
"Ideally the sysadmin should not have to do any configuration other than that
done (semi-)automatically by the postinst script."
+Emilien
[0] https://www.debian.org/Bugs/Developer#severities
[1] https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages shaarli depends on:
ii javascript-common 11
ii libjs-jquery 1.7.2+dfsg-3.2
ii libjs-jquery-lazyload 1.7.2-1
ii libjs-jquery-ui1.10.1+dfsg-1
ii php5 5.6.3+dfsg-1
ii php5-fpm 5.6.3+dfsg-1
ii php5-gd5.6.3+dfsg-1
ii raintpl2.7.2-1
Versions of packages shaarli recommends:
ii nginx-full [httpd] 1.6.2-5
shaarli 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#750910: Fwd: Untagging jessie
FYI: I have removed the "jessie" tag, as - the Jessie Freeze policy in effect (i.e. not reasonable to have the new upstream version 1.1.0-1 that's in Git be included in Jessie) - the package is already removed from Testing (on 2014-07-18) Cheers, +Emilien signature.asc Description: OpenPGP digital signature
Bug#739637: Abandoning Everpad ITP
FYI I am no longer actively using Evernote, and thus Everpad. My initial work on the Debian package can still be found at https://github.com/e2jk/everpad/tree/debian The Ubuntu PPA also still exists, if that can be of any help, see https://github.com/nvbn/everpad#installation +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766316: [Python-apps-team] Bug#766316: Unable to reproduce
Just confirming that: - there is an issue with locating the compiled translation files, as it looks in the relative folder "locale" instead of "/usr/share/locale". Reported in bug #767036. - forcing the *language* (not the locale) to French through the settings didn't change the result: the file downloaded just fine in the folder containing the accent. +Emilien signature.asc Description: OpenPGP digital signature
Bug#767036: subdownloader: Translation files not loaded correctly
Package: subdownloader Version: 2.0.18-1 Severity: important The subdownloader package in Debian seems to not properly locate the compiled .mo translations files: $ subdownloader -d [22:15] DEBUG::subdownloader.gui.main # Scanning translation files .mo in folder: locale [22:15] DEBUG::subdownloader.gui.main # Found these translations languages: [] [22:15] DEBUG::subdownloader.gui.main # Interface language: en The code in question lives in gui/main.py: def SetupInterfaceLang(self): if platform.system() == "Linux": if self.programFolder == '/usr/share/subdownloader': localedir = '/usr/share/locale/' else: localedir = 'locale' else: localedir = 'locale' #Get the local directory since we are not installing anything #local_path = os.path.realpath(os.path.dirname(sys.argv[0])) #print local_path Since in Debian self.programFolder is not /usr/share/subdownloader but /usr/share/pyshared/subdownloader, it defaults back to the relative "locale" folder. The Debian package should patch the 3rd line to adapt for the correct value of self.programFolder. Marking the bug as important, as non-English users might have problems using the program. (note that even after patching this, it looks like part of the UI is still in English. another issue might be causing that) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16-3-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages subdownloader depends on: ii python 2.7.8-1 ii python-crypto2.6.1-5+b1 ii python-kaa-metadata 0.7.7+svn4596-4 pn python:any Versions of packages subdownloader recommends: ii python-qt4 4.11.2+dfsg-1 subdownloader 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#766316: Unable to reproduce
Running a en_US locale (see below), I have created a folder called
~/Téléchargements/ and symlinked a file in that folder. The subtitle is
downloaded correctly without the mentioned Exception.
This is the relevant extract when running subdownloader in debug mode:
$ subdownloader -d
[snip]
[22:08] DEBUG::subdownloader.gui.main # Downloading to:
u'/home/emilien/T\xe9l\xe9chargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.gui.main # Trying to download subtitle
'/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.gui.main # Downloading subtitle
'/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt'
[22:08] DEBUG::subdownloader.httpsearch.OSHttpSearch # Downloading
subtitle from url:
http://www.opensubtitles.org/en/download/file/1954435660.gz
[22:08] DEBUG::subdownloader.httpsearch.OSHttpSearch # Unpacking and
savinng to:
/home/emilien/Téléchargements/DDLValley.rocks_The.Rise.and.Rise.of.Bitcoin.2014.HDRip.XviD.AC3-EVO.srt
Sylvestre, do you have any idea how to reproduce this bug?
Could you try to run the program with the English locale and that folder
with an accent in its name, and tell us if the same Traceback occurs?
$ LANG=en_US.UTF-8 subdownloader -d
See below for further tests I've tried.
Note that when running the program as previously mentioned, I do see the
é character nicely in the folder tree structure on the left side of the
user interface.
I have performed a new test, this time "forcing" the locale to French
(while not having it installed on my dev system):
emilien@debiansid:~/Téléchargements$ LANG=fr_FR.UTF-8 subdownloader -d
[22:15] DEBUG::subdownloader.gui.main # Building main dialog
[22:15] DEBUG::subdownloader.gui.main # Showing main dialog
[22:15] DEBUG::subdownloader.gui.main # Scanning translation files .mo
in folder: locale
[22:15] DEBUG::subdownloader.gui.main # Found these translations
languages: []
[22:15] DEBUG::subdownloader.gui.main # Interface language: en
[22:15] DEBUG::subdownloader.gui.main # Current directory:
/home/emilien/Tlchargements
[22:15] DEBUG::subdownloader.SDService.SDService # Creating Server with
server = None and proxy = None
[22:15] DEBUG::subdownloader.SDService.SDService # Creating XMLRPC
server connection... to server http://api.opensubtitles.org/xml-rpc with
proxy None
[22:15] DEBUG::subdownloader.SDService.SDService # Connecting with
parameters ('http://api.opensubtitles.org/xml-rpc', None)
[22:15] DEBUG::subdownloader.WebService # successfully tested connection
[22:15] DEBUG::subdownloader.SDService.SDService # Trying direct
connection...
[22:15] DEBUG::subdownloader.SDService.SDService # ...connected
[22:15] DEBUG::subdownloader.SDService.SDService # connection connected
[22:15] DEBUG::subdownloader.SDService.SDService # Creating Server with
server = None and proxy = None
[22:15] DEBUG::subdownloader.SDService.SDService # Creating XMLRPC
server connection... to server http://sddb.subdownloader.net/xmlrpc/
with proxy None
[22:15] DEBUG::subdownloader.SDService.SDService # Connecting with
parameters ('http://sddb.subdownloader.net/xmlrpc/', None)
[22:15] DEBUG::subdownloader.WebService # successfully tested connection
[22:15] DEBUG::subdownloader.SDService.SDService # Trying direct
connection...
[22:15] DEBUG::subdownloader.SDService.SDService # ...connected
[22:15] DEBUG::subdownloader.SDService.SDService # connection connected
[22:15] DEBUG::subdownloader.SDService.SDService #
[22:15] DEBUG::subdownloader.SDService.SDService # Logging in (username:
)...
[22:15] DEBUG::subdownloader.SDService.SDService # Login ended in 0.035
with status: 200 OK
[22:15] DEBUG::subdownloader.SDService.SDService # Session ID:
vlpf67sdhldsunvmumo1loqm26
[22:15] DEBUG::subdownloader.SDService.SDService #
The program starts correctly, connects to the server, but:
- The user interface is in English
- The folder that is supposed to have the accent is displayed as
"Tlchargement" in the folder structure.
When clicking on that folder, an exception occurs:
[22:17] DEBUG::subdownloader.FileManagement.FileScan # Scanning:
/home/emilien/Tlchargements
Traceback (most recent call last):
File "/usr/share/pyshared/subdownloader/gui/main.py", line 944, in
onFolderTreeClicked
self.SearchVideos(folder_path)
File "/usr/share/pyshared/subdownloader/gui/main.py", line 781, in
SearchVideos
videos_found,subs_found = FileScan.ScanFilesFolders(path,recursively
= True,report_progress = self.progress)
File "/usr/share/pyshared/subdownloader/FileManagement/FileScan.py",
line 50, in ScanFilesFolders
all_subs_found +=
ScanSubtitlesFolder(os.path.dirname(path),recursively =
False,report_progress=report_progress, progress_end=progress_end)
File "/usr/share/pyshared/subdownloader/FileManagement/FileScan.py",
line 124, in ScanSubtitlesFolder
Bug#766919: nautilus and open-terminal extension
Hi Michael, 2014-10-26 14:22 GMT+01:00 Michael Biebl : > Hi, > > a couple of days ago, we had a user stop by on #debian-gnome, who was > confused because his nautilus had two "Open terminal" entries in the RMB > context menu. > > The issue here is, that newer versions of nautilus have that feature > built in and the user also had the nautilus-open-terminal package > installed, resulting in the duplicated menu entry. Thanks for passing on the information and the result of your investigation. > Now that nautilus-open-terminal is no longer required to provide that > functionality, we were wondering what to do about. > > Should the nautilus-open-terminal package be dropped from the archive > and nautilus have a Conflicts: nautilus-open-terminal, so the package is > removed on upgrades? > Or as an alternative, nautilus-open-terminal could become an empty dummy > package in jessie, which simply depends on a recent enough version of > nautilus and in jessie+1 we simply drop the package. I'm not sure what might have been done in similar situations for other packages: what is the cleanest way to deprecate a package whose functionality is provided by another package? Whatever you recommend, I'll work on that solution with e.g. the Nautilus packagers. > Julien, you seem to be most active uploader of that package, so your > input would be appreciated. Julien has transitioned the package to me in 2011 as he was not using Gnome/Nautilus anymore at that time already, and he has let me know that he is very much inactive in Debian at this moment. I am thus moving him to BCC (that way, he gets my response, but won't be on the rest of the email chain. He could still reply to this message if he wanted to jump in the discussion). > I've also CCed the cinnamon team. Not sure if their nautilus fork nemo > would be affected by this and if they'd like to keep the extension for nemo. Thanks. I have opened bug #766919 against nautilus-open-terminal to track this discussion, and the chosen solution. Cheers, +Emilien signature.asc Description: OpenPGP digital signature
Bug#766919: Fwd: nautilus and open-terminal extension
Forwarded Message Subject: nautilus and open-terminal extension Date: Sun, 26 Oct 2014 14:22:40 +0100 From: Michael Biebl To: pkg-gnome-maintain...@lists.alioth.debian.org, nautilus-open-termi...@packages.debian.org, jul...@debian.org, pkg-cinnamon-t...@lists.alioth.debian.org Hi, a couple of days ago, we had a user stop by on #debian-gnome, who was confused because his nautilus had two "Open terminal" entries in the RMB context menu. The issue here is, that newer versions of nautilus have that feature built in and the user also had the nautilus-open-terminal package installed, resulting in the duplicated menu entry. Now that nautilus-open-terminal is no longer required to provide that functionality, we were wondering what to do about. Should the nautilus-open-terminal package be dropped from the archive and nautilus have a Conflicts: nautilus-open-terminal, so the package is removed on upgrades? Or as an alternative, nautilus-open-terminal could become an empty dummy package in jessie, which simply depends on a recent enough version of nautilus and in jessie+1 we simply drop the package. Julien, you seem to be most active uploader of that package, so your input would be appreciated. I've also CCed the cinnamon team. Not sure if their nautilus fork nemo would be affected by this and if they'd like to keep the extension for nemo. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766919: nautilus-open-terminal obsolete now that Nautilus provides this functionality out of the box
Package: nautilus-open-terminal Severity: important See next post for forwarded information, and discussion on how to best handle this situation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766316: [Python-apps-team] Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"
That sounds similar, but a tad different than #606993 and associated Launchpad bugs LP#913453 and LP#306589. Those were fixed by the 2.0.14-1.1 NMU upload, and the patch was applied upstream. I have removed that patch from the newest 2.0.18-1 package, as it is included in the upstream sources. This actual Exception is thrown when trying to log an error, which message would contain the path. The code path just prior to that error being logged is the following: #Check if we have write permissions, otherwise show warning window while True: #If the file and the folder don't have writte access. if not QFileInfo(destinationPath).isWritable() and not QFileInfo(QFileInfo(destinationPath).absoluteDir().path()).isWritable() : Sylvestre, I assume that folder exists, and that you have write access to it (please confirm), but a potential encoding issue in the destinationPath variable could result in either of these statements to return False: QFileInfo(destinationPath).isWritable() QFileInfo(QFileInfo(destinationPath).absoluteDir().path()).isWritable() I will try to reproduce. +Emilien
Bug#639003: Linking to Launchpad bug
Similar to LP#852321. I'll look into creating -gui and -cli packages after the freeze and release of the newest Debian version. +Emilien
Bug#687126: SubDownloader package in Debian
Correct. I have already made the current version's Debian source package Lintian clean in the subversion repository. I will in the coming days take care of updating to the latest upstream version. +Emilien 2014-10-18 10:43 GMT+02:00 Sylvestre Ledru : > Ok, thanks. That is appreciated. > > Emilien, the freeze is in 2 weeks. we need to make progress in the next few > days. :) > > Sylvestre > > > > On 28/09/2014 09:32, Marco Rodrigues wrote: > > Hi Emilien, > > I'm OK with that, you can take the maintainer role of SubDownloader package. > > Cheers. > > -- > Marco Rodrigues > http://lu.linkedin.com/in/gothicx > > On Sat, Sep 27, 2014 at 3:29 PM, Emilien Klein > wrote: >> >> Hi Marco, >> >> 2012-11-23 21:38 GMT+01:00 Emilien Klein : >> > Hello Marco Rodrigues, >> [snip] >> > Since the latest update of the package in Debian is almost 2 years >> > old, I wanted to check if you were still interested in maintaining it, >> > or if I should propose my help in maintaining the SubDownloader >> > package in Debian. I am a Debian Maintainer (i.e. not [yet] a DD), so >> > I can't directly update new packages, but I'd like to help maintain >> > SubDownloader if you need help/don't have time to take care of it >> > anymore. >> >> Are you OK if I take maintainer role over from you for SubDownloader in >> Debian? >> >> Cheers, >>+Emilien > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687126: SubDownloader package in Debian
Hi Marco, 2012-11-23 21:38 GMT+01:00 Emilien Klein : > Hello Marco Rodrigues, [snip] > Since the latest update of the package in Debian is almost 2 years > old, I wanted to check if you were still interested in maintaining it, > or if I should propose my help in maintaining the SubDownloader > package in Debian. I am a Debian Maintainer (i.e. not [yet] a DD), so > I can't directly update new packages, but I'd like to help maintain > SubDownloader if you need help/don't have time to take care of it > anymore. Are you OK if I take maintainer role over from you for SubDownloader in Debian? Cheers, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762136: RM: gnuhealth -- ROM; Strict dependency on Tryton version and incompatible release schedules
Package: ftp.debian.org Severity: normal Please remove gnuhealth from the unstable repositories (it was already auto-removed from testing) GNU Health depends strictly on Tryton releases, but the release schedule for both projects align very poorly. This results in gnuhealth blocking the progression of tryton to testing 5 months out of 6, and also means that no new version can be uploaded to unstable in that period. More details and discussion about the removal can be read at: https://lists.debian.org/debian-med/2014/06/msg00056.html Thanks, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760747: Remove Julien Valroff from nautilus-open-terminal Uploaders
Package: nautilus-open-terminal Severity: minor Requested in private email by Julien (added in CC for him to confirm on this bug report) +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760744: xmousepos not in mentioned in xautomation manpage
The last sentence was supposed to mention xmousepos instead: 2014-09-07 15:02 GMT+02:00 Emilien Klein : > But it doesn't mention xautomation itself. But it doesn't mention xmousepos itself. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760744: xmousepos not in mentioned in xautomation manpage
Package: xautomation Version: 1.03-1.1 Severity: normal The xautomation package provides the xmousepos binary. xmousepos itself has a manpage (written by the maintainer), which is great. The xautomation manpage mentions that the package consists in the following programs: pat2ppm patextract png2pat rgb2pat visgrep xte But it doesn't mention xautomation itself. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748561: GNU Health autoremove from testing
Hi team, read below for an important announcement regarding the GNU Health package in Debian. 2014-06-02 23:28 GMT+02:00 Emilien Klein : > Piuparts identified this bug in March, and I haven't taken the time to > fully address the issue that only happens in certain locales it seems > (I've not encountered it in all my installations) > > The solution will be either to: > - review the encoding of the database (`psql -l` to check it) The encoding of the database is already Unicode, nothing to change there (I already had the assumption that dbconfig-common does the right thing) > - only initialize a limited number of GNU Health Tryton modules, point 2 in > [0]. That doesn't work, since the "bug" in not in a GNU Health provided file, but in the initializing of the "ir" module, which is provided by Tryton upstream. Since the Tryton Debian package isn't creating a database as part of their packaging efforts, they never hit this issue (which, as I've explained, I've never seen myself, but piuparts somehow does). Based on the various discussions with the Tryton Debian maintainer, I don't expect the Tryton package will start creating its own database anytime soon, and as such they will not see/fix this bug. I will mention this one more time for good measure. In order to pass piuparts, the only solution is to not initialize the database at all. Tryton will not recognize an empty (as in, not Tryton-initialized) Postgres database. Thus, there is no need anymore to create the database using dbconfig-common for the gnuhealth-server package. Creating, but more importantly upgrading and backing up the database was the main driver for the existence of the gnuhealth-server package. The gnuhealth-client package was created as a shell to allow for easy and user-friendly (including creation of a Tryton profile which links to the specific GNU Health Tryton server, a .desktop file with an icon that end users [nurses, doctors, etc.] could just double-click). But since there is no ready-to-use database anymore, the need for this client package also dissapears. Starting with version 2.4.1-3 of the GNU Health package in Debian, there will thus only be one binary package (`gnuhealth`) produced, which will contain the server-side components (Tryton modules) and nothing else. I am a bit sad to remove what I still consider to be a functional and user-friendly packaging: Just apt-get install gnuhealth, enter your chosen password and you're ready to go with a database that will be upgraded and backed up automatically for you, should you forget to do so (you obviously had the option to respond "no" when prompted if the package should maintain the database for you, and you are always free/encouraged to run your own backups of your databases) With the new GNU Health package, you will have to: - set up your Tryton server manually (see the lengthy manual steps at [0], which among other things includes having to modify your PostgreSQL config files manually), - create your database (granted, not too difficult since it can be done in the Tryton client) - more worryingly, make sure that each user has to apply the upstream-provided scripts and back their database up (don't tell me all the users will do that without ever missing a step...) But on the other hand I'm not that sad, since: - it was a very interesting learning project, allowing me to understand dbconfig-common - it's not like it's a super-used package: popcon had an all-time record of 3 installs (and that's including 2 on my test and devel boxes, I assume) - it will still help the user a little bit by not having to download, unpack and install new tarballs, and uninstalling a Debian package is much easier than a PIP-installed sofware ;) Should anyone in the future want to see how the user-friendly package used to work, please look at the Debian-med subversion repository prior to revision 17092 [1]. The new version 2.4.1-3 is pushed to Subversion. Could one of the Debian-med DDs please upload it to unstable? (will close the Serious bug #748561 which, if left open, would mean the complete removal of gnuhealth in sid in less than 2 weeks). The packages gnuhealth-server and gnuhealth-client will have to be removed from sid (and from testing once the new package migrates to testing). I'd appreciate a pointer to understand who I should ask that to. Thanks everybody for your input and help on this package! +Emilien [0] http://anonscm.debian.org/gitweb/?p=tryton/tryton-server.git;a=blob_plain;f=debian/tryton-server.README.Debian;hb=HEAD [1] http://anonscm.debian.org/viewvc/debian-med?view=revision&revision=17092 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748561: GNU Health autoremove from testing
Per "chance" I'm just stumbling on bug #748561 (I unsubscribed from debian-med-packag...@lists.alioth.debian.org due to volume a while ago, seems like I should reconsider). Piuparts identified this bug in March, and I haven't taken the time to fully address the issue that only happens in certain locales it seems (I've not encountered it in all my installations) The solution will be either to: - review the encoding of the database (`psql -l` to check it) - only initialize a limited number of GNU Health Tryton modules, point 2 in [0]. The second solution still might leave a bug around in case the user wants to initialize that other module, so the final solution might have to be a mix of both. The newest version of GNU Health will be out on July 6th [1], which is after the autoremoval date. I'll test the various possibilities this week. +Emilien [0] https://lists.debian.org/debian-med/2014/03/msg00208.html [1] http://lists.gnu.org/archive/html/health-dev/2014-05/msg8.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748223: Adding jquery-lazyload to the list
I've added jquery-lazyload to that list, as we've discussed that as well on the javascript mailing list. http://packages.qa.debian.org/j/jquery-lazyload.html properly detects new version 1.9.3, while http://udd.debian.org/dmd/?email1=&email2=&email3=&packages=node-jsconfig+node-jsdom+node-postgres+pdf.js+rainbow.js+step.js+wax.js+jquery-lazyload&ignpackages=&format=html#todo shows "error" +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725665: nautilus-image-manipulator is marked for autoremoval from testing
Hi Andreas and the python-nautilus maintainer, I have just installed nautilus-image-manipulator in a fresh Sid installation (came with nautilus and python-nautilus as dependencies) and I didn't have any issues of any kind running nautilus and the extension. I assume this bug was indeed fixed with package 1.1-4? Please mark this bug as closed, to prevent the automatic removal of the python-nautilus package from testing planned in two weeks. On 04/09/2014 06:39 AM, Debian testing autoremoval watch wrote: > nautilus-image-manipulator 1.3-1.1 is marked for autoremoval from testing on > 2014-04-29 > > It (build-)depends on packages with these RC bugs: > 725665: python-nautilus: ImportError: could not import gobject (could not > find _PyGObject_API object) > The removal of python-nautilus from testing also implies the removal of the following packages that depend on it: - gnome3-emblems - nautilus-compare - nautilus-image-manipulator (which I maintain) - nautilus-pastebin - rabbitvcs - tortoisehg (reason I've CC'd the primary maintainers of these packages) Thanks, +Emilien signature.asc Description: OpenPGP digital signature
Bug#743252: Multiples XSS in index.php
I have been granted upload rights for Shaarli by Georges, and have uploaded the package to ftp-master. Should anything in particular be done (e.g. pushing directly to testing?) or does this follow the regular upload process? +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743252: Multiples XSS in index.php
Hi David, Salvatore and Georges, 2014-04-01 20:24 GMT+02:00 Salvatore Bonaccorso : > Hi, > > On Mon, Mar 31, 2014 at 06:38:55PM -0400, David Prévot wrote: >> Package: shaarli >> Version: 0.0.41~beta~dfsg2-3 >> Severity: grave >> Tags: security patch upstream >> Control: forward -1 https://github.com/sebsauvage/Shaarli/issues/134 >> Control: tag -1 fixed-upstream >> >> Hi, >> >> A security issue has been fixed a few months ago: >> >> https://github.com/sebsauvage/Shaarli/commit/53da201749f8f362323ef278bf338f1d9f7a925a >> >> Thanks in advance for updating the Debian package. > > A CVE was assigned for these XSS issues: CVE-2013-7351. Please include > this reference also in your changelog when fixing the issue. I have prepared the new package with the fix for the security vulnerability in Shaarli's collab-maint git repo [0]. As I don't have upload rights (I'm a Debian maintainer, Georges did the upload of the previous versions), can one of you take care of uploading the package? I suppose this would work (see file debian/README.source) $ git clone ssh://@git.debian.org/git/collab-maint/shaarli.git $ cd shaarli $ git checkout -b pristine-tar remotes/origin/pristine-tar $ git checkout -b upstream remotes/origin/upstream $ git checkout -b dfsg_clean remotes/origin/dfsg_clean $ git checkout master >From this point on you should be able to build the package with: $ git-buildpackage And then upload it to the archive. Let me know how I can help further. Note: I will be out of the country for the next 3 days starting tomorrow 06:30, email response might be delayed. In case an NMU or other action would be required on your side to fix this security issue, I preemptively approve it. +Emilien [0] http://anonscm.debian.org/gitweb/?p=collab-maint/shaarli.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742805: nautilus-image-manipulator: diff for NMU version 1.3-1.1
I am fine with your NMU. Thanks for taking care of it. No need to delay more if you want. +Emilien 2014-04-01 11:43 GMT+02:00 Luca Falavigna : > tags 742805 + patch pending > thanks > > > Dear maintainer, > > I've prepared an NMU for nautilus-image-manipulator (versioned as 1.3-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Regards, > Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
2014-03-27 13:50 GMT+01:00 Mathias Behrle : > * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System > user for the server" (Thu, 27 Mar 2014 13:06:53 +0100): >> You are correct that having 2 running Tryton servers is not >> helpful/wise. That is why having a service-less Tryton package would >> be very helpful in this case (cf link in my previous post) > > Nice;) You claim, that you want to provide a package with minimal user > interaction for gnuhealth, but ask the 'original' package providing the server > to do the contrary... Yes and no: I do want the user to have as less automatic steps to do as possible. If that means us (technical maintainers) doing a little bit of extra work, that is worth it. We do the hard work in Debian, so that the user doesn't have to. That is the whole interest of the package, otherwise let's just have the user unzip a tarball and do the same configuration steps anyway on their own... >> To me, if a user is going to install GNU Health, they do it for >> medical reasons. They will also take care of the ERP side of running >> the hospital using Tryton, but they won't be running a separate Tryton >> server for that. They'll do it in the same Tryton server that is >> running for GNU Health. > > You are doing heavy assumptions on users. This is exactly the way, you are > narrowing the possible target audience of your package. I could describe a lot > of scenarios where your assumptions will proove to be wrong. Making assumptions is part of a Debian Maintainer's role. We are setting the software up, to lift most of the burden off our user's shoulder. My target is supporting any hospital that wants to use GNU Health. The only assumption that is relevant for this bug report is that they are not yet using Tryton to do their ERP work: - If they don't use Tryton already, then there is no issue at all. - If they were to use Tryton: 1. They would not install GNU Health directly onto their production server, without first testing on a test machine 2. If they decide to go on, they would have to decide whether to use 2 different Tryton servers, or to merge them both on one. A. If they keep 2 servers, it would be best to separate them (virtualization, containerization, or just other physical hardware). That is just standard security practice. B. If they want to have just one server, they'll have to either create a new database on their existing instance and shut the GNU Health startup deamon off, or move the existing Tryton database off to the new GNU Health server Regardless of what option they choose, they'll have to figure out what works best for them. In any case, having the GNU Health package create its own user, and run under that (if they so choose to use the service provided by the gnuhealth-server package, that is) doesn't have any impact on the user. Regardless of whatever assumption you think is being made. >> As mentioned, I consider the Tryton server package to be in a >> "broken/unusable" state right after installation. > > To be precised. What is broken? apt-get install tryton-server (with the other modules you want) Open Tryton client on another machine Connect to your server Doesn't work >> I want the GNU >> Health package to be usable right out of the box, and be able to >> assist the users in all steps related to upgrades (such as updating >> the database models, possibly removing unused tables, etc.). > > I answered this point in #707632 [1] and don't want to repeat the arguments > here. Correct. Having the system doing automatic backups (only at upgrade time) doesn't prevent the user of making their own (hopefully much more regularly). So this added benefit is not an issue, just an extra safeguard should the user have upgraded it's system without first backing it up (you don't think that ever happens?) No need to further discuss this point here. >> I can only do that if the database is managed by the Debian package. >> To manage the database, it needs to be created by the gnuhealth >> package. As I can't fiddle with files installed by the Tryton package >> (e.g. /etc/trytond.conf) as that is obviously against Debian packaging >> conventions. This ensues that I need to have the ability to have a >> gnuhealth user that owns the database, and run a Tryton server under >> that user so that it can access the database. > > You are mixing things. Why shouldn't you be able to manage a database owned by > the tryton user? If you need a separate server configuration to be managed by > your package this can most easily be done with the -c parameter of trytond > (please have a look at the defaults file, that you are also using for the > g
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
2014-03-27 12:46 GMT+01:00 Mathias Behrle : > * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System > user for the server" (Wed, 26 Mar 2014 22:39:05 +0100): > >> The GNU Health package runs its own dedicated Tryton server, under >> that gnuhealth user, unoconv would thus run under the same user as the >> Tryton server. > > I think you are missing the point. It's because I'm coming from a different angle than you. Read on ;) > Provided you are running a tryton-server and > a gnuhealth-server under different users on the same machine, it will be > painful (read: impossible AFAIK) to run a unoconv service for both of them or > for each of them. You are correct that having 2 running Tryton servers is not helpful/wise. That is why having a service-less Tryton package would be very helpful in this case (cf link in my previous post) To me, if a user is going to install GNU Health, they do it for medical reasons. They will also take care of the ERP side of running the hospital using Tryton, but they won't be running a separate Tryton server for that. They'll do it in the same Tryton server that is running for GNU Health. As mentioned, I consider the Tryton server package to be in a "broken/unusable" state right after installation. I want the GNU Health package to be usable right out of the box, and be able to assist the users in all steps related to upgrades (such as updating the database models, possibly removing unused tables, etc.). I can only do that if the database is managed by the Debian package. To manage the database, it needs to be created by the gnuhealth package. As I can't fiddle with files installed by the Tryton package (e.g. /etc/trytond.conf) as that is obviously against Debian packaging conventions. This ensues that I need to have the ability to have a gnuhealth user that owns the database, and run a Tryton server under that user so that it can access the database. >> I will close this issue as the current situation is the best for the >> Debian users of GNU Health. >> You are obviously free to add more details and argument your position, >> should you think this presents major issues for Debian or its users. > > Done. I don't think the current way is the best way to do it. I still can't > see > the added value in using an additional system user compared to the > complications it can cause. Does my explanation below help you understand my point of view? The core of the issue is not so much the dedicated user. It's the fact that in the current situation we have 2 running Tryton servers. The GNU Health-generated one is a precondition for the ease-of-use that I want to provide to my users. If there was a service-less tryton-server package, this issue wouldn't be one. Would you be willing to accept a patch from me to do that? +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
The GNU Health package runs its own dedicated Tryton server, under that gnuhealth user, unoconv would thus run under the same user as the Tryton server. The rationale for using a separate user is explained at length at [0], short version is that I believe a Debian package should (as much as possible) be usable directly after installation, without forcing the user to edit a config file (etc/trytond.conf in this case) to make the package run. Of course, if the user has specific needs, editing the config file is always possible, but in the state I consider the Tryton package to be in a "broken/unusable" state right after installation. Only advanced/expert users know they need to go and read the content of the /usr/share/doc/tryton-server/README.Debian.gz (which they first need to uncompress to access). This is not the way to make FLOSS software reacheable to everyday-people. As suggested in [0], I would encourage the creation of a service-less tryton-server package providing the source code for the server functionality (on which GNU Health would depend), and out-of-the-box working package tryton-server-postgres and tryton-server-sqlite packages that would come with ready-to-use databases and provide a startup service. That way GNU Health can be run using it's own user (best to separate different applications using separate users, best would be to provide full containerization...) and there is no separate Tryton server running unused. I will close this issue as the current situation is the best for the Debian users of GNU Health. You are obviously free to add more details and argument your position, should you think this presents major issues for Debian or its users. +Emilien [0] https://lists.debian.org/debian-med/2013/09/msg00077.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707632: [Debian-med-packaging] Bug#707632: gnuhealth: Package layout
Matthias, we had discussed this in the past, but I hadn't taken the time to properly respond directly on the bug report. Your (welcome!) contributions on the recent discussion [0] finally forces me to take care of this topic ;) Regarding your suggestions to split the gnuhealth Debian package into one binary package for each modules, I still object to that. I see absolutely no benefit to the user to have him perform the following workflow: - Install a barebones gnuhealth-server package using APT - Launching the Tryton client, initializing the base GNU Health module (health_profile) - Testing around, determining it's missing the functionality provided by the health_blabla module - Close the client, go back to the terminal/software center - Install the gnuhealth-blabla module using APT - Restarting the Tryton client and having to select the blabla module to initialize it A workflow like this is thus much easier for the user: - Install a the gnuhealth-server package using APT - Launching the Tryton client, initializing the base GNU Health module (health_profile) - Testing around, determining it's missing the functionality provided by the health_blabla module - Stay in the Tryton client, select the blabla module to initialize it The total size of all the GNU Health modules once installed is less than 45 Mb. Disc size is thus not an issue. The modularity that makes Tryton great lies in the ability to select which modules you want to use. You can have modules installed that you don't use, so there is no problem in installing all the GNU Health modules in one package. This also alleviates the issues that you are facing, whenever a new Tryton module is released, you need to have it uploaded by a Debian Developer, and the package has to be processed in the NEW queue, etc. Please let me know if you strongly disagree, if so please give technical details on why the package should not provide all modules. If not, I will soon close this issue. Thanks for your time maintaining the Tryton modules, and reviewing the GNU Health package +Emilien [0] https://lists.debian.org/debian-med/2014/03/msg00202.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739637: Git branch to track the creation of the package
Please ignore the previous message (Fri, 28 Feb 2014 22:54:46 +0100), it was meant for package gnuhealth, bug#739657. I have started creating the Debian package. Once I've got a working package, I'll use `svn-inject -o` to maintain in as part of the Python Applications Packaging Team. Until that point, I have created a Git branch to track my changes to the package: https://github.com/e2jk/everpad/tree/debian +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739070: qa.debian.org: [new PTS] Links to developer page not working if email contains the symbol +
Thanks Christophe for your work on this, and thanks Raphael for applying it. There is indeed not a high urgency, it can wait for the final deployment. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739070: qa.debian.org: [new PTS] Links to developer page not working if email contains the symbol +
Any luck looking at this? I wasn't able to tag it as "pts", after 5 intents ;) +Emilien
Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found
Hi team, I have made the switch to use su instead of sudo [0]. Please upload gnuhealth 2.4.1-2 to unstable. On 02/24/2014 01:57 PM, Andreas Tille wrote: >> I am also open to use su instead of sudo. That's even what I first >> did, but (for some reason I can't remember) didn't get the command to >> run succesfully using su, so I switched to sudo. > > Ahh, may be you might be able to roll back and we might have a look at > this problem? I was able to reproduce my issue with su: since the user being a system user, she didn't have a shell (default shell for new system users is /bin/false). Running the commands as su --shell /bin/sh -c works as expected. >> Regardless of what comes out of the investigation and on the mentors >> ML, I will try to make it work using su, and figure if I can reproduce >> my issue with it. > > :-) Done ;) >> I look at this as a good learning moment. > > As every day if you open your eyes in the morning :-) Yes, definitely a good learning opportunity. One argument that we hadn't discussed yet, was that I would have needed not just to Depend on sudo, but Pre-Depend on it (as it's needed in the preinst maintainer script [even if it's just at upgrade moment]). Thanks for helping me in my learning experience. +Emilien [0] http://anonscm.debian.org/viewvc/debian-med?view=revision&revision=16361 signature.asc Description: OpenPGP digital signature
Bug#739637: Need help running command as another user using su
Hi, TLDR: is it possible to run a command as another user using su, if that user is a system user? I'm trying to solve bug#739637 by running the command as user gnuhealth, using the command `su` instead of `sudo`. Let's take a simple example to start, running the command whoami as another user, from a root shell. First, become root by your prefered way (I use sudo ;) ) emilien@debiansid:~$ sudo su - [sudo] password for emilien: root@debiansid:~# Running the command using sudo, I see the username being returned as expected: root@debiansid:~# sudo -u gnuhealth whoami gnuhealth Now trying to reproduce that using su. According to the manpage: su [options] [username] -c, --command COMMAND So I would expect to first have the command name su, then -c and the command to execute, and then the username. root@debiansid:~# su -c whoami gnuhealth root@debiansid:~# That doesn't return the expected output. Trying different kinds of possibilities (quoting the command, using = and putting the username before the command) doesn't give better results: root@debiansid:~# su -c "whoami" gnuhealth root@debiansid:~# su -c=whoami gnuhealth root@debiansid:~# su -c="whoami" gnuhealth root@debiansid:~# su --command whoami gnuhealth root@debiansid:~# su --command "whoami" gnuhealth root@debiansid:~# su --command=whoami gnuhealth root@debiansid:~# su --command="whoami" gnuhealth root@debiansid:~# su gnuhealth -c whoami root@debiansid:~# su gnuhealth -c "whoami" root@debiansid:~# su gnuhealth -c=whoami root@debiansid:~# su gnuhealth -c="whoami" root@debiansid:~# su gnuhealth --command whoami root@debiansid:~# su gnuhealth --command "whoami" root@debiansid:~# su gnuhealth --command=whoami root@debiansid:~# su gnuhealth --command="whoami" root@debiansid:~# The weird part is that running these commands [*] in a terminal on my Ubuntu host machine *do* return the expected username back. What could be the reason I don't get the command su to run on my Debian sid machine? Are you able to run that? Aah, wait, now that I'm typing this, I have an enlightenment: the user is created as a system user (I believed according to the instructions on the GNU Health wiki, but I can't find that back now). Could that be the reason why I can't get su to run the command as that user? User creation is done in gnuhealth-server.postinst by this command: adduser --home /var/lib/gnuhealth --quiet --system --group gnuhealth Questions: - Is it possible to run a command as another user using su, if that user is a system user? - Should the created user not be a system user? Cheers, +Emilien [*] except the variants using = with -c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739657: Maintainer scripts: execute command as another user: use sudo or su?
Hi Mentors, TLDR: in order to execute a command as another user, should `sudo` or `su --command` be used? I'd like to get your opinion on how to best solve this issue: I've got a package [0] that uses dbconfig-common to manage its database. The database is owned by a specific user (not root). In the pre- and postinst scripts, a command has to be performed as that user (e.g. make a backup of the database). I've at first used sudo to perform that, and it worked fine until piuparts found an issue [1], since (as I hadn't realized) sudo is not part of the base system (installed on 76% of popcon-reporting machines [2]) I am wondering what the best way is to fix this. I see 2 solutions: 1. Depend on sudo 2. Use "su --command" instead First lines from the respective manpages: sudo, sudoedit - execute a command as another user su - change user ID or become superuser Following the Unix philosophy of using a collection of specialized small tools that do one thing best, when performing an action as another user it seems to be the correct thing to use a tool that "execute a command as another user" rather than one whose primary goal is "change user ID or become superuser". But on the other hand, su is part of corutils (which is in the base install), so using su would remove the need of installing a new package for about 25% of our users. What are your thoughts on this? Thanks for getting a fellow Debian Maintainer out of his confusion! (and let's hope it doesn't turn into a vi vs. Emacs debate ;) ) +Emilien [0] http://pts.debian.net/pkg/gnuhealth [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739657 [2] Looking at popcon (obvious notice about [un]reliability of that data applies) data from 2014-02-24: - There are 167453 registered popcon users that sent information - corutils (package that amongst others, contains su) sports 167451 installations (99.998% of installs) [3] - sudo reports 127695 installations (76% of installs) [4] [3] http://qa.debian.org/popcon.php?package=sudo [4] http://qa.debian.org/popcon.php?package=coreutils -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found
Hi Andreas, Le 23 févr. 2014 22:30, "Andreas Tille" a écrit : > > Hi Emilien, > > On Sun, Feb 23, 2014 at 09:49:46PM +0100, Emilien Klein wrote: > > 2014-02-23 19:53 GMT+01:00 Karsten Hilbert : > > > > > > On Sun, Feb 23, 2014 at 08:38:56AM +0100, Andreas Tille wrote: > > > > > > > > Extract from the manpages: > > > > > sudo: > > > > > sudo, sudoedit - execute a command as another user > > > > > > > > I'd call this a bit confusing since sudo is the command to do something > > > > as superuser. > > > > > > Not really. It just so happens that the *default* > > > target usually is root. > > > > > > Look at "-u username". > > > > > > Correct, sudo is to perform a command as another user (by default > > root, but it can be any user you which), while su is to 'become" that > > other user (and then likely perform commands as that other user). > > > > Only those few commands (in different scripts) need to be performed as > > the database-owning user, all the rest of the process needs to be done > > by root. Using sudo is the correct way to do that. > > I will make sure to Depend on sudo. > > As I tried to express this is *not* the correct conclusion in my > opinion. Yes, I understand what you are saying. > You should use su in your scripts. OK, but why? What I'm missing so far is an explanation on why we shouldn't use sudo for this use-case. > May be you are trying > to grep /var/lib/dpkg/info for the usage of su / sudo to get some > picture what others are doing. Following the Unix philosophy of using a collection of specialized small tools that do one thing best, when performing an action as another user it seems to be the correct thing to use a tool that "execute a command as another user" rather than one whose primary goal is "change user ID or become superuser" I would be in complete agreement to not use that tool if it was either new or obscure, but I don't think this can be said of sudo. Should I ask the -devel mailing list to help us get out of our confusion? Have a great start of your week. +Emilien
Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found
I assumed/believed sudo was part of the "base" Debian system, as I don't have issues when building the package with pbuilder. I indeed want to execute those commands as the user that owns the database. I understood sudo (su DO) was meant to execute commands as another user, while su is used to "become" another user. Granted, with `su -c` you can execute a command as another user. Extract from the manpages: sudo: sudo, sudoedit - execute a command as another user su: su - change user ID or become superuser OPTIONS -c, --command COMMAND Specify a command that will be invoked by the shell using its -c. I am wondering what the most appropriate command is to perform this task. Is the solution to: - Depend on sudo - Use su to execute that command Thoughts welcome. +Emilien
Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found
Le 21 févr. 2014 21:57, "Emilien Klein" a écrit : > > This is already weird: > > populating database via scriptfile... error encountered populating database: /usr/share/dbconfig-common/scripts/gnuhealth-server/install/pgsql exited with non-zero status > > Might be to a call to sudo as well in that script. > The goal is indeed to execute the command under that other user. I know I tried with su, but for some reason that didn't work out. > I don't have my computer this weekend, I'll have a look on Monday. > > +Emilien
Bug#739637: Manpage created for Everpad
I've created a manpage and sent it upstream: https://github.com/nvbn/everpad/pull/400 +Emilien
Bug#739637: PPA Debian source package
The Debian source package from the PPA can be found here: https://launchpad.net/~nvbn-rm/+archive/ppa/+packages?field.name_filter=everpad&field.status_filter=published&field.series_filter= +Emilien
Bug#739637: ITP: everpad -- Evernote client for GNU/Linux
Package: wnpp Severity: wishlist Owner: Emilien Klein * Package name: everpad Version : 2.5 Upstream Author : Vladimir Iakovlev * URL : https://github.com/nvbn/everpad * License : MIT/Expat Programming Lang: Python Description : Evernote client for GNU/Linux Everpad allows to interact with the Evernote service right from your desktop. It supports notes, tags, notebooks, resources, places and en-* tags. Evernote does not provide a client for GNU/Linux. Everpad is one of the 3rd party clients that provide a native client for that service. It is currently available from a PPA maintained by upstream, but looking at the number of bug reports of the type [does not start] it feels like the package could benefit from a greater QA process, which Debian is known for. Also, packaging it straight into Debian means greater ease of installation for a large number of users, and would remove the need to add yet-another PPA. I hope to be able to use the base packaging from the PPA, at least for inspiration. Building on the shoulders of giants and stuff ;) I have opened an issue on upstream's GitHub [0] to track the work needed to properly package Everpad for Debian. I am open to maintain this package in a team. The most appropriate team would likely be the Python Applications Packaging Team (PAPT) [1]. As I'm a DM, not yet DD, I will need a sponsor to upload the package. [0] https://github.com/nvbn/everpad/issues/387 [1] https://wiki.debian.org/Teams/PythonAppsPackagingTeam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739070: Tagging as pts
tags: pts Thanks, +Emilien
Bug#739070: qa.debian.org: [new PTS] Links to developer page not working if email contains the symbol +
Package: qa.debian.org Severity: important Dear Maintainer, This applies to the new PTS. My email address contains a plus "+", like this: emilien+deb...@klein.st The Maintainer link to a maintainer's QA page can be invalid: Example on http://pts.debian.net/pkg/nautilus-image-manipulator the link is: http://qa.debian.org/developer.php?email=emilien+deb...@klein.st The correct link should be: http://qa.debian.org/developer.php?email=emilien%2bdeb...@klein.st Reason: the + symbol is not escape/urlencoded, the browser treats it as a space. I suppose the fix is to urlencode any link that could contain an email address. I marked this bug as important following the classification "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.". It obviously works for almost everybody, but not at all for me ;) Note: I had reported a similar issue for the mentors page: 622503 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#736120: traceback when signing --- monkeysign.gpg.GpgProtocolError
Hi Antoine, 2014-01-21 8:49 GMT+01:00 Emilien Klein : > You should have received mine just now. > Thanks for looking into it. Were you able to look into the examples Zack and I sent you? +Emilien
Bug#735536: Other workaround: downgrading gnupg
Next to zach's workaround of using monkeysign (which worked for 14 of the 16 keys I had to sign [0] [1]), another possibility is to downgrade gnupg: # apt-get install gnupg/stable (credit to odyx@d.o who suggested this to me privately) Thanks for maintaining signing-party. +Emilien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736120 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736548
Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key
Package: monkeysign Version: 1.1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** When trying to sign this particular key (2BEF0A33), I get the error message that the key is expired. This key is not expired I've been in contact with the key owner, who acknoledged that one ID had indeed been revoqued, but that the main key is still active. I'd appreciate if you could give it a look. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages monkeysign depends on: ii gnupg 1.4.16-1 ii python2.7.5-5 ii python-pkg-resources 2.0.2-1 Versions of packages monkeysign recommends: ii python-gtk2 2.24.0-3+b1 ii python-qrencode 1.01-3 ii python-zbar 0.10+doc-9+b1 ii python-zbarpygtk 0.10+doc-9+b1 monkeysign 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#736120: traceback when signing --- monkeysign.gpg.GpgProtocolError
2014/1/21 Stefano Zacchiroli > On Mon, Jan 20, 2014 at 08:01:04PM -0500, Antoine Beaupré wrote: > > If you guys could both send me, in private if you wish, the output of > > the same command with --debug, it would be very helpful. > > Will do in separate mail, thanks for your quick feedback! > You should have received mine just now. Thanks for looking into it. +Emilien
Bug#736120: traceback when signing --- monkeysign.gpg.GpgProtocolError
Package: monkeysign Version: 1.1 Followup-For: Bug #736120 Dear Maintainer, I do get the same type of error when trying to sign one particular key (ironically, Zack's). I have today signed 15 other keys successfully without this problem. This is the traceback I get (notice the different error message, containing a newline at the end): Really sign key? [y/N] y Traceback (most recent call last): File "/usr/bin/monkeysign", line 41, in u.main() File "/usr/lib/python2.7/dist-packages/monkeysign/cli.py", line 69, in main self.sign_key() File "/usr/lib/python2.7/dist-packages/monkeysign/ui.py", line 296, in sign_key if not self.tmpkeyring.sign_key(pattern, alluids): File "/usr/lib/python2.7/dist-packages/monkeysign/gpg.py", line 508, in sign_key self.context.expect(proc.stderr, 'GOT_IT') File "/usr/lib/python2.7/dist-packages/monkeysign/gpg.py", line 243, in expect return self.expect_pattern(fd, '^\[GNUPG:\] ' + pattern) File "/usr/lib/python2.7/dist-packages/monkeysign/gpg.py", line 235, in expect_pattern raise GpgProtocolError(self.returncode, 'expected "%s", found "%s"' % (pattern, line)) monkeysign.gpg.GpgProtocolError: [Errno 0] expected "^\[GNUPG:\] GOT_IT", found "gpg: moving a key signature to the correct place " emilien@debiansid:~$ Thanks for your work on monkeysign! +Emilien -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.8-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages monkeysign depends on: ii gnupg 1.4.16-1 ii python2.7.5-5 ii python-pkg-resources 2.0.2-1 Versions of packages monkeysign recommends: ii python-gtk2 2.24.0-3+b1 ii python-qrencode 1.01-3 ii python-zbar 0.10+doc-9+b1 ii python-zbarpygtk 0.10+doc-9+b1 monkeysign suggests no packages. -- no debconf information
Bug#711988: python-script-but-no-python-dep while package depends on python:any
Hi Lintian maintainers,
I've encountered the same issue, it looks like Lintian doesn't recognize
python:any as being a satisfactory dependency on Python:
After having updated my Sid system (Lintian v2.5.17), while rebuilding the
gnuhealth package I get the following error:
E: gnuhealth-client: python-script-but-no-python-dep
usr/share/gnuhealth-client/gnuhealth-client.py
My control file lists the following:
Depends: ${python:Depends}, ${misc:Depends},
tryton-client (>= 2.8~), tryton-client (<< 2.9~)
And, if I open the generated .deb and look at the /DEBIAN/control file:
Depends: python:any (>= 2.6.6-7~), python:any (<< 3.1), tryton-client (>=
2.8~), tryton-client (<< 2.9~)
Please advise.
+Emilien
Bug#718169: Leading underscore in desktop file entry not recognized
Package: lintian Running Lintian 2.5.15 in sid, I got this warning: I: gnuhealth-client: desktop-entry-lacks-keywords-entry usr/share/applications/gnuhealth-client.desktop I follow the links from the info on the Lintian report page [0], and find the following example from the Gnome website [1]: _Keywords=chat;messaging;im;irc;voip; According to that page, "Maintainers/developers must set a preceding underscore in "_Keywords" to inform intltool that this field should be extracted, and its translations merged back into the .desktop.in file." When running Lintian again, instead of the warning disappearing, a new one appears ;) W: gnuhealth-client: desktop-entry-contains-unknown-key usr/share/applications/gnuhealth-client.desktop:11 _Keywords I: gnuhealth-client: desktop-entry-lacks-keywords-entry usr/share/applications/gnuhealth-client.desktop When removing the underscore, all warnings disappear. I assume Lintian does not recognize the leading underscore in desktop file entries (or maybe just for the newer Keywords)? Cheers, +Emilien [0] http://lintian.debian.org/tags/desktop-entry-lacks-keywords-entry.html [1] https://wiki.gnome.org/GnomeGoals/DesktopFileKeywords
Bug#716711: [Health-dev] Does GNU Health depend on Tryton >= 2.7?
2013/7/27 Luis Falcon > Hi Emilien ! > On 25/07/2013 17:32, Emilien Klein wrote: > > Hi devs, > > > > See [0], is it correct that GNU Health depends on Tryton >= 2.7? > > I noticed that for version 2.0 the configure/makefile build system is > > gone and replaced by a custom installation script [1] which states > > "PYTHON version [2.6.x < 3.x]", was the Python version maybe an "error" > > in the original build system? > > > I confirm that GNU Health 2.0 works under 2.6 and 2.7 . You can put the > blame on me for the original 2.7 :-) > > Thanks for the info! +Emilien
Bug#716711: Does GNU Health depend on Tryton >= 2.7?
2013/7/26 Andreas Tille > On Thu, Jul 25, 2013 at 10:32:14PM +0200, Emilien Klein wrote: > > Hi devs, > > > > See [0], is it correct that GNU Health depends on Tryton >= 2.7? > > s/Tryton/Python/ > (if I'm not totally missleaded). > Oh, yes, completely, sorry for the confusion ;) +Emilien
Bug#716711: Does GNU Health depend on Tryton >= 2.7?
Hi devs, See [0], is it correct that GNU Health depends on Tryton >= 2.7? I noticed that for version 2.0 the configure/makefile build system is gone and replaced by a custom installation script [1] which states "PYTHON version [2.6.x < 3.x]", was the Python version maybe an "error" in the original build system? Thanks! +Emilien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716711 [1] http://hg.savannah.gnu.org/hgweb/health/file/49292f265e45/tryton/gnuhealth_install.sh
Bug#606993: No response from maintainer
Hi Sebastian, 2013/6/1 Sebastian Ramacher : > Hi Emilien, > > On 2013-03-03 18:33:48, Emilien Klein wrote: >> Is there someone on the Python Apps Team that would be willing to >> upload the NMU I prepared? It's uploaded to mentors.d.n [0]? >> >>+Emilien >> [0] http://mentors.debian.net/package/subdownloader > > Thanks for your work on this bug. > > I just wanted to take a look at the NMU and apparently it got removed > from m.d.n. Could you reupload it so we can get that RC bug fixed? Reuploaded! (it might take a few minutes to show up on mentors.d.n) Thanks for looking into it. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654814: Shaarli in Debian
Hi Georges, I noticed you filed a new ITP bug for Shaarli. I did so myself 1.5 years ago, had a working package for version 0.0.32beta, did not find a sponsor, updated the package for 0.0.38beta, still no luck finding a sponsor... I wondered if you would want to review my work, possibly improve it, and sponsor it's upload. We could co-maintain the package, possibly using git-buildpackage and collab-maint if you're into that. I'm a Debian Maintainer, and will in the coming month apply for DD, but for now I can't upload Shaarli on my own ;) FYI I've worked with Seb Sauvage (Shaarli's main author) over the past year to have him publish a Debian-specific tarball, that makes the Debian packaging easier. You'll find this is used in the watchfile. I've attached my most recent debian folder (mind you: based on version 0.0.38beta, not the latest 0.0.41beta), if you're interested in working together on this we'll get to the point to set up a shared repository. Stuff to do with this version of the package: - Update to 0.0.41beta (I know of at least one extra folder location that we need patched) - The package triggers Lintian warnings on the version number (probably due to the word "beta" in the version) - Review the Apache config (since I wrote the package, I'm mostly running nginx, so I'm not testing the Apache config as well anymore) Let me know! I'm happy to see some interest around Shaarli in Debian. +Emilien shaarli-0.0.38beta.debian.tar.gz Description: GNU Zip compressed data
Bug#606993: No response from maintainer
Hi Marco, 2013/3/1 Marco Rodrigues : > Which e-mail did you try to contact me? goth...@sapo.pt? That one I really > don't check it =( No problem, most important is that we got in touch at last. > I'm not so active lately unfortunately, but I'm glad you want to help to > maintain it. You can perhaps ask someone from the Python Apps Team to upload > it for you. Is there someone on the Python Apps Team that would be willing to upload the NMU I prepared? It's uploaded to mentors.d.n [0]? +Emilien [0] http://mentors.debian.net/package/subdownloader -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702053: Acknowledgement (unblock: nautilus-image-manipulator/1.1-2)
The promised debdiff.
+Emilien
diff -Nru nautilus-image-manipulator-1.1/debian/changelog
nautilus-image-manipulator-1.1/debian/changelog
--- nautilus-image-manipulator-1.1/debian/changelog 2012-06-26
19:42:52.0 +0200
+++ nautilus-image-manipulator-1.1/debian/changelog 2013-03-02
09:30:18.0 +0100
@@ -1,3 +1,13 @@
+nautilus-image-manipulator (1.1-2) unstable; urgency=low
+
+ * Fix 2 upstream bugs, patches already applied upstream and released in v1.2:
+- debian/patches/fix-702044: Corrupted config file if width/height are
+defined from keyboard (Closes: #702044)
+- debian/patches/fix-702045: Upload to 1fichier.com not working
+(Closes: #702045)
+
+ -- Emilien Klein Sat, 02 Mar 2013 09:29:45 +0100
+
nautilus-image-manipulator (1.1-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru nautilus-image-manipulator-1.1/debian/patches/fix-702044
nautilus-image-manipulator-1.1/debian/patches/fix-702044
--- nautilus-image-manipulator-1.1/debian/patches/fix-7020441970-01-01
01:00:00.0 +0100
+++ nautilus-image-manipulator-1.1/debian/patches/fix-7020442013-02-28
21:27:08.0 +0100
@@ -0,0 +1,16 @@
+Fixes LP bug #1030927: Corrupted config file if width/height are defined from
keyboard
+Already applied upstream in r193, released in version 1.2.
+
+--- a/nautilus_image_manipulator/ProfileSettings.py
b/nautilus_image_manipulator/ProfileSettings.py
+@@ -216,8 +216,8 @@
+ for section in sections[1:]:
+ name = self.readvalue(c, section, "name")
+ size = self.readvalue(c, section, "size")
+-width = self.readvalue(c, section, "width", "int")
+-height = self.readvalue(c, section, "height", "int")
++width = self.readvalue(c, section, "width", "float")
++height = self.readvalue(c, section, "height", "float")
+ percent = self.readvalue(c, section, "percent", "float")
+ quality = self.readvalue(c, section, "quality", "float", 95)
+ destination = self.readvalue(c, section, "destination")
diff -Nru nautilus-image-manipulator-1.1/debian/patches/fix-702045
nautilus-image-manipulator-1.1/debian/patches/fix-702045
--- nautilus-image-manipulator-1.1/debian/patches/fix-7020451970-01-01
01:00:00.0 +0100
+++ nautilus-image-manipulator-1.1/debian/patches/fix-7020452013-02-28
21:30:46.0 +0100
@@ -0,0 +1,13 @@
+Fixes LP bug #1100027: Upload to 1fichier.com not working
+Already applied upstream in r195, released in version 1.2.
+--- a/nautilus_image_manipulator/upload/z1fichiercom.py
b/nautilus_image_manipulator/upload/z1fichiercom.py
+@@ -31,7 +31,7 @@
+ Note: it's not up to date..."""
+ # The session ID is read from the "files" form on
http://www.1fichier.com
+ html = urllib2.urlopen('http://www.1fichier.com').read()
+-(sessionId) = re.search('http://upload\.1fichier\.com/upload.cgi\?id=(.*)"
method="post">', html).groups()
++(sessionId) = re.search('http://.+\.1fichier\.com/upload.cgi\?id=(.*)"
method="post">', html).groups()
+ # Build the url to upload to and to retrieve the download and delete
links:
+ self.uploadUrl = "http://upload.1fichier.com/upload.cgi?id=%s"; %
sessionId
+ self.endUploadUrl = "http://upload.1fichier.com/end.pl?xid=%s"; %
sessionId
diff -Nru nautilus-image-manipulator-1.1/debian/patches/series
nautilus-image-manipulator-1.1/debian/patches/series
--- nautilus-image-manipulator-1.1/debian/patches/series2012-06-24
11:44:21.0 +0200
+++ nautilus-image-manipulator-1.1/debian/patches/series2013-03-02
09:09:57.0 +0100
@@ -1,2 +1,4 @@
use-packaged-python-poster.patch
nosetests.patch
+fix-702044
+fix-702045
Bug#702053: unblock: nautilus-image-manipulator/1.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi Release team, Please unblock package nautilus-image-manipulator The package has 2 severe bugs in testing, which: - makes the software unusable if the config file is edited manually (bug #702044) - breaks the functionality to upload resized files to the Internet (bug #702045) These bugs are fixed in the latest upstream release, but that version has changes that are not compatible with an unblock. I have therefore uploaded a package to unstable containing only 2 patches to fix these 2 issues. debdiff against the package in testing is attached. unblock nautilus-image-manipulator/1.1-2 -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#702045: File upload currently broken
Package: nautilus-image-manipulator Version: 1.1-1.1 Severity: grave 1fichier.com, the file locker to which Nautilus Image Manipulator can send files after having resized them, has changed the server to which files are to be POSTed. which breaks the application. No useful error message is displayed in the GUI, which leaves end-users wondering what is going on. This bug renders N I M partially unusable. This has been reported upstream as LP#1100027, was fixed upstream in r195, and has been released in the newest 1.2 version. Intent of this bug report is to upload a new 1.1-2 version containing a patch for this bug, to update the version currently in testing (soon to be wheezy). This will require an unblock from the release team. Thanks, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702044: Unable to start when config file has been edited manually
Package: nautilus-image-manipulator Version: 1.1-1.1 Severity: grave If the configuration file has been edited manually, it will not be possible to start Nautilus Image Manipulator afterwards. Reason is that the width and height parameters will be floats, but N I M will assume they are integers, which will make the code reading the configuration launch an Exception, resulting in N I M not being able to start (without displaying any kind of visual indication, as not GUI element will be displayed). This bug renders N I M useless, but the good news is that it's easily fixed! This has been reported upstream as LP#1030927, was fixed upstream in r193, and has been released in the newest 1.2 version. Intent of this bug report is to upload a new 1.1-2 version containing a patch for this bug, to update the version currently in testing (soon to be wheezy). This will require an unblock from the release team. Thanks, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606993: No response from maintainer
Hi Marco Rodrigues and the Python Applications Packaging Team, The subdownloader package you co-maintain has a grave bug [0] which resulted in the package being removed from Testing more than 2 years ago. This bug has been fixed in version 2.0.18 (4 releases later than 2.0.14 packaged in Debian). I've patched that specific bug and uploaded a NMU to mentors.d.n [1], please review and upload. Additionally, as I didn't get any answer back from you on any of my emails over the last 4 months, I am wondering if you are still willing to maintain this package? I would be willing to give a helping hand, and get the newest version packaged (the one currently packaged is 2.5 years old). Cheers, +Emilien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606993 [1] http://mentors.debian.net/package/subdownloader -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606993: Patch for this bug
Hi, I've sent a patch fixing this grave issue and created a NMU [0] a bit over 3 months ago, please review it and upload to unstable. This bug caused the removal of subdownloader from testing, which is too bad... Please let us know if this package is not maintained anymore, as a user of it I'll gladly take care of the Debian packaging Thanks, +Emilien [0] http://mentors.debian.net/package/subdownloader 2012/11/23 Emilien Klein : > Hi Python Applications Packaging Team and Marco Rodrigues, > > Please have a look at the patch I sent to fix this "Severity: grave" > bug which caused the removal of SubDownloader from the archive. > As mentioned in my previous mail, I've prepared a NMU [0] for this, it > would be nice if you could check it. > > Thanks, > +Emilien > > [0] http://mentors.debian.net/package/subdownloader -- +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697204: GExiv2: New version in experimental provides GObject introspection
from gi.repository import GExiv2
im = GExiv2.Metadata('t.jpg')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: GObject.__init__() takes exactly 0 arguments (1 given)
I can confirm that I get the same error with a patch that was
submitted to me [0] when using the version available in Debian
experimental.
If I manually install the version from [1], everything works as
expected. And with the version available in Ubuntu 12.10 [2] it also
works fine.
There must be something different in the package available in Debian
experimental that makes it fail... Not sure what it is though.
Maintainers, any thought why this difference?
> Why the version in the binary package name?
Note sure, but that seems to be the convention. See [3] and type "sudo
aptitude install gir1.2-" in the terminal and then double-tab, you'll
see that all packages follow this convention. It does feel weird,
since the package itself is version 0.5, but the package name contains
0.5...
+Emilien
[0]
https://code.launchpad.net/~robru/nautilus-image-manipulator/gexiv2/+merge/141539
[1] http://debian.dev-zero.nl/debian/pool/main/g/gexiv2/
[2]
http://launchpadlibrarian.net/122960396/gir1.2-gexiv2-0.4_0.5.0-0ubuntu1_amd64.deb
[3] http://lists.debian.org/debian-devel/2009/09/msg00899.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697204: GExiv2: New version in experimental provides GObject introspection
Version 0.5.0 has been uploaded to experimental, that version introduces a new binary package gir1.2-gexiv2-0.4 that provides GObject introspection data for the gexiv2 library. I've installed it from experimental, and "from gi.repository import GExiv2" works fine. Please confirm that it works for you as well. Steps to configure experimental and install: Add this line to your /etc/apt/sources.list: deb http://ftp.debian.org/debian experimental main Update your sources and execute this: sudo aptitude -t experimental install gir1.2-gexiv2-0.4 Question to the maintainers: what is the reason for 0.5.0 not to be uploaded to unstable? I believe the freeze for the new release only affects testing, but you should still be allowed to upload to unstable, right? Cheers, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696044: nautilus-open-terminal still does'nt work..!!
Hi Andre, Which version of gsettings-desktop-schemas do you currently have installed? Updating that package to 3.4.2-3 fixed the issue for most of us. The last report on bug 692518 [0] mentions that "I had to set back to default the configuration of org.gnome.desktop.default-applications.terminal exec", could you try that as well? Let us know... +Emilien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692518#81 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692518: (no subject)
Hi Ed, 2012/12/2 Ed LaBonte : > You guys may have resolved it to your satisfaction, but I've still got the > bug. I'm running Wheezy and it is fully upgraded. I open nautilus to > $HOME/Documents (for example) and the terminal opens to $HOME. By Wheezy I assume you mean Testing. The version of gsettings-desktop-schemas currently in testing is 3.4.2-2, which has this issue. The problem is fixed in gsettings-desktop-schemas 3.4.2-3, which according to [0] is "Too young, only 8 of 10 days old" to migrate from sid to testing. I assume that when you update your system in 2 days the problem will be fixed. Can you please confirm that your current version of gsettings-desktop-schemas is 3.4.2-2? Cheers, +Emilien [0] http://packages.qa.debian.org/g/gsettings-desktop-schemas.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694749: ITP: GNU Health -- Electronic Medical Record and Hospital Information System
2012/11/30 Andreas Tille :
> Hi,
>
> On Fri, Nov 30, 2012 at 05:00:14PM +0800, Chow Loong Jin wrote:
[...]
>> Is it really not part of GNU? I see the URL being a subdomain of gnu.org:
>>
>> >> [...]
>> >> * URL : http://health.gnu.org/
>> >> [...]
>>
>> And from their webpage:
>> | Health is an official GNU package, part of the GNU System. All the
>> | development is at : GNU Health project[1] at Savannah
Yes, GNU health is an official GNU package.
> I think either
>
> gnu-health or gnuhealth
>
> would be a proper package name because it is just the name of the
> project. We also do have gnumed-{server,client} packages because the
> project ist named GNUmed. We just have to settle with a reasonable
> name without space (and '_') and need to stick to lower case letters.
gnuhealth is the one I prefer, closest to the official project name,
and unlikely to get in conflict with other future packages (using
"health" alone would be too generic)
> BTW, the packaging in
>
>svn://svn.debian.org/debian-med/trunk/packages/gnuhealth/trunk/
>
> has "gnuhealth" as package name.
>
> Kind regards
>
>Andreas.
>
> PS: Most probably it makes sense to let reportbug reject invalid package
> names in ITP bugs.
>
> --
> http://fam-tille.de
+Emilien
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694749: ITP: GNU Health -- Electronic Medical Record and Hospital Information System
Package: wnpp Severity: wishlist Owner: Emilien Klein * Package name: GNU Health Version : 1.6.4 Upstream Author : Luis Falcon * URL : http://health.gnu.org/ * License : GPLv3+ Programming Lang: Python (Tryton modules) Description : Electronic Medical Record and Hospital Information System GNU Health is a multi-user, highly scalable, centralized Electronic Medical Record (EMR) and Hospital Information System (HIS) for Tryton, so doctors and institutions all over the world, independently of their economic status, will benefit from a centralized, high quality, secure and scalable system. GNU Health at a glance: * Strong focus in family medicine and Primary Health Care * Major interest in Socio-economics (housing conditions, substance abuse, education...) * Diseases and Medical procedures standards (ICD-10 / ICD-10-PCS) * Prescription writing * Billing * Patient Genetic and Hereditary risks: over 4200 genes related to diseases (NCBI / Genecards) * Epidemiological and other statistical reports * 100% paperless patient examination and history taking * Patient Administration (creation, evaluations / consultations, history...) * Doctor Administration * Lab Administration * Medicine / Drugs information (vademécum) * Medical stock and supply chain management * Hospital Financial Administration * GNU Health allows one to attach documents (X-rays, Biopsy results, ...) to the Patient chart. * Designed with industry standards in mind -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692518: nautilus-open-terminal always set the current
close 692518 thanks After installing the latest update of gsettings-desktop-schemas, nautilus-open-terminal now properly opens the terminal at the desired location. Bug fixed, please confirm. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694128: x-terminal-emulator as default term breaks nautilus-open-terminal
Hi Andre, 2012/11/24 Andre Verwijs : > RE x-terminal-emulator as default term breaks nautilus-open-terminal > > the problem stil exists, how do i fix it ? Not sure what you mean by "the problem". Can you have a look at bug #693894 and tell me if that's related? According to the latest message from Josselin Mouette on that bug this issue is fixed. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687126: SubDownloader package in Debian
Hello Marco Rodrigues, I've sent a patch for bug #606993 that fixes that issue which caused the removal of SubDownloader from Debian testing. I've prepared a NMU with the patch, hopefully this is helpful to get this bug fixed soon. A new version (2.0.18) got released a week ago that includes this patch. It might actually just be easier to package that new version! Since the latest update of the package in Debian is almost 2 years old, I wanted to check if you were still interested in maintaining it, or if I should propose my help in maintaining the SubDownloader package in Debian. I am a Debian Maintainer (i.e. not [yet] a DD), so I can't directly update new packages, but I'd like to help maintain SubDownloader if you need help/don't have time to take care of it anymore. Let me know! +Emilien [0] https://launchpad.net/subdownloader/trunk/2.0.18/+download/subdownloader_2.0.18.orig.tar.gz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606993: Patch for this bug
Hi Python Applications Packaging Team and Marco Rodrigues, Please have a look at the patch I sent to fix this "Severity: grave" bug which caused the removal of SubDownloader from the archive. As mentioned in my previous mail, I've prepared a NMU [0] for this, it would be nice if you could check it. Thanks, +Emilien [0] http://mentors.debian.net/package/subdownloader -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606993: Patch for this bug
Hi, The following patch (already applied upstream [0]) fixes this bug. I've prepared a NMU (versioned as 2.0.14-1.1) and uploaded it to mentors.d.n [1], please review and upload. Thanks, +Emilien [0] http://bazaar.launchpad.net/~subdownloader-developers/subdownloader/trunk/revision/552 [1] http://mentors.debian.net/package/subdownloader fix-non-ascii-download-path.patch Description: Binary data
Bug#685018: Generate a subkey for encryption
Hi Anibal, I will generate a subkey for encryption as soon as I'm back from vacation, and will then remove the tag. Thanks, +Emilien
Bug#685018: Please add Emilien Klein as a Debian Maintainer
Package: debian-maintainers Severity: normal Please add Emilien Klein to the Debian Maintainer keyring. The jetring changeset is attached. Thank you. +Emilien add-AE0C84BB0A2368F0 Description: Binary data
Bug#684836: nautilus-image-manipulator: FTBFS: AttributeError: 'tuple' object has no attribute 'major'
reassign 684836 python-distutils-extra merge 682631 684836 affects 682631 nautilus-image-manipulator thanks This is similar to bug #682634, which most probably finds its cause in python-distutils-extra Cheers, +Emilien P.S.: this is the first time I'm reassigning and merging bugs, let me know if I did something wrong. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676045: nautilus-image-manipulator: diff for NMU version 1.1-1.1
2012/6/27 Salvatore Bonaccorso : > I can cancel the NMU if you would like to upload yourself, this would be > perfect! It's still time do to so[1]. I just checked the patch and everything is fine. I'm OK with you doing the NMU. > Btw, I had some warnings on build: > >> WARNING: syntax errors in nautilus_image_manipulator/ProfileSettings.py: >> encoding declaration in Unicode string (ProfileSettings.py, line 0) >> WARNING: syntax errors in bin/nautilus-image-manipulator: encoding >> declaration in Unicode string (nautilus-image-manipulator, line 0) >> WARNING: syntax errors in >> nautilus_image_manipulator/nautilus_image_manipulatorconfig.py: encoding >> declaration in Unicode string (nautilus_image_manipulatorconfig.py, line 0) >> WARNING: syntax errors in docs/conf.py: encoding declaration in Unicode >> string (conf.py, line 0) >> WARNING: syntax errors in nautilus_image_manipulator/helpers.py: encoding >> declaration in Unicode string (helpers.py, line 0) >> /usr/lib/python2.6/dist-packages/DistUtilsExtra/auto.py:336: >> DeprecationWarning: the sha module is deprecated; use the hashlib module >> instead >> mod = __import__(module) >> WARNING: syntax errors in nautilus_image_manipulator/upload/z1fichiercom.py: >> encoding declaration in Unicode string (z1fichiercom.py, line 0) >> WARNING: syntax errors in nautilus_image_manipulator/ImageManipulations.py: >> encoding declaration in Unicode string (ImageManipulations.py, line 0) >> WARNING: syntax errors in >> nautilus_image_manipulator/NautilusImageManipulatorDialog.py: encoding >> declaration in Unicode string (NautilusImageManipulatorDialog.py, line 0) I'll investigate this. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676045: nautilus-image-manipulator: diff for NMU version 1.1-1.1
Hi Salvatore, 2012/6/26 Salvatore Bonaccorso : > tags 676045 + pending > thanks > > Dear maintainer, > > I've prepared an NMU for nautilus-image-manipulator (versioned as 1.1-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Regards, > Salvatore Thanks a lot for the patch and the NMU. I will test it at home tonight, but looking at the patch it should be alright. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664823: [Pkg-javascript-devel] Bug#664823: beautify sha512
Thanks shawn. Shouldn't this better be submitted to upstream [0]? I also doubt whether there is much use to "beautifying" (mainly adding whitespace) such a file, but I'll leave this to the upstream author to decide. +Emilien [0] http://pajhome.org.uk/crypt/md5/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654814: ITP: shaarli -- Shaarli is a minimalist delicious clone designed to be personal (single-user), fast and handy.
And since Shaarli also contains the code for RainTPL - easy php template engine [0], and that last month I gave a presentation about Debian packaging at my local LUG, I've asked the attendees if they wanted to start packaging in Debian with RainTPL. I mentioned that if nobody volunteers I'll start packaging it myself in one week. [0] http://www.raintpl.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654814: ITP: shaarli -- Shaarli is a minimalist delicious clone designed to be personal (single-user), fast and handy.
Update: Upstream has released 0.0.38beta which I've started packaging, however I noticed the inclusion of another minified Javascript file for the Lazy Load Plugin for jQuery [0]. I have asked upstream to remove the minified file from the tarball that is released for Debian packaging, and am currently working with the Debian Javascript Maintainers on getting that new jQuery plugin packaged in Debian [1] [2]. Once this package is available in Sid I'll make Shaarli's package depend on it. [0] http://www.appelsiini.net/projects/lazyload [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659408 [2] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-February/002750.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659408: ITP: jquerylazyload -- Lazy Load Plugin for jQuery
Package: wnpp Severity: wishlist Owner: Emilien Klein * Package name: jquerylazyload Version : 1.7.0 Upstream Author : Mika Tuupola * URL : http://www.appelsiini.net/projects/lazyload * License : MIT/Expat Programming Lang: JavaScript Description : Lazy Load Plugin for jQuery Lazy Load is a jQuery plugin written in JavaScript. It delays loading of images in long web pages. Images outside of viewport (visible part of web page) wont be loaded before user scrolls to them. This is opposite of image preloading. Using Lazy Load on long web pages containing many large images makes the page load faster. Browser will be in ready state after loading visible images. In some cases it can also help to reduce server load. Lazy Load is inspired by YUI ImageLoader Utility by Matt Mlinac. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654814: ITP: shaarli -- Shaarli is a minimalist delicious clone designed to be personal (single-user), fast and handy.
I've uploaded shaarli_0.0.33beta-1 to mentors [0], as well as sent a RFS email [1] today. [0] http://mentors.debian.net/package/shaarli [1] http://lists.debian.org/debian-mentors/2012/01/msg00280.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654814: ITP: shaarli -- Shaarli is a minimalist delicious clone designed to be personal (single-user), fast and handy.
Package: wnpp Owner: Emilien Klein Severity: wishlist * Package name: shaarli Version : 0.0.32 beta Upstream Author : Seb Sauvage * URL : http://sebsauvage.net/wiki/doku.php?id=php:shaarli * License : zlib/libpng Programming Lang: PHP Description : Shaarli is a minimalist delicious clone designed to be personal (single-user), fast and handy. Saving simple links should not be a complicated heavy thing. Shaarli is simple, but it does the job and does it well. And your data is not hosted on a foreign server, but on your server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638707: python-poster: diff for NMU version 0.8.1-0.1
tags 638707 + patch
tags 638707 + pending
thanks
Dear Robert,
I've prepared an NMU for python-poster (versioned as 0.8.1-0.1) and
Jakub Wilk uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards,
+Emilien
diff -Nru python-poster-0.7.0/debian/changelog
python-poster-0.8.1/debian/changelog
--- python-poster-0.7.0/debian/changelog2011-12-10 11:44:12.0
+0100
+++ python-poster-0.8.1/debian/changelog2011-12-10 11:44:14.0
+0100
@@ -1,3 +1,10 @@
+python-poster (0.8.1-0.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * New upstream release (Closes: #638707)
+
+ -- Emilien Klein Fri, 09 Dec 2011 21:19:18 +0100
+
python-poster (0.7.0-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru python-poster-0.7.0/MANIFEST.in python-poster-0.8.1/MANIFEST.in
--- python-poster-0.7.0/MANIFEST.in 2009-01-06 22:15:06.0 +0100
+++ python-poster-0.8.1/MANIFEST.in 2011-04-16 15:36:56.0 +0200
@@ -1 +1,2 @@
include tests/*.py
+exclude setup.cfg
diff -Nru python-poster-0.7.0/PKG-INFO python-poster-0.8.1/PKG-INFO
--- python-poster-0.7.0/PKG-INFO2010-10-23 17:52:24.0 +0200
+++ python-poster-0.8.1/PKG-INFO2011-04-16 15:40:23.0 +0200
@@ -1,12 +1,12 @@
Metadata-Version: 1.0
Name: poster
-Version: 0.7.0
+Version: 0.8.1
Summary: Streaming HTTP uploads and multipart/form-data encoding
Home-page: http://atlee.ca/software/poster
Author: Chris AtLee
Author-email: ch...@atlee.ca
License: MIT
-Download-URL: http://atlee.ca/software/poster/dist/0.7.0
+Download-URL: http://atlee.ca/software/poster/dist/0.8.1
Description: The modules in the Python standard library don't provide a way to
upload large
files via HTTP without having to load the entire file into memory
first.
diff -Nru python-poster-0.7.0/poster/encode.py
python-poster-0.8.1/poster/encode.py
--- python-poster-0.7.0/poster/encode.py2010-10-23 17:15:06.0
+0200
+++ python-poster-0.8.1/poster/encode.py2010-12-03 06:25:52.0
+0100
@@ -22,6 +22,11 @@
return sha.new(str(bits)).hexdigest()
import urllib, re, os, mimetypes
+try:
+from email.header import Header
+except ImportError:
+# Python 2.4
+from email.Header import Header
def encode_and_quote(data):
"""If ``data`` is unicode, return urllib.quote_plus(data.encode("utf-8"))
@@ -76,7 +81,7 @@
"""
def __init__(self, name, value=None, filename=None, filetype=None,
filesize=None, fileobj=None, cb=None):
-self.name = encode_and_quote(name)
+self.name = Header(name).encode()
self.value = _strify(value)
if filename is None:
self.filename = None
@@ -195,11 +200,6 @@
headers.append("Content-Type: %s" % filetype)
-if self.filesize is not None:
-headers.append("Content-Length: %i" % self.filesize)
-else:
-headers.append("Content-Length: %i" % len(self.value))
-
headers.append("")
headers.append("")
diff -Nru python-poster-0.7.0/poster/__init__.py
python-poster-0.8.1/poster/__init__.py
--- python-poster-0.7.0/poster/__init__.py 2010-10-23 17:19:56.0
+0200
+++ python-poster-0.8.1/poster/__init__.py 2011-02-13 20:12:47.0
+0100
@@ -1,4 +1,4 @@
-# Copyright (c) 2010 Chris AtLee
+# Copyright (c) 2011 Chris AtLee
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
@@ -29,4 +29,4 @@
import poster.streaminghttp
import poster.encode
-version = (0, 7, 0) # Thanks JP!
+version = (0, 8, 1) # Thanks JP!
diff -Nru python-poster-0.7.0/poster/streaminghttp.py
python-poster-0.8.1/poster/streaminghttp.py
--- python-poster-0.7.0/poster/streaminghttp.py 2010-09-03 16:59:41.0
+0200
+++ python-poster-0.8.1/poster/streaminghttp.py 2011-04-16 15:24:30.0
+0200
@@ -181,16 +181,18 @@
return urllib2.HTTPSHandler.do_request_(self, req)
+def get_handlers():
+handlers = [StreamingHTTPHandler, StreamingHTTPRedirectHandler]
+if hasattr(httplib, "HTTPS"):
+handlers.append(StreamingHTTPSHandler)
+return handlers
+
def register_openers():
"""Register the streaming http handlers in the global urllib2 default
opener object.
Returns the created OpenerDirector object."""
-handlers = [StreamingHTTPHandler, StreamingHTTPRedirectHandler]
-if hasattr(httplib, "HTTPS"):
-handlers.append(StreamingHTTPSHandler)
-
-opener = urllib2.build_opener(*handlers)
+opener = urllib2.build_opener(*get_handlers())
urllib2.install_opener(opener)
diff -Nru python-poster-0.7.0/poster.egg-info/PKG-INFO
p
Bug#638707: RFS: python-poster
2011/12/9 Jakub Wilk : > I uploaded the package to DELAYED/2. Please post full debdiff between > 0.7.0-1.1 and 0.8.1-0.1 to the bug log. Thanks Jakub for the upload. Full debdiff is to be found here: http://paste.debian.net/148759/ Please let me know if using the paste service isn't appropriate (I've set it to never expire) +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638707: NMU done but unresponsive maintainer
Hi Mentors and Alessio, 2011/11/25 Emilien Klein : > Hi Mentors, > > About a month ago [6 weeks now] I made a NMU of the python-poster package for > the > latest version 0.8.1, as suggested by Robert. Unfortunately Robert > hasn't answered my last 4 emails on 28/10, 2/11, 4/11 and 20/11, I > suppose due to the new baby ;) > > I am thus looking for someone to sponsor my NMU. It can be found at > http://mentors.debian.net/package/python-poster. [...] Is there anyone available to sponsor my NMU from 2011-10-27? Thanks, +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
