Re: future of python-pipeline package
Il giorno ven, 02/05/2014 alle 15.53 +1000, Brian May ha scritto: [...] Alternatively, django-pipeline could be modified to conflict with python-pipeline. This would allow closing the grave bug report, but seems wrong. Sorry if this is trivial to all of you... (but it's not mentioned in the RFA bug or in the breaks bug): the original python-pipeline was renamed to python-grapevine. See http://jwilk.net/software/python-grapevine Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1399233829.30660.10.ca...@debiousci.pietrobattiston.it
Re: request for packaging: numba (numpy-aware LLVM-based python compiler)
For Sylwester and whoever may be interested: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743877 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743876 I hope this is useful to someone (apart from me)! Pietro Il giorno ven, 15/03/2013 alle 10.49 +0100, Sylwester Arabas ha scritto: Dear Debian Python Team, Could you please add (if not yet there) Numba to the Debian Python packaging TODO. Numba is a NumPy-aware LLVM-based python compiler. Website: http://numba.pydata.org/ Repository: https://github.com/numba/numba Documentation: http://numba.pydata.org/numba-doc/0.7/ Most recent stable version: 0.7 / Feb 2013 (0.1 was release in Aug 2012) License: BSD Thanks, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396897126.5398.19.ca...@debiousci.pietrobattiston.it
Re: search.html doesn't look like a Sphinx search page
Il giorno sab, 25/02/2012 alle 08.25 +0800, Paul Wise ha scritto: On Fri, Feb 24, 2012 at 8:13 PM, Pietro Battiston wrote: If there is consensus (and I guess it would be good to find it), I wasn't able to detect it... http://lists.debian.org/debian-mentors/2011/05/msg00194.html Notice I _did_ provide locally some javascript libraries which (the upstream downloads remotely, and which) are required for the functionality of the documentation. I would say that Debian Policy 2.2.1 constitutes consensus: http://www.debian.org/doc/debian-policy/ch-archive.html#s-main Please report RC bugs where you find this issue. Maybe I misunderstood you Paul, but 1) I think I followed what the policy states precisely in the fact that I provided locally javascript libraries which were _required_ for browsing the documentation. That's not the issue on which I beg for consensus. 2) Google Analytics is certainly not required (strictly speaking, it doesn't even enhance the documentation browsing experience), and in particular it can't be provided locally 3) on the other hand, if Google Analytics, and more in general remotely downloaded javascript libraries, are considered a dependency, then web browsers should not be in main. Instead they are (and users are free to block remote javascripts). I want to make clear that I do not oppose the view that Google Analytics should be stripped off from documentation... I'm just saying that as far as I understand the policy doesn't state that. _Also_ because it doesn't mention the privacy issue (and for instance the .js which is the subject of bug #637580 _could_ be provided locally, and that wouldn't entirely solve the bug according to the submitter). thanks for any clarifications Pietro -- 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/1330196426.4912.141.ca...@debiousci.pietrobattiston.it
Re: search.html doesn't look like a Sphinx search page
Il giorno sab, 25/02/2012 alle 19.12 +, Lars Wirzenius ha scritto: On Sat, Feb 25, 2012 at 08:00:26PM +0100, Pietro Battiston wrote: I want to make clear that I do not oppose the view that Google Analytics should be stripped off from documentation... I'm just saying that as far as I understand the policy doesn't state that. _Also_ because it doesn't mention the privacy issue (and for instance the .js which is the subject of bug #637580 _could_ be provided locally, and that wouldn't entirely solve the bug according to the submitter). It is probably true that the Debian Policy does not mandate that we protect the privacy of our users. That should not have to be mandated: it is clearly the right thing to do, just like we protect our users' security. Ehm... OK, makes sense. Sorry for the noise. Pietro -- 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/1330212828.4912.156.ca...@debiousci.pietrobattiston.it
Re: search.html doesn't look like a Sphinx search page
Il giorno ven, 24/02/2012 alle 12.24 +0100, Jakub Wilk ha scritto: * Paul Wise p...@debian.org, 2012-02-24, 13:29: Also, please remove Google Analytics code, and references to other JavaScript code and CSS hosted on external websites. I don't want to be tracked when viewing local documentation. : That sounds like an RC bug; things in main depending on stuff not in Debian. I would certainly consider things like thing RC for my packages, but I'm not sure there's consensus about this among the project. If there is consensus (and I guess it would be good to find it), I wasn't able to detect it... http://lists.debian.org/debian-mentors/2011/05/msg00194.html Notice I _did_ provide locally some javascript libraries which (the upstream downloads remotely, and which) are required for the functionality of the documentation. Pietro -- 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/1330085587.4411.42.ca...@debiousci.pietrobattiston.it
Re: search.html doesn't look like a Sphinx search page
Thank you for the reply Jakub. Il giorno mar, 21/02/2012 alle 17.03 +0100, Jakub Wilk ha scritto: * Pietro Battiston m...@pietrobattiston.it, 2012-02-19, 16:55: I'm trying to adopt dh_sphinxdoc, but it dies with the following error: dh_sphinxdoc: debian/python-sqlkit-doc/usr/share/doc/python-sqlkit-doc/html/search.html doesn't look like a Sphinx search page The page is available at http://anonscm.debian.org/gitweb/?p=collab-maint/sqlkit.git;a=blob;f=doc/html/search.html The page reads: creato usando a href=http://sphinx.pocoo.org/;Sphinx/a 0.6.4. Well, don't expect dh_sphinxdoc to be able to process stuff that was not build with the current version of Sphinx. My bad: I referred you to the page in git (and in the original tarball) as an example, but in fact that's not exactly the page dh_sphinxdoc complains about: the latter is indeed generated during the creation of the package, and I uploaded a copy for your convenience at¹ http://pietrobattiston.it/c/search.html So finally I'd appreciate any pointer on why _this_ is not recognized. thanks again Pietro ¹ If you just want to reproduce the problem cleanly: git clone git://git.debian.org/git/collab-maint/sqlkit.git cd sqlkit git checkout sphinxdoc_temptative git-buildpackage --git-debian-branch=sphinxdoc_temptative -- 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/1329878254.3318.165.ca...@debiousci.pietrobattiston.it
search.html doesn't look like a Sphinx search page
Hello, I'm trying to adopt dh_sphinxdoc, but it dies with the following error: dh_sphinxdoc: debian/python-sqlkit-doc/usr/share/doc/python-sqlkit-doc/html/search.html doesn't look like a Sphinx search page The page is available at http://anonscm.debian.org/gitweb/?p=collab-maint/sqlkit.git;a=blob;f=doc/html/search.html It _is_, I guess, heavily customized... but I didn't think this was a problem. So I'd appreciate any advice: should I 1) submitting a bug for dh_sphinxdoc, 2) patching the page/asking some modifications upstream, or just 3) keep on living without dh_sphinxdoc? thanks in advance Pietro -- 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/1329666934.2960.6.ca...@debiousci.pietrobattiston.it
RFS: gallery-uploader 2.3-1
Dear mentors, I am looking for a sponsor for the new version 2.3-1 of my package gallery-uploader. It builds these binary packages: gallery-uploader - graphical tool to upload pictures and videos to Gallery The package appears to be lintian clean. The upload would fix these bugs: 576414 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gallery-uploader - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gallery-uploader/gallery-uploader_2.3-1.dsc I would be glad if someone uploaded this package for me. Out of template: Piotr Ożarowski sponsored past uploads of the package, but he's currently in quasi vacation. If anyone is interested in sponsoring/reviewing but has no access to a gallery instance to test, please contact me in private so I can provide him the credentials for a test account. Kind regards Pietro Battiston signature.asc Description: This is a digitally signed message part
Re: Ideal directory structure?
There's no particular message I want to reply to: just wanted to signal that I find the structure ./appname ./appnamelib/__init__.py ./appnamelib/... ./stuff/appname.svg ./stuff/appname.glade ./stuff/... the most practical to get appname running in both installed and uninstalled mode - which I do find very useful for most applications. Then, in my apps, I put not_installed_dir = os.path.dirname(os.path.realpath(__file__)) if os.path.exists(not_installed_dir + '/stuff/appname.svg'): STUFF_DIR = not_installed_dir + '/stuff' LOCALE_DIR = not_installed_dir + '/locale' else: for directory in [sys.prefix, sys.prefix + '/local']: installed_root_dir = directory + '/share' if os.path.exists(installed_root_dir + '/nautilus-scripts-manager/stuff'): STUFF_DIR = installed_root_dir + '/nautilus-scripts-manager/stuff' LOCALE_DIR = installed_root_dir + '/locale' break ... and then put STUFF_DIR in the path of files I need (and import normally the modules/packages). What I ignore is: is there some smarter (than [sys.prefix, sys.prefix + '/local']) way to check possible _installed_ locations? Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
Il giorno sab, 30/01/2010 alle 21.10 +0530, Umang ha scritto: On 30/01/10 20:02, Pietro Battiston wrote: What I ignore is: is there some smarter (than [sys.prefix, sys.prefix + '/local']) way to check possible _installed_ locations? You're not _supposed_ to look in sys.prefix + '/local'. (i.e. /usr/local) If you used a pure version of distutils, then everything would fall straight into sys.prefix. However the Debian version has been patched. You can simply install as follows and get everything to work properly: $ sudo python setup.py install --install-layout=deb As far as I know, I'm not supposed to decide or even know how users will install my application... Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
Il giorno sab, 30/01/2010 alle 09.42 -0500, Guy Hulbert ha scritto: On Sat, 2010-30-01 at 15:32 +0100, Pietro Battiston wrote: ./appname ./appnamelib/__init__.py appending lib to everything is really ugly* ... I don't find ugly to signal that a library is a library... (regardless if it is used or not by other apps, and where it gets hence installed) is it because ./appname.py ./appname/__init__.py fails to work ? Also, yes. [*] And the debian perl group pre-pend 'lib' to all the packaged perl modules so you'd have libappnamelib-V.deb I'm not following you here. Notice that in neither of my mails I proposed a particular schema of debian packaging (though so far I never found inconsistencies between my upstream behaviour and possible debian packaging choices). Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
Il giorno sab, 30/01/2010 alle 16.14 +0100, Josselin Mouette ha scritto: Le samedi 30 janvier 2010 à 15:32 +0100, Pietro Battiston a écrit : Then, in my apps, I put not_installed_dir = os.path.dirname(os.path.realpath(__file__)) Every time you use introspection features (like __file__) for something else than introspection, you have completely failed somewhere in the design process. __file__ is a plague. If it wasn’t here, people would have, long ago, developed correct distribution systems for Python instead of using such an unreliable way of determining the filesystem layout. In my ignorance, what I've exposed is the only way I know to get things working as I want, so I'll be happy to get in touch with better designs... for me, so far, __file__ may very well have been a hack, but certainly not a plague. Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: __file__ is a disease
Il giorno sab, 30/01/2010 alle 22.56 +0100, Josselin Mouette ha scritto: Le samedi 30 janvier 2010 à 21:40 +0100, Pietro Battiston a écrit : In my ignorance, what I've exposed is the only way I know to get things working as I want, so I'll be happy to get in touch with better designs... for me, so far, __file__ may very well have been a hack, but certainly not a plague. Maybe you don’t understand it is a plague, because you are not trying to package the things you write with __file__ for a distribution. Not only I did try (and apparently succeeded) packaging some things I wrote for a distribution (called Debian, some of you may have heard about it), but I developed my style of packaging - which may certainly have its flaws - explicitly thinking to something that would - work uninstalled, - work installed, _and_ - reduce the packaging work to the minimum The location of module files on the system should be a hidden implementation detail. Because of __file__, it is not and this implementation detail has to be exposed by packaging tools, restricting what they can do in ways you don’t imagine, making it impossible to just abstract them behind the “module” concept - which is the only one that should matter for a programmer. I use __file__ exactly in detecting the case in which there is _no_ packaging tool involved. I perfectly know that this hack - like every hack - has its drawbacks: if the binary happens to be in the same folder of a folder called stuff which contains a file called $appname.svg, _then_ it will erroneously think it's running uninstalled. I consider this a minor problem, but feel free to point out anything I'm missing. Python is the only widespread high-level language to do that. I’ve never seen a Perl, Java or C# module look for its installation path before deciding what to do. In these languages, modules are abstract objects and you can do whatever you want with them on the filesystem without changing any line of code. Believe me, I love the Python language, but the interpreter is plagued with such issues. Actually, this is the only case in which I use __file__, and apparently you are much more competent than me about Python. So I have no reason to not believe you, in general. Going back to the topic, please try using autoconf, waf or even cmake to distribute your modules. These tools were designed to abstract things like filesystem locations and to generate everything needed at installation time. Python-specific tools like setuptools are not able to do that, not unless you bundle specific scripts with your packages. I find setuptools much more elegant, I like its ease of maintenance, I experienced it is easily extendable, I trust that if it has flaws they will get fixed... but most importantly for our discussion, if I did use some of those systems that you suggest (and that I frankly thought were just obsolete stuff still hanging around and nobody would adopt voluntarily for a Python app today), I think I would still use __file__ to know when I'm running uninstalled. Pietro -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please upload python2.6 to unstable
Il giorno mar, 12/01/2010 alle 00.06 -0800, Steve Langasek ha scritto: On Tue, Jan 12, 2010 at 08:56:08AM +0100, Sandro Tosi wrote: On Tue, Jan 12, 2010 at 08:39, Andreas Tille andr...@an3as.eu wrote: I have no idea what makes you think that even more angry mails on public mailing list will solve the problem. Be quiet won't solve it either, sadly. That's proved by the long silent period that provides not advance on the python maintainership-side. At least i'm proposing to form a group (and be part of that) to take over maintainership. A group hijack is still a hijack. I don't know why you try to make this sound like some sort of noble enterprise for the good of Debian. I'm certainly not a guru, but I never thought a hijack can't be noble and in particular for the good of Debian... pointers? Pietro signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: [Future Icon Records] You've been added to our mailing list.
Il giorno sab, 28/11/2009 alle 22.59 -0500, Future Icon Records ha scritto: Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS br/(Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) br/and we want to share with you His first Originalbr/Christmas song br/ br/I made a radio edit of so happy br/here it is if you like itbr/Radio Edit Of - So Happybr/https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060dbr/ br/Instrumental Radio Edit - So Happybr/https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410br/ Get your free download from Future Icon Records here: http://fburls.com/80-4IN6fGBp You have been added to the Future Icon Records fan list! If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link: http://www.FanBridge.com/signup/fansignup.php?userid=129853email=debian-pyt...@lists.debian.orgconfCode=25d3a6PPXhrak6X9K7d5tta41c -- This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists. With FanBridge your information is always secure. For more information about FanBridge please visit http://www.FanBridge.com/learn/ -- ***Important: Please be sure to add the email address (futureiconreco...@live.com) to your safe senders list.*** Here's how: Gmail 1.Click Contacts along the left side of any Gmail page. 2.Click Add Contact. 3.In the primary email address box, type futureiconreco...@live.com. 4.Click Save. AOL (version 9.0 or higher) 1.Click the Mail menu and select Address Book. 2.In the pop up box, click the Add button. 3.In the Other E-Mail field, type futureiconreco...@live.com. 4.Make our From address the Primary E-Mail address by checking the associated check box. 5.Click the Save button. AOL 8.0 1.Open this confirmation email. 2.Click Add Address. 3.Verify the sender's contact information (futureiconreco...@live.com). 4.Click Save. Yahoo! 1.Click the addresses button 2.Select Add Contact 3.Save the futureiconreco...@live.com to your contacts list. Hotmail 1.Click Options. 2.On the left side of the page, click Mail, and then click Junk E-Mail Protection. 3.Click Safe List. 4.Type futureiconreco...@live.com, and then click Add. Outlook 1.Right-click on a message from futureiconreco...@live.com. 2.Point to Junk E-mail, and click Add Sender to Safe Senders List. No Thunderbird, Evolution, Alpine and Mutt? We really should complain. Pietro signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Migration from python-central to python-support
Hello, since I have read [0], I'm migrating to python-support for the new version of my python-shapely package. But I admit that in the followups of the said mail, I got somehow confused... the 3 lines that Piotr suggests to add: | if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then | pycentral pkgremove python-foo | fi seem to be of at least debated utility... however [1] seems still open... so in the end is there a final position on this at all? thanks Pietro P.S: it was a while since I didn't read mail from the list, but I think/hope I have read all what could even vaguely have something to do with the subject... sorry if I missed anything. [0]: http://lists.debian.org/debian-python/2009/03/msg00015.html [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479852 signature.asc Description: Questa è una parte del messaggio firmata digitalmente
scipy packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, a package I maintain, gvb, has just entered sid, and I noticed that unfortunately I erroneously set Priority: optional (it is wrong because it depends on python-scipy which has Priority: extra). I was already fixing this, but first I was curious on why scipy had extra. I noticed it Conflicts: with the following packages: python-scipy-core, python2.3-scipy, python2.3-scipy-core, python2.4-scipy, python2.4-scipy-core actually, those seem to me all obsolete or only used in kfreebsd architecture... in other words, it seems to me better to set Priority: extra in those and Priority: optional in main python-scipy package. Please forgive me if I'm missing something, those are my first steps as Debian maintainer... Pietro Battiston -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIckWccZVtR82bmAYRAu2JAJ4rhr0OwrO/bY5PI0g4cBtlKdpVPACfdCfl xpIYdKLd0Yovd1+ElG6llDo= =U3SJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scipy packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ondrej Certik ha scritto: On Mon, Jul 7, 2008 at 6:34 PM, Pietro Battiston [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, a package I maintain, gvb, has just entered sid, and I noticed that unfortunately I erroneously set Priority: optional (it is wrong because it depends on python-scipy which has Priority: extra). I was already fixing this, but first I was curious on why scipy had extra. I noticed it Conflicts: with the following packages: python-scipy-core, python2.3-scipy, python2.3-scipy-core, python2.4-scipy, python2.4-scipy-core actually, those seem to me all obsolete or only used in kfreebsd architecture... in other words, it seems to me better to set Priority: extra in those and Priority: optional in main python-scipy package. Please forgive me if I'm missing something, those are my first steps as Debian maintainer... Thanks for asking these questions. Even though I try to keep python-scipy in shape, I don't know the answers. To me personally it doesn't really matter, if it's extra, or optional. But if you need something fixed in python-scipy and you get a consensus on that, I'll fix it, or help you fix it. Ondrej Actually, a further look showed that all the packages in Conflict: (do not exists in unstable/testing, and...) also have Priority: extra, so those conflicts are not themselves the reason of the extra priority... they are maybe a hint (python-scipy has probably inherited this), but I still don't get the original reason. Anyway, if it's not so important, I will wait a couple of days for some more info and then switch my package to extra and stop bothering. thanks Pietro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcoOJcZVtR82bmAYRAvqGAJ9VwCEHxBpXIbFTv90ltGubtgdE8QCdEKLN VsrhrEp9GeZI9dZrBj77Nyw= =hepX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
