Re: blocked migration from unstable to testing: old binaries left
On 2015-06-19 02:48, Jerome BENOIT wrote: > Hello, > > thanks for your prompt reply. > > On 18/06/15 14:55, Paul Wise wrote: >> On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: >> >>> what am I supposed to do for unblocking ? >> >> You started a (minor) transition without involving the release team, >> please read this: >> >> https://wiki.debian.org/Teams/ReleaseTeam/Transitions >> >> According to the cruft report, the old binaries can't be removed >> because ovito build-depends on libtachyon-dev. You'll need to convince >> the ovito maintainers to switch to the new tachyon dev packages. >> >> https://ftp-master.debian.org/cruft-report-daily.txt >> > > Will a dummy libtachyon-dev package solve the problem ? > > Thanks, > Jerome > > Yes, provided it depends on the correct -dev packages. Though it might have to go through NEW at this point. At this junction, it /may/ be easier to just update ovito as it is the only affected reverse dependency. ~Niels -- 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/5583b192.6050...@thykier.net
Re: blocked migration from unstable to testing: old binaries left
Hello, thanks for your prompt reply. On 18/06/15 14:55, Paul Wise wrote: > On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: > >> what am I supposed to do for unblocking ? > > You started a (minor) transition without involving the release team, > please read this: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > According to the cruft report, the old binaries can't be removed > because ovito build-depends on libtachyon-dev. You'll need to convince > the ovito maintainers to switch to the new tachyon dev packages. > > https://ftp-master.debian.org/cruft-report-daily.txt > Will a dummy libtachyon-dev package solve the problem ? Thanks, Jerome -- 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/558366f9.5070...@rezozer.net
Bug#789195: marked as done (RFS: sfcgal/1.1.0)
Your message dated Thu, 18 Jun 2015 23:49:11 +0200 with message-id <55833cd7.7010...@xs4all.nl> and subject line RFS: sfcgal/1.1.0 [uploaded] has caused the Debian Bug report #789195, regarding RFS: sfcgal/1.1.0 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.) -- 789195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789195 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Hello, I have just uploaded the library package sfcgal which I have been preparing after consulting debian-gis maintainers. * Package name: sfcgal Version : 1.1.0-1 Upstream Author : Mickael Borne (IGN), Hugo Mercier (Oslandia), Vincent Mora (Oslandia), Olivier Courtin (Oslandia) * URL : http://www.sfcgal.org/ * License : LGPL-2+ Section : science Sources have already been uploaded to alioth and are availabe via the following URL: git+ssh://git.debian.org/git/pkg-grass/sfcgal.git Regards Sven -- Exploits and holes are a now a necessary protection against large corporate interests. (Alan Cox) /me is giggls@ircnet, http://sven.gegg.us/ on the Web signature.asc Description: Digital signature --- End Message --- --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Sven, Thanks for your work on this package. On 06/18/2015 09:02 PM, Sven Geggus wrote: > Sources have already been uploaded to alioth and are availabe via > the following URL: > git+ssh://git.debian.org/git/pkg-grass/sfcgal.git I've sponsored the uploaded, and since the package will have to pass the NEW queue I'm closing the RFS manually. Kind Regards, Bas - -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVgzzWAAoJEGdQ8QrojUrxPxUP/3hF6/UabyXT8QEGjEPPIfxv PpUl31mxRc5iyNger6zTV3cKXjj8DrlsF67FrqzaB/GDlZIpA4wGgFMqhGfiTPDj EMep4MbQiGmc5DZ9yYF5BpE9WCpV7YITbZFtdhqgTROUYVzCzjnZLEazOh/QCHcM gvJU8VgkYecfeqsZJ9TNFoc0znkuaBgOXGYDLBo+L26bVznyujx8xbkfB5T92NkN cgufDlmc+8pn8pexDUAVIkY6O14wBA8DarNLAJg2E4veF8Ro8n0zmu0zGJ3124aq FBuK5XtZPgoXiIOVzaYPjEi27raABF5oyv5uyRtnBMSmEBL2hQ9vYedlTFSvxc9D Ov/70feeX8BAUSUKih3JPF+Bbt0XJXdEsftgqdaFjOilbaHoXxf/aIqiDjSkiklR rPr+7/T44JUUIpyLiWASmNP75w3ZbU+BEJlPTOuxm+6Ekab+LneXkwbfHdDMHKgJ MNYuEtxOkLN4zMqOB9vQoqeUOHvFa4UtL4105x3ccNxsYqdsngx61u8LmJ06J1QM qiI/TcsOmPvUwkcUTtw3uN0Tu6p10ga3cPku6Aw80o97VarbVXouuyMMy/nfZ/MB fxO0LwWc3+NZKd3WnKDiaZMXXoU5MrZKg8RTGHjQQnTChVeRTP5/esOSmP0lR/tn szcLRPlzWCLZjxz3ZaTb =R4Uu -END PGP SIGNATURE End Message ---
xvfb-run with windowmanager
Hi, I have a test script that works only in an X11 environment with window manager. How can I start this with xvfb-run, so that it works during package build and CI test? And which window manager should I choose? Best regards Ole -- 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/87wpz0aicz@debian.org
Bug#789195: RFS: sfcgal/1.1.0
Package: sponsorship-requests Severity: normal Hello, I have just uploaded the library package sfcgal which I have been preparing after consulting debian-gis maintainers. * Package name: sfcgal Version : 1.1.0-1 Upstream Author : Mickael Borne (IGN), Hugo Mercier (Oslandia), Vincent Mora (Oslandia), Olivier Courtin (Oslandia) * URL : http://www.sfcgal.org/ * License : LGPL-2+ Section : science Sources have already been uploaded to alioth and are availabe via the following URL: git+ssh://git.debian.org/git/pkg-grass/sfcgal.git Regards Sven -- Exploits and holes are a now a necessary protection against large corporate interests. (Alan Cox) /me is giggls@ircnet, http://sven.gegg.us/ on the Web signature.asc Description: Digital signature
Re: packaging Advanced Gtk+ Sequencer - automatic debian build
Hi Joël, On 06/16/2015 04:28 PM, Joël Krähemann wrote: > Hi, could someone please take a look at my repository: > > http://anonscm.debian.org/cgit/pkg-multimedia/gsequencer.git I am also a member of the multimedia team and have seen your commits rolling in. You are getting close to having something ready for sponsorship. But on a quick (not complete check) there is still some work to do (see below). > Please tell me what I have to do that it gets processed by the automatic > debian build system. Further what is still left to do so. Coming to the mentors list was a very good idea. There are many experienced guys here that can help out. The best thing to do next is to prove you can build your package by uploading the built package to the mentors website. The website will also tell any reviewer whether you have fixed all the relevant lintian errors. See here for information: https://mentors.debian.net/intro-maintainers > Note there aren't any signed tags, yet. Should I rebase and add tags for > old commits? Normal practise is to sign a tag when you import the upstream release. Then when the package is uploaded to the debian archive, there should be a signed tag for the last commit before the upload. There is information on tagging specific to the multimedia team here: https://wiki.debian.org/DebianMultimedia/DevelopPackaging > best regards > Joël Krähemann > Now for some comments: debian/changelog - Your changelog entry looks a little unfinished. It should close your ITP bug, and as it is a new package it really only needs one entry which is something like: * Initial release (Closes: #) debian/copyright - You only list the copyright for files in the debian directory. You should also list the copyright for the upstream source code. debian/debhelper.log - This file is the resulting log from a previous build of the package to help with troubleshooting. It should be deleted. debian/rules - You should remove all the unnecessary commenting. It is normally okay to leave the "verbose" option commented out so that it can be quickly added in when you are troubleshooting. Some references that you might want to read (again?): https://www.debian.org/doc/manuals/maint-guide/index.en.html https://wiki.debian.org/UpstreamGuide (* as I know you are also upstream). Keep going! Cheers, Ross signature.asc Description: OpenPGP digital signature
Re: Fwd: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Le 18/06/2015 16:16, Brandon Bradley a écrit : > Would it be OK to include the gradle wrapper jar as part of the > repo for building? I don't know the exact policy about binary artifacts > in dsc files. Also, what about including JARs not packaging directly > into the package? There is really no way to keep the wrapper or any other jar. In Debian everything has to be built from the sources, and dependencies must be packaged first. This is quite frustrating for us Java developers used to download artifacts from a Maven repository, but it turns out to be fun too if you see this as a puzzle to be assembled piece by piece. > I'm only building the 'core' subproject which depends on the 'clients' > subproject. Here is a list of runtime dependencies from running > `./gradlew -PscalaVersion=2.9.2 core:dependencies`. If you focus on a subset of Kafka that may be easier. Looking at the dependency tree it looks like the lz4 support may be disabled in favor of snappy. That would leave zkclient as the only dependency left to package. Emmanuel Bourg -- 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/5582e1d7.9020...@apache.org
Re: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
On Thu, Jun 18, 2015 at 07:44:05AM -0500, Brandon Bradley wrote: > I have multiple reasons for not contacting Wikimedia or using their work. > The possibility of them having additions for their own purposes is very > high. I believe starting fresh was easier than analyzing and debugging > their repo. Don't guess, ask :) That particular package has been prepared and is maintained by my team at the Wikimedia Foundation, which incidentally has 3 DDs (Filippo Giunchedi, Moritz Mühlenhoff and myself) in it, plus at least a couple of other people with Debian packaging expertise. At Wikimedia, we're using Kafka extensively. We're obviously very keen on pushing things upstream too, which why e.g. I already pushed our librdkafka package in Debian (already part of jessie). Vincent Bernat also worked on kafkacat (from the same upstream) which we also use, so we collaborated and now jointly comaintain each other's packages. We're definitely not trying to work in a silo :) We haven't attempted to push the "main" Kafka package to Debian, since our time was limited and the packaging was a bit hacky/get-the-job-done (e.g. replacing the complex build system that downloads jars off the Internet by a Makefile), plus, JVM packages are usually harder to maintain properly :) I've been quietly watching this ITP, though, and we would definitely be interested to join efforts and switch to better, properly maintained packages, if there is enough momentum from people that want to see this in Debian. Time is (always) limited but I'd be more than happy to review/mentor/upload. I'll also convey this whole conversation internally to my team, maybe we can pull some resources for this, if you're interested in collaborating. Best, Faidon -- 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/20150618141029.ga1...@tty.gr
Bug#775532: license of the CSL scheme files
Great! Thank you very much. Best, Daniel On 18.06.2015 16:37, Rintze Zelle wrote: > http://citationstyles.org/developers/ now says "Note. All versions of > the CSL schema have recently been relicensed under the more > permissible MIT license, and the GitHub repository will soon be > updated to reflect this change.". > > I'll add the MIT license to the repository and change the "rights" > blurb in the schema itself, but it might be a while before I get to > that. > > Rintze -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- 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/5582d8f4.7070...@danielstender.com
Re: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Hello Faidon, Thank you for coming to talk to us! And your willingness to review/mentor/upload. Glad to know Wikimedia is listening and willing to contribute. Another reason I did separate packaging work was to get the latest version of Kafka running. We can find some time in the next few weeks to discuss on IRC. Whenever is good for you. Cheers! Brandon On Thu, Jun 18, 2015 at 9:10 AM, Faidon Liambotis wrote: > On Thu, Jun 18, 2015 at 07:44:05AM -0500, Brandon Bradley wrote: > > I have multiple reasons for not contacting Wikimedia or using their work. > > The possibility of them having additions for their own purposes is very > > high. I believe starting fresh was easier than analyzing and debugging > > their repo. > > Don't guess, ask :) > > That particular package has been prepared and is maintained by my team > at the Wikimedia Foundation, which incidentally has 3 DDs (Filippo > Giunchedi, Moritz Mühlenhoff and myself) in it, plus at least a couple > of other people with Debian packaging expertise. > > At Wikimedia, we're using Kafka extensively. We're obviously very keen > on pushing things upstream too, which why e.g. I already pushed our > librdkafka package in Debian (already part of jessie). Vincent Bernat > also worked on kafkacat (from the same upstream) which we also use, so > we collaborated and now jointly comaintain each other's packages. We're > definitely not trying to work in a silo :) > > We haven't attempted to push the "main" Kafka package to Debian, since > our time was limited and the packaging was a bit hacky/get-the-job-done > (e.g. replacing the complex build system that downloads jars off the > Internet by a Makefile), plus, JVM packages are usually harder to > maintain properly :) > > I've been quietly watching this ITP, though, and we would definitely be > interested to join efforts and switch to better, properly maintained > packages, if there is enough momentum from people that want to see this > in Debian. > > Time is (always) limited but I'd be more than happy to > review/mentor/upload. I'll also convey this whole conversation > internally to my team, maybe we can pull some resources for this, if > you're interested in collaborating. > > Best, > Faidon >
Bug#775532: license of the CSL scheme files
http://citationstyles.org/developers/ now says "Note. All versions of the CSL schema have recently been relicensed under the more permissible MIT license, and the GitHub repository will soon be updated to reflect this change.". I'll add the MIT license to the repository and change the "rights" blurb in the schema itself, but it might be a while before I get to that. Rintze On Sun, Jun 14, 2015 at 11:33 AM, Daniel Stender wrote: > Thank you very much for the reply. Yes I think a link to something like > this on the project's page would do it until then, great! I'll check for it > and put in the copyright register in the package, then. > > Greetings, > Daniel > > On 14.06.2015 17:26, Rintze Zelle wrote: >> Hi Daniel, >> >> Bruce D'Arcus and I think that the MIT license might be the best >> option for relicensing the CSL schema. I just proposed the change on >> our mailing list >> (http://xbiblio-devel.2463403.n2.nabble.com/MIT-license-as-default-for-CSL-software-tp7579193p7579395.html), >> but I don't expect any objections. We certainly always wish to be >> FOSS-compatible and nonrestrictive. >> >> If nobody objects to the MIT license, it might still be a while before >> I get to updating all the schema files with the new license, so maybe >> I'll just make a note to that effect on http://citationstyles.org/. >> You can also rely on this email for permission to package the schema >> under MIT-license terms. >> >> Best, >> >> Rintze > > -- > http://qa.debian.org/developer.php?login=debian%40danielstender.com > 4096R/DF5182C8 > 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 > > -- 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/ca+pmmqqjt79hks98k7swc_ctll+uubuexmy0p5m2wrd6i-k...@mail.gmail.com
Fwd: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Hey Emmanuel, Thanks for your reply! This is one of the big things I wanted to address first. Would it be OK to include the gradle wrapper jar as part of the repo for building? I don't know the exact policy about binary artifacts in dsc files. Also, what about including JARs not packaging directly into the package? I have done that, but I didn't not upload my new work yet as I was on vacation for about ten days. I'm only building the 'core' subproject which depends on the 'clients' subproject. Here is a list of runtime dependencies from running `./gradlew -PscalaVersion=2.9.2 core:dependencies`. runtime - Runtime classpath for source set 'main'. +--- project :clients |+--- org.slf4j:slf4j-api:1.7.6 |+--- org.xerial.snappy:snappy-java:1.1.1.6 |\--- net.jpountz.lz4:lz4:1.2.0 +--- org.scala-lang:scala-library:2.9.2 +--- org.apache.zookeeper:zookeeper:3.4.6 |+--- org.slf4j:slf4j-api:1.6.1 -> 1.7.6 |+--- org.slf4j:slf4j-log4j12:1.6.1 ||+--- org.slf4j:slf4j-api:1.6.1 -> 1.7.6 ||\--- log4j:log4j:1.2.16 |\--- log4j:log4j:1.2.16 +--- com.101tec:zkclient:0.3 |+--- org.apache.zookeeper:zookeeper:3.3.1 -> 3.4.6 (*) |\--- log4j:log4j:1.2.14 -> 1.2.16 +--- com.yammer.metrics:metrics-core:2.2.0 |\--- org.slf4j:slf4j-api:1.7.2 -> 1.7.6 \--- net.sf.jopt-simple:jopt-simple:3.2 Cheers! Brandon On Thu, Jun 18, 2015 at 8:58 AM, Emmanuel Bourg wrote: > Hi Brandon, > > Thank you very much for packaging Kafka. In addition to the > debian-mentors and debian-java lists you may find some help on the > #debian-java IRC channel. > > I reviewed quickly the package, the main issue is the usage of the > gradle wrapper. Since it downloads jars from the internet it can't be > used for an official Debian package. The gradle package is being > upgraded and we should have a more recent version soon. I hope this will > solve the issues you encountered with the version 1.5. > > Not using the wrapper also means all the dependencies have to be > packaged in Debian first. Assuming the tests are disabled Kafka requires: > > com.101tec:zkclient:0.3not packaged > com.typesafe.zinc:zinc:0.3.1 not packaged > com.yammer.metrics:metrics-core:2.2.0 work in progress > commons-logging:commons-logging:1.0.4 OK > net.jpountz.lz4:lz4:1.2.0 not packaged > net.sf.jopt-simple:jopt-simple:3.2 OK > org.apache.avro:avro:1.4.0 OK > org.apache.hadoop:hadoop-core:0.20.2 not packaged > org.apache.pig:pig:0.8.0 not packaged > org.apache.pig:piggybank:0.12.0not packaged > org.apache.zookeeper:zookeeper:3.4.6 OK > org.codehaus.jackson:jackson-core-asl:1.5.5OK > org.codehaus.jackson:jackson-mapper-asl:1.5.5 OK > org.scala-lang:scala-library OK > org.slf4j:slf4j-api:1.7.6 OK > org.xerial.snappy:snappy-java:1.1.1.6 OK > > So the next step to get Kafka in Debian is to package the missing > dependencies. Hadoop is on my radar and I'll probably package it since I > need it for Solr. > > Emmanuel Bourg > >
Re: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Hi Brandon, Thank you very much for packaging Kafka. In addition to the debian-mentors and debian-java lists you may find some help on the #debian-java IRC channel. I reviewed quickly the package, the main issue is the usage of the gradle wrapper. Since it downloads jars from the internet it can't be used for an official Debian package. The gradle package is being upgraded and we should have a more recent version soon. I hope this will solve the issues you encountered with the version 1.5. Not using the wrapper also means all the dependencies have to be packaged in Debian first. Assuming the tests are disabled Kafka requires: com.101tec:zkclient:0.3not packaged com.typesafe.zinc:zinc:0.3.1 not packaged com.yammer.metrics:metrics-core:2.2.0 work in progress commons-logging:commons-logging:1.0.4 OK net.jpountz.lz4:lz4:1.2.0 not packaged net.sf.jopt-simple:jopt-simple:3.2 OK org.apache.avro:avro:1.4.0 OK org.apache.hadoop:hadoop-core:0.20.2 not packaged org.apache.pig:pig:0.8.0 not packaged org.apache.pig:piggybank:0.12.0not packaged org.apache.zookeeper:zookeeper:3.4.6 OK org.codehaus.jackson:jackson-core-asl:1.5.5OK org.codehaus.jackson:jackson-mapper-asl:1.5.5 OK org.scala-lang:scala-library OK org.slf4j:slf4j-api:1.7.6 OK org.xerial.snappy:snappy-java:1.1.1.6 OK So the next step to get Kafka in Debian is to package the missing dependencies. Hadoop is on my radar and I'll probably package it since I need it for Solr. Emmanuel Bourg -- 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/5582ce8a.2070...@apache.org
Re: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
On Thu, Jun 18, 2015 at 8:44 AM, Brandon Bradley wrote: > Sandro, > > I have multiple reasons for not contacting Wikimedia or using their work. can you share those with us? > The possibility of them having additions for their own purposes is very > high. I believe starting fresh was easier than analyzing and debugging their > repo. they are running those software, so it is very unlikely there is much to debug, on the opposite, there is probably much to learn. > Init scripts are recommended but not mandatory. Also, using a specific init > system is acceptable is the maintainer decides so. Please see this link: > https://www.debian.org/vote/2014/vote_003 I know, what I am asking is to include that init scrip anyway. > I am clear on how packaging works. However, there are tons of policies > scattered about, and mistakes will be made because of this. This is my first > package; I think I've done fairly well given the situation. I think you have still quite a bit to learn, so dont get defensive; please follow up with other interesting parties for this package, as I have definitely lost interest in sponsoring it. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxwx7ivnpi0r1osfew8mh00qpmppfba5sj7a-gbstw5...@mail.gmail.com
Re: blocked migration from unstable to testing: old binaries left
On 2015-06-18 14:55, Paul Wise wrote: > On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: > >> what am I supposed to do for unblocking ? > > You started a (minor) transition without involving the release team, > please read this: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > According to the cruft report, the old binaries can't be removed > because ovito build-depends on libtachyon-dev. You'll need to convince > the ovito maintainers to switch to the new tachyon dev packages. > > https://ftp-master.debian.org/cruft-report-daily.txt > As Paul already mentioned, it is due to a transition. * Your packages had no reverse dependency left on release architectures (but did have on sparc and possibly others). * It /did/ have reverse build-dependencies on release architectures, but it was decrufted regardless, so those are now broken. * As a result, ovito is most likely unbuildable in unstable on (e.g. amd64). Haven't tested it, but evidence points to this conclusion. For now I have blocked your package from migration. - It will show up as a "block hint from nthykier" or so in many hours from now as was not part of the original reason for it being blocked. I am a bit pressed on time atm., so I cannot follow through on this one right now. Jerome, please verify that the Build-Depends of ovito are not installable in unstable (linux-amd64 or linux-i386 should do) and if so file a serious bug against ovito asking them to migrate to the new dev package replacing it. I will get back to you later (in several hours from now or worst case, tomorrow). ~Niels -- 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/5582c42b.3070...@thykier.net
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
On Thu, 18 Jun, 2015 at 1:15 PM, PICCA Frederic-Emmanuel wrote: Hello, upload but I have a few remarks. here the rules file # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk why is it necessary to export the symbols since you are using compat level 9 ? Blind copy from the multiarch page of the Debian wiki. Will remove it in a later update. Then, I am guessing the explicit dependency on dpkg-dev is not needed either ? %: dh $@ --sourcedirectory=src \ --buildsystem=cmake \ --parallel \ --dbg-package=libclblas2-dbg override_dh_auto_configure: dh_auto_configure -- \ -DBUILD_RUNTIME=ON \ -DBUILD_TEST=OFF \ -DBUILD_PERFORMANCE=OFF \ -DBUILD_SAMPLE=OFF \ -DBUILD_CLIENT=ON \ -DBUILD_KTEST=OFF \ -DBUILD_SHARED_LIBS=ON echo "I: Generating Doxygen documentation" cd doc/ && doxygen clBLAS.doxy && rm html/jquery.js why do you build the documentation during the configuration why not puting the documentation generation under an: override_dh_auto_build ? Because it worked and I did not look further than that ^^. Would be cleaner in a override_dh_auto_build, I agree. Added to my todo-list. override_dh_auto_clean: dh_auto_clean [ ! -f doc/doxygen_sqlite3.db ] || $(RM) doc/doxygen_sqlite3.db [ ! -d doc/html ] || $(RM) -rf doc/html why no -$(RM) -f doc/doxygen_sqlite3.db -$(RM) -rf doc/html Force remove versus remove if present philosophy. That being said, just realized I do a force remove on doc/html anyway... To be changed as well. Cheers Fred Would you consider sponsoring clBLAS and ArrayFire as well? :-) Thanks for the comments and mentorship on clFFT, very much appreciated! Ghis
Re: Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Sandro, I have multiple reasons for not contacting Wikimedia or using their work. The possibility of them having additions for their own purposes is very high. I believe starting fresh was easier than analyzing and debugging their repo. Init scripts are recommended but not mandatory. Also, using a specific init system is acceptable is the maintainer decides so. Please see this link: https://www.debian.org/vote/2014/vote_003 I am clear on how packaging works. However, there are tons of policies scattered about, and mistakes will be made because of this. This is my first package; I think I've done fairly well given the situation. Cheers! Brandon On Wed, Jun 17, 2015 at 10:48 PM, Sandro Tosi wrote: > On Wed, Jun 17, 2015 at 10:16 PM, Brandon Bradley > wrote: > > Hello Sandro! And thanks for your reply. > > > > Your questions are annotated below. > > > > On Wed, Jun 17, 2015 at 2:56 PM, Sandro Tosi wrote: > >> > >> Hi everyone, > >> I'm looking at Brandon's package for kafka, and here are some comments: > >> > >> * did you sent an email to debian-mentors asking for comments? it's > >> usually a good way to get exposure of a package and receive feedbacks > >> about it > > > > > > I have not. I should and will very soon. > > I just added the list to this reply. > > > > >> > >> * there is already a packaging effort from wikimedia at > >> https://git.wikimedia.org/summary/operations%2fdebs%2fkafka.git/HEAD - > >> did you look at it (eventually contacting them to have the packages in > >> debian)? > > > > > > Indeed, I found this. The work there is most likely acceptable. However, > I > > believe that if they wanted to contribute this to Debian packaging that > they > > would have already done so. > > still not an excuse not to contact them and/or base the packaging in > what they have alraedy done. > > > Also, I find bash scripts hard to debug in some > > situations. As such, I will not be contributing init scripts myself. I > would > > be more than willing to accept contributions that support init scripts. > > debian/kafka.service works great on Jessie and will be what I maintain. > > bash scripts are the foundations of system administrations and are no > more no less difficult to debug than any other language. > > > > >> > >> * you mention gradle in Debian is broken: have you investigated what > >> needs to be done to fix it? > > > > > > I have. I cannot find the specific issue again, but Debian's gradle > package > > uses a very old version that breaks the Kafka build. I'll try to document > > the issue if I find it again. > > > >> > >> * debian/changelog > >> - it still contains 'UNRELEASED', that should be 'unstable' instead > > > > > > Ok! I thought it would be changed when the package is accepted. > > you should provide a package which is ready to be uploaded without any > further modification > > >> > >> * debian/control > >> - consider adding a Vcs-Browser field in source stanza > >> - short description should start with a lowercase letter > >> > >> * debian/kafka.links > >> - is empty and could be removed > > > > > > Ok! > > > >> > >> * debian/kafka.lintian-overrides > >> - I think there is still a lot of "heat" around it and I would > >> strongly advice to provide an init script > > > > > > Answered above. > > and i did reply, and init script is required (from my POV) > > >> > >> * debian/kafka.postinst > >> - you do some operations in 'configure' but it seems you dont undo > >> them when removing/purging the package, which should happen instead > > > > > > Are you talking about adduser and addgroup? > > yes and all the other actions performed in the 'configure' branch > > > > >> > >> * debian/rules > >> - consider using the more compact: --with A,B instead of --with A > --with > >> B > >> - it looks really suspicious the usage of HOME: have you tried to > >> build your package in a clean chroot? > >> - override_dh_systemd_start: true is, to say the least, unexpected, > >> what it is for? > > > > > > - Ok! > > - `./gradlew clean` was not using the chroot root user's home. This usage > > does that. It is strange, and I hope to find a better way to do it. > > - It is there so `dh_systemd_start` does nothing. I don't want Kafka to > > start after installation in case someone is running ZooKeeper on another > > node that is not up yet. > > then the right way is to instruce systemd and the init script to read > from /etc/default/kakfa which is a file containing a boolean variable > (defaulting to False) to specify whether to start or not kakfa > > > > >> > >> * debian/watch > >> - please provide it > > > > > > Ok! > > > >> > >> the package fails to build from source (FTBFS as you might find > >> usually written) in pbuilder exactly when using HOME: > >> > >> dh_auto_clean > >> GRADLE_USER_HOME=/tmp/buildd/.gradle ./gradlew clean > >> Error: Could not find or load main class > >> org.gradle.wrapper.GradleWrapperMain > >> debian/rules:15: recipe for target 'override_dh_auto_clean
Re: blocked migration from unstable to testing: old binaries left
On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: > what am I supposed to do for unblocking ? You started a (minor) transition without involving the release team, please read this: https://wiki.debian.org/Teams/ReleaseTeam/Transitions According to the cruft report, the old binaries can't be removed because ovito build-depends on libtachyon-dev. You'll need to convince the ovito maintainers to switch to the new tachyon dev packages. https://ftp-master.debian.org/cruft-report-daily.txt -- 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/CAKTje6Fdw7Y92PWt+bGVcGgA+WQT_kRaOQP=02kwnonzgd9...@mail.gmail.com
blocked migration from unstable to testing: old binaries left
Hello List, one of my package, tachyon not to mention it, reached unstable more than 5 days ago: its migration to testing is now blocked because `old binaries [are] left' [1]: what am I supposed to do for unblocking ? Thanks in advance, Jerome [1] https://release.debian.org/migration/testing.pl?package=tachyon -- 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/5582b7ec.4000...@rezozer.net
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
Hello, upload but I have a few remarks. here the rules file > # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/default.mk why is it necessary to export the symbols since you are using compat level 9 ? > %: >dh $@ --sourcedirectory=src \ >--buildsystem=cmake \ >--parallel \ >--dbg-package=libclblas2-dbg >override_dh_auto_configure: >dh_auto_configure -- \ >-DBUILD_RUNTIME=ON \ >-DBUILD_TEST=OFF \ >-DBUILD_PERFORMANCE=OFF \ >-DBUILD_SAMPLE=OFF \ >-DBUILD_CLIENT=ON \ >-DBUILD_KTEST=OFF \ >-DBUILD_SHARED_LIBS=ON >echo "I: Generating Doxygen documentation" >cd doc/ && doxygen clBLAS.doxy && rm html/jquery.js why do you build the documentation during the configuration why not puting the documentation generation under an: override_dh_auto_build ? > override_dh_auto_clean: >dh_auto_clean >[ ! -f doc/doxygen_sqlite3.db ] || $(RM) doc/doxygen_sqlite3.db >[ ! -d doc/html ] || $(RM) -rf doc/html why no -$(RM) -f doc/doxygen_sqlite3.db -$(RM) -rf doc/html Cheers Fred -- 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/a2a20ec3b8560d408356cac2fc148e53b216d...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
2015-06-18 10:08 GMT+01:00 PICCA Frederic-Emmanuel < frederic-emmanuel.pi...@synchrotron-soleil.fr>: > > I have updated both clBLAS and clFFT with a patch that suppresses the > offending flags. > > > You can build the most recent version of the package from the d-science > repositories with: > > > gbp buildpackage --git-upstream-tag=v2.4 --git-upstream-branch=master \ > >--git-debian-branch=debian/sid --git-no-pristine-tar > > Hello Ghislain, I personnaly prefer to work from mentors when doing > sponsoring :) > > Is it possible for you to upload into mentors both packages. > > Thanks > > Fred No problem, They are now both available on d-mentors. Ghis.
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
> I have updated both clBLAS and clFFT with a patch that suppresses the > offending flags. > You can build the most recent version of the package from the d-science > repositories with: > gbp buildpackage --git-upstream-tag=v2.4 --git-upstream-branch=master \ >--git-debian-branch=debian/sid --git-no-pristine-tar Hello Ghislain, I personnaly prefer to work from mentors when doing sponsoring :) Is it possible for you to upload into mentors both packages. Thanks Fred -- 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/a2a20ec3b8560d408356cac2fc148e53b216d...@sun-dag3.synchrotron-soleil.fr
Bug#788217: RFS: clfft/2.4-1 [ITP Bug#783084] -- OpenCL FFT library
Hi Fred, 2015-06-17 20:24 GMT+01:00 Ghislain Vaillant : > >> >> > One option would be to just patch the build system and comment out the >> part where the offending build flag is set. I >> > doubt however that upstream would be happy with this solution, since >> they must have setup their CI infrastructure >> > around this option I presume. >> >> > I am wondering what would be a good solution to suggest upstream about. >> I guess it is just more convenient for them to >> > let the build system handle mutliarch builds, including setting the >> appropriate build flags and arch-dependent install paths >> > instead of setting a proper build environment up like dh does. >> >> I do not know what is the recommended way in cmake for this kind of >> "multi-arch" things. >> >> maybe someone with more cmake experience can tell how to deal with this >> kind of problem. >> >> Cheers >> >> Fred > > > From what I read, other packages just patch the build system to avoid > setting the m32 / m64 flags explicitly. > > I'll update both clBLAS and clFFT with this change and report back. > > Ghis > I have updated both clBLAS and clFFT with a patch that suppresses the offending flags. You can build the most recent version of the package from the d-science repositories with: gbp buildpackage --git-upstream-tag=v2.4 --git-upstream-branch=master \ --git-debian-branch=debian/sid --git-no-pristine-tar for both. Please let me know if that addresses your issues. Ghis
