Bug#866443: Info received (Replace with python-pil)

[Emilien Klein]

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#821656: Bumping severity of PHP 7.0 transition bugs to serious

[Emilien Klein]

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#769348: biomaj-watcher: Should /var/lib/tomcat8/shared exist?

[Emilien Klein]

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#773039: Unblock request sent to the Release team

[Emilien Klein]

Unblock request sent to the Release team, see bug #773113.
+Emilien



signature.asc
Description: OpenPGP digital signature

Bug#773039: Unblock request sent to the Release team

[Emilien Klein]

 Unblock request sent to the Release team, see bug #773113.
The unblock request was approved.



signature.asc
Description: OpenPGP digital signature

Bug#750910: Fwd: Untagging jessie

[Emilien Klein]

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#773039: shaarli: Unusable after install due to incorrect folder permissions out of the box

[Emilien Klein]

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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748561: GNU Health autoremove from testing

[Emilien Klein]

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 emil...@klein.st:
 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=revisionrevision=17092


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

Bug#748561: GNU Health autoremove from testing

[Emilien Klein]

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-rc-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

[Emilien Klein]

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

[Emilien Klein]

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-rc-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

[Emilien Klein]

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 dktrkr...@debian.org:
 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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743252: Multiples XSS in index.php

[Emilien Klein]

Hi David, Salvatore and Georges,

2014-04-01 20:24 GMT+02:00 Salvatore Bonaccorso car...@debian.org:
 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://user@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-rc-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

[Emilien Klein]

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 COMMAND USERNAME
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=revisionrevision=16361



signature.asc
Description: OpenPGP digital signature

Bug#739657: Maintainer scripts: execute command as another user: use sudo or su?

[Emilien Klein]

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-rc-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

[Emilien Klein]

Hi Andreas,

Le 23 févr. 2014 22:30, Andreas Tille andr...@an3as.eu 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 karsten.hilb...@gmx.net:
  
   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

[Emilien Klein]

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

[Emilien Klein]

Le 21 févr. 2014 21:57, Emilien Klein emilien+deb...@klein.st 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#735536: Other workaround: downgrading gnupg

[Emilien Klein]

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#606993: No response from maintainer

[Emilien Klein]

Hi Sebastian,

2013/6/1 Sebastian Ramacher sramac...@debian.org:
 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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606993: No response from maintainer

[Emilien Klein]

Hi Marco,

2013/3/1 Marco Rodrigues goth...@gmail.com:
 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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606993: No response from maintainer

[Emilien Klein]

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-rc-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

[Emilien Klein]

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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702045: File upload currently broken

[Emilien Klein]

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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606993: Patch for this bug

[Emilien Klein]

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 emil...@klein.st:
 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-rc-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

[Emilien Klein]

Hi Andre,

2012/11/24 Andre Verwijs i...@verwijs-pc.nl:
 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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606993: Patch for this bug

[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


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

Bug#606993: Patch for this bug

[Emilien Klein]

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#684836: nautilus-image-manipulator: FTBFS: AttributeError: 'tuple' object has no attribute 'major'

[Emilien Klein]

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-rc-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

[Emilien Klein]

Hi Salvatore,

2012/6/26 Salvatore Bonaccorso car...@debian.org:
 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-rc-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

[Emilien Klein]

2012/6/27 Salvatore Bonaccorso car...@debian.org:
 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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649910: nautilus-image-manipulator is also affected

[Emilien Klein]

While wanting to package a new version of nautilus-image-manipulator
in Sid I encountered the same crash as reported by Andrea Veri.

With both nautilus-python 1.1-1 and nautilus-image-manipulator 0.4-1
installed, this is the output of `aptitude dist-upgrade` as of today:

Les paquets suivants ont des dépendances non satisfaites :
 python-gi: Casse: python-nautilus (= 1.1-1) mais 1.1-1 est installé.
Les actions suivantes permettront de résoudre ces dépendances :

Supprimer les paquets suivants :
1) nautilus-image-manipulator
2) python-nautilus

Accepter cette solution ? [Y/n/q/?]

I have accepted the proposed solution [removal of both packages] to be
able to update my system. When this bug is resolved I'll reinstall my
Nautilus extension and package the new version.

Side note:
Josselin had opened (automatically?) a bunch of package name:
Please transition to nautilus 3 and GObject introspection bugs to
prepare for the introduction of nautilus 3 to unstable around the
beginning of October. Example for N I M:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644694

In those bug reports, a [very useful] link to
http://live.gnome.org/PyGObject/IntrospectionPorting was provided. the
first step for the transition was to use the `pygi-convert.sh` script,
which (among a lot of other things) executes this rename regex:

`-pe s/import gobject\n/from gi.repository import GObject\n/g; \`

Would running that script against nautilus-python [partially] solve the issue?

Cheers,
+Emilien



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

Bug#644694: Nautilus transition started; please upload to unstable

[Emilien Klein]

Just released version 0.4 that contains the transition to nautilus 3
and GObject introspection. I'm getting to work on packaging it!



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