On Wed, Mar 15, 2017 at 11:27 AM, Ghislain Vaillant <[email protected]> wrote: > Le mardi 14 mars 2017 17:21:20 UTC, anatoly techtonik a écrit : >> On Mon, Mar 13, 2017 at 7:11 PM, Ghislain Vaillant <[email protected]> >> wrote: >> > >> > Early disclaimer: I am one of the Debian package maintainers for spyder. >> >> Nice. I've create a recipe that builds Spyder automatically. >> https://code.launchpad.net/~techtonik/+recipe/spyderlib-daily-master >> >> But.. it seems I got branches wrong. It builds from master >> https://code.launchpad.net/~techtonik/spyderlib/master >> merges with Debian packaging >> https://code.launchpad.net/~techtonik/spyderlib/debian-packaging >> and resulting binary has a version 3.1.2. > > You need to bump the version in debian/changelog accordingly.
Can Debian packaging branches be identical to Spyder branches? So that nightly/daily builds could be completely automatic. I'd gladly move recipes and artifacts into some team PPA on Launchpad, because I am subject of being hit by a bus way too often. >> I created another recipe to work directly with Git branches, but it fails >> to build fail at all. >> https://code.launchpad.net/~techtonik/+recipe/spyderlib-daily > > That's why I'd recommend to use the backportpackage utility on the Debian > experimental > or the Ubuntu Zesty package (which is sync'd from experimental). Debian > experimental will > receive all subsequent updates whilst the freeze is happening. PPA recipes don't allow arbitrary commands, so it won't run daily. Also I am not sure how that backportpackage can help - builds are failing because Debian checks don't like Spyder sources https://launchpadlibrarian.net/310888373/buildlog.txt.gz >> > Le dimanche 12 mars 2017 14:39:31 UTC, anatoly techtonik a écrit : >> > >> > It depends what definition of "stable" you mean, i.e. as bug-free or as >> > non-changing. >> > >> > Sure, each release of spyder introduces its lot of bug-fixes but also >> > new >> > features and enhancements which are likely to introduce regressions. For >> > instance, the recent breakage of code completion with Jedi comes to my >> > mind >> > (thanks Carlos for fixing it for 3.1.4). >> >> Bug free. Regressions are not good, but it is better to have regressions >> and ability install earlier version temporarily than don't have an ability >> to install version without bugs. > > > That's your opinion. Stable releases of Debian are focusing on being > regression-free > from one version to the next. Should you need to keep up with the latest > updates of > spyder, then there are better alternatives like installing spyder in a venv > or using Debian > testing/unstable, at a higher price of system maintenance. Yes. Often Debian/Ubuntu ships with unusable version of software I am interested in, so I usually get it from source and compile/patch myself. Especially for project like Spyder - Python IDE written in Python, which more or less assumes by its own unwritten guidelines that users are able to patch and share their changes. That's not the case with Debian/Ubuntu, because changes are not really shared. They wait until permission. I remember the whole SourceForge source browser was broken, because Debian decided to remove duplicated JQuery from tracker and when tracker frontend updated to last version, Debian could not revert it. Sometimes developers of the software know better what version is to use. That's why I asked this thread. Debian policies, which are the same for everything, with no user/developer feedback about real update cycle, no channels for alternative cycles. It is so outdated. I mean there is a lot of space for improvement. Just no money to get to it. =) But whatever, I was once banned from Debian maintainers - critics it hard to get there. People like their ponies, and I am just lucky to be able to use free open source software, so let's leave it where it is. =) >> > [2] >> > http://manpages.ubuntu.com/manpages/precise/man1/backportpackage.1.html >> >> Sorry. It is about 16.10, not 16.04. The point is to get 3.1.x >> releases on Yakkety. >> https://bugs.launchpad.net/ubuntu/+source/spyder/+bug/1672159 > > > You could do both with backportpackage. There is an option to specify the > target > distribution of the package. You may try both Xenial and Yakkety, although > the value > of providing backports for Yakkety is arguable considering the short support > cycle of > interim Ubuntu releases. Can you expand what do you mean by value? I am running Ubuntu 16.10, and I need latest released stable Spyder, which is 3.1.4, so what is arguable here? If you're concerned about maintenance, then I am not interested in maintaining those manual backports as well. If automation is set correctly, maintenance doesn't matter, but the problem is that backportpackage can not be run by daily servers. -- anatoly t. -- You received this message because you are subscribed to the Google Groups "spyder" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/spyderlib. For more options, visit https://groups.google.com/d/optout.
