Re: debian github organization ?
On Sat, 18 Apr 2015 06:03:12 +1000 Ben Finney wrote: > Paul Tagliamonte writes: > > > So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't > > think this should be the Vcs-Git: target. No, I don't think we > > should endorse GitHub. Yes, we need free tools. Yes, we should > > contribute to the F/OSS community where upstreams are. > > That last part seems to deny the D in DVCS. Why are we under such > pressure to use one particular centralised service? I don't see the problem when it is used as just one remote amongst many. People like the github interface. That is unarguable. It does not matter one jot that some people don't like github for this reason or that. There are people (quite large numbers of people) who expect to find stuff on github and who prefer the UI. Having github as one of my remotes is extremely helpful. As Paul mentioned, I also prefer to *not* have my github remotes "locked-away" under a personal moniker as that makes it harder to add new admins etc. and it is project admins on github which make the whole point of github actually work. > Upstream is using a decentralised VCS, it seems a little condescending > to assume they are incapable of using it. That makes no sense at all. Upstream have their own git source but that is optimised to their needs (particular code review, access lists which need *everyone* to have yet another web account etc.) Nobody wants to have a hundred web accounts for every possible distributed VCS server. So having a few which act as mirrors for the plethora of local ones brings advantages that people are actually able to interact using a common UI. I have very little on github which is not simply a mirror of the primary git source used by upstream - but that is precisely the point. I'm using github (and now github.com/debian) precisely because the code is in a DVCS because github allows me to offer the one UI that most contributors seem to prefer at no cost to me, except maybe an extra "git push" command. Alioth cannot be another github, random other upstreams cannot be another github. Sourceforge well, just no really. Github is exactly that - a hub. Use it to push the code out from within the access constraints of a typical upstream project. It's easy for others to work with your code that way. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpZHUnBsDqgw.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Sat, 18 Apr 2015 00:01:29 +0100 Steve McIntyre wrote: > Ben Finney wrote: > >Paul Tagliamonte writes: > > > >> So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't > >> think this should be the Vcs-Git: target. No, I don't think we > >> should endorse GitHub. Yes, we need free tools. Yes, we should > >> contribute to the F/OSS community where upstreams are. > > > >That last part seems to deny the D in DVCS. Why are we under such > >pressure to use one particular centralised service? We are not - however, there is good reason for everyone to not have to work with every git service on the net. Many to Many is worth doing, Every to Every is insane. There has to be somewhere where a number of "small fry" services push mirrors to make their code accessible to the many. We know this already from working with so many upstreams for Debian - some service needs to be a central mirror. Few projects can work with git entirely using patches on a mailing list. What works for one (admittedly large) user base does not work for all - even if it does work for the upstream team, it typically does *not* work for all potential contributors. Now with an extremely large project, that can be an advantage by actually acting as a barrier to entry. For smaller projects, there should be as low a barrier as possible. The simplest way to that goal is to push to github. I don't care what anyone thinks of github - that is the simple fact. If you want to make the barrier to entry of your upstream project as low as possible, you have to include github. It's actually a nice place to be and it's trivial to work with as a project admin too. That's why people use it - it's easy. By all means lock your own little projects into alioth or personal git servers but the reason to go to github is to make it easier for you and the contributors. It makes no sense to ignore that. git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. > Agreed - it's really annoying to see everybody clamour for a > centralised single point of of failure for git hosting. :-( Sorry, Steve, you've missed the point of github being just a hub of mirrored code. It actually does that extremely well, no other service even comes close. Github is just a centralised User Interface, nothing else. It is *the* UI that most people seem to want. It avoids users having to have hundreds of different web accounts and it is a simple hub. It's trivial to push another copy of the source to github and keep the primary source within the corporate access control server. That way, everyone gets a chance to work with you without registering for a corporate web account and upstream get to include github into their access-controlled review workflow. There's no reason for github to be the single remote for anyone with an alioth account - there is also absolutely no reason for anyone to *not* have a github remote for each of their upstream projects as one of a handful of remotes. Why use a DVCS if you are not going to have multiple remotes? github.com/debian is a very useful service and I intend to use it fully. I think a lot more Debian folk and a lot more upstream folk should too. It's a hub, use it as a hub, as one of your remotes. Why not use the biggest, easiest hub to reach the biggest number of potential contributors? What's not to like? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWHS151aLMJ.pgp Description: OpenPGP digital signature
GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)
Russ Allbery writes: > Ben Finney writes: > > Yet it is exactly those lock-in features that is the basis for > > arguments to put special effort into the centralised single point of > > failure. > > > For example, the centralised proprietary GitHub “pull request” is > > presented as a reason to abandon a decentralised model: > > Uh, a pull request isn't something proprietary. It was part of the > design of Git from the beginning and is based on the workflow of the > Linux kernel. The Git pull request (‘git-request-pull(1)’) is not proprietary. I didn't claim that. Indeed, Git's ‘request-pull’ works in a federated way, allowing peer repositories on different hosting services to collaborate without needing to establish an account on each other's services. This is why the Linux repository, for example, deliberately opts to keep using the standard, federated Git ‘request-pull’ feature https://github.com/torvalds/linux/pull/17#issuecomment-5654674> and not the GitHub “pull request” feature. The GitHub pull request function is *not* compatible with Git's ‘request-pull’. It mangles them on the way in, and it doesn't produce them going out. GitHub's pull request feature is proprietary to GitHub, it can only work between repositories hosted inside the GitHub silo, and any project using that feature is thereby locking its workflow to the single-vendor GitHub service. Git repositories outside GitHub cannot interact with the GitHub pull request workflow using Git's own features. (I've done some searching to try to disprove this with recent information; if this has changed since 2010, I'd like to know https://github.com/blog/712-pull-requests-2-0>.) Emma Jane Hogbin Westby has a useful perspective on this too http://developerworkflow.com/resources/evolution-social-coding.html>. > Of course not. You don't have to use anything you don't want to use, > and no one in this thread is advocating otherwise, at least that I've > seen. If a project uses GitHub pull requests for their workflow, they are thereby prejudicing their workflow against repositories not hosted on the proprietary GitHub service. They have chosen (or have never been aware they made the choice) to make it much harder to interact with them using the existing, standard, federated Git ‘request-pull’ feature, instead opting to exclude anyone who doesn't want an account on a specific vendor's service. That's not cool, no matter how nice the UI is for the proprietary feature. That's damaging to a collaborative software community. > All that I'd ask is that, if other people want to use GitHub, for you > to not be an ass about it, the same way that we don't lecture people > for using a proprietary editor to write free sofware. Sure, so long as their decisions don't hamper anyone's ability to collaborate with them. If they use proprietary features of that tool which hampers collaboration with others in the community, I hope you'll agree that's something to object to. > Sometimes I wonder if people think free software is so fragile that if > anyone who works on it ever touches non-free software, everything we > built will crumble. I think our community and ecosystem is a lot more > robust than that. Conversely, I wonder why people are so eager to cede the power of peer collaboration by setting up single-vendor services as mediators of our peer relationships. Surely we have seen that fail far too many times to be led down that path yet again. -- \ “[…] we don’t understand what we mean when we say that [God] is | `\‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case | _o__) For God_, 2009 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857ft9rhui.fsf...@benfinney.id.au
Bug#782804: ITP: ssr -- Simple Screen Recorder
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz * Package name: ssr Version : 0.3.3 Upstream Author : Maarten Baert * URL : http://www.maartenbaert.be/simplescreenrecorder/ * License : GPL-3 Programming Lang: C, C++, Shell script Description : Simple Screen Recorder Simple Screen Recorder is, despite its name, an actually quite complex piece of software. The name reflects the fact that it is simple to use unlike many other free screen recording applications available. It can be easily configured to start recording from an intuitive wizard-like interface. To perform an X11 recording, all it takes is selecting an area on the root window with the mouse, choosing an output file and pressing record, either by using the mouse or using a hotkey. Its complexity becomes apparent in its powerful features. It allows one to record X11 windows and fullscreen OpenGL applications including sound supporting both ALSA, PulseAudio and JACK. It uses libavformat to encode the recorded material into a variety of video formats. Scaling the recorded video is possible as well as configuring the encoding quality for the codec chosen directly from the user interface. I have chosen to package Simple Screen Recorder because I haven't found any other screen recorder that is up to par with ssr both in its easy to use as well as features provided. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150418075604.20859.46284.report...@jessie64.physik.fu-berlin.de
Re: debian github organization ?
On Sat, 18 Apr 2015 11:44:34 +1000 Ben Finney wrote: > Russ Allbery writes: > > > Steve McIntyre writes: > > > Agreed - it's really annoying to see everybody clamour for a > > > centralised single point of of failure for git hosting. :-( > > > > Funny, this is why I don't get why people are so upset that some use > > GitHub. Because of how Git works, the impact of lock-in is pretty > > much limited to the non-repository stuff (issues and so forth). > > Yet it is exactly those lock-in features that is the basis for > arguments to put special effort into the centralised single point of > failure. That just ignores the whole point of using github in the first place. github is *not* lock-in. It is the opposite of lock-in because it allows me to push free software from a locked-down corporate server to a mirror that makes it easier for me to accept contributions from people without those people needing to register with my particular corporate server. > For example, the centralised proprietary GitHub “pull request” is > presented as a reason to abandon a decentralised model: No - it is presented as a method of retrieving useful contributions which would not have been made via other methods. That contribution can then be reviewed, pushed to the internal corporate review frontend by one of the team whilst retaining the author details of the github user and that user then gets a listing in the corporate git master branch if the patch is accepted. The github pull request is just a nice UI over a patch. What on earth is wrong with that? > Paul Tagliamonte writes: > > > An entirely fair point, however, I also think it's quite rude to > > ignore the workflow they've chosen for contributions -- if they > > expect PRs, it might disrupt their workflow and result in a much > > harder time for them. > > So upstream have chosen a proprietary lock-in service for their > workflow. That should not put any obligation on others to also submit > to proprietary lock-in. That ignores the whole point of a DVCS - to have multiple remotes. This is about extending access, of removing lock-in. Pushing to github *increases* access, it does not invole lock-in on any level. I've chosen to offer github pull requests on all my free software because that allows me to access contributions which would otherwise be awkward to handle. The BTS, whilst excellent at so many things, is simply not designed to track git branches. One-off small patches, yes. Large changes which evolve over a period of time and keep track of changes elsewhere? umm, no - really, no and neither should it become so. Github provides that service and the people who are offering this code want to use it. Why would I refuse to use that service to open up my own locked-down server without the admin hassle of creating hundreds of new accounts? The people are already on github - if I want their contributions, what is the sense in *not* pushing to github as one of my remotes? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp28uh41J1h7.pgp Description: OpenPGP digital signature
Re: GitHub “pull request” is useful and can be easily integrated'’ (was: debian github organization ?)
On Sat, 18 Apr 2015 17:55:17 +1000 Ben Finney wrote: > Russ Allbery writes: > > > Ben Finney writes: > > GitHub's pull request feature is proprietary to GitHub, it can only > work between repositories hosted inside the GitHub silo, and any > project using that feature is thereby locking its workflow to the > single-vendor GitHub service. Not true. Simply and completely untrue. The pull request exists on github, fine. I can either choose to manually pick that out of the github interface or I can choose to use my github account to merge that pull request into a local branch. At that point, I can use all the power of git to do whatever I like with that, including pushing directly to my own corporate git review process. I can use precisely the same workflow for *all* contributions, pull requests or not. git pull is separate from git push, it's not as if a pull from github must inevitably be followed by a push to the other remotes. I pull from github, I rebase onto a local branch, I push the branch to the review frontend, I update the pull request issue with the results of the review. How is that a problem? It's a sight easier than pulling a patch from my email client. > Git repositories outside GitHub cannot interact with the GitHub pull > request workflow using Git's own features. Untrue. I use github and git.linaro.org side by side and have applied github pull requests as reviews on review.linaro.org without disrupting my workflow and without needing to limiting access to any of the features of git. > If a project uses GitHub pull requests for their workflow, they are > thereby prejudicing their workflow against repositories not hosted on > the proprietary GitHub service. Untrue. > They have chosen (or have never been aware they made the choice) to > make it much harder to interact with them using the existing, > standard, federated Git ‘request-pull’ feature, instead opting to > exclude anyone who doesn't want an account on a specific vendor's > service. Sorry, that makes no sense. Working with github as a second remote is trivial. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgphhvZcpZfNV.pgp Description: OpenPGP digital signature
Bug#782749: general: All browsers except Links2 crash constantly and iceweasel is broken
On Fri, Apr 17, 2015 at 6:18 PM, Dominik George wrote: > iceweasel is a bit outdated, but existent in wheezy for sparc; Chromium > is not existent for sparc, which cannot be called „broken“. In addition, Debian jessie (to be released next weekend) does not support sparc and the new sparc64 port was not added to Debian yet. I would encourage you to switch to another architecture or get involved in making the sparc64 port happen for Debian stretch (the release after jessie). https://wiki.debian.org/Sparc64 https://lists.debian.org/debian-sparc/ https://wiki.debian.org/PortsSparc https://lwn.net/Articles/596663/ -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6h-0c8qbkn5werc3do-facu4lywn055evu0k6nst6y...@mail.gmail.com
Re: MBF: build Python 3 modules for packages that support it upstream
* Paul Tagliamonte , 2015-04-17, 20:07: faulthandler This one is is part of stdlib since Python 3.3. cython Already packaged as "cython3". -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150418083810.ga7...@jwilk.net
Re: debian github organization ?
On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: > git won the DVCS argument a long time ago. github won the DVCS UI > argument a long time ago - it is clearly the one UI that the > largest number of git contributors actually want to use. Are there any good DFSG-free desktop UIs for git? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6g4whnsfobodah_hm40ons3zht57xggc-6zp1zplo3...@mail.gmail.com
Re: debian github organization ?
2015-04-18 12:04 GMT+02:00 Paul Wise : > On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: > > > git won the DVCS argument a long time ago. github won the DVCS UI > > argument a long time ago - it is clearly the one UI that the > > largest number of git contributors actually want to use. > > Are there any good DFSG-free desktop UIs for git? > gitg is quite good for simple tasks.
Re: debian github organization ?
On Sat, 18 Apr 2015 12:07:22 Jérémy Lal wrote: > > Are there any good DFSG-free desktop UIs for git? > > gitg is quite good for simple tasks. 0.2.7 is still good but unfortunately upstream ruined newer versions... :( -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: debian github organization ?
2015-04-18 12:16 GMT+02:00 Dmitry Smirnov : > On Sat, 18 Apr 2015 12:07:22 Jérémy Lal wrote: > > > Are there any good DFSG-free desktop UIs for git? > > > > gitg is quite good for simple tasks. > > 0.2.7 is still good but unfortunately upstream ruined newer versions... :( I guess it's a matter of taste. I like gitg + meld + gedit (with git plugin) all at ~ 3.14.
Re: debian github organization ?
On Sat, 18 Apr 2015 18:04:40 +0800 Paul Wise wrote: > On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: > > > git won the DVCS argument a long time ago. github won the DVCS UI > > argument a long time ago - it is clearly the one UI that the > > largest number of git contributors actually want to use. > > Are there any good DFSG-free desktop UIs for git? For desktop UI, I find qgit to be usable. However, that's just for viewing branches, diffs and history - contributions need to come via something off desktop and qgit does little to help me when reviewing patches submitted by others beyond what I would see anyway with a web-based diff frontend or the superb 'meld'. (I don't know where I would be without conflict resolution support in meld - big *thank you* to the meld maintainers & upstream - I grew to like meld when I was on svn, it has become even more important and useful with git). So I should clarify that, github won the DVCS web UI ... it's contribution support and repository creation / browsing / searching support is far better than any of the other tools I have to use (command-line, desktop or web). Integration with an issue tracker actually works when most alternatives do not, the wiki is fast, usable and has a nicer rendering than any other wiki I regularly use. I also look at github and sites like it when planning how to implement new web UI features in my own free software. More important than all that, it's where the users are. It's a circular argument, I know, but I use it because that's where people expect to find stuff and where people expect to be able to contribute. TBH I'm far from worried about a web service like github being run on non-free software. It's not the sole source for anything I care about, it provides a useful service to me but if it went away, meh, it went away - I'd just have to find out where the users went and probably follow. It's not that github is the best possible answer, it is the best current answer and has a large, interested, user base. It's primarily the user base that matters, the UI support is very good but secondary to me. Ignoring or snubbing github won't affect github or reduce it's usefulness to others - it will just cut off a possibly interesting source of new contributors. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5UNEbc4czE.pgp Description: OpenPGP digital signature
Re: debian github organization ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/18/2015 01:09 PM, Neil Williams wrote: > On Sat, 18 Apr 2015 18:04:40 +0800 Paul Wise > wrote: > >> On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: >> >>> git won the DVCS argument a long time ago. github won the DVCS >>> UI argument a long time ago - it is clearly the one UI that >>> the largest number of git contributors actually want to use. >> >> Are there any good DFSG-free desktop UIs for git? > > For desktop UI, I find qgit to be usable. However, that's just for > viewing branches, diffs and history - contributions need to come > via something off desktop and qgit does little to help me when > reviewing patches submitted by others beyond what I would see > anyway with a web-based diff frontend or the superb 'meld'. (I > don't know where I would be without conflict resolution support in > meld - big *thank you* to the meld maintainers & upstream - I grew > to like meld when I was on svn, it has become even more important > and useful with git). > > So I should clarify that, github won the DVCS web UI ... it's > contribution support and repository creation / browsing / > searching support is far better than any of the other tools I have > to use (command-line, desktop or web). Integration with an issue > tracker actually works when most alternatives do not, the wiki is > fast, usable and has a nicer rendering than any other wiki I > regularly use. I also look at github and sites like it when > planning how to implement new web UI features in my own free > software. More important than all that, it's where the users are. > It's a circular argument, I know, but I use it because that's where > people expect to find stuff and where people expect to be able to > contribute. > > TBH I'm far from worried about a web service like github being run > on non-free software. It's not the sole source for anything I care > about, it provides a useful service to me but if it went away, meh, > it went away - I'd just have to find out where the users went and > probably follow. It's not that github is the best possible answer, > it is the best current answer and has a large, interested, user > base. It's primarily the user base that matters, the UI support is > very good but secondary to me. Ignoring or snubbing github won't > affect github or reduce it's usefulness to others - it will just > cut off a possibly interesting source of new contributors. > So we now just need somehow make every DD (or DM or other packaging contributor) to package one dependency for Gitlab and then make gitlab.debian.net infrastructure and everyone is happy I guess. Cheers, zlatan - -- Its not the COST, its the VALUE -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVMkw3AAoJEC5cILs3kzv9OjMQAK0CyVxnzL/DvF19hNNDVOgD hBRh6VLrnryfKpcNTdIRpgvh9nRqKdhmoxB5AXK6ZblvCwVYxqJe0iT7qVek0a69 kjkC+nbkLqQzdMKrOMsbiH8qUKacW+sHAysMwy4EgGea/jRCp7QcSHBJ1YsgUOtq jZpTk1pBVwuPaVLTxn03VL6ZaWd3bDo6XZsmBoqhuk9Uw2y2pPWmTFcZcUfK5it7 BIddKBAHBiIpmF7d/00iVk4EGebAyYT8onEXE1ndZklqUPzlXaGjpmQsykCRIT+u 1KUqzhBXYdmczrjXJkGz74ILLJGWe16NXTBPqlp3XHFZZ3HjHuD9B2D5eUpj+5YB gg3cNweaLsq8HACXE28G6yszUhSkYIpFaTHb2X4ulyRZa1++Ac965gDbblSPphht /vw2+5oELq94J0soWjBvJeywS2YS/95lM10mCCUvKXHcvVTvdGmw4wmcz0V2QAi3 gR4BvQ/i1q1JAg0mJHzzI/Y6KLCpI9pSngRa3FjSwUNQ0YE0GFKgWu0rHfJugBUo db2IHrTbxkzxsQqYset9Yg9n4x5LfA0Y4JCwPEsOv9D/gDWI+1Mi0fuVl4ZNWiQP CXLjmo1Y+tnF+Smc4bw9EfbKHc8b9DBzf7cR64C6xceY7QQFz936YRr/Sdzej0oA rQKDvzmTyk2g2HFfR4rX =dAUO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55324c37.6010...@riseup.net
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)
On Sat, Apr 18, 2015 at 05:55:17PM +1000, Ben Finney wrote: > > Sometimes I wonder if people think free software is so fragile that if > > anyone who works on it ever touches non-free software, everything we > > built will crumble. I think our community and ecosystem is a lot more > > robust than that. > > Conversely, I wonder why people are so eager to cede the power of peer > collaboration by setting up single-vendor services as mediators of our > peer relationships. Surely we have seen that fail far too many times to > be led down that path yet again. The real conversation here is slightly more subtle, I think. You, me and the majority of people here on this list *are* willing to make tradeoffs for our freedom. Our tradeoffs often come at the expense of ultra-modern hardware, fancy new non-free software and the SaaS of the month. We're willing to hack on our stuff to make it work -- to create a free and open source world. That's why I'm here. That's why I spend hours on this stuff. Other people, they made other tradeoffs on their freedom. They're willing to give up some of that freedom to a company, subject themselves to a power dynamic wherein they're denied freedom, in a pragmatic decision to just "not worry about it". People use GitHub simply because they don't have to host it, they don't have to maintain it, they don't have to tell contributors how to contribute. They're using Slack because NTEUs can use it better than IRC. They're using gmail because mail servers suck to maintain. Everyone's willing to make tradeoffs on our freedom. It's what tradeoffs we make, that's the question. -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [py3porters-devel] MBF: build Python 3 modules for packages that support it upstream
On Sat, Apr 18, 2015 at 10:38:10AM +0200, Jakub Wilk wrote: > * Paul Tagliamonte , 2015-04-17, 20:07: > > faulthandler > > This one is is part of stdlib since Python 3.3. > > > cython > > Already packaged as "cython3". Perfect, thanks jwilk! I'll remove those from the list :) (I actually knew about the first, that was out of my local list, sorry about that!) Cheers, Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: MBF: build Python 3 modules for packages that support it upstream
* Paul Tagliamonte: " Re: MBF: build Python 3 modules for packages that support it upstream" (Fri, 17 Apr 2015 20:07:38 -0400): > On Thu, Apr 16, 2015 at 06:50:11PM -0400, Paul Tagliamonte wrote: > > Severity will be wishlist. Target is the next release / sid after Jessie > > release. > > > Draft text and dd-list attached. Please let me know of any false > positives if you see them. > > I'll start filing tomorow night. Mathias Behrle relatorio (U) Already in CVS, will be uploaded soonish after release. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgpUhuqdsYRaC.pgp Description: Digitale Signatur von OpenPGP
Re: Bits from the dpkg project: 1.17.x series, general news
Hi, this: Am Samstag, den 18.04.2015, 21:27 +0200 schrieb Guillem Jover: > * Add support for versioned Provides [!]: > - Packages can provide a specific version, “virtual (= 1.0)” which will > be honored, previously it would just be accepted when parsing. > - Non-versioned virtual packages will not satisfy versioned dependencies. > - Versioned virtual packages will satisfy non-versioned dependencies. is great. I assume that support for this needs to be added to more tools and infrastructure. Any estimate as to when can we start using this feature in packages uploaded to Debian unstable? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
dose3 support for versioned provides (was: Re: Bits from the dpkg project: 1.17.x series, general news)
Hi, Quoting Joachim Breitner (2015-04-18 22:24:20) > is great. I assume that support for this needs to be added to more tools > and infrastructure. Any estimate as to when can we start using this > feature in packages uploaded to Debian unstable? for source packages that require versioned virtual packages, dose3 support for this is needed because otherwise the affected source packages will remain bd-uninstallable. But right now dose3 can only parse versioned provides but does not treat them correctly yet. This is this bug: https://gforge.inria.fr/tracker/index.php?func=detail&aid=17556&group_id=4395&atid=13808 Since the build infrastructure runs stable, it might be tricky to be able to upload source packages relying on versioned virtual packages before the next stable release (assuming this dose3 bug is fixed during the next release cycle). cheers, josch signature.asc Description: signature
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull’ (was: debian github organization ?)
On Sat, Apr 18, 2015 at 10:04 PM, Paul Tagliamonte wrote: > Everyone's willing to make tradeoffs on our freedom. It's what tradeoffs > we make, that's the question. To those of you who are willing to use github for Debian related things, it would be great if you could: Mirror the repositories to alioth so Debian has a backup. Also accept contributions via email or git request-pull. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fpmhr-n+1qkcopqyo66fxhjadsr88emidi915hrw1...@mail.gmail.com
Re: debian github organization ?
On Sat, 2015-04-18 at 12:07 +0200, Jérémy Lal wrote: > gitg is quite good for simple tasks. I'm guessing it isn't good enough to be a replacement for the github web UI though and that there is no equivalent free software desktop UI. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
