Re: Python 2, Python 3, Stretch & Buster
Paul Tagliamonte (2015-04-16): > Background > == > > Python 2 is scheduled to be EOL'd upstream officially and for good in 2020. > We're in 2015 now (wow, that went quickly), and keeping our release cadence up > (3 years a pop) puts Stretch up in 2018, and Buster in 2021. Wheezy was first released in May 2013. Jessie gets hopefully released in April 2015. That doesn't make it 3 years between releases. You should stop trying to replace 2's with 3's. ;p > after Python 2 is EOL -- that's right, EOL! Nuts, right? (Last time EOL approached, it was pushed back by 5 years, so…) Mraw, KiBi. signature.asc Description: Digital signature
Re: python-openssl unavailable in sid
Brian May (2014-08-21): > Can somebody please tell me why python-openssl and python3-openssl isn't > available in sid? […] > It appears that the packages produced have changed to architecture > dependant packages, seriously wondering if maybe this got DAK confused. > > > (this problem is preventing me from uploading a fix for an RC bug) Adding ftpmasters in the loop to make sure they see your report. dak sees: python-openssl | 0.14-1 | sid | all while the amd64 Packages file only lists: python-openssl-dbg (amd64) python-openssl-doc (all) python3-openssl-dbg (amd64) https://ftp-master.debian.org/removals.txt reports that the following packages were indeed removed from sid: python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc So it looks to me it might “just” be about getting arch:all packages listed again in Packages files. Mraw, KiBi. signature.asc Description: Digital signature
Re: Python talks at DebConf
anatoly techtonik (18/05/2010): > Please translate to simple English. This was simple English, even French guys understood it… Mraw, KiBi. signature.asc Description: Digital signature
Re: python-twisted-core not getting updated on i386, but is updated on amd64 [was Re: Increasing number of conflicts]
Hi. Rick Thomas (21/04/2010): > I don't know how this can happen, but it definitely did happen. > Enjoy! The list of Arch: all packages merged into the Packages list for a given architecture depends (!) on the build status of the related Arch: any packages. I can think of the following reference: “Tracking arch all packages” in http://lists.debian.org/debian-devel-announce/2009/11/msg1.html Mraw, KiBi. signature.asc Description: Digital signature
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
Hi Lino, Lino Mastrodomenico (20/04/2010): > Given how much work is required to change the default Python, does > it make sense to just skip Python 2.6 and use 2.7 as the default > Python version in Squeeze? Python 2.6 transition is already going on. > The glaring downside of this is that 2.7 hasn't yet been released, > but a feature-complete beta is available and, given how big the test > suite is nowadays, it's pretty stable. The final 2.7 should be > released in June (see PEP 373 for the full schedule) which is, I > guess, before the release of Squeeze. Heard of what's called “freeze” in the release process? Hopefully, it will start before Python 2.7 is released. And the testsuite ensures basically nothing WRT Python Modules from other source packages. > Python 2.7 is faster than 2.6 (in my limited tests from a few > percents to more than 7 times faster, the latter with a small > CPU-intensive math program), it has a few cool new toys, for many > years in the future it will be THE Python 2 version (it's the last > one) and, most importantly it has several new features to make the > transition to Python 3 easier. For any software, new versions always have new shiny features and of course no regressions. > Including it in Debian now should make many Python programmers > happier in the next few years. Including it and making it the default are two different topics. > TIA for any feedback to this crazy idea. You named it. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: zynjacku package - build log
Jaromír Mikeš (07/04/2010): > Or maybe spam filter? Is it allowed to sent attachments to this > list? Not if you exceed the (IIRC list-specific) size limit. Mraw, KiBi. signature.asc Description: Digital signature
Re: RC severity for Python 2.6 related bugs
Jonathan Wiltshire (28/02/2010): > I think we need to do both before we end up running out of time. I > propose that we upgrade/file bugs as serious so that they get > maintainer attention where possible, and allow (let's say) 7 days to > react. What about providing with patches instead of only playing around with severity? *That* would help things going forward… Mraw, KiBi. signature.asc Description: Digital signature
Re: (again) Why default python is not 2.6 yet?
Jakub Wilk (17/02/2010): > * Failures, which should be fixable by give-backs: > > jppy amd64 armel i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc > twisted-runneralpha amd64 armel i386 kfreebsd-amd64 kfreebsd-i386 > mips mipsel powerpc I think I've given twisted-runner back several times already, and even ended up marking it as Failed. I've given it back anyway, as well as jppy. > * Temporary(?) dependency problems: > > dballe/kfreebsd* Not temporary, B-D on libsqliteodbc, from src:sqliteodbc, which is uncompiled. > openscap/kfreebsd* Not temporary, B-D on libnl-dev, from src:libnl, which is uncompiled. Mraw, KiBi. signature.asc Description: Digital signature
Re: (again) Why default python is not 2.6 yet?
Sandro Tosi (17/02/2010): > No, don't tell me it's because of the first round of binNMUs: either > someone's going to fix them or they will be FTBFS with 2.6 as > default, and better explicit than implicit (how many people look at > those binNMUs except us?). While 2.5 is the default, one can use (with the default interpreter) any package built against 2.5; meaning those FTBFSes don't matter much. Switching to 2.6 would mean that the packages currently FTBFSing can't be used (with the default interpreter). So, sorry, but yes, I think the FTBFSes are holding up the transition, and for a good reason. Hopefully, I guess a few NMUs should do the trick. (I might be missing something, I'm a bit laggy buildd-wise since past week.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Please consider adopting python-{networkx,pygraphviz}
Hi. Sandro Tosi (30/01/2010): > If you're decision is taken, I'd like to take the package back into > DPMT repo and take care of them with the team. Sure. > If you still want to be in Uploaders it would be nice (but I'll > understand if you don't), No, thanks; > and if you prefer to maintain the current GIT repo (instead of > reinjecting in SVN DPMT repo) we'll sort it out somehow. it's natural to keep all your stuff at the same place, please go ahead, and reinject. Sorry for the additional work. Thanks. Mraw, KiBi. signature.asc Description: Digital signature
Please consider adopting python-{networkx,pygraphviz}
Hi,
Yaroslav Halchenko managed[1] to piss me off so badly that I'm not
sure I want to have anything to do with python-{networkx,pygraphviz}
anymore. It would be nice to see some python-savvy folks take care of
it from now on.
1. See #565319 for reference.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Ongoing Python Transition: related FTBFSes
Scott Kitterman (17/12/2009): > I believe that we are getting close to uploading Python 2.6 to > Unstable and dropping Python 2.4 as a supported Python version. If > we finish preparations in the next week, are there any ongoing > transitions a python2.6/python- defaults upload would entangle that > would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567220: qscintilla2 #567222: python-qt3 #567224: python-qt4 #567226: pysvn #567227: pyqwt3d #567228: pyqwt5 #567231: gammu #567302: babel python-qt* FTBFSes are likely responsible for some others, so interested people may want to look into those first. > P.S. Please cc me on any replies as I am not subscribed to the list. Done. I've also added -python@ in the loop. Mraw, KiBi. signature.asc Description: Digital signature
Re: direct-changes-in-diff-but-no-patch-system foo.egg-info/SOURCES.txt
Ben Finney (15/01/2010): > Now, this is a “pedantic”-level tag, but it does seem valid: the > SOURCES.txt file is in fact modified from the original upstream > source. Just rm it in clean? > Can I prevent this from happening, perhaps by an option to the > Setuptools procedure? If not, can I recover from this result during > the Debian packaging? IIRC, that setuptools stuff should just be able to recreate that file if it doesn't exist? Mraw, KiBi. signature.asc Description: Digital signature
Re: Questions about PAPT and the uploading process
Piotr Ożarowski (06/01/2010): > > 5. lintian complains about my not using my full name in the > > package. Is that necessary? Is it bad if I use only my first > > name? > > which lintian tag is it? How do I grep? $ noglob git grep -e ^Tag.*full -- checks/fields.desc checks/fields.desc:Tag: maintainer-not-full-name checks/fields.desc:Tag: uploader-not-full-name Mraw, KiBi. signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Dmitrijs Ledkovs (09/12/2009): > Where is this git repository hosted? Or where can I get the current > version of the policy as seen on the debian.org website? $ debcheckout debian-policy declared git repository at git://git.debian.org/git/dbnpolicy/policy.git git clone git://git.debian.org/git/dbnpolicy/policy.git debian-policy ... Initialized empty Git repository in /tmp/debian-policy/.git/ […] Mraw, KiBi. signature.asc Description: Digital signature
Re: lintian troubles and .changes doubts
Alessandro Dentella (03/09/2009): > Hi, Hello, > I'm trying to produce the python-sqlkit package. I'm both the upsteam > author and the mantainer. I have /debian folder in original package. I > recently read is not recommended but I found easier to manage to have it > in the same mercurial repo. I have several questions: > > release version > --- > > The .deb was lintian clean on rel 0.8.6-rc5, then I did 'dch -v 0.8.6' and > dch required -b option as felt 0.8.6-rc5 was grater than 0.8.6. it is. You should have used “0.8.6~rc5”, which sorts lower than “0.8.6”, while “0.8.6-rc5” sorts higher. > I forced > it an now lintian complains: > >san...@bluff:/misc/src/hg/py$ lintian python-sqlkit_0.8.6_all.deb >W: python-sqlkit: latest-debian-changelog-entry-without-new-version > >What should I do? When you use -v, you have to specify the revision as well, that is: the -$N part. > .changes > > > If I run 'dpkg-buildpackage' I get a debian package named > 'python-sqlkit_0.8.6_all.deb but a .changes that has i386 in it: why? Because you built on i386. There's no _all.changes. > bad-distribution-in-changes-file > > > If I run lintian on .changes it complains > "bad-distribution-in-changes-file" but I'm unsure on what I should do. > At present I'm building on an ubuntu-hardy so the name gets written in > the changelog. There is nothing peculiar of one distro or another so I'm > unsure what I should write. Not sure about Ubuntu, but for Debian, that'd always be “unstable” (unless you're uploading to another suite of course, but that's another story). Mraw, KiBi. signature.asc Description: Digital signature
Re: Trac team almost dead?
Bernd Zeimetz (28/08/2009): > long time, actually there is even a plan (at least in my head) to > make it possible to have modules in git or svn while still being > able to checkout all of them in a useful way, but that means writing > new code, and I didn't have the time to do so yet. You meant putting a few lines into a .mrconfig file? Mraw, KiBi. signature.asc Description: Digital signature
Re: Migrating unmanaged Python l ibrary extension from ‘python-central’ to ‘python-support’
Ben Finney (14/04/2009): > > Put them into /usr/lib/python*/site-packages, as documented in its > > manpage? > > What, though, is ‘python*’ here? Remember, this is specifically for a > module that (at present) has no build system upstream; the code is > “installed” by manually copying files. Given you only have a .py file, no need to iterate over every supported python version (that would mean a loop over $(pyversions -s)), and only install it into the location for the current/default python version (thanks to $(pyversions -d)). See the MANPAGE_WRITER_DIR setting I proposed. Mraw, KiBi. signature.asc Description: Digital signature
Re: Migrating unmanaged Python l ibrary extension from ‘python-central’ to ‘python-support’
Cyril Brulebois (14/04/2009): > I'm attaching a source debdiff […] Oops, reading it upon receiving my answer makes me realise I didn't meant to delete get-orig-source from .PHONY, sorry for that. Mraw, KiBi. signature.asc Description: Digital signature
Re: Migrating unmanaged Python l ibrary extension from ‘python-central’ to ‘python-support’
Ben Finney (14/04/2009):
> As per bug#523965 http://bugs.debian.org/523965>, I'm attempting
> to migrate the ‘docutils-manpage-writer’ package from using
> ‘python-central’ to using ‘python-support’.
*-writer-manpage, actually.
> Currently (because there is no upstream build system specifically for
> this code) the package needs the following rules:
>
> =
> PROGRAM_DIR = usr/bin
> PROGRAM_NAME = rst2man
> WRITERS_DIR = writers
> MANPAGE_WRITER_DIR = usr/share/pyshared/docutils/${WRITERS_DIR}
>
> […]
>
> .PHONY: install
> install: build
>install -d ${MANPAGE_WRITER_DIR}
>install -m 644 writers/manpage.py ${MANPAGE_WRITER_DIR}
>install -d ${PROGRAM_DIR}
>install -m 755 ${PROGRAM_NAME} ${PROGRAM_DIR}
>dh --with python_central install
> =
That would be python-central, according to the manpage.
> I'm not very familiar with using ‘python-support’, so I'm not clear
> what I need to change in these rules. Where do I need to install the
> library files for them to be properly discovered by ‘dh_pysupport’?
Put them into /usr/lib/python*/site-packages, as documented in its
manpage?
I'm attaching a source debdiff with various things that should help you
reach some working package. Note that cleanup isn't perfect yet, and
that I haven't actually tested it (there are some Breaks: against some
of my locally-installed packages). There are some maintainer scripts,
though (see ./debian/docutils-writer-manpage/DEBIAN after build).
Hope this helps.
Mraw,
KiBi.
diff -u docutils-writer-manpage-0.1~svn.r5663/debian/changelog docutils-writer-manpage-0.1~svn.r5663/debian/changelog
--- docutils-writer-manpage-0.1~svn.r5663/debian/changelog
+++ docutils-writer-manpage-0.1~svn.r5663/debian/changelog
@@ -1,3 +1,10 @@
+docutils-writer-manpage (0.1~svn.r5663-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Ben's homework.
+
+ -- Cyril Brulebois Tue, 14 Apr 2009 04:09:10 +0200
+
docutils-writer-manpage (0.1~svn.r5663-3) unstable; urgency=low
* debian/rules:
diff -u docutils-writer-manpage-0.1~svn.r5663/debian/rules docutils-writer-manpage-0.1~svn.r5663/debian/rules
--- docutils-writer-manpage-0.1~svn.r5663/debian/rules
+++ docutils-writer-manpage-0.1~svn.r5663/debian/rules
@@ -12,26 +12,26 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-WRITER_PACKAGE = docutils-writer-manpage
-PROGRAM_PACKAGE = rst2man
-PROGRAM_DIR = usr/bin
-MANPAGE_WRITER_DIR = usr/share/pyshared/docutils/writers
+MANPAGE_WRITER_DIR = usr/lib/$(shell pyversions -d)/site-packages/docutils/writers
RST_SUFFIX = .txt
MANPAGES = rst2man.1
BYTECODE_SUFFIX = .pyc
-bytecode_files = $(wildcard ${CURDIR}/*${BYTECODE_SUFFIX})
GET_ORIG_SOURCE = $(dir $_)get-orig-source
+PLACEHOLDER=output/.placeholder-for-empty-directory
+
-.PHONY: build
build: manpages rst2man
- touch output/.placeholder-for-empty-directory
+ touch $(PLACEHOLDER)
dh build
+ # Manual installation to the proper directory (depends on
+ # pyversions -d's output):
+ install -d $(MANPAGE_WRITER_DIR)
+ install -m 644 writers/manpage.py $(MANPAGE_WRITER_DIR)
-.PHONY: manpages
manpages: ${MANPAGES}
%.1: %${RST_SUFFIX}
@@ -43,26 +43,13 @@
-.PHONY: clean
clean:
dh clean
- rm -f ${bytecode_files}
+ find -name "*.$(BYTECODE_SUFFIX)" -delete
+ rm -f $(PLACEHOLDER)
+ rm -f $(MANPAGES)
-.PHONY: get-orig-source
get-orig-source:
$(GET_ORIG_SOURCE)
-.PHONY: install
-install: build
- install -d ${MANPAGE_WRITER_DIR}
- install -m 644 writers/manpage.py ${MANPAGE_WRITER_DIR}
- install -d ${PROGRAM_DIR}
- install -m 755 rst2man ${PROGRAM_DIR}
- dh --with python_central install
-
-.PHONY: binary-indep
-binary-indep: build install
- dh --with python_central binary-indep
+%:
+ dh $@
-.PHONY: binary-arch
-binary-arch: build install
-
-.PHONY: binary
-binary: build binary-indep binary-arch
+.PHONY: manpages
diff -u docutils-writer-manpage-0.1~svn.r5663/debian/control docutils-writer-manpage-0.1~svn.r5663/debian/control
--- docutils-writer-manpage-0.1~svn.r5663/debian/control
+++ docutils-writer-manpage-0.1~svn.r5663/debian/control
@@ -5,16 +5,14 @@
Homepage: http://docutils.sourceforge.net/sandbox/manpage-writer/
VCS-bzr: http://bzr.debian.org/collab-maint/docutils-writer-manpage/
Build-Depends: debhelper (>= 7.0.14),
-python-central (>= 0.6.8),
+python-support,
python-docutils
Standards-Version: 3.8.0
-XS-Python-Version: all
Package: docutils-writer-manpage
Architecture: all
Depends: ${misc:Depends}, ${python:Depends},
python-docutils
-XB-Python-Version: ${python:Versions}
Description: writer for Docutils that outputs Unix manual pages
The purpose of the Docutils project is to create a set of tools for
processing plaintext documentation into useful formats, such as HTML,
@@ -27,7 +25,6 @@
Architecture: all
Depends: ${misc:Depends},
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Piotr Ożarowski (03/03/2009): > [Cyril Brulebois, 2009-03-03] > > Piotr Ożarowski (02/03/2009): > > > [Ben Finney, 2009-03-02] > > > > Why does this not happen automatically when the package is upgraded > > > > from a version that uses python-central? > > > > > > how can dh_pysupport know that x versions ago this package was using > > > python-central? > > > > I suggest you check “6.6 Details of unpack phase of installation or > > upgrade” in the Policy. > > > > (I'm not sure whether -central is so buggy that it can't handle removal > > properly, but I guess it could be.) > > see #479852 OK. I guess it's the answer Ben was looking for. And well, that might make pretty obvious to anyone not convinced yet that -central can't really be considered a “chosen one”, no? Mraw, KiBi. signature.asc Description: Digital signature
Re: Piotrek's new preferred Python helper tool - (unfair) decision
Piotr Ożarowski (02/03/2009): > [Ben Finney, 2009-03-02] > > Why does this not happen automatically when the package is upgraded > > from a version that uses python-central? > > how can dh_pysupport know that x versions ago this package was using > python-central? I suggest you check “6.6 Details of unpack phase of installation or upgrade” in the Policy. (I'm not sure whether -central is so buggy that it can't handle removal properly, but I guess it could be.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Bzr lightweight checkout, bzr shallow branches, and git
Steve Langasek (02/03/2009): > My rebuttal is that if git is technical superior to bazaar because > bazaar has a mechanism to create repositories with only partial > history, then bazaar is technically superior to git because git has > rebasing as a first-class feature. Oh my HEAD, it hurts. Mraw, KiBi. signature.asc Description: Digital signature
Re: Leaving DPMT?
Piotr Ożarowski (26/02/2009): > > Now, question: should I keep DPMT in Uploaders, or drop it? > > please remove it, one exception will lead to other requests and I just > love grep -r :-P OK, did so. Mraw, KiBi. signature.asc Description: Digital signature
Leaving DPMT?
Hello.
There's no f* way in hell I'm gonna keep using SVN. (That's not a troll,
a flame, whatever. Just a statement.)
That's why I'm planning to move python-{networkx,pygraphviz} out of
DPMT's svn and move them to collab-maint's set of git repositories.
Now, question: should I keep DPMT in Uploaders, or drop it?
Thanks for your views.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Frozen unstable (was: please test the numpy package)
Ben Finney (06/02/2009): > I'm unhappy about it too, but I don't understand it. Where can I find > an explanation for the necessity of freezing ‘unstable’ when preparing > to release ‘testing’? For more than verbose explanations, see -devel@ a few weeks ago, starting at <200812160703.00258.russ...@coker.com.au>. Mraw, KiBi. signature.asc Description: Digital signature
Re: please test the numpy package
Ondrej Certik (05/02/2009): > Ok. But we are wasting people's time. I just got another email from a > Ubuntu user that he will rather consider compiling it for Ubuntu's PPA > himself, because he cannot use debian experimental. Of course. > > So he needs to invest his time in the package, I need to invest my > time in the package and the result is that it will not even be in > unstable anyway. :( (Following at home, so I might be missing something obvious.) What's the difference between unstable and experimental from that Ubuntu user point of view? If the use of a PPA is what I think it is, he has to fetch the source, be it from unstable or from experimental, throw it into the *builder of his choice, and upload that to the so-called PPA. How much time does he need to dget && *builder && dput? That's not what I call “invest time in the package”. And not breaking unstable at this point of the release cycle is something that matters, especially for late hotfixes that might be needed (and there still are such needs). Mraw, KiBi. signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
Tristan Seligmann (20/12/2008): > My personal preference ordering would probably be: > > hg, bzr, svn, git git, FD, * devotee to the rescue. Mraw, KiBi. signature.asc Description: Digital signature
Re: [RFS] python-osd (updated)
Mauro Lizaur <[EMAIL PROTECTED]> (22/09/2008):
> BTW, if you sponsor this package, the only thing left is to contact
> RMs explaining the situation, right?
Mostly, yes.
> [0] http://lusers.com.ar/packages/python-osd_0.2.14-4.dsc
Hmm, many remarks:
- debian/rules modifications aren't documented at all in the changelog.
- the libxosd2 dependency should be pulled by ${shlibs:Depends}, you
should never have to include a dependency manually like that.
- you didn't document that you dropped Conflicts and Replaces, nor why.
- you didn't document that you added a debian/watch file.
- your not mentioning the case change (s/python/Python/) in the first
line of the long description is OK, though.
So you've got to fix some bits before someone can sponsor this.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: [RFS] python-osd (updated)
Kel Modderman <[EMAIL PROTECTED]> (22/09/2008): > > BTW, Since the bug in the previous revision practically renders > > pyosd unusable, in order to have the chance to update this package > > on Lenny would be OK to change the severity from 'normal' to > > 'important' and/or the urgency to 'high'? Any advice is welcome. I'd bump the bug severity to serious. > iirc, the release managers stated that urgency is not to be raised to > higher priorities for this purpose. See: > > http://lists.debian.org/debian-devel-announce/2008/07/msg6.html Indeed, but I'd use medium in this case, so that the package doesn't get hold too long in unstable (assuming the RMs grant it a freeze exception). If you don't find a sponsor, you're welcome to get back to me tomorrow or so. Mraw, KiBi. signature.asc Description: Digital signature
Re: matplitlib build problems
Kumar Appaiah <[EMAIL PROTECTED]> (18/09/2008): > Now, this shouldn't really happen, since g++ is supposed to be present > during the build, right? Also, note that the g++ package is being > installed on arm and ia64, but not on mips and powerpc. At least on ia64 (didn't check the others), looks like broken chroot: | Toolchain package versions: libc6.1-dev_2.7-6 gcc-4.3_4.3.1-9 g++-4.3_ binutils_2.18.1~cvs20080103-7 libstdc++6_4.3.1-9 libstdc++6-4.3-dev_ Note the x_ packages (as opposed to x_y), they are missing. Mraw, KiBi. signature.asc Description: Digital signature
Re: Best practice for test(s) directories?
Cyril Brulebois <[EMAIL PROTECTED]> (14/07/2008): > Since it isn't really needed for the module to correctly work, I'd be > tempted to keep it out of python-support's paths, and to keep it under > /usr/share/$package instead, but what do you think? Also, should it be > set +x in that case? Thanks for your thoughts. Some remarks: - The test-as-example idea can make sense, but not really in this case. - There's no debug package for this particular package, so that doesn't make much sense to add a binary with just that. - The tests can't be used at build time, since they rely on a working networking connection to be successful. So I think I'll just let them only in the source package. Mraw, KiBi. signature.asc Description: Digital signature
Best practice for test(s) directories?
Hi folks, I'm wondering whether there's a preferred place where to drop the test(s) directory. I don't really know whether to choose /usr/share/python-support/$package/test(s) or /usr/share/$package/test(s). Since it isn't really needed for the module to correctly work, I'd be tempted to keep it out of python-support's paths, and to keep it under /usr/share/$package instead, but what do you think? Also, should it be set +x in that case? Mraw, KiBi. signature.asc Description: Digital signature
Re: join DPMT?
Carlos <[EMAIL PROTECTED]> (08/07/2008): > > "tiziano-guest" (btw, why *-guest?). > > AFAIK '-guest' is appended to every not-DD login. Correct. Mraw, KiBi. signature.asc Description: Digital signature
Re: debhelper 7 and python-central
On 18/05/2008, Monty Taylor wrote:
> 1. What are the real differences between these two?
> 2. Why, as a packager, would I choose one over the other?
A bit of stats:
# source-wise
$ for i in central support; do grep-dctrl -S -F Build-Depends python-$i
-sPackage /var/lib/apt/lists/*Sources | wc -l ; done
325
426
# binary-wise
$ for i in central support; do grep-dctrl -P -F Depends python-$i -sPackage
/var/lib/apt/lists/*Packages | wc -l ; done
453
593
I might be missing the Indep thingies, but you see the idea if you want
complete stats.
More seriously, you may want to compare the following:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-support
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-central
In particular, check the grave and serious keywords (coloured in red),
and the outstanding bugs.
You may also want to have a look at the maintainer scripts. From a quick
look, postinst's are mostly equivalent, from a complexity point of view.
prerm's are a bit more challenging:
(var/lib/dpkg/info/python-networkx.prerm)
| # Automatically added by dh_pysupport
| if which update-python-modules >/dev/null 2>&1; then
| update-python-modules -c python-networkx
| fi
| # End automatically added section
(/var/lib/dpkg/info/python-imaging.prerm)
| # Automatically added by dh_pycentral
| if [ "$1" = remove ]; then
| if which python >/dev/null 2>&1 && which pycentral >/dev/null 2>&1; then
| pycentral pkgremove python-imaging
| else
| flist=$(tempfile)
| slist=$(tempfile)
| dpkg -L python-imaging | tee $flist | \
| while read n; do
| case "$n" in
| /usr/share/pyshared/*)
| n2=${n#/usr/share/pyshared/*}
| case "$n" in
| *.py) echo "p $n";;
| *) [ -d "$n" ] && echo "d $n2" || echo "f $n2"
| esac
| ;;
| *) continue
| esac
| done > $slist
| if [ -s $slist ]; then
| for d in /usr/lib/python[0-9].[0-9]/-packages; do
| case "$d" in */python2.1/*|*/python2.2/*) continue; esac
| while read t n; do
| case "$t" in
| p) rm -f $d/$n $d/${n}[co];;
| d) rmdir $d/$n 2>/dev/null || true;;
| *) rm -f $d/$n
| esac
| done < $slist
| done
| fi
| awk '/\/usr\/share\/pyshared/ {next} /\.py$/ {print $0"c\n" $0"o"}'
$flist \
| | xargs -r rm -f >&2
| rm -f $flist $slist
| fi
| fi
| # End automatically added section
So, if you want your eyes to start bleeding, have a look ath the preinst
scripts. Empty in the -support case. And in the -central one:
| # Automatically added by dh_pycentral
| if which pycentral >/dev/null 2>&1 && pycentral --help 2>/dev/null | grep -q
pkgprepare; then
| pycentral pkgprepare python-imaging <> /var/lib/pycentral/delayed-pkgs
| fi
| # End automatically added section
> 3. Is there a valid reason to have both of them be acceptable if they
> both do the same job?
I'd rather say that one of them is doing an unacceptable job and should
disappear.
Mraw,
KiBi.
pgpHWgf6ofytD.pgp
Description: PGP signature
Re: Proposed new package, bugs-everywhere_0.0.193-1.1
On 21/04/2008, Ben Finney wrote: > I'd appreciate any feedback from those more experienced with Debian > packaging in general and Python packaging in particular. I won't be able to comment much on the python part since you're using -central, that I don't know. Anyway, some quick comments: - debhelper version mismatch: 5 is debian/compat, >= 6 in debian/control. - strange to see there's only a © 2005 copyright line, IIRC the project has been quite active lately. But still IIRC you're more versed into legalese than I am, so you probably told them to update their copyright notices. Hmm, and a quick grep shows that you're missing at least: ./libbe/hg.py:# Copyright (C) 2007 Steve Borho <[EMAIL PROTECTED]> - debian/README.Debian looks like superfluous (and contains a different address, for the sake of the argument). Maw, KiBi pgpSqI2aMOpXU.pgp Description: PGP signature
