Looking for Python developers that want to improve Debian
Hey people, I wanted to share the Freexian announce that I just published in my blog: https://raphaelhertzog.com/2022/03/29/join-freexian-to-help-improve-debian/ We are a small team of Debian developers/contributors. We are bound by our mission statement: > Freexian's mission is to help Debian evolve to be the leading Linux > distribution and a model to follow in the free software world. > > We want to achieve that by enabling passionate contributors to spend most > of their time working on Debian and free software, combining lucrative > work in support of enterprise customers, core contributions to Debian's > processes, and personal goals. We would like to grow our team to tackle new challenges and we are looking for Python developers since all our new developments are done with Python. I can't promise working only with Python because our main revenue stream comes from LTS and ELTS so any candidate will have to provide security updates in a multitude of programming languages. If any of this sounds interesting to you, please reach out to us at gera...@freexian.com. Cheers, PS: Take the time to read the full mission statement: https://www.freexian.com/apropos/index.html#mission -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#988658: RFP: python3-pyupgrade -- Automatically upgrade syntax for newer versions of the Python language
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
* Package name: python3-pyupgrade
Version : 2.16.0
Upstream Author : Anthony Sottile
* URL : https://github.com/asottile/pyupgrade
* License : BSD
Programming Lang: Python
Description : Automatically upgrade syntax for newer versions of the
Python language
This helper script can help you normalize your Python source code
by rewriting parts of your code to use the latest syntax improvements.
Some examples from the README:
set([]) # set()
'{0} {1}'.format(1, 2)# '{} {}'.format(1, 2)
x is 5 # x == 5
'{foo} {bar}'.format(foo=foo, bar=bar) # f'{foo} {bar}'
I discovered this tool by reading some documentation and I'd like
it to be available in Debian so that I can try it and use it :-)
ccing debian-python@lists.debian.org in the hope to catch the attention of
someone with more time than me.
Thank you!
--
Raphaël Hertzog
Re: Python package situation
Hi, On Wed, 17 Feb 2021, Brian May wrote: > I believe there are a number of Python packages in Debian unstable that > are out of date in respect to latest upstream. > > e.g. > https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes > > Somebody needs to do the work to update them. But maybe the fact that > nobody is doing so, might mean that nobody is using them? Quite often, we introduce Python packages for the need of a specific application and then we don't really see a benefit to upgrade the package unless the application also needs a newer version of the module. That likely explains partly why so many modules are lagging behind. > I personally found a while back that keeping these packages up-to-date > was draining far too much of my time. Time I don't actually have. So I > now use Docker+pip for my applications. On the Kali side, I'm trying to work with Jelmer and his janitor bot to try to automate as much as possible the work of preparing new upstream releases. We're getting close to having something useful where the bot does at least the upstream tarball import and a test rebuild and so on. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: upstream python concerns, python3-full package for bullseye
On Fri, 12 Feb 2021, Thomas Goirand wrote: > What I read from Elana, is that *upstream* think we have a problem. But > do we really have one? Or are we just being influenced by upstream who > is trying to impose a view we don't necessary share? Or is it you that is trying to impose your view on those users? Let's be clear, I understand what you are saying and I mostly agree with your view but Debian is about inclusiveness and about meeting the needs of as many people as possible and I believe that implementing this python3-full meta-package can only help towards this. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Transfer cherrytree from DPT to Debian group
Hello Andrius, On Fri, 16 Oct 2020, Andrius Merkys wrote: > Recently cherrytree [1] has been rewritten from Python to C++, thus it > no longer belongs in DPT. Could someone with adequate permissions > transfer it from DPT to generic Debian group on salsa.d.o? > Alternatively, one could grant me permission to manage cherrytree so as > I could transfer it myself. > > [1] https://salsa.debian.org/python-team/packages/cherrytree Transferring to another group requires owner rights on both the source and the target group, and the "debian" group is owned only by the salsa admins so you have to ask their help: https://salsa.debian.org/salsa/support/-/issues Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Newcomers project: DPMT/PAPT pristine-tar verification
[ Putting Jelmer in copy ] On Sun, 19 Jul 2020, Sandro Tosi wrote: > On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog wrote: > > On Fri, 10 Jul 2020, Sandro Tosi wrote: > > > The checks i have in mind for now, are: > > > > > > * pristine-tar branch must exist, if not -> it's a bug > > > * pristine-tar + upstream branch must produce the same tarball as > > > downloaded from the archive, if not -> it's a bug > > > * bonus point: fix the repo if it doesn't generate the right tarball > > > and or the branch is missing. > > > * bonus point: make this into a service that runs regularly (not > > > strictly necessary to be limited to us) > > > > I would suggest that this would be a nice job for the janitor bot. > > https://janitor.debian.net/ > > How would you suggest implementing this? The janitor bot can be added to our salsa groups and he can be configured to push changes directly instead of proposing merge requests. All the above operations are simple automatable jobs that only result in changes to the git repositories (mainly updates to the pristine-tar branch). I would thus suggest to add this functionality to the janitor and I believe the right place for this is here: https://jelmer.uk/code/silver-platter/tree/master/silver_platter/debian Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Newcomers project: DPMT/PAPT pristine-tar verification
Hi, On Fri, 10 Jul 2020, Sandro Tosi wrote: > The checks i have in mind for now, are: > > * pristine-tar branch must exist, if not -> it's a bug > * pristine-tar + upstream branch must produce the same tarball as > downloaded from the archive, if not -> it's a bug > * bonus point: fix the repo if it doesn't generate the right tarball > and or the branch is missing. > * bonus point: make this into a service that runs regularly (not > strictly necessary to be limited to us) I would suggest that this would be a nice job for the janitor bot. https://janitor.debian.net/ Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Move python-libusb1 from NEW/Unstable
Hello Mattia, On Sun, 24 May 2020, Mattia Rizzolo wrote: > On Sat, May 23, 2020 at 05:03:50PM -0700, debianb...@felinefamily.org wrote: > > The package maintainer, Arnoud Fountaine uploaded the fix to the last > > bug a week or so ago but it’s been stuck in the NEW queue ever since. > > Is there anyone that can approve it so it can get moved to Sid > > NEW is a manual process from the ftp-team. > It can take from a few hours up to months, and it's not really something > that can be prodded just to have a quicker backports. > The queue is processed in a non specified order, and you can see it > here: https://ftp-master.debian.org/new.html > > *Usually* (not always!), if it's a small packages it is processed quite > quickly, but poking the ftp team before not even a month has passed > without a good reason (for example, it's blocking an RC bug fix) is just > inappropriate. I don't agree with your assessment. A month is a very long time and I have prodded members of the FTP team way earlier than that when I had a reason. And here a reason was given. I don't really see why you judge that reason to not be a good reason. Any reason which ends up as "it's blocking further work" is a good reason IMO. Mattia, I really appreciate what you have been doing in Debian but at times I have the feeling that you keep alive the idea that some of the most glaring deficiencies of Debian are "normal". Please try to show some compassion to other contributors when they are stuck. To me, the above response sounded like "yeah, that's normal, don't complain, it's inappropriate". It would have been much better if it had been worded as « It's unfortunate that this is blocking your work but NEW is a manual process To speed up the process, you can try to prod ftpmasters on #debian-ftp explaning your reason why you need it. I'm not convinced that a backport passes the threshold justifying such a prod but you can always try. » Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes
On Mon, 11 May 2020, Sandro Tosi wrote: > when i push i always do > > $ git push --all ; git push --tags To push only branches which are shared on both sides and the associated tags I use this: $ git push origin : --follow-tags Which I alias as "git dpush" so I have this in ~/.gitconfig: [alias] dpush = push origin : --follow-tags drelease = !gbp dch -R --commit (I left my "git drelease" alias as well, I use it just before to update the changelog...) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Merge Requests
On Fri, 06 Dec 2019, Louis-Philippe Véronneau wrote: > On 19-12-06 04 h 34, Jonathan Carter wrote: > > For other MRs, I noticed that many small changes in the packaging didn't > > have an associated changelog entry with it, so I had to dch to add a > > changelog entry. I think for small changes I'd prefer the person who > > submits the MR to add them. For larger ones it probably makes sense not > > to do that since it might take longer. > > I rarely add a changelog entry when creating MRs, as I feel it often is > a burden for the maintainers if the MR isn't immediately merged and new > releases are made (creates merge conflicts, etc.). And it's also painful when you use "gbp dch", having a commit in the middle introduce a changelog entry means that the next "gbp dch" run might miss some commits that need to be documented. Not everybody is sold to the idea of using "gbp dch" but it's definitely cleaner IMO. Commits that do not modify debian/changelog are also easier to cherry-pick between different branches, etc. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Streamlining the use of Salsa CI on team packages
Hi, On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote: > For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is > the most mature solution, has more contributors and has more features > (including reprotest and piuparts). This option seems to have had the > most support so far. Ack. I also deployed this pipeline on 500 Kali packages at https://gitlab.com/kalilinux/packages/ and it has been working relatively well. There are a couple of remaining issues but the project is evolving quickly and I'm confident that we can get past them. One of the issue is related to the fact that the CI build does not bump the version and it can conflict with the version in the archive and it will often confuse piuparts. https://salsa.debian.org/salsa-ci-team/pipeline/issues/78 The project is a bit lacking in terms of leadership/guidance and there are pending issues that should have been resolved more quickly to avoid confusion and better define the rules: https://salsa.debian.org/salsa-ci-team/pipeline/issues/84 https://salsa.debian.org/salsa-ci-team/pipeline/issues/76 https://salsa.debian.org/salsa-ci-team/pipeline/issues/86 > For step 2, so far people seemed to agree that: > > * having a standardised CI pipeline is a good idea > * the CI should be used as a tool to help us improve our packages, and > not be required to pass On this, I disagree. The CI should pass, but it's perfectly OK to disable some of the failing tests to make it pass. We want merge requests to run the CI and we want them to succeed to prove that they are not making the package regress compared to the current situation. Consider that the package tracker is likely to display the CI status at some point. Note that for merge request, it won't really work until https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
Hi, On Sun, 01 Sep 2019, Norbert Preining wrote: > At all: anything you want to see before I upload the new version? I checked the package quickly (without building it), it looks good. Maybe you could have bumped debhelper to 12 and standards-version to 4.4.0 but that's a minor detail. Thanks for leading this! Cheers, > On September 1, 2019 9:43:33 AM GMT+09:00, Matthias Klose > wrote: > >On 01.09.19 01:59, Norbert Preining wrote: > >> Hi Raphael, > >> > >> @Matthias, please read on. > >> > >> On Sat, 31 Aug 2019, Raphael Hertzog wrote: > >>> https://salsa.debian.org/python-team/modules/python-mechanize > >> > >> Thanks, that is perfect. I pushed my work there, changed control VCS, > >> maintainer, and uploader. > >> > >> ATM I only put me into the uploaders. Please, those who are > >interested, > >> put yourself in there, thanks! > >> > >>>> Do we go through package salvaging? > >>>> https://wiki.debian.org/PackageSalvaging > >>> > >>> I don't think it's required here. The bugs have been open for long > >enough > >>> without any activity. > >> > >> Hmmm... I don't feel confident simply uploading someone's else > >package. > >> Best would probably be if Matthias Klose, one of the current > >Uploaders, > >> agrees to that and uploads the current package thus passing over > >> maintainership. > >> > >> Matthias? > > > >did you see my comment in #936270? > > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. + JAIST + TeX Live + Debian Developer > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: updating mechanize - help concerning tests with pybuild
Hi, On Sun, 01 Sep 2019, Norbert Preining wrote: > Fine with me. If you could give me DPMT membership on salsa I can push > my current work there. I can't grant you the right to the whole group (I'm not an owner) but I created the repository and granted you the rights on this repository at least: https://salsa.debian.org/python-team/modules/python-mechanize Let me know if you need anything else. To get access to the group, you should follow the procedure described in this document: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > Do we go through package salvaging? > https://wiki.debian.org/PackageSalvaging I don't think it's required here. The bugs have been open for long enough without any activity. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: updating mechanize - help concerning tests with pybuild
Hello, On Sat, 31 Aug 2019, Norbert Preining wrote: > I would be interested in adopting mechanize if the current maintainers > / uploaders are fine with it. Or we put it into the python modules team > and I do the stuff there. All is fine for me. I would like to see the package in the python modules team as well. We have packages in Kali depending on this module and we also need the Python 3 version. Hence we also pinged the current maintainers here just one day before you: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912014#10 > How could be proceed here? Looking at the status of the packages in the team, it's quite clear that the team is MIA as a whole: https://qa.debian.org/developer.php?email=pkg-zope-develop...@lists.alioth.debian.org The only recent upload is from TANIGUCHI Takaki on zope.deprecation 4.4.0-1. It's also the only package Thus I would suggest to go ahead and take over the package in the DPMT team. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Git, gbp blues
On Sun, 25 Aug 2019, Dmitry Shachnev wrote: > The correct procedure is running “gbp pq import” *before* importing a new > tarball. Then after importing you do “gbp pq rebase”. > > Sometimes I myself forget to run “gbp pq import”. In this case I do the > following: Instead you should use "gbp pq import --time-machine=X" where X is the number of commits that you accept to go backwards to try to find a point where the patch series can be applied. Then you are on your branch, ready for a rebase... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
Re: Dropping Python 2 support for web.py before buster
Hi, On Tue, 22 Jan 2019, Julien Danjou wrote: > I'm not actively maintaining rebuildd for years now. I'm not even sure > it has still any user. FWIW, the Kali buildd do still use rebuildd. > I wouldn't spend time on porting rebuildd nor I would let it block it > updating web.py. > Not sure what's the other solution would be (removal?) but if you have > any idea, go ahead. Anyway, the fact that we have one known user should not forbid you to go forward with all this. I will change the Kali infrastructure to use something else, most likely buildd and wannabuild. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Please add me to PAPT
Hello,
I'm part of the DPMT and I have already agreed to follow the policy.
However I'm not part of PAPT and I would like to join this team too
because at multiple times I have felt the need to update some packages
in that team and I just skipped doing it because I did not have access
to the git repositories.
So please add me ("hertzog") to
https://salsa.debian.org/python-team/applications
Thank you.
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
New upstream version of python-xlwt
Hi, ccing maintainers of reverse dependencies of python-xlwt. We switched to a new upstream version (0.7.5 -> 1.3.0) so you might want to check that your packages are still working with this new version (rows, python-pandas, On Thu, 26 Oct 2017, Thomas Goirand wrote: > I've found out that antlr.py is embedded, and still in use in this > upstream release. So I added a patch to remove it from upstream. This change was not good. The embedded antlr.py is patched for xlwt. See https://github.com/python-excel/xlwt/issues/73 This change thus got reverted and I uploaded the resulting package with a few more cleanups. > However, the package was using git-dpm. As always, importing a new > release with git-dpm is a nightmare. Therefore, before doing it, I > simply removed all patches (as I thought no patch was needed). Now, > what's the way to make it again so that the package uses git-dpm? Is it > still needed these days, or is it ok to not do it in the team? AFAIK it's OK to not use git-dpm. However it seems that the team documentation would need an update... also since we haven't documented the switch to salsa either. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: PAPT and DPMT membership request for moschlar-guest
Hi, On Mon, 26 Mar 2018, Piotr Ożarowski wrote: > [Moritz Schlarb, 2018-02-15] > > please also add my user "moschlar-guest" to the respective Groups on Salsa. > > looks like my thread is broken, I cannot find referenced emails. Do you > accept our policy? Which packages do you want to work on? Original email: https://lists.debian.org/debian-python/2017/01/msg00030.html So it's about the "nagstamon" package. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: xhtml2pdf updated, but can't push to salsa
Hi, On Thu, 22 Feb 2018, Ondrej Novy wrote: > 2018-02-22 11:18 GMT+01:00 Drew Parsons : > > The python group on salsa does not have the button for joining the > > group (I don't actually want to join the group, but the commits to > > xhtml2pdf should be pushed). > > I'm sorry, but you need to join the group to push commits into it. I added Drew Parsons to the project directly (i.e. not the group) so that he can push his work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Move to salsa? Team structure preview ready
On Thu, 08 Feb 2018, W. Martin Borgert wrote: > No need to merge the subgroups ever. > With this structure, it is one team already. > > If there nobody objects, we have to: > - migrate the git archives (you volunteered, thanks!) - setup the webhook to close bugs - configure email on pushes to send commit mails to the package tracker - configure IRC notifications (irker?) > - ask for membership in the team (everybody) This is not really needed. In fact I would suggest to de-activate the "request to join" feature. It mails all "masters" (and all DD are masters since they need to be able to create new repositories) and it doesn't offer a way to explain why you need to join the team. Instead one should go through alioth project members and add them directly to salsa. And -guest users should create their accound and ask here to be added (explaining that they were member before already). But IMO alioth project members should be added to the "modules" sub-group and not to the top-level group. Otherwise the "interpreter" subgroup will have way too many members compared to what is desired. > - change Python team documentation (who?) - document how to setup new repositories (with the webhook, tracker integration, etc.) > - make an MR for https://salsa.debian.org/salsa/AliothRewriter (who?) > - ? > Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Move to salsa? Merge modules and apps team?
Hello, On Wed, 07 Feb 2018, W. Martin Borgert wrote: > how about moving the Python team(s) to salsa? Definitely! But we might want to learn from the perl team to structure the python-team: https://lists.debian.org/debian-perl/2018/01/msg00039.html We could then have everything python related in the same team but with different sub-groups for modules, applications and interpreter. > Moving git packages (modules team) is very easy using > import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git I used those scripts with a small loop to migrate pkg-security and it worked fine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: PAPT git migration
Hi, On Thu, 01 Jun 2017, Brian May wrote: > On 2017-06-01 07:32, Barry Warsaw wrote: > > > Let's assume not (which is fine with me; i.e. why adopt git-dpm for PAPT > > when > > we know we just want to get rid of it later?). Then i tried to import a new > > upstream as described here https://wiki.debian.org/Python/GitPackagingPQ > > Another problem I have noticed with that document - but not had time to > come up with a solution yet. > > There are several places where "git push --all" (or variant) is > recommended. But this will also push the gbp pq branch(es), which should > never get pushed. "git push origin : --tags" is what I use in general, it pushes branches available on both sides and tags. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
On Thu, 01 Jun 2017, Ian Campbell wrote: > > https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/commit/?id=ded34be > > There's a typo in there: > > +run tests with “-W errro” when you detect that you are running against the > ^ Fixed, thanks. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: [Python-modules-team] Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t
On Mon, 30 Jan 2017, Brian May wrote: > Help in fixing this RC bug would be appreciated. I have forwarded this > upstream, however need a quick fix for the Debian package (not sure but > suspect it might be too late for stretch). > > Unfortunately, not sure where to start. I don't understand this > date_time_this_century() function that appears to be the cause of it. I have not looked into this but tzdata is no longer (transitively) part of build-essential, is the package installed in the failing build? Maybe try to rebuild with the package explicitely listed in Build-Depends? Regards, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: git-dpm breakage src:faker
On Sun, 29 Jan 2017, Brian May wrote: > 3. Update debian/source/options with "unapply-patches" (anything else?). You don't need that. dpkg-buildpackage unapplies them automatically after the build if it has applied them. If they were already applied before the build, then it leaves them applied. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Binary naming for Django Related Packages
Hi, On Wed, 30 Nov 2016, Scott Kitterman wrote: > Raphael, do you think that the upstream Django project might be willing to > make some kind of best practices for naming third party django packages? If > they did that, then that would give us a basis for Debian maintainers talking > to their upstreams about moving to django_. They already partly do that, see: https://docs.djangoproject.com/en/1.10/intro/reusable-apps/#packaging-your-app They recommend a "django-" prefix in the PyPi package name. But they say nothing about the Python module name and the sample just bundles a "polls" module in a "django-polls" package. Thus I posted this to gather their feedback on the need to recommend the prefix on the name of the module too: https://groups.google.com/forum/#!topic/django-developers/f8yNRkn6Fpo Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Binary naming for Django Related Packages
On Mon, 28 Nov 2016, Scott Kitterman wrote:
> > > Please let me know what you think. I'm open to suggestions on wording.
> > > I'd like to get this done in the next week and do a python-defaults
> > > upload with this and a few minor (non-policy) changes that are pending.
+1 from me. I'm actually the one who started this convention when I
packaged the first Django extension. When I look for available Django
extension, I like to be able to rely on the prefix.
> > [²] sys.path.append('/usr/lib/python3/django-packages/') in
> > django/__init__.py if django import always prepends other imports
> > (python3-django- namespace would be tolerable then, I guess)
>
> I'm not one of the python-django uploaders, so we'd need their feedback on
> [2]. I think something like that is a reasonable compromise if they are
> willing to support it.
I certainly don't want to introduce this Debian-specific difference, no.
Django applications/extensions are meant to be managed via "pip" and they
must be available in the global namespace. I would not be surprised that
some of the extensions actually rely on being available globally...
I don't see any benefit to this change. The global namespace pollution
already exists at the upstream level, while we have to handle potential
conflicts, it's not up to us to preventively curate the namespace when
upstream has not followed the best practice (i.e. the "django_" prefix
in the module name).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Re: Binary naming for Django Related Packages
On Mon, 28 Nov 2016, Piotr Ożarowski wrote: > [Barry Warsaw, 2016-11-28] > > Is there any risk of having confusing names because of a conflict between a > > 3rd party Django module and a Django subpackage? e.g. python3-django-foo > > vs. python3-django.foo. > > > > I'm sure it's a non-issue in practice. > > this is a huge issue IMHO beacause Django submodules use global > namespace and thus any unique django submodule name takes not so unique > Python module name (i.e. they're installed under > /usr/lib/python3/dist-packages/ now, not under > /usr/lib/python3/dist-packages/django) This is true but it's still a non-issue in practice because that kind of conflict is usually detected and thus avoided at the pypi level. And checking for file conflict is part of the job of the packager and we have QA tools doing that kind of work too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: DPMT Membership request
Hello Marcos, On Wed, 23 Nov 2016, Marcos Fouces wrote: > I am still waiting for an answer. I don't know how to proceed in this case. You should have subscribed to debian-python@lists.debian.org and you would have seen that you have to reply to https://lists.debian.org/20161117075743.i7exf7vmpbi4a...@sar0.p1otr.com That's the blocker right now. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
On Wed, 10 Aug 2016, Nikolaus Rath wrote: > I don't believe that switching from git-dpm to git-buildpackage is going > to make things easier, it'll just be trading one set of problems for > another. I don't agree on this. I have been a happy git-buildpackage user for all my packages. The problem with git-dpm is that the patch series can't be easily fixed after a merge when it generates conflicts. It's too intricately tied to git-dpm's own fake merge logic with commit it recorded in debian/.git-dpm and it's very painful to bring the repository in a state where git-dpm is happy. With git-buildpackage, the merge and the update of the patch series are distinct operations that can be done at different times. Since patches are unapplied, the merge usually works fine and the patch series can be easily rebased afterwards with your tool of choice. Anyway, +1 from me to switch to git-buildpackage and in fact among the python-django maintainers we are close to decide to switch back to git-buildpackage because it's really horrible to use when you want to merge across branches of different releases. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: django-pipeline / slimit
On Wed, 23 Mar 2016, Brian May wrote: > Looks like slimit doesn't support Python3 and hasn't had an upstream > release since 2013-03-26. > > Any suggestions where to go from here? > > Maybe hack pipeline to disable the failing test? I think pipeline can be > configured to use jsmin instead of slimit and jsmin is packaged in > python2 and python3 versions. Yeah, skip the test on Python 3, tell upstream that slimit is not supported on Python 3 and that the test should be skipped there. Make sure that slimit is not the default. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: django-pipeline / slimit
On Wed, 23 Mar 2016, Brian May wrote: > I: pybuild base:184: PYTHONPATH=. python3.5 /usr/bin/django-admin test > --settings=tests.settings ^ > File "/«PKGBUILDDIR»/pipeline/compressors/slimit.py", line 12, in > compress_js > from slimit import minify > ImportError: No module named 'slimit' [...] > Does this mean we need to change the slimit package into python-slimit > and python3-slimit packages? Looks like so, indeed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Bug#812117: RM: simpletal -- RoQA; unmaintained; low popcon
On Wed, 20 Jan 2016, Mattia Rizzolo wrote: > loggerhead: loggerhead And that rdep is relatively important since AFAIK we use loggerhead at least on alioth to browse bzr repositories. Maybe it's best to invest a bit of time into updating it rather than dropping it just for the sake of its low popcon? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: How to maintain multiple branches (sid/bpo/exp etc)?
Hi Sandro, On Mon, 02 Nov 2015, Sandro Tosi wrote: > hello, > with the new DPMT repo layout and tools, what is the right way to > maintain multiple active branches for our packages? things like: > > 1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2 > 2. unstable at v1, experimental at v2 > > all of them active, so in the 2. case there should be a way to keep > updating v1 and v2 releases (and so unstable and exp) as the come. Have a look at what we did for python-django and check out its README.source to learn how to configure git-dpm to match the various upstream branches and the corresponding Debian packaging branches. I experienced yesterday how to merge a branch into another branch (merging experimental with 1.8 into unstable that had 1.7) and the least I can say is that it was not flawless... I already reported the issue here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667 So I did a plain "git merge" and did the following to clean up: - resolved all conflicts by picking the merged side (including debian/.git-dpm) - ran git-dpm status and reverted changes that did not conflict during the merge but that were not part of the upstream changes (they are probably left-over from debian patches since those are now applied in the packaging branch) - manually cleaned up debian/patches Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: dh-python (pybuild + dh_py*) documentation
Hi Piotr, On Mon, 26 Oct 2015, Piotr Ożarowski wrote: > How can I improve it? Do you need more detailed description of options? > Do you need more examples? Or maybe I should hide most of options, the > "corner case" ones? I focus on making things work out of the box, if > possible, and make it very customizable so that weird corner cases are > possible as well - this means there are a lot of options, is this the > problem? > > Can you be more specific about what's missing? I for one lack a high level presentation of how the various bits work together and a clear description of the "magic" behind each tool. For instance, dh_python2 explains that it tries to translate Python dependencies into Debian dependencies but it's not clear that it needs the corresponding packages installed (so it's not clear that for this to work you have to add something to Build-Depends). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Wed, 21 Oct 2015, Sandro Tosi wrote: > On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote: > > Maybe we should fix #801666 first and then revisit this question? > > git-dpm hasnt seen a single line changed since more than a year > (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold > my breath on it :( Yeah :( That makes another point that was missed in the evaluation of git-dpm vs git-buildpackage and its "gpb pq" command. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Tue, 20 Oct 2015, Brian May wrote: > Barry Warsaw writes: > > > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt > > *as long as the final state of the repo is compatible with git-dpm*. > > Meaning, > > in general, you can make whatever local decisions you want as long as they > > don't force other team members to go outside of team recommendations. > > I don't see how you could use quilt and maintain compatability with > git-dpm. git-dpm expects all patches to be in git, and will update > debian/patches automatically from git. quilt writes patches directly in > debian/patches/* and doesn't support git. > > Not something that concerns me personally, quilt was starting to become > very painful for me. I regularly ended up forgetting the "quilt add" > operation before editing files, resulting in invalid patches. And also for import of upstream tarballs you basically have to use git-dpm as git-dpm keeps state data in debian/.git-dpm whereas git-buildpackage does not have similar state data (except the generic git data like availability of a upstream/ tag, and so on). I really regret to not have invested time earlier to try out git-dpm... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Django 1.8 in unstable in early November
Hello, I just filed 20 bugs on packages that FTBFS with Django 1.8. They have two weeks to be fixed before we upload Django 1.8 to unstable. https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django18 If you maintain a package in the Django ecosystem, please double check that it's ready for Django 1.8. The fact that it doesn't fail to build does not mean that it will necessarily work if you don't have any tests or if you don't run them. If you file more bugs related to Django 1.8, don't hesitate to add the "django18" usertag associated to the "python-dja...@packages.debian.org" user. (I wish we could easily rerun the DEP-8 functional tests with a new version of the package) Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
On Sun, 11 Oct 2015, Brian May wrote: > Just noticed how it named the upstream branches. > > * [new branch] upstream-debian/experimental -> upstream-debian/experimental > * [new branch] upstream-debian/jessie -> upstream-debian/jessie > * [new branch] upstream-debian/sid -> upstream-debian/sid > > Not sure this is ideal :-( I added debian/README.source documenting how to avoid this and keep using the upstream branches based on upstream versions. And I filed #801666 (git-dpm: Need a way to set the upstream branch names from within the repository). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
On Sun, 11 Oct 2015, Brian May wrote: > Just noticed how it named the upstream branches. > > * [new branch] upstream-debian/experimental -> upstream-debian/experimental > * [new branch] upstream-debian/jessie -> upstream-debian/jessie > * [new branch] upstream-debian/sid -> upstream-debian/sid > > Not sure this is ideal :-( This definetely sucks, I want to continue to use upstream/1.7.x, upstream/1.8.x and so on. We want to be able to maintain multiple upstream branches in parallel, no matter where they are uploaded. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
Hi, On Sat, 10 Oct 2015, Barry Warsaw wrote: > >And I would suggest that we generalize the DEP-14 naming scheme as part of > >our git packaging policy... > > I'm all for standardization, but I do like the shorter names for the common > case where you only need the unstable version. Certainly if there are vendor > or series differences, the namespaces make a lot of sense. But most of my > packages don't need it. This is something that you don't know... a derivative can always want to fork for whatever reason (the most common one being that we lag behind upstream). And another reason for the namespace is to not collide with the upstream namespace. And this one is almost always there (given most upstream use git nowadays). > Would you be open to allowing such simplification in the common case in > DEP-14? Given the above, I believe that having just debian/master is better than encouraging the use of "master". I think the DEP reached a good compromise already. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Git migration schedule
On Sun, 11 Oct 2015, Brian May wrote: > What branches do I need to put the debian/README.source file in? There are > six debian/* branches, don't think it is a good idea to try and maintain a > consistent debian/README.source in all branches. > > Maybe debian/experimental would be sufficient? Or perhaps > debian/experimental + debian/sid? > > In fact, putting in a branch seems wrong, it isn't specific to any one > branch, not sure where a better place would be though. IMO, you should just indicate that the repository follows DEP-14 and not be specific about the branch names. That way you don't have any problem. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: python-django
Hi, On Fri, 09 Oct 2015, Brian May wrote: > We can move the migrated version out of the way, restore the old version, > and update it to the required standards (e.g. git-dpm). Is everyone happy > with this approach? Yes, except for the naming of branches where I would prefer to keep the DEP-14 naming scheme (we should just rename debian/sid into debian/master). http://dep.debian.net/deps/dep14/ And I would suggest that we generalize the DEP-14 naming scheme as part of our git packaging policy... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: [DPMT] radical changes: automation, carrot and stick
On Wed, 07 Oct 2015, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? While I understand the desire to have one identified maintainer for each package, I don't agree with the rule. Changing maintainer means changing the flow of information and it is a pain. When I get interested in a package, I subscribe to the package in the tracker. At some point, I end up the "maintainer" because the former maintainer left and here I should put myself in maintainer... that would mean getting duplicate mails and me having to fix my subscriptions or add procmail rules to avoid this. So I don't think that this rule gives us more benefits than annoyances. If you want to identify someone as in charge, let's define that the first person in the Uploaders field is that person. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#781165: RFP: prospector -- Python code analysis tool
Package: wnpp Severity: wishlist * Package name: prospector Version : 0.9.9 Upstream Author : Carl Crowder * URL : https://github.com/landscapeio/prospector * License : GPL-2+ Programming Lang: Python Description : Python code analysis tool Prospector is a tool to analyse Python code and output information about errors, potential problems, convention violations and complexity. It brings together the functionality of other Python analysis tools such as pylint, pep8 and McCabe complexity. More information and a complete list of supported tools is available on the documentation site. The primary aim of Prospector is to be useful 'out of the box'. A common complaint of other Python analysis tools is that it takes a long time to filter through which errors are relevant or interesting to your own coding style. Prospector provides some default profiles, which hopefully will provide a good starting point and will be useful straight away, and adapts the output depending on the libraries your project uses. It would be nice to have this available to help check one's own Python code. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20150325142746.ga17...@home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
Hi, On Fri, 10 Oct 2014, Charles Plessy wrote: > Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit : > > > > Where is the repository of the scripts involved? Maybe I have > > some spare time this weekend... I hope, it's all sh or Python. > > I forgot all my Perl. > > Hi Martin, > > good news, it is in Python :) > > https://github.com/mhagger/git-multimail/ But the IRC notifier is "kgb-client" (packaged in Debian) and this is Perl. I just filed a wishlist bug about this: #764713 Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141010131715.gh29...@x230-buxy.home.ouaza.com
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
On Fri, 10 Oct 2014, W. Martin Borgert wrote: > On 2014-10-10 15:59, Ben Finney wrote: > > Agreed. This is a direct result of rebasing Debian packaging history > > onto upstream VCS history, and keeping them all in the same repo as one > > undifferentiated history, no? > > Not sure, but isn't this more a result of the scripts in use, to > not differentiate paths? > > I assume, that the script uses post-receive, so it has access to > all commits, including all affected paths. If so, generating only > emails or IRC messages when debian/ is involved should be easy. Yes, are you volunteering to implement it? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141010081324.gb15...@x230-buxy.home.ouaza.com
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
On Thu, 09 Oct 2014, W. Martin Borgert wrote: > On 2014-10-09 10:02, Raphael Hertzog wrote: > > I fixed the default configuration in setup-repository to limit to 20 > > commits per push as a maximum. And I also limited the size of individual > > commit emails to 1000 lines. > > I wonder, whether some kind of digest function would be possible > and useful? There is already a single mail per push that summarizes all the commits and the individual commits are sent as replies to that initial mails (provided that the number of commit doesn't exceed 20, otherwise you only get the summary mail). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141009093602.gg3...@x230-buxy.home.ouaza.com
Re: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
On Thu, 09 Oct 2014, Sandro Tosi wrote: > so is there any chance you stop this commit storm madness anytime > soon? another bunch of >300 commit messages arrive this night I fixed the default configuration in setup-repository to limit to 20 commits per push as a maximum. And I also limited the size of individual commit emails to 1000 lines. I updated the configuration of the already existing repositories. hertzog@moszumanska:/git/python-modules/packages$ for i in *.git; do cd $i; git config multimailhook.maxCommitEmails 20; git config multimailhook.emailMaxLines 1000; cd -; done Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20141009080251.gf3...@x230-buxy.home.ouaza.com
Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
Hi, On Wed, 24 Sep 2014, Julian Taylor wrote: > > Nah. It's a great reason to teach the tool in question to be *way* more > > reasonable. Who needs a single email per commit? Esp. since the number of > > actual commits will go way up with increased git usage – feature branches > > are easy in git, and more granular commits are a great way to help with > > tracking down exactly which change introduced a regression. > > Single mails/irc messages per commmit are very useful, they help a lot > to find mistakes others are making before an upload happens. > > What we don't want is messages for upstream changes. This should be > simple to fix, simply check the changed paths for debian/ before sending > a message. The default script in use on Alioth is based on git-multimail: https://github.com/mhagger/git-multimail It doesn't have such a path-based filtering. But it's Python \o/ So it would be nice it you could contribute such a feature upstream. :-) That said using maxCommitEmail is still a good safeguard. There's also the possibility of only using refchangeList (instead of mailinList) so that we only send out the summary mail of what has been pushed. The caveat being that we don't get diff of the changes wich is what makes those email notifications interesting. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140924073229.gb5...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi, On Tue, 16 Sep 2014, Brian May wrote: > On 11 September 2014 16:39, Brian May > wrote: > > > Ok, will look into this tomorrow. > Just pushed a change. > > Unfortunately, had problems testing this because "debian/rules clean" > removes Django.egg-info/* which is flagged by git-buildpackage as > uncommitted changes. Recent versions of git-buildpackage should no longer call debian/rules clean IIRC. But you can disable this with: [DEFAULT] cleaner = /bin/true in ~/.gbp.conf Alternatively you can build with "--git-ignore-new" too. > Also django-migrate-south won't work without virtualenv installed. Was > wondering if maybe I should add it to recommends (wheezy needs > "python-virtualenv"; sid needs "virtualenv" installed). I'm not sure that adding such a script in /usr/bin/ is a good idea. It doesn't have a manpage, it's a temporary hack, etc. I would put the script in the doc directory and I would document to run it as: sh /usr/share/doc/python-django/migrate-south --settings app.settings Then it's more logical to not change the dependencies and just document (as you did) the need to install virtualenv. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140916065130.ga23...@x230-buxy.home.ouaza.com
Re: django 1.7 bugs
Hi, On Fri, 12 Sep 2014, Zygmunt Krynicki wrote: > I wrote large parts of lava-server and both of the django- packages > here but I'm not an active upstream anymore (I cannot commit to those > repositories, only Linaro folks can) . If anyone wants my help though > I'd gladly render assistance. I already provided some patches to fix unit test failures but upstream is concentrated on other stuff in the short term so Neil might appreciate your help to review the patches and do some higher level testing with Django 1.7. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140914130225.gd20...@x230-buxy.home.ouaza.com
Re: django 1.7 bugs
Hi, On Sat, 13 Sep 2014, Thomas Goirand wrote: > I think we should all focus first on the Python Team modules, and see > where that leads us. Also, to me, considering the amount of remaining > bugs without a single reply, it's too early to upload Django 1.7 to Sid. > Raphael, do you still plan to upload next week? Yes. I prefer to do it now, thus raising the bugs to higher severities soon since that's the only thing that will attract the attention of the remaining maintainers and of all people who help squash RC bugs. Also if some packages get removed due to RC bugs, it's better when it happens soon so that reverse-dep get notified earlier and have a chance to reintroduce the package if needed, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140914125838.gc20...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi Brian, thanks for those investigations! On Thu, 11 Sep 2014, Brian May wrote: > Note that I have explicitly called python. This ensures Python 3 not used > (not supported by South + the virtualenv is Python 2 only) and that we get > the python from the virtualenv. > > I have tested this and it appears to work, although the above was changed > not to be specific to my app. Please document this in python-django's README.Debian and mention where to find this sample in the current debian/python-django.NEWS entry. TIA. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140911062808.gb9...@x230-buxy.home.ouaza.com
Re: django 1.7 change for backport to wheezy
Hi, On Tue, 09 Sep 2014, Brian May wrote: > Can I please get the following change in python-django git? > > Add the following to debian/control: > > X-Python-Version: >= 2.7 > > This will make backports to stable a lot easier. Otherwise the package > builds fine, but won't install in Python 2.6 is installed. > > I would do it myself, but not 100% confident of the branches - I guess I > should use the debian/experimental branch? Yes, please commit that on the debian/experimental branch. (Sorry that I lost this in the git conversion.) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140909063146.ga31...@x230-buxy.home.ouaza.com
Re: Recommendation: adopt git-dpm
On Thu, 04 Sep 2014, Barry Warsaw wrote: > Even with those complaints, git-dpm feels like the better tool for team > package management in git. The problems are minor and probably easily > fixable. >From my point of view, since you're anyway using features of git-buildpackage, it would be better to improve git-buildpackage... I like how git-dpm can keep patches applied on the packaging branch and porting the required shell to "gbp pq" should not be too complicated. It would also be nice if we could fix "gbp pq" to not rename quilt patches. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140904223231.gb7...@x230-buxy.home.ouaza.com
Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)
On Thu, 04 Sep 2014, Barry Warsaw wrote: > On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote: > > >Actually, nevermind. That's not the problem you were trying to solve, > >although you could remove the patch as described and then apply the updated > >patch at the end of the series. > > Yeah, though sometimes for legitimate reasons you can't reorder patches. It > vaguely feels like with git-dpm since the patch branch is never pushed, you > could "uncommit" (`git reset --hard HEAD^`) and stash each commit until you > got to the one you wanted to amend, then unstash and recommit back up the > stack. E.g. just like quilt push/pop. As others have mentionned, you should use "git rebase -i ". This is what you want to use on your patch-queue branch to modifiy individual commits, reorder them, or drop them. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140904222559.ga7...@x230-buxy.home.ouaza.com
Re: A few git-bp nits
Hi, On Thu, 28 Aug 2014, Barry Warsaw wrote: > * There are anomalies when pushing and pulling branches created with g-i-d. >I get the following errors when I do the initial push: > > remote: fatal: Invalid revision range > ..e14331dcbaf3f097267ca1a7a2ee6a7fd734 > > remote: fatal: Invalid revision range > ..a9bb83a461be57ebcd09fa7b5a57597a866dfb52 > > remote: fatal: Invalid revision range > ..48ba72c1bb849788fbe6ae0c20d9e28093039cd9 > > remote: fatal: Invalid revision range > ..1a90ad5e79b2a5298d42a38308019e281bfc95c5 > > >I have no idea what's causing these or what horrible deformity it's leaving >the state of the repo in. Those are harmless, it's probably /usr/local/bin/git-post-receive-tag-pending that is generating those for the initial push (where there is no old commit). >It does *something* bad because subsequently cloning the repo afresh, >I get this error: > >warning: remote HEAD refers to nonexistent ref, unable to checkout. This is unrelated. I modified /git/python-modules/setup-repository to call “git symbolic-ref HEAD refs/heads/debian/sid” so that the default branch is debian/sid. So unless your repositoriy contains a debian/sid branch, you will get this warning. Still your clone is fine, you can do "git checkout master" and you will have a proper checkout. You can can call the above command with another branch as parameter if you want to reset the default branch to something else. You can also re-modify the script if everybody prefers to experiment with "master" as the default branch. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140829193155.gd6...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
On Wed, 27 Aug 2014, Sandro Tosi wrote: > like true contributors are those using svn right now. and what about > the majority of contributors now? we should change just because maybe, > eventually, if we're lucky we'll attract more contributors? saying "I > won't contribute to your team if you don't move to Git" is IMHO > arrogance and against team work (but we know. I'm different :) ) Please don't try to split contributors in two camps. I do continue to use svn-buildpackage for the few django extensions that I maintain in python-modules. And even if I moved python-django to git, I'm still a team contributor even if I touch only a small subset of packages. > > Because your packaging decisions are not influenced by upstream changes? > > i don't follow? is that an advantage of having the upstream source > code in the Debian packaging repository? Yes, I regularly use "git log" on upstream metadata files to see whether we missed some new (optional) dependencies and stuff like that. > > Not everybody is using git but I think that you should face it, most > > of the upstreams projects do. > > i dont think so. It might be true for the big projects, but look at > the vast majority of the packages in DMPT/PAPT, they are small > modules/apps how many of them are using git? I wont say "most" more > "few" of them. No point in arguing here (I don't have time to do a proper analysis and come up with figures). That said in my experience, most new stuff I tend to package are actually maintained in github or a similar service. The fact that we are grabbing .tar.gz on pypi means that we might also not be directly aware that the tarball is generated out of a git repository. > > It's 200% more easy to manage multiple branches and merge them properly. > > Most of the average python modules will not need multiple branches but for > > things like python-django, we do need multiple branches... and the fact > > that svn is such a pain means that the security updates were not managed > > in svn for example... > > branches exist in svn too (I admin they are harderd than git tho) and > security updates always evolve in 2 separate ways than current > development (in fact, I think you're referring to update in stable, so > you'll have a branch for stable and trunk, which likely are at 2 > different versions, evolving indipendently. I did that for matplotlib, > and it's doable) I said "200% more easy", I know that they are doable, but it's just painful... > > All those are real problems for real people doing packaging work. > > you skipped the part of what are the problems the teams is facing with > svn we want to solve with git, while it seems you're talking about > your experience with Django alone, which is important of course but > not necessarily representative of a huge amount of packages in our > teams. And? If we want a single VCS then we must cater to the most demanding use cases. Obviously svn-buildpackage is just fine for small packages with a single branch and no patches... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140827091911.ge23...@x230-buxy.home.ouaza.com
Re: DebConf14 svn->git migration BOF notes
On Wed, 27 Aug 2014, Stuart Prescott wrote: > > I've done some personal investigation since the BOF, and am preparing > > some really simple migration scripts, so we can get a feel for what it > > will look like. My scripts so far (very very simple) > > git://git.debian.org/users/stefanor/dpmt-migration.git > > is there any reason to use a loop around git-import-dsc rather than git- > import-dscs --debsnap here? I haven't looked at stefano's script but git-import-dscs will import all source packages in a single linear history (importing the packages by increasing version) and that isn't representative of the true history. For python-django, I imported all the "normal" versions in the debian/sid branch but manually imported the "+deb7uX" in a debian/wheezy branch, the "+squeezeX" in a debian/squeeze branch, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140827085224.gd23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
Hi Sandro, On Wed, 27 Aug 2014, Sandro Tosi wrote: > It seems to me like very vocal Git fanatics, who refuse to touch any > package which is not maintained in Git (-.-), are pushing and pushing > to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. > Upstream releases history? why do we need to care, we are packagers we > should care about packaging commits history. Because your packaging decisions are not influenced by upstream changes? > from the VCS again? seems kinda twisted to me :) And no, not the whole > programming world is using Git for upstream code (sometimes we're not > even able to teach upstream to use proper versions), so the usual > mantra "I can pull from upstream repo and be happy ever after" is > kinda weak. Not everybody is using git but I think that you should face it, most of the upstreams projects do. > is there anything else so "attractive" about git? It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... And handling security updates in svn is a pain because you can't commit localy and push only when the security update is disclosed publicly. etc. All those are real problems for real people doing packaging work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140827084040.gc23...@x230-buxy.home.ouaza.com
Re: Playing with git-buildpackage
On Fri, 22 Aug 2014, Barry Warsaw wrote: > >Why would you push your temporary branch? > > Only because `git push --all` seems like the obvious choice. But I think > git's cli is akin to quantum mechanics, i.e. don't trust your intuition. :) Ideal is when a "git push" alone is enough, you can do "git config push.default matching" to make it push all the branches that exist on both sides. That used to be the default but it's counter-intuitive... I agree it's a pity that there's no "git push --matching" option instead of the non-explicit "git push origin :". > >It would be nice if the admins could whitelist all mails containing > >an "X-Git-Repo" header. > > In Mailman, that's easy. > > >Or at least whitelist all *@users.alioth.debian.org emails as those are in > >the From of those emails. (I just changed a setting so that it uses this > >domain now) > > In Mailman, that's easy. > > >Alternatively you can subscribe to the list with your > >@users.alioth.debian.org mail and disable mail delivery for that > >address. > > In Mailman, that's easy. > > Anybody know the maintainer of the mailing list? http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-commits => stra...@users.alioth.debian.org aka Gustavo Franco I'm not sure if Gustavo is still active or if someone else has the admin password... Gustavo? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140823071521.ga31...@x230-buxy.home.ouaza.com
Re: Playing with git-buildpackage
Hi,
On Thu, 21 Aug 2014, Barry Warsaw wrote:
> Then I `git init`'d a new local repository and used `gbp import-dsc` to
> initialize the git information. That seemed to work just fine.
FWIW, I usually setup the repository on git.debian.org first and then I
clone that empty repository. With this process, the git repository already
has the "origin" remote already setup.
> Now I wanted to update the package to 2.0.1, so I used `git-import-orig
> --uscan` which works great, except that it doesn't add a debian/changelog
> entry. That would be a nice convenience I think.
gbp's developer is relatively active, feel free to file wishlist bug
reports for that kind of things.
> `gbp pq` is the tool to manage the patch branch, but there were a few things
> that seemed messier than with the git-dpm experiment:
>
> * I used `gbp pq switch` to get to the patch-queue/master branch. Unlike with
> git-dpm, this does *not* delete the debian/ directory. It did make things
> smoother with Emacs because upon switching back (later) to master, I didn't
> have to revert the files I was visiting. But I realized that it did leave
> me in a somewhat confusing state. Should I use quilt? The patches were not
> automatically applied by `gbp pq switch`. Maybe I should have imported
> them.
"gbp pq import" is the right command indeed, it will create the branch with
everything required and switch to it.
> It makes me think that git-dpm's handling of debian/ is probably closer to
> right, so that there'll be no temptation to muck about with quilt while in the
> patches branch. Maybe a better approach would be to delete just
> debian/patches - that would remove my confusion but wouldn't force me to
> revert all the debian/ files I was editing.
When you analyzed git-dpm, the lack of debian was a negative point, so it
would be weird to want to remove it here.
What you possibly need is an enhanced shell prompt displaying the name of
the current branch, it's relatively easy to do by embedding $(__git_ps1
2>/dev/null) somewhere in your $PS1. That way you immediately see that you
are on the patch-queue branch...
> I was disappointed with the documentation surrounding the `gbp pq` workflow.
> It's not really described in the git-buildpackage manpage and the best
> documentation for `gbp pq` is off-site and external to debian.org.
man gbp-pq ?
It effectively points to the website of the author, but that doesn't sound
like a problem. It's possibly because the software is quite well
documented on https://honk.sigxcpu.org/piki/projects/git-buildpackage/
that there's no wiki page or anything like that explains everything.
> The other disappointing thing is that once I was back on the master branch,
> the patch-queue/master branch was not deleted. That's a nice little cleanup
> that git-dpm handles for you. After all, who wants that temporary patch
> branch on git.d.o?
Why would you push your temporary branch?
I know this can happen if you do "git push --all" but that command is
not a good idea in general... you can do "git push origin :" to push all
the branches that are pre-existing on the remote side.
Keeping the branch makes it easier to rebase it in the future and then
re-export the patches.
> git-buildpackage has --git-ignore-new but that's actually not enough! Because
> of the vagaries of git, you have an extra "level" of changes, i.e. the index.
> This means that if you want to include uncommitted changes in the package, you
> need to also use --git-export. There are two options here: --git-export=INDEX
> obviously includes the staged changes while --git-export=WC includes the
> working copy. =WC seems much more aligned with my own personal preferences,
> and is closer to what svn-bp does by default.
Note that this is only required because you actually use
--git-export-dir=../build-area/. When you don't do that you build out of
the working copy and --git-ignore-new is then enough.
> Once I uploaded the package, I had trouble with git-bp --git-tag-only
> recognizing my gpg keys. I didn't investigate further, but just used
> --git-no-sign-tags for now.
I never had any problem with signing the tags. Does your git identity
matches your identity on the GPG key?
> After this experiment, my own personal preference is leaning toward git-dpm.
> It just seems like a cleaner, more self-contained, and better documented
> workflow. I think there's room for improvement, but git-dpm is "just" a fancy
> shell script so I hope it's maintainer will be open to patches and
> suggestions.
gbp is Python and the author is also open to patches and suggestions :-)
> In truth though, I bet it won't be hard to convert from one to the other. The
> biggest difference that I can tell is that if you use the default branch
> names, it's mostly just the tag names that differ:
>
> git-dpm: {debian,patched,upstream)-
> git-bp: {debian/upstream}/
In python-django, I just switched to debian/ +
upstream/ following early result
Re: Playing with git-dpm
On Wed, 20 Aug 2014, Barry Warsaw wrote: > So, because of the way I've named the branches, the full invocation is: > > $ git-buildpackage -S --git-export-dir=../build-area/ > --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest So --git-export-dir is usally best set in ~/.gbp.conf: $ cat ~/.gbp.conf [DEFAULT] pristine-tar = True cleaner = /bin/true [git-buildpackage] sign-tags = True export-dir = ../build-area/ For the other two options, the recommended practice is to put them in debian/gbp.conf but I generally don't do that and just use standard branch names (master / upstream). > Thanks for both the recommendation and the fix! Once the team decides on a > workflow, will it be feasible to write the equivalent of svn-inject? Since > shell access to g.d.o is required it seems like this won't be completely > self-services, but teammates who are DDs could do it for other folks. git-import-dsc is your svn-inject, it will put upstream sources in the upstream branch and will create the master branch based on that with the packaging changes. But the quilt patches won't be applied after this operation. I managed to start using git-dpm on a pre-existing repository but it required an initial "git-dpm init .../mypkg_1.orig.tar.gz" IIRC. Note that all members of the team automatically have shell access to git.debian.org (it's just alioth itself). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140820201709.gc2...@x230-buxy.home.ouaza.com
Re: Playing with git-dpm
Hi Barry, On Tue, 19 Aug 2014, Barry Warsaw wrote: > * The egg-info directory is a PITA. > > The upstream tarball has a lazr.smtptest.egg-info directory. debuild -S blows > this away, and then git thinks I want to delete it. It doesn't get staged, so > it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying > *very* quickly after just a few debuilds. I'm not sure what the best way to > handle this is, if there is one. You can commit the removal, but it will regularly cause merge conflicts. Or you can build the package in another directory, like svn-buildpackage does. I'm not sure if git-dpm has something for this but you can probably use "git-buildpackage --git-export-dir=../build-area/" in combination with git-dpm. > * debian/patches/* get named automatically > > `git-dpm checkout-patched` creates a temporary patch branch. I had to patch > the setup.py, so I just edited it as normal. Note though that you *must* > commit this file while on the patch branch or it doesn't get quilt-ified, but > it will still show up as modified on your packaging branch if you switch to > it. Oh, and the first line of your commit message gets turned into patch > name. I like that it handles quilt-ifying the patch automatically when you > `git-dpm update-patches` but watch out with your commit messages or you may be > left with a patch file that has an odd name. I didn't try to change that and > see if git-dpm could still grok the patch. I believe that git-dpm can handle any quilt series as input but it will always rename it based on the commit after a "checkout-patched". > * Where to push the repo? > > I'm not sure that we have a definitive path on git.debian.org for team > maintained packages under git, but there is a python-modules directory > containing a few packages. So I pushed my branches to > git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git > > It takes a bit of work to create this directory initially, but I found that > gbp has a nice command you can corrupt into doing the right thing for > you, e.g.: Please do something like this to create new git repositories for python-modules: $ ssh git.debian.org $ cd /git/python-modules $ ./setup-repository lazr.smtptest "lazr.smtptest packaging" $ exit It will setup some default hooks to to forward the commit notices where appropriate. (I just did the required configuration for you.) > Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have > no idea why. It's there now. The repository listing is not updated in real time (too much I/O involved). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140820192111.gb2...@x230-buxy.home.ouaza.com
Re: guardian and django1.7
Hi, On Tue, 19 Aug 2014, Brian May wrote: > > For example, I renamed migrations to south_migrations and created a > > Django1.7 compliant migrations directory, however still get the same error. Did you fill that new directory with an initial migration generated with ./manage.py makemigrations? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140819080439.ga1...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
On Wed, 13 Aug 2014, Piotr Ożarowski wrote: > [Raphael Hertzog, 2014-08-13] > > > * old patch needs an update, what should I do? > > > (quilt edit? quilt refresh? XYZ rebase on a different branch?) > > > * new patch is needed, how can I add it? > > > (quilt new? another branch?) > > > > I don't see the need for the team to impose anything here. patches are > > stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq". > > that's the problem. I'm lazy and I rather stop helping / sponsoring than > learn 650 ways to add a patch. You don't have to learn multiple ways to add a patch. You pick your preferred tool and you use it. Others use their preferred tool and everybody is happy since the exchange format (quilt series stored in debian/patches) is well defined. git-dpm and gbp-pq uses local branches that don't get pushed to update the patch series but the result is a simple update of debian/patches in whatever branch we store the Debian packaging. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140814154758.ga2...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
So let me give my own answer to some of the questions asked here. On Wed, 06 Aug 2014, Dimitri John Ledkov wrote: > However, it does not integrate with git-dpm at the moment and there is > no clear conversion / vcs history import available. Do we care about > preserving vcs history for our packages? Do we want synthetic history > (e.g. per upload granularity)? I believe it's useful to have some history, at least on a per-upload basis (and it's relatively easy to do do with git-import-dscs + debsnap). On Wed, 06 Aug 2014, Piotr Ożarowski wrote: > If one wants us to consider XYZ, please send a link to test repo and a > list of commands that will let us deal f.e. with such problems: Feel free to use "debcheckout python-django" as a test bed (just don't "git push" your tests). > * how can I fetch foo sources? what about updating all packages in one > command? > (XYZ pull? mr update?) "git clone" For the multiple repositories, yes it's "mr" that most teams use. > * how can I build it? > (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?) I do use "git-buildpackage" but it's really not a requirement. debbuild should be usable on a git clone. > * old patch needs an update, what should I do? > (quilt edit? quilt refresh? XYZ rebase on a different branch?) > * new patch is needed, how can I add it? > (quilt new? another branch?) I don't see the need for the team to impose anything here. patches are stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq". > * there's new upstream release, how can I import it? > (uscan in source pkg's root dir?) git-import-orig --pristine-tar --uscan > * how can I share my changes? > (XYZ push?) git push origin : git push origin --tags On Sat, 09 Aug 2014, Brian May wrote: > At the moment, in subversion, we only store the debian/* directory. Is > there any requirement/benefit in putting the full upstream source in git > too? Not putting the upstream sources would be non-sense. We want to be able to use the git tools to maintain the quilt series and for this we need the sources in git. It also makes it possible to use standard tools like debuild instead of needing some pre-build setup logic to extract the upstream sources and inject the debian directory. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140813190835.ga18...@x230-buxy.home.ouaza.com
Django 1.7 preparations
Hi, I rebuilt all reverse deps of python-django and I tagged confirmed all the associated bugs where the package failed to build with python-django 1.7 and I sent the relevant extract of the build log... It makes a total of 31 bugs that will need some attention: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 And 42 more that need manual evaluation of the situation. There's a good proportion of failures that look trivial (missing django.setup() call) but there might be more problems once this one is fixed... As usual your help is welcome. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140807214803.gb11...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
On Thu, 07 Aug 2014, Brian May wrote: > On 23 July 2014 15:58, Brian May wrote: > > > You are expected to do all database migrations with Django 1.6, then > > upgrade to Django 1.7 > > > > Some more thoughts. > > Are there any packages in Debian that attempt to automatically do database > migrations on upgrade? I don't think so. The few packages with south migrations were not concerned in the wheezy->jessie upgrade. > virtualenv --system-site-packages ~/old_django > . ~/old_django/bin/activate > pip install django==1.6.5 > pip install django-south > django-admin --settings=??? migrate --all > touch /etc/xyz/south_migrations_complete > deactivate > rm -rf ~/old_django > > Don't particularly like using --system-site-packages, think it will be > required to find the application however. Hopefully it will still get the > correct version of Django in this case. Can you test something like this? I would like to document something like this in NEWS.Debian of python-django so that admins are not left in the cold for their own django apps. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140807214213.ga11...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
Hi Matthew, On Wed, 06 Aug 2014, Matthew Vernon wrote: > Is 1.7 released yet? At least Grappelli only aims to work with released > versions, so I think it's currently only 1.6-compatible. I'd expect > 1.7-support to be along once that's been out for a bit. 1.7 will be out in a few days/weeks and we aim to include it in Debian Jessie. We have opened bugs against all reverse dependencies asking them to validate their package with Django 1.7rc2 in experimental. See https://lists.debian.org/debian-python/2014/07/msg00085.html So please ensure they work with Django 1.7 before upload, or file a bug yourself and user tag them so that they appear in: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 Thank you! -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140806192529.gb13...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
Hi, On Tue, 05 Aug 2014, Matthew Vernon wrote: > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git [...] > Naturally, I'd like to upload these as maintained by > python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If > so, I'll make some ITPs, and initial uploads. I would feel uncomfortable having the name of the team on it while the package is not on a repository writable by all members. (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) Looking on git.debian.org, it looks like that some people started using git for team maintained packages: $ ls -al /git/python-modules/packages/ total 48 drwxrwsr-x+ 6 bzed scm_python-modules 4096 juil. 22 09:26 . drwxrws---+ 5 root scm_python-modules 4096 janv. 30 2014 .. drwxrwsr-x+ 7 obergix scm_python-modules 4096 nov. 29 2013 django-ldapdb.git drwxrwsr-x+ 7 azatoth-guest scm_python-modules 4096 mars 18 2013 plastex.git drwxrwsr-x+ 7 zigo scm_python-modules 4096 mai 16 2013 python3-pyparsing.git lrwxrwxrwx 1 aelmahmoudy-guest scm_python-modules 36 juil. 22 09:26 python-whoosh.git -> ../../collab-maint/python-whoosh.git drwxrwsr-x+ 7 dkg scm_python-modules 4096 mars 18 2013 python-xlrd.git So please move your git repository there. /me notes to switch python-django to git. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140806064730.ga13...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi, On Mon, 04 Aug 2014, Thomas Goirand wrote: > and already found out that TEMPLATE_DIRS needed an additional comma in > settings.py, though there's still a lot more failure in the unit tests. > If you want to help, just try to rebuild Horizon (and add a comma as I > wrote in horizon/tests/settings.py to begin with...). > > Horizon is my main concern. I spent some time on horizon and managed to fix quite a few failures in the test suite. I just sent my patches to the bug. There's still some work left though... > Well, I'm doing my best to add Python 3 support everywhere I can. I've > been doing this for months already. I know it wont be possible to fix > everything. Currently, I have 2 blockers which I am working on: > > - python-memcache > - beautifulsoup > > Both needs patches in upstream code, which I already partially wrote, > but it's not fully working (yet?). memcached isn't easy at all, as it > has to deal with lots of unicode stuff. Once these are done, then this > unlocks Python 3 support in maybe 40 other packages. Nice! beautifulsoup has also been annoying me as it's currently used by Distro Tracker (aka tracker.debian.org) and I want to make it work on Python 3. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140804220353.gb17...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
On Sun, 03 Aug 2014, Brian May wrote: > > Django 1.7 final isn't even released upstream, and therefore, downstream > > projects didn't even try to run against it. There *will* be issues we > > will have to deal with. 85 packages is quite something. I'm ok, and even > > welcome to *try* to make it before Jessie, though it is my view that > > it's unreasonable to rush without taking care of possible breaking. I already explained you in another thread on debian-release, that it's not reasonable security-wise to release Jessie with Django 1.6. And you're well placed to know what it means to maintain a package that gets security updates very often... We have very few Django end-users apps in Jessie, so let's try to take care of those but it's not a problem if some of the Django "extensions" (i.e. apps available for integration in custom developments that have almost no reverse dependencies) are dropped from jessie. > > FYI, I'm trying to deal with python-memcache support for Python 3.4. > > Until that one is fixed, I wont be able to add support for Python 3 in > > keystoneclient, and therefore *a lot* of other packages will have no > > Python 3 support. I've tried to forward port a patch from > > python3-memcached, though it's still not ready, and unit tests are > > failing. Julien Danjou (eg: acid@d.o) wrote to me he'll try to find time > > to help. I really hope this one issue will be fixed soon, so that I can > > work on adding Python 3 everywhere possible in OpenStack, though right > > now it's a major blocker. I also hope we can upstream Python3 support > > for memcached, as the python3-memcached fork has been a major waste IMO. If you aren't able to deal with Django 1.7 support and Python 3 support before the freeze, please treat python 3 support as lower priority to Django 1.7 support. That said it would be nice to have both. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140803072708.gb19...@x230-buxy.home.ouaza.com
Re: Problem migrating from South to Django migrations for Linux distributions
Hi Andrew, thanks for your quick answer. On Thu, 24 Jul 2014, Andrew Godwin wrote: > There is no way around this; it's unfortunate that the packaging situation > means that Django will get auto-upgraded as part of a distribution upgrade; > I'm surprised that Debian hasn't had this with packages before? (Version > upgrades that break installed but non-packaged things) We probably had this kind of things before and the best we can do for non-packaged things is usally to document this in the release notes. But for packaged things, we try usually hard to get things to just work without any human intervention. Hence my question. > Neither of your suggested ways to go forward will work; the two history > models are very different, so the tagging of positions isn't going to work, > and Django 1.7 has changed substantially enough internally that porting > South 1.x up to it would be a very large amount of work. OK. > Also, what are the applications in particular that this will be a problem > for? I'm curious to know what Django + South things Debian is shipping > these days. Applications that depend on South and have different upstream versions in Debian 7 and Debian 8 are: http://tracker.debian.org/pkg/python-django-voting http://tracker.debian.org/pkg/python-django-threadedcomments http://tracker.debian.org/pkg/python-django-reversion http://tracker.debian.org/pkg/python-django-picklefield http://tracker.debian.org/pkg/bcfg2 Given the package names, it probably means only a single end-user application. The others are Django "extensions" for use in non-packaged applications. And looking more closely the case of bcfg2, the package in Debian 7 does not use South, it started using South in the version in Jessie so it should be easy to deal with. For the 4 others, they should provide some NEWS.Debian entry warning users of the potential upgrade problem. (Bccing the 5 relevant bug reports to keep a record of this) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140725080457.gc15...@x230-buxy.home.ouaza.com
Re: Problem migrating from South to Django migrations for Linux distributions
Hi Brian, On Fri, 25 Jul 2014, Brian May wrote: > I can't help but think this might be unrealistic (?). Changes required for > new versions of Django often break compatibility with old versions, and > 1.4.5 is really old now. Just because many packages don't have versioned > dependencies on Django (or a versioned dependency on a really old version) > doesn't necessarily mean they will work with any 1.4.5. Anyone want to test > every Django package in Debian sid against the Django in wheezy? I agree with you that this is not realistic. A better alternate solution is to document the process of how to execute the South migrations with Django 1.6 in a virtualenv after having done the upgrade to Debian 8. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140725074344.ga15...@x230-buxy.home.ouaza.com
Problem migrating from South to Django migrations for Linux distributions
[ Please keep me in CC ] Hello, I'm one of the python-django Debian package maintainers and I have been working on preparing the field for Django 1.7... and we have one problem that we don't know how to handle. Consider that Debian contains Django but also Django applications using South. When our users will upgrade from Debian 7 to Debian 8 they will upgrade at the same time Django itself and the Django applications. The new versions of the Django applications are likely to have unapplied schema migrations managed by South but the system will have Django 1.7 and we have no means to let the users apply those schema changes. I see two ways to go forward: - either we find a way to apply South migrations with Django 1.7 - or we enhance Django migrations to be able to tag some point in the Django migrations as equivalent to some other point in the South migrations, that way we can recreate the supposedly-unapplied South migrations with Django 1.7 and mark those as unneeded if all South migrations were already applied How can we solve this problem? Thank you for your help! -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140724202733.ga8...@x230-buxy.home.ouaza.com
Re: Help needed to test packages with Django 1.7
Hi,
On Wed, 23 Jul 2014, Brian May wrote:
> Attempt to summarize the problem: You want to make sure Django 1.7 is never
> installed if there are any apps with Django south migrations that haven't
> been run, and if Django 1.7 is installed you want to make sure django-south
> is not in INSTALLED_APPS.
>
> Think of the situation where somebody does an "apt-get dist-upgrade", and
> upgrades the packages containing the migrations and Django at the same time.
Multiple points:
- we should package South 1.0, it uses "south_migrations" instead of
"migrations" if it exists, that way applications can provide migrations
for South and for Django 1.7
- the settings needs to include South only in Django < 1.7, you can do
this for example:
import django
if django.VERSION < (1, 7):
INSTALLED_APPS += ('south',)
- still this doesn't solve the problem you mention, how can we ensure that
all deployed Django apps have all their South migrations applied prior
to switch to Django 1.7. This is only a problem if there are actual
schema changes managed by South between the wheezy and squeeze version
of the affected packages. There are only a handful reverse depends of
South:
python-django-voting,python-django-south
0.1 in wheezy, 0.2 in jessie
python-django-threadedcomments,python-django-south
0.5.3 in wheezy, 0.9.0 in jessie
lava-server,python-django-south 0.7.3
=> only in sid, not a problem
python-django-sitetree,python-django-south 0.7.1
=> only in jessie/sid, not a problem
python-django-reversion,python-django-south
=> 1.6 in wheezy, 1.8 in jessie/sid
python-django-picklefield,python-django-south
=> 0.2.1 in wheezy, 0.3.1 in sid
python-django-oauth-plus,python-django-south 0.7.5
=> only in sid, not a problem
bcfg2-web,python-django-south 0.7.5
1.2.2 in wheezy, 1.3.4 in jessie
At the very least, we should document this in debian/NEWS in
python-django.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20140723064623.ga3...@x230-buxy.home.ouaza.com
Help needed to test packages with Django 1.7
(Please cc me as I'm not subscribed) Hello, I have filed 85 bugs against all reverse-deps of python-django to ask their maintainers to ensure that their packages works well with Django 1.7 (1). A good chunk of those are maintained or co-maintained by the Python Modules team, and as usual in a large sample of packages, some maintainers will be MIA and I won't have any answer. So it would be highly appreciated if some people could help process the following bugs so that when Django 1.7 is out we have a good picture of what needs to be done and/or what will possibly have to be (temporarily) removed from testing: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 It would be nice if all packages had a test suite to ensure whether they still work but a large part doesn't even have a python-django build dependency so it's not really the case... What could be done however is mass-rebuild the packages against django 1.7 and mass-tag as confirmed the set of packages which are failing to build with Django 1.7. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140722090523.gb27...@x230-buxy.home.ouaza.com
Re: Is python-django still maintained in DPMT svn?
Hi Barry, On Tue, 28 Jan 2014, Barry Warsaw wrote: > As the package is supposed to be team maintained, I'm wondering *where* it's > maintained. I have some patches to fix build failures against Sphinx 1.2.1. Good question. Luke, are you using git-svn and you forgot to push or something? > PS. I suppose I should add myself to Uploaders? Not required if you don't intend to work regularly on it. Just put "Team upload" in the changelog and lintian will be happy. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140128131627.gc15...@x230-buxy.home.ouaza.com
Maintainer needed for python-trml2pdf
Hello, I just uploaded a new version of python-trml2pdf where I removed myself from Uploaders. I originally packaged this because it's needed for Satchmo but I never went further to package satchmo. So I have no interest in this package. In the mean time it got one reverse dependency, namely kraft. So it can't be removed. Someone should step up to maintain this package, and quite possibly one of the kraft maintainers (since we're using the version released by Kraft's upstream anyway). The package is currently maintained within the python-modules SVN repository and all Debian developers have write access. It's trivial to maintain and should not require much work. On the bad side, it has no real upstream. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20120504064142.ga26...@rivendell.home.ouaza.com
Re: ${python:Breaks}
On Thu, 10 Mar 2011, Piotr Ożarowski wrote: > seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹, > we don't have to worry about 2.X transitions when 2.7 will become the > only supported one. If you don't like Breaks, I will remove it, it > really doesn't matter - that's why at the beginning I wasn't generating > either of these dependencies (in Depends and in Breaks). Well, if upstream changes their plans it will to late to fix the dependencies... > What do you want me to do? Can I drop both of them or do you want me to > drop Breaks only? So I would suggest to continue as usual and generate only the versioned Depends. Better safe than sorry. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110310111501.gc31...@rivendell.home.ouaza.com
Re: Quick analysis of the Python dist-packages transition
On Fri, 18 Sep 2009, Josselin Mouette wrote: > If there are no objections, I will submit a MBF for those 75 packages in > a few days. Go ahead, we have waited too much for python 2.6 already. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517308: python-syck: lacks a python-support dependency
Package: python-syck Version: 0.61.2-1 Severity: serious The package uses python-support but does not depend on it. The dependency should be auto-generated in a substvar, you just have to add the proper substvar. Note: the package is unmaintained, someone from the python team should probably take it over. It is currently a dependency of dak and thus it would be nice to have it properly maintained. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008, Ondrej Certik wrote: > I am surprised I am actually the 6th most active. Pretty cool. :) I am surprised to still be in the top 10 (hertzog)… it means the team is not so active as one would expect. :-) Anyway, I'm fine with git as well but I'm not convinced it's that important. You should also look at the perl team, they are using git on some packages only and have not yet decided to mass-convert from SVN to Git. One of the reasons of the block is that Git makes it difficult to do operations on all the repositories. And for a global update, you're forced to use tools like "mr" (and even that won't add new package automatically). Furthermore, Git alone doesn't mean much, the questions is whether we have to use git-buildpackage, topgit and so on. Hence I would rather suggest a per-package decision for the switch. I won't cry if SVN continues to be used. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#500391: ITP: python-django-debug-toolbar -- Embedded debugging toolbar for Django projects
On Sun, 28 Sep 2008, Chris Lamb wrote: > Raphael Hertzog wrote: > > > Do you plan to maintain the various Django related packages in the > > python-modules team ? > > I'm open to persuasion on this, otherwise no. Well, I'm maintaining like you several Django related packages (python-django itself, python-django-registration, python-django-tagging) and it would be nice if we could co-maintain all those packages in the same repository. Currently this repository is python-modules's SVN repo. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unexpected Depends: both python-central and python-support
On Mon, 16 Jun 2008, Ben Finney wrote: > What's causing this, and how can I fix it so it doesn't have this > unexpected extra dependency? It's because dh (from debhelper 7) will use dh_pysupport by default if it's available. Just use what debhelper uses by default or make sure to skip that script by using appropriate dh --before pysupport and dh --after pysupport invocation to skip dh_pysupport (until Joey decides to implement a --skip option in debhelper at least). Check the output of "dh binary-arch --no-act" to verify it by yourself. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Migration of Alioth account
Hi, On Fri, 18 Apr 2008, Vincent Bernat wrote: > Could someone with appropriate rights remove my account bernat-guest and > add bernat instead? Already done by Piotr apparently. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
On Tue, 15 Apr 2008, Adeodato Simó wrote: > * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]: > > The solution is really simple, just add them to python’s Provides: list. > > Plus, uhm, can't really be done for (c)elementtree, since python 2.5 > provides the modules under a different name/namespace. ?! In that case it might be a good idea to build python-celementtree for python 2.5 as well... I haven't heard of technical incompatibility but just that it was bundled with python 2.5 and thus unneeded/in conflict. But if the namespace is different, there's no file conflict and I don't understand why we cared about not generating the module for python 2.5. > python-pysqlite2, on the other hand/for example, still provides the > modules for python 2.5 under the old name. elementtree could do this, > or else the packages should be somehow checked, I guess? Indeed. (I should read mails entirely before replying :)) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
On Mon, 14 Apr 2008, Adeodato Simó wrote:
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python << 2.5 only, the dependency generated is on
> python (<< 2.5), rendering them uninstallable.
I think they should simply be updated to not use ${python:Depends}.
I wonder if that should be replaced by some custom dependency however.
Probably not. There's no reason to depend on python-2.4... that's the
job of packages containing python scripts requiring 2.4.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternative for python
On Thu, 10 Jan 2008, Yaroslav Halchenko wrote: > I know that some packages might not yet ship extensions built for 2.5, > but still, since lenny is targetting python >= 2.5, and unstable is > unstable, why don't we allow users to experiment a bit and change > default python on their systems to python2.5? (yeah yeah -- they could > probably simply ln -sf python2.5 /usr/bin/python, but that is not the > point, since alternatives are there to provide such facility) Because if we allow that, then we must be able to support such changes. And we don't. If you want to experiment, overwrite temporarily the symlink. If we let people change the symlink, and if it breaks, then it's a bug in our packaging and we have to fix it. And it's far easier to package everything while knowing that python is a a single python version (identified by the corresponding python package). > In any case -- I just wanted to raise a concern and may be some > discussion -- may be I should simply a wishlist bug against python? No. The situation is fine as is. No need to introduce more complexity. I pushed for such a change in perl a long time ago, and we're back to a single perl version... let's not reiterate the mistake for python. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python modules not installed correctly with pycentral
On Tue, 08 Jan 2008, Vincent Bernat wrote: > > What should I be doing about this? > > Isuppose thatalintian overrideworks too.Create > debian/source.lintian-overrides with: > yourpackage source: package-lacks-versioned-build-depends-on-debhelper 6 debhelper 6 has been uploaded to unstable a few hours ago. So you can start depending on it. Adding overrides for situations that are known to be transient is not a good idea in general. It's best to keep the lintian warning so that it reminds you to update the build-depends once the updated packages is available. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maintainer field
On Thu, 06 Sep 2007, Steve Langasek wrote: > > > So I myself chose to be among Uploaders and set Maintainer to DPMT, > > > because this more enforces team work and I like team work. > > > I had a discussion on #debian-devel about this, and "they" thought it > > was pretty stupid to have DPMT as uploader, as it would make every > > package NMU. > > No, what was said was that it was meaningless to list a mailing list in the > Uploaders field because a mailing list can never do an upload and therefore > it misses the /point/ of the Uploaders field. The only (good) reason of listing the mailing list in the Uploaders field is to have the package in the group's QA page: http://qa.debian.org/[EMAIL PROTECTED] Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Egg Guidelines across distros
Hi, On Tue, 04 Sep 2007, Toshio Kuratomi wrote: > I'm revising the Fedora Python Guidelines to make better use of eggs and > saw an interesting bug report against python-docutils that left me > wondering how Debian had dealt with some of the decisions that I'm > having to make. If we come out with similar conclusions, that will be > one less difference for end users to have to worry about between > distros. If we come to different conclusions, at least we'll know what > to tell users when they ask why things don't work the way they do in > that other distro :-) Thanks for the initiative, it's much appreciated! We don't have a 100% clear policy, the general rule has been that we don't provide .egg files but we provided the egg meta-informations along with the usual modules when upstream uses setuptools by default. In some cases, when other modules requires an egg for a module which is not using setuptools by default, we apply a patch to use setuptools. See http://wiki.debian.org/DebianPythonFAQ However I noticed lately that egg-info are systematically generated even with distutils based modules and in fact we have /usr/lib/python2.4/distutils/command/install_egg_info.py provided by python2.4. I don't know when the change happened and can't find any note on python's Changelog... Matthias? So in practice we always provide egg-info but this change has not been discussed here. That said I don't see a compelling reason to refuse it. > 2) We're deciding how we want to make packages when we want to have > multiple versions of a module. For instance cherrypy is on release > 3.0.2 but the TurboGears framework requires a 2.2.x version. So we need > to provide both versions to our users. I've been drafting guidelines > for doing this using eggs[1]_ but some recent discussions with Phillip > Eby[2]_, setuptools author are proving there are some difficulties to > doing this. Have you guys considered doing anything like this? Again, no general discussion happened on this topic but the cherrypy maintainer packaged both versions and made them conflict (i.e. they are not co-installable). So we report the problem back to the user who wants to use two version of the product at the same time. :-) http://packages.debian.org/sid/python-cherrypy http://packages.debian.org/sid/python-cherrypy3 $ apt-cache show python-cherrypy3 | grep Conflicts Conflicts: python2.3-cherrypy, python2.4-cherrypy, python-cherrypy > These are my current goals for multiple versions: > 1) import MODULE should import whatever the vendor decided should be the > default. > 2) requires.txt in a project's egginfo should work to select a specific > version from the installed eggs. > 3) In a simple script (without requires.txt), > should work to select a specific version from the installed eggs. I think you're more advanced than us on this topic and we didn't not have any plans to try to use setuptools to achieve this. The python packaging is already complicated enough that we'd like to avoid having to resort to such things. And in general, the Debian packagers don't like Eggs as they replace (badly) the functionnalities of our package manager. So we avoid promoting them and are not keen to use them to solve new problems that shouldn't exist in the first place. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making all DD members of the team by default
On Thu, 26 Jul 2007, Raphael Hertzog wrote: > Hello, > > this mail is crossposted to two mailing lists. Please reply only to the one > that concerns you (perl or python team). This warning is still valid. :-) > As an Alioth admin, I can add those ACL. However I'd like to have your > opinion and agreement first. Both projects agreed and I just added the ACL. It would be great if some people could update the respective documentation of each project to share this information. It has been noted that when a DD gets highly involved in the team, he should nevertheless be added to the Alioth project. Non-DD who are looking for sponsors can then better identify them and that way we keep a list of "core-members". We'll also publicize this change in debian-devel-announce later (either in a Bits of Alioth or in a more generic mail, we'll see). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging django-openid ? and django dev release in experimental ?
Hello Brett, I was looking for some OpenID support in Django and found out http://code.google.com/p/django-openid/ Would you be interested in packaging this ? Also, given the long time between two stable releases of Django it might be worth packaging development release in experimental. What do you think ? Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Making all DD members of the team by default
Hello, this mail is crossposted to two mailing lists. Please reply only to the one that concerns you (perl or python team). The collab-maint project gives write access to all DD by default using ACL (see man setfacl and getfacl). $ getfacl /svn/collab-maint/ [...] group:Debian:rwx [...] default:group:Debian:rwx I believe the perl and python team would benefit from using similar ACL so that any DD who wishes to integrate his packages in the team can do so without requesting access that we'll grant him anyway. We expect DD to be educated and to ask before messing up if they're not sure of what they're doing. In most cases, they'll figure it by themselves because the available documentation hopefully directed them correctly. :-) This also let NMUer integrate their NMU in the VCS directly if they so wish. As an Alioth admin, I can add those ACL. However I'd like to have your opinion and agreement first. Cheers, PS: If you know other teams that would be interested, feel free to suggest them and direct them to alioth admins ([EMAIL PROTECTED]) to get the ACL added. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Full checkout with svn:externals
On Sun, 24 Jun 2007, Bernd Zeimetz wrote: > that would mean I'd have to checkout all modules, I wanted to avoid > that. BTW, I discovered that there might be a way to checkout everything out of trunk without extracting tags and branches. The idea would be to have a directory all-packages with the property "svn:externals" listing all the trunk of all packages: http://svnbook.red-bean.com/en/1.0/ch07s03.html Might be worth considering... and documenting so that people add the new packages there as well. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: joining the python modules packaging team
Hello, On Thu, 05 Apr 2007, Michel Casabona wrote: > Hello, > > I'd like to join the team to maintain the python-hachoir packages that I > build, > which will be soon uploaded to debian (thanks a lot to Piotr Ożarowski), > and help maintaining other packages if possible. You have been added. Welcome to the group! Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
