Re: Built-Using and Cython
Hi Nikolaus, Nikolaus Rath wrote: > If a debian package uses Cython in its build process, does it need to > declare Built-Using: cython? I don't think typical licenses require that, no. The policy text could use a lot of help in this area. See http://bugs.debian.org/688251 if you have ideas for improving it. Thanks and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130304065240.GA893@elie.Belkin
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
On 03/04/2013 03:37 AM, John Paul Adrian Glaubitz wrote: > A great place for maintaining the packaging for Debian is github, for > example. Many DDs, including myself, think it's better to host Debian stuff on Debian infrastructure (that is: alioth.debian.org), and that the problem with platforms such as Github is that its platform isn't open source (eg: you don't have the sources of Github available), so it's better to avoid it in the favor of more open places where you can run your own instance if you want/need. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51343f51.4020...@debian.org
Bug#702208: ITP: python-autobahn -- WebSocket/WAMP implementation for Python/Twisted
Package: wnpp Severity: wishlist Owner: Victor Vasiliev * Package name: python-autobahn Version : 0.5.14 Upstream Author : Tavendo GmbH * URL : http://autobahn.ws/python * License : Apache 2.0 Programming Lang: Python Description : WebSocket/WAMP implementation for Python/Twisted It provides Python applications ability to act as WebSocket server, as well as WebSocket Application Messaging Protocol. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130304044625.2543.28624.reportbug@philomena
Built-Using and Cython
Hello, Cython converts a Python-like source code into .c or .cpp, which can then be compiled into a Python extension (as .so) with a C compiler. The Cython generated C file contains lots of glue code and helper functions that presumably may change from Cython version to Cython version. If a debian package uses Cython in its build process, does it need to declare Built-Using: cython? Thanks , -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqtnnbo9@vostro.rath.org
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
John Paul Adrian Glaubitz writes: > The license issue was just an example (hence the braces). The reasoning > is that the Debian packaging is supposed to be independent of upstream, > especially since we cannot always follow upstream, during a freeze, for > example. That makes sense. > Assume we have version 3.0 in Debian and upstream has 3.5 and we're > frozen. During the freeze, someone discovers a nasty bug in subsurface > which is considered RC (release critical) in Debian, but gets fixed in > 3.5.1 upstream. > > Now, since we'd be in freeze, uploading the new version 3.5.1 into > unstable to fix the problem in testing would not be possible. Instead, > the fix would have to be backported to 3.0 and fixed in the Debian > packaging. If the Debian packaging would be part of upstream, > backporting the bug would be a bit difficult since the fix would be > realized as a patch in the debian/patches directory which wouldn't apply > if upstream was already at 3.5.1 (which includes the fix naturally) and > the official Debian packaging (which is at 3.0) would be part of the > upstream repository. > > I am aware that you could probably avoid this problem with branches, but > I think it would just make things difficult. Debian cannot simply be > up-to-date with upstream and thus upstream shouldn't maintain the > Debian-specific part. Yes, all this could be worked around but it creates a dependency of Debian on upstream and that's not desired. No problem. >>> A great place for maintaining the packaging for Debian is github, for >>> example. >> >> Well - I run my own git server at git.hohndel.org but we can use >> whatever works for the packaging. > > Sure, that was just a suggestion. I'd just keep it independent from > upstream. OK, no problem. /D -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303153712.74248.fmu31...@air.gr8dns.org
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
On 03/03/2013 10:35 PM, Cristian Ionescu-Idbohrn wrote: On Sun, 3 Mar 2013, John Paul Adrian Glaubitz wrote: The license issue was just an example (hence the braces). The reasoning is that the Debian packaging is supposed to be independent of upstream, especially since we cannot always follow upstream, during a freeze, for example. Assume we have version 3.0 in Debian and upstream has 3.5 and we're frozen. During the freeze, someone discovers a nasty bug in subsurface which is considered RC (release critical) in Debian, but gets fixed in 3.5.1 upstream. What about upstream keeping stuff on release branches (3.0, 3.0.2, 3.5, and so on)? And doing that sort of backporting patches themselfs? How much would that help with packaging? Yes, but that would always mean Debian somehow depends on upstream which is not really a desired situation. As I said, we cannot always keep up with upstream for various reasons. Debian-specific changes through patches are not uncommon and it doesn't always make sense to adopt the changes upstream. Debian packaging should only be part of the upstream repository if the package is Debian-native, e.g. it has its origin in Debian. Like dpkg or apt, for example. You can recognize these packages from the missing -n (n being a natural numner) in the version number. I am aware that you could probably avoid this problem with branches, but I think it would just make things difficult. Debian cannot simply be up-to-date with upstream and thus upstream shouldn't maintain the Debian-specific part. Alright. Package maintenence stuff separated from upstream source stuff. Did I get that right? I'd recommend that, yes. As for the current situation, I'd recommend getting the current upstream version of subsurface ready for Debian and have it uploaded into experimental. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5133c38d.3040...@physik.fu-berlin.de
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
On Sun, 3 Mar 2013, John Paul Adrian Glaubitz wrote: > > The license issue was just an example (hence the braces). The reasoning is > that the Debian packaging is supposed to be independent of upstream, > especially since we cannot always follow upstream, during a freeze, for > example. > Assume we have version 3.0 in Debian and upstream has 3.5 and we're frozen. > During the freeze, someone discovers a nasty bug in subsurface which is > considered RC (release critical) in Debian, but gets fixed in 3.5.1 upstream. What about upstream keeping stuff on release branches (3.0, 3.0.2, 3.5, and so on)? And doing that sort of backporting patches themselfs? How much would that help with packaging? > I am aware that you could probably avoid this problem with branches, but I > think it would just make things difficult. Debian cannot simply be up-to-date > with upstream and thus upstream shouldn't maintain the Debian-specific part. Alright. Package maintenence stuff separated from upstream source stuff. Did I get that right? Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1303032210170.11...@znkvzvyvna.pvv.fr
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
John Paul Adrian Glaubitz writes: > > On 03/03/2013 08:33 PM, Dirk Hohndel wrote: >> Would you consider adding one of the active contributors to Subsurface >> as a co-maintainer? This is currently a really fast moving project >> (3.0.2 will come out tonight or tomorrow, 3.1 is planned for next month) >> and it might be easier to have someone who is part of the developer team >> helping out with the packaging (this is what we are doing on several of >> the other distributions). > > If someone from the Subsurface project is actually willing to step up > and help, it would be a great idea. I highly encourage > co-maintainership, especially since help will be coming from upstream. > > I'd also be happy to review and sponsor any uploads. We have several people who offered to step up, a couple of them are copied on this email... >> PS: would it be useful for me to include the Debian packaging files in >> the git tree? we have an ancient version under packaging/debian but I'll >> be happy to update those if you are interested. > > Well, no, I actually would not advise doing that. Debian usually prefers > doing the packaging on its own, especially since when there are > sometimes (license) issues which make the software not comply with the > DFSG (which I am not assuming in this case). We are 100% GPLv2 so I don't think this would pose a problem, but I'm fine with that and will instead remove the outdated files from the sources to avoid confusion. > A great place for maintaining the packaging for Debian is github, for > example. Well - I run my own git server at git.hohndel.org but we can use whatever works for the packaging. > In any case, I'd be happy to help with sponsoring. Thanks /D -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303115109.883220.fmu31...@air.gr8dns.org
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
On 03/03/2013 08:51 PM, Dirk Hohndel wrote: I'd also be happy to review and sponsor any uploads. We have several people who offered to step up, a couple of them are copied on this email... Great. Just in case ;). PS: would it be useful for me to include the Debian packaging files in the git tree? we have an ancient version under packaging/debian but I'll be happy to update those if you are interested. Well, no, I actually would not advise doing that. Debian usually prefers doing the packaging on its own, especially since when there are sometimes (license) issues which make the software not comply with the DFSG (which I am not assuming in this case). We are 100% GPLv2 so I don't think this would pose a problem, but I'm fine with that and will instead remove the outdated files from the sources to avoid confusion. The license issue was just an example (hence the braces). The reasoning is that the Debian packaging is supposed to be independent of upstream, especially since we cannot always follow upstream, during a freeze, for example. Assume we have version 3.0 in Debian and upstream has 3.5 and we're frozen. During the freeze, someone discovers a nasty bug in subsurface which is considered RC (release critical) in Debian, but gets fixed in 3.5.1 upstream. Now, since we'd be in freeze, uploading the new version 3.5.1 into unstable to fix the problem in testing would not be possible. Instead, the fix would have to be backported to 3.0 and fixed in the Debian packaging. If the Debian packaging would be part of upstream, backporting the bug would be a bit difficult since the fix would be realized as a patch in the debian/patches directory which wouldn't apply if upstream was already at 3.5.1 (which includes the fix naturally) and the official Debian packaging (which is at 3.0) would be part of the upstream repository. I am aware that you could probably avoid this problem with branches, but I think it would just make things difficult. Debian cannot simply be up-to-date with upstream and thus upstream shouldn't maintain the Debian-specific part. A great place for maintaining the packaging for Debian is github, for example. Well - I run my own git server at git.hohndel.org but we can use whatever works for the packaging. Sure, that was just a suggestion. I'd just keep it independent from upstream. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5133abaa.4000...@physik.fu-berlin.de
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
Khalid El Fathi writes: > Hi, > > Sorry to answer only now... I was busy with my work. I think I can update the > package soon. That's great news. Would you consider adding one of the active contributors to Subsurface as a co-maintainer? This is currently a really fast moving project (3.0.2 will come out tonight or tomorrow, 3.1 is planned for next month) and it might be easier to have someone who is part of the developer team helping out with the packaging (this is what we are doing on several of the other distributions). Just a suggestion. /D PS: would it be useful for me to include the Debian packaging files in the git tree? we have an ancient version under packaging/debian but I'll be happy to update those if you are interested. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303113324.466293.fmu31...@air.gr8dns.org
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
Hi, On 03/03/2013 08:33 PM, Dirk Hohndel wrote: Would you consider adding one of the active contributors to Subsurface as a co-maintainer? This is currently a really fast moving project (3.0.2 will come out tonight or tomorrow, 3.1 is planned for next month) and it might be easier to have someone who is part of the developer team helping out with the packaging (this is what we are doing on several of the other distributions). If someone from the Subsurface project is actually willing to step up and help, it would be a great idea. I highly encourage co-maintainership, especially since help will be coming from upstream. I'd also be happy to review and sponsor any uploads. PS: would it be useful for me to include the Debian packaging files in the git tree? we have an ancient version under packaging/debian but I'll be happy to update those if you are interested. Well, no, I actually would not advise doing that. Debian usually prefers doing the packaging on its own, especially since when there are sometimes (license) issues which make the software not comply with the DFSG (which I am not assuming in this case). A great place for maintaining the packaging for Debian is github, for example. In any case, I'd be happy to help with sponsoring. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5133a663.2090...@physik.fu-berlin.de
Re: Bug#701964: RFP: python-v8 -- python interface for the v8 javascript engine
Joost, On 03/01/2013 09:51 AM, Joost Yervante Damad wrote: >Package name: python-v8 > Version: 1.0-preview-r446 > Upstream Author: Xiaohai Lu > URL: http://code.google.com/p/pyv8/ > License: APL2.0 > Description: python interface for the v8 javascript engine I took a quick look. Using the plain setup.py distutils based build script, a build automatically checks out v8 and gpy (via svn). Both of these are packaged for Debian already. From a manageability and security standpoint, it's not feasible for python-v8 to "include" v8 (or gpy), but it should rely on libv8 as provided by Debian. That, however, doesn't seem feasible because pyv8 interfaces with v8::internal, a namespace that's not (or not completely) exposed by libv8 - for good reasons, as its name suggests. Thus, I'd currently argue that the upstream package isn't up to Debian standards. I considered, but decided against (trying to) package this piece of software. However, I'm a) not a DD and b) maybe others find a way to make libv8 work with python-v8. Regards Markus Wanner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5133a41b.6080...@bluegap.ch
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
Hi, Sorry to answer only now... I was busy with my work. I think I can update the package soon. Sincerely, Le 3 mars 2013 à 18:36, Cristian Ionescu-Idbohrn a écrit : > On Sun, 3 Mar 2013, John Paul Adrian Glaubitz wrote: >> >>> The maintainer seems MIA since June 2012, not responding to bug >>> reports nor direct mails. >>> The two most recent upstream releases not packaged. >> >> Why would this be a reason to *remove* a package? Especially after >> such a short time. The package hasn't even been orphaened. > > Well, "short time" is relative to how slow/fast things move. In this > case, upstream is _not_ moving slow, I would say :) > >> I have seen packages in Debian which haven't received updates from the >> maintainer after much longer periods. > > True, but let's not focus too much on that, please. This is a little bit > different. Dirk, Linus and many more working with upstream are pushing > things forward at higer pace than average. > >> This doesn't necessarrialy mean the maintainer is MIA. > > True. But nothing happened for many moons :) > >> Debian is run by volunteers and sometimes, people are busy with more >> important things in life. > > Aren't we all? Volunteers and trying to also cope with the "important > things in life"? The good thing with such a large community is that > there's a lot of backup. > >> This doesn't mean that anyone has the right to immediately remove their >> packages from Debian. > > True. But that doesn't mean either everyone is happy seeing things > stalling? > >> I suppose Khalid will be happy to continue to work on the package >> again once he finds the time. > > I certainly hope so. But, unfortunatelly, there was no sign of life from > Khalid for a, relatively, long time. No RFHs either, AFAICT. > >> I don't see any need (and I think it's impolite) to pressure him in such >> a way. > > I appologise, in that case. But that was not my intent. My intent is to > find a debian maintainer/developer that has the time to work on these 2 > packages. > > > Cheers, > > -- > Cristian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f2c5e82b-6aac-402b-a557-801174a01...@elfathi.fr
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
On Sun, 3 Mar 2013, John Paul Adrian Glaubitz wrote: > > > The maintainer seems MIA since June 2012, not responding to bug > > reports nor direct mails. > > The two most recent upstream releases not packaged. > > Why would this be a reason to *remove* a package? Especially after > such a short time. The package hasn't even been orphaened. Well, "short time" is relative to how slow/fast things move. In this case, upstream is _not_ moving slow, I would say :) > I have seen packages in Debian which haven't received updates from the > maintainer after much longer periods. True, but let's not focus too much on that, please. This is a little bit different. Dirk, Linus and many more working with upstream are pushing things forward at higer pace than average. > This doesn't necessarrialy mean the maintainer is MIA. True. But nothing happened for many moons :) > Debian is run by volunteers and sometimes, people are busy with more > important things in life. Aren't we all? Volunteers and trying to also cope with the "important things in life"? The good thing with such a large community is that there's a lot of backup. > This doesn't mean that anyone has the right to immediately remove their > packages from Debian. True. But that doesn't mean either everyone is happy seeing things stalling? > I suppose Khalid will be happy to continue to work on the package > again once he finds the time. I certainly hope so. But, unfortunatelly, there was no sign of life from Khalid for a, relatively, long time. No RFHs either, AFAICT. > I don't see any need (and I think it's impolite) to pressure him in such > a way. I appologise, in that case. But that was not my intent. My intent is to find a debian maintainer/developer that has the time to work on these 2 packages. Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1303031809350.11...@znkvzvyvna.pvv.fr
Re: Subsurface maintaince in Debian [was Re: Bulding 3.0.1 Under Ubuntu 10.04 i386]
On Sun, 3 Mar 2013, Sylvestre Ledru wrote: > > As a Debian Developer and as a professional diver, I am interested to > help on this. That sounds great. Thanks for volunteering. > I have been in touch with Khalid to help him on this and he replied: > "No problem for to co-maintaince > > I'm sorry, but I've been very busy the last few months. > " > > As Christian proposed, I am sure we can be move this package in the > sport team. By all means. Will join that list shortly. Would you, please, do the honors ;) > Cristian, if you want, we can work together to improve the package and > maintain new releases for Jessie. Of course. Which means new packages will go to unstable/experimental. Would it be possible to make back-porting to wheezy as painless as possible? But, bare in mind, although I can often find my way around debian packages, I'm neither a maintainer nor a developer. But I'll try to do whatever I can. I hope some other people on the subsurface list want to help too. > FYI, I reported some bugs on these two packages: > http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libdivecomputer Adding a symbol list file may probably be a good idea, I guess, bu you know better. > http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=subsurface Yes. I read the comments. The upstream maintainers expressed their wish to have subsurface statically built against libdivecomputer, as ABI changes occured frequently, but if you think package maintenance is easier with shared linking, I'm almost sure there'll not be too many protests :) Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1303031735530.11...@znkvzvyvna.pvv.fr
Re: git dangerous operations on alioth
On Sun, Mar 3, 2013 at 11:21 PM, Thomas Goirand wrote: > So yes, I would think having a safe, backup of Alioth is important. > Now, what worries me is that I didn't read any of the Alioth admins > explaining what is currently in production. I've searched, and the > only info I found was hosted projects on alioth.d.o (like pkg-bacula, > slbackup, etc.), but so far, no info on how Alioth is backed-up. Did > I miss the obvious? Take a look at /etc/da-backup*, alioth is backed up to backup.d.o like all debian.org hosts. -- bye, pabs http://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: http://lists.debian.org/CAKTje6HhDOGZhqDYY3hE7Ehdrtjhe_5G0=2ww_rwt-wh6lg...@mail.gmail.com
Re: git dangerous operations on alioth
On 03/01/2013 02:20 AM, Daniel Pocock wrote: > > DD access is also an `all or nothing' scenario, and it is tightly > controlled in other ways. > > What I was anticipating is how we can provide more access for upstreams > and other non-DDs using the guest account mechanism or potentially some > kind of non-UNIX level access > > To give one example, one of my packages fails to build with clang due to > some other header file in package foo. Somebody actually uploaded a fix > for foo onto mentors long before the freeze, but it got no further. It > leaves me feeling that the DD community could benefit from more > automated ways to ramp up new members and accept their contributions, > but that would also mean taking the sharp edges off some things. As already stated by someone else, something like Gerrit would do what you ask for above. If anyone from the fusionforge project feels like integrating with Gerrit (or anything of the same kind which can have some kind of review- before-merge feature) that'd be really nice. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51336b5e.7050...@debian.org
Re: git dangerous operations on alioth
On 03/03/2013 12:51 AM, Wouter Verhelst wrote: > On Thu, Feb 28, 2013 at 11:07:22AM +0100, Stefano Zacchiroli wrote: >> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote: >>> Has anybody had experience controlling access to git repositories, for >>> example, to give users access but prevent some of the following >>> dangerous operations? >> Related to this, there is also the risk that a user will ssh on alioth >> and rm the repository (accidentally or not). Do we have any kind of >> protection against that? (e.g. backups we can access to without >> bothering the alioth admins, or a way to give git access but not ssh >> access, or...) > "real men don't take backups. They just put their stuff on a public FTP > server and let the world mirror." > > Every user who has a checkout of a git repository is making backups... If Alioth was to fail and loose all repository data, I would have a real hard time to collect all local copies, with the latest version given a specific branch, being stored in one of the 3 machines I do Debian packaging on. It would take me literally days to find out on which of these computers I made the latest commit (I generally don't care, Git always yell^Wtell if I don't have a fast-forward copy anyway). I also read that others have the habit to *not* store a local copy of the packages they work on. Once the commit is done, they just delete the local copy. That's not my workflow, but I can understand why doing that. So yes, I would think having a safe, backup of Alioth is important. Now, what worries me is that I didn't read any of the Alioth admins explaining what is currently in production. I've searched, and the only info I found was hosted projects on alioth.d.o (like pkg-bacula, slbackup, etc.), but so far, no info on how Alioth is backed-up. Did I miss the obvious? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51336a5c.9090...@debian.org
Re: Bulding 3.0.1 Under Ubuntu 10.04 i386
Quoting Cristian Ionescu-Idbohrn (cristian.ionescu-idbo...@axis.com): > Yes, I finally found that list (it's pkg-running-devel, isn't it?) and I > had a look. Sadly, it looks more like a spam-box than a development > mailinglist. Can anything be done about that? I'd gladly join that list > if that would help to push the packaging work ahead. pkg-running-de...@lists.alioth.debian.org, indeed. Spam box? Well, it's an opened mailing list (because it is set as Maintainer for several packages and therefore is the place where bug reports are received)so like opened mailing lists, it gets spam. I indeeed didn't notice that mostly because I have some good spam filtering software running on my box, which easily identifies spams such as those you can see in the ML archive. Still, this mailing list (and the relevant group on alioth.debian.org) is used for several sports-related packages maintenanceso it might be a good place to start with. signature.asc Description: Digital signature
Re: Bug#701536: RM: subsurface -- RoQA; unmaintained package, maintainer MIA
> The maintainer seems MIA since June 2012, not responding to bug > reports nor direct mails. > The two most recent upstream releases not packaged. Why would this be a reason to *remove* a package? Especially after such a short time. The package hasn't even been orphaened. I have seen packages in Debian which haven't received updates from the maintainer after much longer periods. This doesn't necessarrialy mean the maintainer is MIA. Debian is run by volunteers and sometimes, people are busy with more important things in life. This doesn't mean that anyone has the right to immediately remove their packages from Debian. I suppose Khalid will be happy to continue to work on the package again once he finds the time. I don't see any need (and I think it's impolite) to pressure him in such a way. Regards, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303120604.ga18...@physik.fu-berlin.de
Bug#702166: ITP: esteidpkcs11loader -- Loads pkcs#11 module for web authentication with smart cards
Package: wnpp Severity: wishlist Owner: "Siim Põder" * Package name: esteidpkcs11loader Version : 3.7.0 Upstream Author : RIA * URL : http://www.ria.ee/ * License : LGPL 2.1 Programming Lang: javascript Description : Loads pkcs#11 module for web authentication with smart cards Helper that loads the appropriate pkcs11 module for authentication in browser with smart cards, in particular with Estonian ID card. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303114418.17063.11375.report...@djembe.p6drad-teel.net
Bug#702165: ITP: ruby-georuby -- Ruby data holder for OGC Simple Features
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: ruby-georuby Version : 2.0.0-1 Upstream Author : Guilhem Vellut * URL : http://georuby.rubyforge.org/ * License : Expat Programming Lang: Ruby Description : Ruby data holder for OGC Simple Features -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303114313.16112.26199.report...@chris-desktop.home
Bug#702164: ITP: esteidcerts -- Estonian ID card root, intermediate and OCSP certificates
Package: wnpp Severity: wishlist Owner: "Siim Põder" * Package name: esteidcerts Version : 3.7.0 Upstream Author : RIA * URL : http://www.ria.ee/ * License : LGPL 2.1 Programming Lang: certificates Description : Estonian ID card root, intermediate and OCSP certificates Certificates to verify certificates Estonian ID cards -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303113946.16798.46687.report...@djembe.p6drad-teel.net
Subsurface maintaince in Debian [was Re: Bulding 3.0.1 Under Ubuntu 10.04 i386]
On 01/03/2013 00:13, Cristian Ionescu-Idbohrn wrote: > On Thu, 28 Feb 2013, Robert Wolfe wrote: >> >> Um, forgot about me already, hmm? :) > > But, of course not. Do you want to be Cc:ed? > >> And yes, libdivecomputer-3.0.1 in .DEB format > > That should probably be: > > subsurface-3.0.1 and > libdivecomputer-0.3.0 > > I presume. Can you make the source packages available too to Dmitrijs? > It's: > > subsurface_3.0.1-x.debian.tar.gz and > libdivecomputer_0.3.0-x.debian.tar.gz > > or similar, I'm thinking about. > > Dmitrijs, > > Old debian source packages (subsurface-1.2-1 and libdivecomputer-0.1.0), > could also be of some value. > > I'm really looking forward to see latest subsurface/libdivecomputer in > debian, as soon as it can be done. It'll most probably be unstable, but > Dmitrijs, could you please try to make them as painless as possible > portable to wheezy? As a Debian Developer and as a professional diver, I am interested to help on this. I have been in touch with Khalid to help him on this and he replied: "No problem for to co-maintaince I'm sorry, but I've been very busy the last few months. " As Christian proposed, I am sure we can be move this package in the sport team. Cristian, if you want, we can work together to improve the package and maintain new releases for Jessie. FYI, I reported some bugs on these two packages: http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libdivecomputer http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=subsurface Sylvestre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51333478@debian.org
Bug#702162: ITP: estonianidcard -- Metapackage installing all the packages for Estonian ID card support
Package: wnpp Severity: wishlist Owner: "Siim P�der" * Package name: estonianidcard Version : 3.7.0: Upstream Author : ria * URL : http://www.ria.ee/ * License : LGPL 2.1 Programming Lang: metapackage Description : Metapackage installing all the packages for Estonian ID card support Installs qesteidutil, qdigidoc, esteidfirefoxplugin and esteidpkcs11loader -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303104003.12001.33930.report...@djembe.p6drad-teel.net
Bug#702161: ITP: ruby-dbf -- small fast Ruby library for reading database files
Package: wnpp Severity: wishlist Owner: Christopher Baines * Package name: ruby-dbf Version : 2.0.3 Upstream Author : Keith Morrison * URL : http://github.com/infused/dbf * License : Expat Programming Lang: Ruby Description : small fast Ruby library for reading database files -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130303104546.5568.6892.report...@chris-desktop.home
Re: Bulding 3.0.1 Under Ubuntu 10.04 i386
Please keep me on the Cc: list, as I'm not subscribed. Sorry :( I have to pick this up again, as I screwed up last time and not much happened since I started this thread. Won't bother the subsurface mailing list with debian packaging details. On Fri, 1 Mar 2013, Christian PERRIER wrote: > > > Old debian source packages (subsurface-1.2-1 and libdivecomputer-0.1.0), > > could also be of some value. > > > > I'm really looking forward to see latest subsurface/libdivecomputer in > > debian, as soon as it can be done. It'll most probably be unstable, but > > This thread is interesting. I faced about the same challenges when > working on packaging pYtrainer for Debian (Pytrainer is a Python > application for sports tracking, mostly used by runners and bikers). Thanks for the insight. Yeah, it seems to be very difficult to find someone interested of packaging this stuff and also _work_ it :( Last offer came from Dmitrijs. Are you still willing to do the packiging work Dmitrijs? > That was the point : doing the work in Debian guaranteed that our > quality criteria did benefit to the quality of the resulting packages > and this, up to derived distro users. > > There are certainly probably 10, or 20, or 30 more users of Pytrainer > packages on Ubuntu systems than Debian systems. But, indeed, all those > can use this nice software because we did prepare the packages with > our Debian "culture" in mind (the original culprit for these packages > is Noèl Köthe, not me, by the way). Yes, those were my thoughts too when I brought subsurface up. > So, yes, if people are interested in getting this diving software > ported and well-supported in many deb-based distros as possible, I > would highly recommend doing the work in Debian. Please folks, pick this up. Two easy packages to maintain, with active upstreams and very interested to make the packaging work easier. > That would even be a good way to discover that those Debian weirdos > are not all pizza eaters and beer drinkers and that some might even > dive very well, just like some Debian weirdos happen to run or bike > not so badly...:-) Yes, I'm still hoping to find an interested diver and debian developer/maintainer too, willing to pick this up. There's some interesting development here (thanks to Yannick): On Fri, 1 Mar 2013, Yannick Brosseau wrote: | | Hi, | | I'm not sure if anybody was actually working on it, but I've built | package for debian (sid) if it can be of any use for somebody. | | I only did a simple update of the packaging currently available in debian. | | The packaging git are here: | http://git.dorsal.polymtl.ca/~ybrosseau?p=pkg-libdivecomputer | http://git.dorsal.polymtl.ca/~ybrosseau?p=pkg-subsurface | | And the files: | http://www.dorsal.polymtl.ca/~ybrosseau/debian/libdivecomputer-dev_0.3.0-1_amd64.deb | http://www.dorsal.polymtl.ca/~ybrosseau/debian/libdivecomputer0_0.3.0-1_amd64.deb | http://www.dorsal.polymtl.ca/~ybrosseau/debian/subsurface_3.0.1-1_amd64.deb | The rest of the source are available: | http://www.dorsal.polymtl.ca/~ybrosseau/debian/ AFAICT, those packages need some small polishing work. > How about joining the pkg-running umbrella? It's quite some time that > stuff we maintain in this team is more "sport stuff" than "running > stuff" anyway. Yes, I finally found that list (it's pkg-running-devel, isn't it?) and I had a look. Sadly, it looks more like a spam-box than a development mailinglist. Can anything be done about that? I'd gladly join that list if that would help to push the packaging work ahead. Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1303031027450.11...@znkvzvyvna.pvv.fr
