Re: Help with interpreting piuparts error
On Mon, Dec 30, 2019 at 01:49:12AM +0100, Martin wrote: > Hi, > > I'm not sure how to interpret this 14799 lines piuparts log: > https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log > It says "ERROR: FAIL: Installation and purging test." > Any idea what's wrong with the package? TIA! > > Cheers Try searching for the line "0m28.7s ERROR: FAIL: After purging files have disappeared:" and viewing the stuff around that part of the log file. I'm not sure what the issue is exactly, but it does sound related to the failure in question. -- Kind regards, Loong Jin
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
On Thu, Oct 09, 2014 at 07:57:48PM -0400, Scott Kitterman wrote: [..] Presumably one is the one who set up the git repos. I, for another one, would really appreciate it if someone would take care of this. Don't they all share the hook script? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Recommending get-orig-source for packages ?
On Tue, Dec 03, 2013 at 05:42:31PM +0100, Jakub Wilk wrote: * Olivier Berger olivier.ber...@telecom-sudparis.eu, 2013-12-03, 17:06: Piotr Ożarowski pi...@debian.org writes: if there's working debian/watch file, there's no need to add get-orig-source (and to be honest, I prefer debian/rules without get-orig-source if debian/watch is available) +1 What's your rationale, Piotr ? I'd understand if there was something in debhelper/dh-python that would automatically handle debian/watch, but that's not the case, AFAICT... so, what harm is there to make things explicit It harms everyone who reviews the package. It's impossible to write g-o-s target that is both policy-compliant and easy to understand. I don't want to waste time glaring at extra 10 lines of code only to realize it's a fancy wrapper over uscan. Perhaps dh(1) should sprout a default get-orig-source target that just pokes uscan. That way, all packages with the %: dh $@ stanza will get it for free. Looks like there's a bug for it already: http://bugs.debian.org/515856 -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: python-django build weirdness
On Tue, Sep 24, 2013 at 11:23:14AM +1000, Brian May wrote: Hello, From a wheezy box, I am running the following commands: dget http://ftp.de.debian.org/debian/pool/main/p/python-django/python-django_1.5.4-1.dsc cd python-django-1.5.4 dpkg-buildpackage -rfakeroot -sa 21 | tee $logfile For different values of $logfile. If I run this from my home directory, it works. Every time. If I run this instead from /tmp/brian/tmp.rJDf6JJXaz - it fails. It always fails at exactly the same point. == FAIL: test_instance_is_maintained (django.contrib.formtools.tests.wizard.wizardtests.tests.WizardFormKwargsOverrideTests) -- Traceback (most recent call last): File /tmp/brian/tmp.rJDf6JJXaz/python-django-1.5.4/django/contrib/formtools/tests/wizard/wizardtests/tests.py, line 375, in test_instance_is_maintained self.assertEqual(2, User.objects.count()) AssertionError: 2 != 3 Why don't you catch the AssertionError at this point and check what the extra User object is? I just tried it on the same path as you used, but it worked for me. My /tmp is on tmpfs though. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: python-django build weirdness
On Tue, Sep 24, 2013 at 02:11:56PM +1000, Brian May wrote: On 24 September 2013 13:16, Chow Loong Jin hyper...@debian.org wrote: Why don't you catch the AssertionError at this point and check what the extra User object is? [User: johndoe, User: test1, User: test2] grepping for johndoe shows one match in tests/regressiontests/utils/simplelazyobject.py, where the test case creates a johndoe user. I suspect the error comes from using unittest.TestCase instead of django.test.TestCase. The latter does some cleanup and reinitialization after each testcase, which is necessary, but isn't happening here. Fixing the import line should do the trick. I just tried it on the same path as you used, but it worked for me. My /tmp is on tmpfs though. Not surprised... -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 01:43, Piotr Ożarowski wrote: does git-buildpackage work with git submodules (with debian dir as a separate git repo)? It should. I wrote the initial patch for submodule support in git-buildpackage. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 20/02/2013 23:45, Scott Kitterman wrote:
On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
[...]
If you are modifying some packages, it's to upload them at some point.
In such case, you will need the upstream tarball, right? I don't see where
the waste of bandwidth is then.
A VCS with all the upstream history will always be bigger than the tarball
for
just the current release. Sometimes substantially so.
Not always. Text compresses easily, so it is not uncommon for the .git to be
smaller than a single uncompressed checkout of the tarball. And with
pristine-tar, you end up having every single tarball in history contained in
that .git directory.
Second, I think Debian packaging work and upstream's product should be
distinct in the source package. The source package is what Debian as a
project ships as the source for DFSG purposes and it should be useful.
Which is why we have branches. One with the upstream code, and one
with the debian folder added. Everything being contained in that debian
folder. So it's really distinct.
You're missing my point. If it's only in the VCS, it's not in the source
package. The source package needs to stand alone without the VCS to, in my
opinion, properly comply with the spirit of the DFSG.
In the pkg-cli-{apps,libs}, we keep upstream history separate from downstream
history. Only the tarballs are imported, and that is done using git import-orig
--pristine-tar. Patches are maintained using gbp-pq or quilt. At the end of the
day, there isn't anything that only lives in the VCS.
Here's a huge mass of code and to understand what we did to it, you need
to refer to this external repository (VCS) is not socially acceptable to
me.
It's not any different to have absolutely zero upstream code in the VCS:
you will need to refer to an upstream tarball, which has a huge mass
of code.
Right, but if you embed Debian specific changes and don't use patches (as
I've
seen some people do who use Git) then any Debian changes to the upstream code
are difficult to parse and undocumented. When you have patches, they are
documented in debian/changelog and in the patch comments exactly why they are
there (I know sometimes this isn't done, but it is supposed to be).
Actually, with git-buildpackage, there's a gbp-pq tool which allows you to
import a quilt series of patches into a temporary patch-queue/$branch in git,
allowing you to use git rebase and whatever other git tools you have to figure
out what changes go where. After which, they can be exported into debian/patches
again and committed.
[...]
I've had it explained to me how to do it, done it, and then the next time I
needed to do it could no longer remember it. For people that do packaging
all
day, every day, I think many of these tools are great, but for people like me
for whom this is not the main focus of their day there's too much complexity
involved to be useful.
That argument applies to any VCS that you don't use on a daily basis. You use
bzr on a daily basis and forget how to use git. I use git on a daily basis and
forget how to use svn/bzr and have to relearn it any time someone forces me to
use one of those. I don't think this is a valid reason for avoiding git.
By the way, I do the packaging of MLMMJ, and upstream provides both
mercurial
and Git, which I think is really awesome. If we could have that, and not
only Git,
that would be best, IMO, so that those who likes hg could use it. Last
time I
looked, it didn't seem so hard to setup. Probably that would be a nice
addition
to Alioth as well, so that any Alioth project using Mercurial would have
Git too.
Do you also think it would be worth asking the Fusion Forge team?
I've used partial (debian dir) VCS branches for years in both Debian and
Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
all to full source.
WIthout full source, how do you use git-buildpackage? Could you describe
your workflow so that I can understand your view as well?
I don't. I generally unpack the upstream tarball, export the debian dir from
the VCS into the unpacked tarball, update the package, build it with dpkg-
buildpackage, and then commit the changes back to the VCS repository with
debcommit (which is very nice since it speaks to multiple VCS through the
same
interface).
That sounds like awful lot of steps to take. My workflow only involves editing
things directly in the git repository, and then running git-buildpackage to
build. With the export-dir option that I have set in ~/.gbp.conf, that
automatically exports it out to ../build-area/ and builds on the spot.
Committing can be done with debcommit or any other method of committing into a
git repository.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 11:58, Scott Kitterman wrote: On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote: On 21/02/2013 01:59, Scott Kitterman wrote: I've done the boring bits enough that my fingers mostly do them without much attention from my brain. If I were going to abandon my current approach, I'd have to see significant advantages for a new way and I don't. Somehow I can only read this as: I've done things manually all this while and it works for me, so go away and don't bother me because I don't see any advantages in having things automated. If the automation actually made things easier, I'd be in favor of it. I used to manually tag uploads in svn for DPMT/PAPT because I didn't trust svn- buildpackage. Then I learned it a bit better and started using it because it was easier. Then I learned debcommit -r -R and it was even easier. I'm all for easy. I have yet to see a full source (regardless of VCS) or git workflow that I didn't find more complex and harder to remember/do correctly than what we have now. I really don't care about what the new hotness is. It actually needs to be better and not just cooler. For me, a lot of better is simpler. Update package: - edit - debcommit -a - git buildpackage (--git-builder=sbuild -d $distribution) Tagging: - git buildpackage --git-tag (or --git-tag-only if you've already built) Import new orig tarball: - git import-orig $tarball Cloning repository: - gbp-clone git://git.debian.org/….git Updating repository: - gbp-pull Looks simple enough to me. How much simpler do you want it? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 12:02, Scott Kitterman wrote: It is to a degree, but the learning curve for git is subtantially steeper than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and there is no question in my mind which one, by a lot, is the most complex to learn. I'll admit that git isn't the simplest one, the others are not perfect either. To this day, I can't for the life of me figure out how to use CVS. Thank goodness git-cvsimport works. SVN is simple enough, but so is git when used with only linear history. But let's not forget the horrible hack that is svn tagging/branching. Bzr is simple enough as well, but $deity help you when you get incompatible pack format repositories, or when bzr suddenly decides that your branches have diverged for no apparent reason whatsoever. At least with git, you know when you've rewritten history -- you're no longer on the same commit. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
(Re-posted back on list. Sorry ScottK.) On 21/02/2013 12:37, Scott Kitterman wrote: With git (I've never used gpb, and maybe that's my problem) I end up having to do things like: git clone git://git.debian.org/….git for branch in pristine-tar debian/unstable ; do git branch --track $branch origin/$branch ; done That's the sort of thing that convinces me it's too hard. The fact that I have to manually make the association between individual local and remove branches is just insane. That's what gbp-clone does for you -- it clones, and creates master/pristine-tar/upstream. pristine-tar is the most important, because if this branch isn't present then git-buildpackage silently builds a brand new tarball for you. Aside from that, git (as of 1.7.10.4, not sure when it was introduced) also automatically does that set up for you when you git checkout $branch where $branch doesn't exist but origin/$branch does. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 12:46, Barry Warsaw wrote: #9 on Steve Bennett's list is right on target IMHO, but I've had this discussion so many times before, I don't have much energy for it again. 9. Git history is a bunch of lies The primary output of development work should be source code. Is a well-maintained history really such an important by-product? Most of the arguments for rebase, in particular, rely on aesthetic judgments about “messy merges” in the history, or “unreadable logs”. So rebase encourages you to lie in order to provide other developers with a “clean”, “uncluttered” history. Surely the correct solution is a better log output that can filter out these unwanted merges. Well, rebasing aside, my main reason for rewriting history is to ensure that each commit is properly separated so that if I ever need something specific reverted, I can just git revert and take out that particular change instead of having to pick aside the appropriate change from inside the commit. git-bisect also works a lot better if your commits are clean and uncluttered. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 17/02/2013 07:10, Barry Warsaw wrote: [...] OTOH, there's no doubt there are rough edges. Heck, I would even support a transition to git if the workflow were largely similar to Ubuntu's source branches, but with better quilt integration. To me, something like that is my packaging nirvana. git-buildpackage has gbp-pq which works pretty nicely. I've been using it for a while now. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: #! /usr/bin/python{,3} -Es
On 26/10/2012 19:02, Thomas Kluyver wrote: On 26 October 2012 11:53, Chow Loong Jin hyper...@debian.org wrote: What is the definition of system script? Any script installed via dpkg, perhaps? I wouldn't have said so - I install plenty of Python scripts from packages, like /usr/bin/ipython, that I wouldn't call system scripts. I don't think there's a robust distinction on Linux, but there's loosely a difference between system components and user applications. For the purposes of this discussion I would be inclined to define system scripts to be scripts installed by the system administrator, i.e. stuff that gets installed via dpkg, while user scripts are scripts that are installed by the user in his/her $HOME. So with that definition in place, are there any global scripts installed by the system administrator that should honour the PYTHONHOME/PYTHONPATH environment variables? When I run these scripts, I'd expect them to use whatever they came with, or you could end up with $script importing $private_module of a different version and then crashing due to incompatibilities. In the case of django-admin, I'd be inclined to treat it as a global script as described above, as you should be using ./manage.py for your local-repo administration tasks anyway, if you really intend to use it with a virtualenv. And if you really need to use django-admin with a virtualenv, then django-admin.py resolves to the in-virtualenv django-admin. django-admin without the extension is a Debianism. ipython as mentioned in a different post, would be an exception to the rule -- I would want it to the environment variables so I can play with things inside a virtualenv. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: #! /usr/bin/python{,3} -Es
On 26/10/2012 18:33, Jakub Wilk wrote: * Thomas Kluyver tho...@kluyver.me.uk, 2012-10-26, 11:03: Are there any situations where you might want to run a system script with modified Python environment variables? I can't think of any off the top of my head. Here's the list of environment variables: http://docs.python.org/using/cmdline.html#environment-variables What is the definition of system script? Any script installed via dpkg, perhaps? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Scons build system
On 24/10/2011 23:51, José Luis Segura Lucas wrote: Hello people. I don't know if this list is appropiate to discuss about Scons. If it isn't, please redirect me to the right one. I'm starting to package a C++ library for Debian and it uses scons to generate the binaries. The problem is that scons doesn't set the soname on the generated .so file. I was able to fix that, but I had to modify the upstream scons stuff. It's there any way to set the sonane using environment variables instead patching the upstream sources? I'm looking for something like LINKFLAGS=-Wl,-soname=mylib.version.so http://mylib.version.so I've actually packaged one such package in the past, i.e. sigx. You can take a look at the packaging if you like (which would really be a blast from the past because the package hasn't been updated for a few years). There really isn't a way to set the soname in scons unless the SConstruct things have provisions for setting LDFLAGS and such already. In fact, one of the major problems with scons was the lack of DESTDIR support and the need to manually implement it. Based on my experience with scons at that time, I think it wouldn't be too far from the truth to compare scons with raw Makefiles. It's such a crappy build system I don't even know why people even use it. Good luck. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Switching to git
On Monday 07,March,2011 06:44 AM, Piotr Ożarowski wrote: [...] (it's not that anyone else will do the work anyway - few tried to convince us to switch to $VCS and I didn't hear from them after asking to start preparing it) If we switch to git, I'd volunteer to help out with the transitions like I did for #debian-cli, so it's not like you didn't hear from me. However, if we don't switch to git, all my packages will remain in collab-maint git, and any new Python-related packages I create will also go there. PAPT/DPMT members are welcome to push there if they feel like it. I'm only putting my stuff there because the git-buildpackage merge-with-upstream workflow doesn't work very well with git-svn. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Switching to git
On Monday 07,March,2011 07:59 AM, Yaroslav Halchenko wrote: On Mon, 07 Mar 2011, Chow Loong Jin wrote: stuff there because the git-buildpackage merge-with-upstream workflow doesn't work very well with git-svn. any specific concerns? works for me ok with cython Merging history gets lost with dcommit, or maybe I'm not doing it right. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Switching to git
On Monday 07,March,2011 10:13 AM, Yaroslav Halchenko wrote: ah -- I never tried to dive that deep as in committing git merges back into SVN. Whenever I am interacting with SVN I am trying to be gentle with the repository -- just linear changes ;) My point was that I was using the merge-with-upstream kinda workflow, where you do merge stuff into your repository. I think it's a waste of space to keep the tarballs separate from the tree. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Switching to git
On Monday 07,March,2011 10:22 AM, Yaroslav Halchenko wrote: I think it's a waste of space to keep the tarballs separate from the tree. which you will do anyways at least for a moment (noone escaped from the fact of needing .orig.tar.gz yet), but might not be needed for the long run. So, if you carry about 100s of packages at once, carrying complete development histories (even though GIT is super-efficient in storage) might become a bit a burden... not to mention fetching of the entire collection of repositories (I bet alioth would simply choke then) Well not really. We've had an all-packages.git for pkg-cli-apps and pkg-cli-libs for some time, and it hasn't choked badly in my experience before. The size of Banshee's entire history is equivalent to the size of two tarballs. And it stretches back to 2005. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Untrusted search path vulnerabilities
On Friday 19,November,2010 03:47 AM, Filippo Rusconi wrote:
Hello, Pythonistas,
in my slow learning of Python and of Python program packaging, here am
I again asking for advice:
On Wed, Nov 17, 2010 at 10:58:48PM +0100, Jakub Wilk wrote:
A number of packages in the archive sets the PYTHONPATH environment
variable in an insecure way. They do something like:
PYTHONPATH=/spam/eggs:$PYTHONPATH
This is wrong, because if PYTHONPATH were originally unset or empty,
current working directory would be added to sys.path.
OK, so I may test if the content of the PYTHONPATH variable is empty
the way below, so that I can set the path in differenciated manners :
~~ start-script ~~~
#!/bin/sh
# Only append ${PYTHONPATH} if it actually contains something. Thus,
# test the length of the string in PYTHONPATH.
if [ ${#PYTHONPATH} = 0 ]
then
PYTHONPATH=/usr/lib/mmass/mspy/plot
else
PYTHONPATH=/usr/lib/mmass/mspy/plot:${PYTHONPATH}
fi
export PYTHONPATH
exec python2.6 /usr/share/mmass/mmass.py
~~~ end ~~~
You probably want something like:
export PYTHONPATH=/usr/lib/mmass/mspy/plot${PYTHONPATH:+:$PYTHONPATH}
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: dfsg suffix
On Tuesday 26,October,2010 02:00 AM, Sandro Tosi wrote: On Mon, Oct 25, 2010 at 19:53, Chow Loong Jin hyper...@ubuntu.com wrote: On Tuesday 26,October,2010 01:51 AM, anatoly techtonik wrote: On Mon, Oct 25, 2010 at 8:47 PM, Chow Loong Jin hyper...@ubuntu.com wrote: On Tuesday 26,October,2010 01:45 AM, anatoly techtonik wrote: What dfsg suffix in package version is for? In trac-bitten to be exact. It means that the tarball was repacked to meet DFSG[1] requirements. [1] http://www.debian.org/social_contract#guidelines Does that mean that I need to figure out why tarball was repacked and manually repack it again with the same changes to do new release? Yes, pretty much so. Or if the reasons do not apply any more, you can use the tarball as is. No: if it's been repacked, it should be stated in debian/copyright why, if not it's a bug (that should be filed it not there already); also, a get-orig-source target in debian/rules would be nice to have. That's exactly what I understood from figure out why tarball was repacked. It's usually either documented in debian/changelog or debian/copyright. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: direct-changes-in-diff-but-no-patch-system foo.egg-info/SOURCES.txt
On Friday 15,January,2010 04:39 PM, Floris Bruynooghe wrote: On Fri, Jan 15, 2010 at 02:16:10PM +1100, Ben Finney wrote: Cyril Brulebois k...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au (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? But that would also result in a change from the original upstream source. No? Backup and restore the file? I do that with some autotools stuff in a package in order to keep a clean diff. dpkg-source doesn't record deletions of files. So if you rm the changed files away, dpkg-source won't take note of it and your diff.gz will be clean. In the case of autotools stuff, something like find -name Makefile.in -delete after an autoreconf works well. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: VCS for Python code Was: Trac team almost dead?
On Tuesday 01,September,2009 09:16 PM, Dmitrijs Ledkovs wrote: Recently I have discovered some very nice features of hg that make it attractive: 1) Multiple branches such that debian/ can be kept on alioth and have working copy that has everything if maintainer prefers so 2) MercurialQueues plugin allows to keep versioned quilt patches, rebase, merge and split them. Keep their history in a seperate branch and always upto date series file. This 2 features are very neat that imho bzr and git are lacking. (well bzr will have stable support for nested trees soon can be simulated with checkouts now and git has tg2quilt) Git has #1, by the way, if I'm understanding you correctly. Which means both said features are present in Git at the very least. Also, Git does seem like a more popular option than Mercurial, so I think going Git would be a better choice, or many of us and potential newcomers would have to learn a new tool which they may potentially disagree with. In my case, the more I read about Mercurial, the more I dislike it, but that's a different matter. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: VCS for Python code Was: Trac team almost dead?
I'm all for Git. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
