Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package mininet: * Package name: mininet Version : 2.2.0 Upstream Author : Bob Lantz et al. * URL : http://mininet.org/ * License : BSD-like (mininet-license) Section : net It builds those binary packages: mininet - process-based network emulator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mininet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mininet/mininet_2.2.0-1.dsc More information about hello can be obtained from http://www.mininet.org. Notes: * the package was difficult to prepare for reasons related to open vswitch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757761; the bug was workarounded and the new version does not require Openswitch controller in the system (it will degrade to pure software switch, see: https://github.com/mininet/mininet/pull/432) Regards, T. Buchert -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150112133034.ga24...@buchert.pl
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
On 12/01/15 15:03, Vincent Bernat wrote: ❦ 12 janvier 2015 14:30 +0100, Tomasz Buchert tomasz.buch...@inria.fr : It builds those binary packages: mininet - process-based network emulator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mininet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mininet/mininet_2.2.0-1.dsc More information about hello can be obtained from http://www.mininet.org. In Ubuntu, the package is maintained by James Page. I pinged him a week ago about packaging it in Debian but got no answer. Your package seems an original work. Did you try to reach James about that? Did you look at how the problems you got have been solved in this version? Hi Vincent, I don't quite remember if I have met James electronically yet. I know, however, that Ubuntu packaging of openvswitch provided openvswitch-controller which solved the problem for them. This is described in the bug #757761. About the package: - in d/control, you recommend openvswitch-controller but no such package exists in Debian. Thanks, my bad. - in d/copyright, you license debian/* under GPL-2+ but since the original software is licensed as MIT, it would be better to use the same license. This allows upstream to integrate your changes more easily. That makes sense. However, the license is *not* MIT literally speaking (https://mailman.stanford.edu/pipermail/mininet-discuss/2014-August/004879.html). I renamed the license to mit-mininet-license and used the same license for debian/* as you proposed. - in d/copyright, the license is MIT with a preface, just use MIT as the keyword (but keep the whole license). See above. - in d/repack, why is this script here if not used? Well spotted. I removed it (note, however, that there is a comment at the beginning saying that it may be used one day). - in d/rules, you use python_distutils as a build system, this will call python setup.py clean in dh_auto_clean, not make clean. This explains why you have to use make clean. As for CPPFLAGS, this is because the Makefile don't include it. I think both of your fixes are fine. Ok, I removed todos. - d/TODO should be removed if those problems are solved. Done. I have not tested the result, but the package looks good otherwise. I've just reuploaded the package to mentors. It should be visible in few minutes. Thanks a lot, Tomasz -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150112144345.ga27...@buchert.pl
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
❦ 12 janvier 2015 14:30 +0100, Tomasz Buchert tomasz.buch...@inria.fr : It builds those binary packages: mininet - process-based network emulator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mininet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mininet/mininet_2.2.0-1.dsc More information about hello can be obtained from http://www.mininet.org. In Ubuntu, the package is maintained by James Page. I pinged him a week ago about packaging it in Debian but got no answer. Your package seems an original work. Did you try to reach James about that? Did you look at how the problems you got have been solved in this version? About the package: - in d/control, you recommend openvswitch-controller but no such package exists in Debian. - in d/copyright, you license debian/* under GPL-2+ but since the original software is licensed as MIT, it would be better to use the same license. This allows upstream to integrate your changes more easily. - in d/copyright, the license is MIT with a preface, just use MIT as the keyword (but keep the whole license). - in d/repack, why is this script here if not used? - in d/rules, you use python_distutils as a build system, this will call python setup.py clean in dh_auto_clean, not make clean. This explains why you have to use make clean. As for CPPFLAGS, this is because the Makefile don't include it. I think both of your fixes are fine. - d/TODO should be removed if those problems are solved. I have not tested the result, but the package looks good otherwise. -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Re: best way to fork data only package on Alioth?
On Mon, Jan 12, 2015 at 08:25:41AM +0800, Paul Wise wrote: On Sun, Jan 11, 2015 at 11:32 AM, Paul Elliott wrote: ... Your mail doesn't include which package/data you are talking. It is very hard to give you correct advice when we aren't being given the necessary information about the situation we are responding to. I want to create a new package that is identical to the old one except that 1) the name of the package is changed. 2) the data files and their names are changed. What is the reason for wanting the new package? It sounds unnecessary. Would it be a reasonable way to proceed to fork the old package? Create a meta-package depending on the old package and containing symlinks to the old data files. The new package contains data most people won't want. It is big. 69M But those who need this data, need it. By creating a different package, I give the majority the default of opting out, while giving the few the chance to get the data they need. The new package contains ephermis extrapolated data for far past, and far future dates. Researchers can use this data for astronomical historic research like determining the date of the Mahabarata war. I had already decided on the new package. I was asking about the best way to technical way to execute the fork. The Old package is swe-standard-data, new will be swe-extrapolated-data. (Now in progress). -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: Digital signature
Bug#775097: marked as done (RFS: qmapshack/0.10.0-1~exp1)
Your message dated Mon, 12 Jan 2015 20:14:23 + with message-id e1yalnx-0003n7...@quantz.debian.org and subject line closing RFS: qmapshack/0.10.0-1~exp1 has caused the Debian Bug report #775097, regarding RFS: qmapshack/0.10.0-1~exp1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 775097: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775097 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package qmapshack Package name: qmapshack Version : 0.10.0-1~exp1 Upstream Author : Oliver Eichler oliver.eich...@gmx.de URL : https://bitbucket.org/maproom/qmapshack/wiki/Home License : GPL-3+ Section : science It builds those binary packages: qmapshack - GPS mapping (GeoTiff and vector) and GPSr management To access further information about this package, please visit the following URL: http://mentors.debian.net/package/qmapshack Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/q/qmapshack/qmapshack_0.10.0-1~exp1.dsc More information about QMapShack can be obtained from https://bitbucket.org/maproom/qmapshack/wiki/Home. Changes since the last upload: * New upstream release. * Add path to fix 'artificial' typo. Regards, Bas Couwenberg ---End Message--- ---BeginMessage--- Package qmapshack version 0.10.0-1~exp1 is in experimental now. http://packages.qa.debian.org/qmapshack---End Message---
Bug#775043: marked as done (RFS: pyepr/0.8.2-1)
Your message dated Mon, 12 Jan 2015 20:14:21 + with message-id e1yalnv-0003mw...@quantz.debian.org and subject line closing RFS: pyepr/0.8.2-1 has caused the Debian Bug report #775043, regarding RFS: pyepr/0.8.2-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 775043: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775043 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package pyepr: * Package name: pyepr Version : 0.8.2-1 Upstream Author : Antonio Valentino antonio.valent...@tiscali.it * URL : http://avalentino.github.com/pyepr * License : GPL-3.0+ Section : python It builds those binary packages: python-epr - Python ENVISAT Product Reader API (Python 2) python-epr-dbg - Python ENVISAT Product Reader API (debug extension for Python 2) python-epr-doc - Python ENVISAT Product Reader API (common documentation) python3-epr - Python ENVISAT Product Reader API (Python 3) python3-epr-dbg - Python ENVISAT Product Reader API (debug extension for Python 3) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pyepr Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pyepr/pyepr_0.8.2-1.dsc More information about pyepr can be obtained from http://avalentino.github.io/pyepr. Changes since the last upload: * New upstream release * debian/control - added an explicit build dependency from dh-python - Standard version bumped to 3.9.6 (no changes) - fix Vcs-Browser URL * debian/patches - updated 0001-Only-use-local-files-for-generating-sphinx-doc.patch: do not include links to the ohloh and travis-ci widgets Regards -- Antonio Valentino ---End Message--- ---BeginMessage--- Package pyepr version 0.8.2-1 is in unstable now. http://packages.qa.debian.org/pyepr---End Message---
Re: best way to fork data only package on Alioth?
On Tue, Jan 13, 2015 at 12:55:29PM +0800, Paul Wise wrote: On Mon, Jan 12, 2015 at 6:28 PM, Paul Elliott wrote: The new package contains data most people won't want. It is big. 69M But those who need this data, need it. By creating a different package, I give the majority the default of opting out, while giving the few the chance to get the data they need. The new package contains ephermis extrapolated data for far past, and far future dates. Researchers can use this data for astronomical historic research like determining the date of the Mahabarata war. I had already decided on the new package. I was asking about the best way to technical way to execute the fork. The Old package is swe-standard-data, new will be swe-extrapolated-data. (Now in progress). Could you explain how these two data sets relate to each other? Is swe-standard-data a strict subset of swe-extrapolated-data? If so I would say make swe-extrapolated-data depend on swe-standard-data. Or are the two packages have some data in common and some unique data in each of them? If so I would split the data up into three sets, swe-core-data/swe-standard-data/swe-extrapolated-data. The data is in the same format and used by libraries linked to libswe0. The two sets of data are disjoint. The data one would want depends on the time one is studying. A researcher reasoning about the putitive 5561BC date of the Mahabarata war might want only swe-extrapolated-data. An astrologer doing horiscopes for modern clients would want only swe-standard-data. From the README file: The swe-extrapolated-data package contains only data files for the periods: 11 Aug 13000 BC to 5402 BC and 5400 AD to 7 Jan 16800 AD such data is not usually needed by people not doing extraordinary research. In terms of git repositories, I would only put the debian/ dirs in git. -- bye, pabs https://wiki.debian.org/PaulWise -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: Digital signature
Need Help
Hi I have tried to create a local debian package in my machine .After typing fakeroot dpkg-buildpackage -F I have encountered these error .Please give me a guidance to overcome this error... make: *** [clean] Error 2 dpkg-buildpackage: error: debian/rules clean gave error exit status 2 Thank you Nandaraj.ks
Bug#773861: Signify - OpenBSD's cryptographic signing tool
On 12/01/15 12:37, Brian White wrote: I don't maintain Signify it any longer (or even use it) so feel free to do with it whatever you like. Hmm... does that mean that I need to adopt signify before signify-openbsd will be accepted? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b4c4b7.8030...@bitmessage.ch
Re: best way to fork data only package on Alioth?
On Mon, Jan 12, 2015 at 6:28 PM, Paul Elliott wrote: The new package contains data most people won't want. It is big. 69M But those who need this data, need it. By creating a different package, I give the majority the default of opting out, while giving the few the chance to get the data they need. The new package contains ephermis extrapolated data for far past, and far future dates. Researchers can use this data for astronomical historic research like determining the date of the Mahabarata war. I had already decided on the new package. I was asking about the best way to technical way to execute the fork. The Old package is swe-standard-data, new will be swe-extrapolated-data. (Now in progress). Could you explain how these two data sets relate to each other? Is swe-standard-data a strict subset of swe-extrapolated-data? If so I would say make swe-extrapolated-data depend on swe-standard-data. Or are the two packages have some data in common and some unique data in each of them? If so I would split the data up into three sets, swe-core-data/swe-standard-data/swe-extrapolated-data. In terms of git repositories, I would only put the debian/ dirs in git. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6edb5kedwvf3y7el_ldgnmtfz5-3xa5r8fy_n+b9qn...@mail.gmail.com
Re: best way to fork data only package on Alioth?
On Tue, Jan 13, 2015 at 1:17 PM, Paul Elliott wrote: The two sets of data are disjoint. Your initial mail made it sound like two packages have data in common. Since they actually have no data in common, I'm not sure why forking is needed. If you are wondering about forking the debian/ dir, just copy it to a new git empty repository, delete and recreate debian/changelog, done. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6EenSh6VHgY86PCHH=j=l94jxyn4andbx928nhqsyq...@mail.gmail.com
Re: Need Help
On Tue, Jan 13, 2015 at 2:19 PM, Nandaraj Ks wrote: I have tried to create a local debian package in my machine .After typing fakeroot dpkg-buildpackage -F I have encountered these error .Please give me a guidance to overcome this error... make: *** [clean] Error 2 dpkg-buildpackage: error: debian/rules clean gave error exit status 2 Please provide the full build output, what you have provided is not enough to figure out what went wrong. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gxtpqnypph0hvevh_t+_apbpcmoxqyblthx-r0rwu...@mail.gmail.com
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
❦ 12 janvier 2015 15:43 +0100, Tomasz Buchert tomasz.buch...@inria.fr : - in d/copyright, you license debian/* under GPL-2+ but since the original software is licensed as MIT, it would be better to use the same license. This allows upstream to integrate your changes more easily. That makes sense. However, the license is *not* MIT literally speaking (https://mailman.stanford.edu/pipermail/mininet-discuss/2014-August/004879.html). I renamed the license to mit-mininet-license and used the same license for debian/* as you proposed. Well, the binding parts of the license is the MIT license (this is what you also said in the mailing post, isn't it?). This is a bit like the preface for the GPL license. This is not the license, but we still say this is the GPL. It explains the motivation. So, like for GPL, I think that you should say this is MIT but keep the whole text (unlike GPL which is present in base-files). I just think that by using a dedicated keyword, this would make people (or programs) think that this is a MIT-derivative (with more conditions or some exception) while this is not the case. Oh, and we say MIT, but the right keyword is Expat. Sorry. I have not tested the result, but the package looks good otherwise. I've just reuploaded the package to mentors. It should be visible in few minutes. I'll try the package later. -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html signature.asc Description: PGP signature
Re: git-p4 package in contrib, how to proceed?
reassign 773245 src:git 1:2.1.3-1 quit Vincent Cheng wrote: Yes, source packages in main can generate binary packages in contrib; Policy does not prevent this from happening, and there are existing source packages in main, in the archive, which generate binary packages in contrib. See e.g. src:nvidia-settings (and #747837 which was what prompted one of the binary packages built from it to be moved from contrib to main). Thanks for looking into it. I'll apply the patch for git in jessie+1. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150112183244.gy29...@google.com
