Re: I'll be offline for an indefinite period
On Sunday, 16 September 2018 10:29:23 PM AEST أحمد المحمودي wrote: > I will be offline for an indefinite period. I hope you are all right, or will be all right. Take care and good luck. -- Regards, Dmitry Smirnov. --- To predict the behavior of ordinary people in advance, you only have to assume that they will always try to escape a disagreeable situation with the smallest possible expenditure of intelligence. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Re: RFS: python-uinput/2.3.2-1 [NEW]
On Sunday, 5 August 2018 3:33:33 PM AEST أحمد المحمودي wrote: > Please sponsor the upload of the new package python-uinput Uploaded, thanks. Just one note, regarding the following Lintian warning: debian-changelog-has-wrong-day-of-week 2018-07-28 is a Saturday The best way to update changelog is to use command `dch --release`. -- Regards, Dmitry Smirnov. --- Free speech is the bedrock of liberty and a free society. And yes, it includes the right to blaspheme and offend. -- Ayaan Hirsi Ali, 2010 signature.asc Description: This is a digitally signed message part.
Re: Bug#803117: celery: non-free documentation (CC-BY-NC-SA-3.0)
On Tuesday 27 October 2015 16:36:15 Brian May wrote: > Sounds like we might have to repackage the source to drop the entire > docs directory and remove the python-celery-doc package :-( It might be helpful to bring upstream's attention to the matter... -- Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: please remove "xpra" package repository
On Tue, 7 May 2013 02:20:43 Jakub Wilk wrote: > * Dmitry Smirnov , 2013-05-07, 02:12: > >When convenient please remove old "xpra" package repository from > > > > http://svn.debian.org/viewsvn/python-apps/packages/xpra/trunk/ > > > >All Xpra maintainers agreed with this decision but I can't remove the > >above repository myself as I'm not a member of team. > > Why is the team in the Maintainer field if the package is not > team-maintained? Anyway, removed. Thanks for removing, Jakub. We kept team as Maintainer because Ahmed was reluctant to replace it. Perhaps we thought that team might still be involved to Xpra maintenance at some point. We had to move repository but didn't want to break connection with team. Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201305071107.06920.only...@member.fsf.org
please remove "xpra" package repository
Dear team, When convenient please remove old "xpra" package repository from http://svn.debian.org/viewsvn/python-apps/packages/xpra/trunk/ All Xpra maintainers agreed with this decision but I can't remove the above repository myself as I'm not a member of team. Some time ago we moved Xpra packaging to collab-maint where all history is preserved. Thank you. Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is a fine thing to be honest, but it is also very important to be right. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Re: Xpra to publicly expose its modules
On Wed, 19 Sep 2012 03:21:14 Barry Warsaw wrote: > Does it make any sense to split the source package into multiple binary > packages? Then the library bits would live in python-xpra (and maybe > someday, python3-xpra ) and the program part would live in xpra. One day it could be done (perhaps when upstream introduce support for python3) but IMHO at this time it doesn't worth it. Executable part would then have just 3-lines wrapper script and hard dependency on exact library version... Also we will need * to think about which package config files should go. * to think about which package should ship arch-indep files in /usr/share/xpra * to find a sponsor for splitted package. Considering there are some examples of application/library packages shipped by one package I believe we can consider splitting later, if necessary. I just recalled another example of package shipping executables and libraries: mysql-utilities, but this may be not a good example because mysql-utilities might need to be splitted too. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209191112.46296.only...@member.fsf.org
Re: Xpra to publicly expose its modules
On Wed, 19 Sep 2012 01:23:39 أحمد المحمودي wrote: > Hello, > > On Tue, Sep 18, 2012 at 06:27:21PM +1000, Dmitry Smirnov wrote: > > Although Xpra is mainly an application its modules can be used by > > frontends like "winswitch", packaged by yours truly. In particular > > winswitch have an ugly workaround [1] to find private Xpra modules. This > > is something upstream already complained to me about. > > ---end quoted text--- > > Ok, but in that case, should the package be renamed to python-xpra > since the python modules will be public ? Or can the package still > keep the name 'xpra' ? That should be fine but please don't take my words as granted. :) At the moment I can't recall a good example but there are some exceptions like when package in mainly used as application. Proves nothing but worth noticing that Ruby packaging team has the following naming guideline: If the package is mainly used as an application (not as a library), then it can be named "foo". But IMHO that's common sense. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209190300.24916.only...@member.fsf.org
Xpra to publicly expose its modules
Dear Ahmed,
At the moment xpra installs its modules privately to /usr/lib/xpra/xpra.
While this path appears to be incorrect due to unnecessary nesting we have a
bigger problem with hiding xpra modules which should be exposed publicly
because Xpra is both application and a library.
Although Xpra is mainly an application its modules can be used by frontends
like "winswitch", packaged by yours truly. In particular winswitch have an
ugly workaround [1] to find private Xpra modules. This is something upstream
already complained to me about.
There are some other concerns articulated by upstream. From our discussion:
Me: "python-apps packaging team is clearly advise to install private modules
whenever possible probably to avoid python namespace collision."
Upstream: "Looks totally wrong to me, especially seeing that we have python
compiled extensions in wimpiggy and xpra (linked against libpython)
and that python3 code is quite different too.
Using /usr/lib/xpra means that you cannot have xpra installed
against more than one python version. whereas the default/standard
/usr/lib*/pythonN.N/site-packages/xpra allows that.
IMO, the most compelling argument for shipping xpra in the regular
installation path used by all python applications (except on
debian.) and not in /usr/lib is going to be that xpra has shared
objects linked with libpython, and one may want multiple versions
of python installed, each with xpra - this is not possible with a
single xpra in /usr/lib.. After all, winswitch could (and should?)
fallback to the less optimal parsing of the "xpra --version"
command line when loading the python package directly fails.
Considering the above I'm attaching the patch to install Xpra modules to
default location i.e. to /usr/lib/python2.N/dist-packages/xpra.
After well over one month since I applied for membership in "Python
Applications Packaging Team" I still got no reply to my application so I can't
apply this patch myself.
Anyway because this change could be considered controversial I wouldn't commit
it without your consent.
Also I'm CCing to debian-python in order to double check with the team that
we're not going against policy or best practice.
Please advise.
Thank you.
Best regards,
Dmitry.
[1]: https://winswitch.org/trac/changeset/5055
From f2a0235c1aeb373026da900ed47bd6bd51320a1b Mon Sep 17 00:00:00 2001
From: Dmitry Smirnov
Date: Tue, 18 Sep 2012 18:11:51 +1000
Subject: [PATCH] xpra to publicly expose its modules.
Xpra is both application and a library.
Exposing modules publicly will simplify interaction with
frontends like winswitch and will allow to install for more
than one python version. The latter may be of concern
due to some bindings that may be sensitive to python version.
---
debian/changelog|3 +++
debian/patches/private-pkg.diff | 44 ---
debian/patches/series |1 -
debian/xpra.install |2 +-
4 files changed, 4 insertions(+), 46 deletions(-)
delete mode 100644 debian/patches/private-pkg.diff
delete mode 100644 debian/patches/series
diff --git a/debian/changelog b/debian/changelog
index 3ec5f5c..03bc27d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,8 +3,11 @@ xpra (0.3.6+dfsg-2) UNRELEASED; urgency=low
* NOT RELEASED YET
* debian/README.Debian: Remove Known issues section, it is invalidated with
0.3.6 release.
+ [ Dmitry Smirnov ]
+ * Dropped private-pkg.diff in order to publicly expose xpra modules.
+
-- أحمد المحمودي (Ahmed El-Mahmoudy) Sun, 19 Aug 2012 09:04:44 +0200
xpra (0.3.6+dfsg-1) unstable; urgency=low
diff --git a/debian/patches/private-pkg.diff b/debian/patches/private-pkg.diff
deleted file mode 100644
index 0d4aed7..000
--- a/debian/patches/private-pkg.diff
+++ /dev/null
@@ -1,44 +0,0 @@
-Description: Add /usr/lib/xpra to sys.path for xpra script and /usr/lib/parti
- to sys.path for parti script.
-Author: أحمد المحمودي (Ahmed El-Mahmoudy)
-Forwarded: not-needed
a/scripts/parti
-+++ b/scripts/parti
-@@ -1,6 +1,7 @@
- #!/usr/bin/env python
-
- import sys
-+sys.path.append("/usr/lib/parti")
- import parti.scripts.main
-
- parti.scripts.main.main(sys.argv)
a/scripts/parti-repl
-+++ b/scripts/parti-repl
-@@ -1,6 +1,7 @@
- #!/usr/bin/env python
-
- import sys
-+sys.path.append("/usr/lib/parti")
- import parti.scripts.repl
-
- parti.scripts.repl.main(sys.argv)
a/scripts/xpra
-+++ b/scripts/xpra
-@@ -1,6 +1,7 @@
- #!/usr/bin/env python
-
- import sys
-+sys.path.append("/usr/lib/xpra")
- import xpra.scripts.main
-
- sys.exit(xpra.scripts.main.main(__file__, sys.argv))
a/scripts/xpra_launcher 2012-06-03 19:16:59.330360871 +0200
-+++ b/scripts/xpra_l
joining the team
Dear admins, Pleas allow me to join "Python Applications Packaging Team" (PAPT) for co-maintaining "xpra" package. Some time ago I sent my join request using form on Alioth but there were no reply yet. My user name is 'onlyjob-guest' (I'm a DM). Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
