Bug#862940: marked as done (RFS: slick-greeter/1.0.3-1 ITP)
Your message dated Thu, 25 May 2017 04:22:54 +0200 with message-id <20170525022254.k4s6blegpmqci...@angband.pl> and subject line Re: Bug#862940: RFS: slick-greeter/1.0.3-1 ITP has caused the Debian Bug report #862940, regarding RFS: slick-greeter/1.0.3-1 ITP 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.) -- 862940: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862940 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "slick-greeter" * Package name: slick-greeter Version : 1.0.3-1 Upstream Author : Clement Lefebvre * URL : https://github.com/linuxmint/slick-greeter/ * License : GPL-3+ Section : x11 It builds those binary packages: slick-greeter - Slick-looking LightDM greeter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/slick-greeter Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/slick-greeter/slick-greeter_1.0.3-1.dsc Notes: Slick-Greeter has been created by Linux Mint as their primary LightDM greeter for their distro. It is being promoted as a distro-agnostic greeter. I am aware it is available in several non-Debian based distro's. Given the limited number of LightDM based greeters available in Debian I believe this is a good complement for Debian with a long-term upstream viability. Packaging issues. Linux Mint do not PGP sign their packages. The upstream tarball contains their Debian package specific to their Distro. I asked the question whether they would separate distro specific packaging from the source but this was declined -https://github.com/linuxmint/slick-greeter/issues/22 As such to build this package I am prepared to maintain the Debian package under our distro GithHub organisation Ubuntu Budgie To build this I have had to-do the following: uscan to autodownload the upstream tarball via the debian/watch in this Debian package Unpack the published upstream tarball. Remove the upstream Debian folder and its contents Copy back from the published UbuntuBudgie slick-greeter debian branch the Debian package. This Debian package contains one patch - this is to replace the upstream specific font dependency with what I consider a good font available in Debian and all Debian based distros (font-cantarell) I'm aware of the release state of Stretch; this package is therefore not appropriate for Stretch. Please let me know if experimental is perhaps more appropriate than unstable given the status of Stretch. I can confirm that the necessary build dependency differences between Ubuntu and Debian have been met here i.e. builds successfully both on Debian and Ubuntu without needing separate distro packages. Have run check-all-the-things on the source and adjusted the debian/copyright accordingly. Doesnt appear to be any other changes required as a result of the check-all-the-things output. Also ran lintian -i -I on the built changes and this returned no issues. Changes since the last upload: * Initial release. (Closes: #862934) Regards, David Mohammed --- End Message --- --- Begin Message --- On Wed, May 24, 2017 at 11:59:15PM +0100, foss.freedom wrote: > > * the fonts looks ugly. I see you want to use fonts-cantarell but don't > > actually depend on it; since it's configurable, a Suggests: or Recommends: > > stanza would be appropriate. > > k - fonts-cantarell was maybe not a good idea. > > Have changed it in the recent upload to a standard Sans font which > looks ok on stretch xfce (well at least to my eyes) - but as you > mentioned its configurable. Looks like we have a miscommunication: I'm not complaining about the look of Cantarell itself _when installed_. My problem is when fonts-cantarell is not installed, and there is nothing that pulls it in. > Yes please to New if you are happy with the minor tweaks I've done above. Right, let's tweak it in -2, I've tossed it to the NEW bin so the ftpmasters can do their thing. Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.--- End Message ---
Bug#862940: RFS: slick-greeter/1.0.3-1 ITP
Hi Adam, k - fonts-cantarell was maybe not a good idea. Have changed it in the recent upload to a standard Sans font which looks ok on stretch xfce (well at least to my eyes) - but as you mentioned its configurable. Have raised the issue upstream about slick-greeter.conf - I'll do an upstream PR anyway very soon to cover this and therefore will be made available in a subsequent update. I had a look at the configurator - it currently has a dependency according to the upstream debian/control file on a package called python3-xapp that doesn't exist in Debian. I need to have a closer look at the source to see it really does need this dependency. Assuming I can iron this bit out, yes I intend to package it as well. Yes please to New if you are happy with the minor tweaks I've done above. David On 24 May 2017 at 21:34, Adam Borowski wrote: > On Wed, May 24, 2017 at 06:57:17PM +0100, foss.freedom wrote: >> I have switched liblightdm-gobject-1-dev and liblightdm-gobject-dev >> around in the latest upload. Hopefully this will resolve the first >> alternate rule on buildds > > Builds and runs fine, thanks! > > The package is in a shape fit for unstable now; let's continue with review > but you can choose whether you prefer to get it into NEW then do incremental > improvements, or to fix the issues immediately. > > * the fonts looks ugly. I see you want to use fonts-cantarell but don't > actually depend on it; since it's configurable, a Suggests: or Recommends: > stanza would be appropriate. > > * the README talks about /etc/lightdm/slick-greeter.conf -- yet it 1. is not > shipped with the package and 2. there's not a word of documentation about > what can you put in that file and what is its syntax. I'd recommend > installing such a file with commented out possible settings. > > * it talks about a configurator, "lightdm-settings". I assume someone will > package it in nearby future, right? > > > Meow! > -- > Don't be racist. White, amber or black, all beers should be judged based > solely on their merits. Heck, even if occasionally a cider applies for a > beer's job, why not? > On the other hand, corpo lager is not a race.
Bug#862940: RFS: slick-greeter/1.0.3-1 ITP
On Wed, May 24, 2017 at 06:57:17PM +0100, foss.freedom wrote: > I have switched liblightdm-gobject-1-dev and liblightdm-gobject-dev > around in the latest upload. Hopefully this will resolve the first > alternate rule on buildds Builds and runs fine, thanks! The package is in a shape fit for unstable now; let's continue with review but you can choose whether you prefer to get it into NEW then do incremental improvements, or to fix the issues immediately. * the fonts looks ugly. I see you want to use fonts-cantarell but don't actually depend on it; since it's configurable, a Suggests: or Recommends: stanza would be appropriate. * the README talks about /etc/lightdm/slick-greeter.conf -- yet it 1. is not shipped with the package and 2. there's not a word of documentation about what can you put in that file and what is its syntax. I'd recommend installing such a file with commented out possible settings. * it talks about a configurator, "lightdm-settings". I assume someone will package it in nearby future, right? Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.
Bug#863278: RFS: usbguard/0.7.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "usbguard" * Package name: usbguard Version : 0.7.0-1 Upstream Author : Daniel Kopeček * Url : https://dkopecek.github.io/usbguard/ * Licenses: CC-BY-SA-3.0,FSFULLR,GPL-3+,GPL-2+ Section : utils It builds those binary packages: * libusbguard0 * usbguard * usbguard-applet-qt To access further information about this package, visit the following URL: https://mentors.debian.net/package/usbguard Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/usbguard/usbguard_0.7.0-1.dsc Or clone the package from https://0xacab.org/muri/debian-usbguard More information about usbguard can be obtained from https://dkopecek.github.io/usbguard/ Changes since last upload: * New upstream version 0.7.0 This release contains a backwards incompatible change because it changes how the device hash is computed for Linux root hub devices * Add support for bash-completion * Delete add-unistd.patch, its not needed anymore * Compile the library static, to make `make check` work * Bump compat version to 10 * Add d/usbguard.dirs Regards, Muri Nicanor signature.asc Description: OpenPGP digital signature
Bug#862940: RFS: slick-greeter/1.0.3-1 ITP
Thanks Adam for the feedback. unstable is therefore appropriate. I have switched liblightdm-gobject-1-dev and liblightdm-gobject-dev around in the latest upload. Hopefully this will resolve the first alternate rule on buildds cheers David On 24 May 2017 at 15:02, Adam Borowski wrote: > Control: tags -1 +moreinfo > > On Fri, May 19, 2017 at 12:59:28AM +0100, foss.freedom wrote: >> I am looking for a sponsor for my package "slick-greeter" >> >> Changes since the last upload: >> >>* Initial release. (Closes: #862934) > > Alas, it fails to build when build-dependencies are restricted to the first > alternative listed, such as sbuild's default -- which is also used on > official buildds. > > There's no package named liblightdm-gobject-1-dev anywhere in Debian -- you > need to put liblightdm-gobject-dev first. > >> Please let me know if experimental is perhaps more appropriate than >> unstable given the status of Stretch. > > For new packages, unstable is fine. In fact, assuming you believe the > package to be in a releasable shape, unstable is better as this way we won't > have to migrate the package. > > > Meow! > -- > Don't be racist. White, amber or black, all beers should be judged based > solely on their merits. Heck, even if occasionally a cider applies for a > beer's job, why not? > On the other hand, corpo lager is not a race.
Bug#862940: RFS: slick-greeter/1.0.3-1 ITP
Control: tags -1 +moreinfo On Fri, May 19, 2017 at 12:59:28AM +0100, foss.freedom wrote: > I am looking for a sponsor for my package "slick-greeter" > > Changes since the last upload: > >* Initial release. (Closes: #862934) Alas, it fails to build when build-dependencies are restricted to the first alternative listed, such as sbuild's default -- which is also used on official buildds. There's no package named liblightdm-gobject-1-dev anywhere in Debian -- you need to put liblightdm-gobject-dev first. > Please let me know if experimental is perhaps more appropriate than > unstable given the status of Stretch. For new packages, unstable is fine. In fact, assuming you believe the package to be in a releasable shape, unstable is better as this way we won't have to migrate the package. Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.
Bug#863251: RFS: node-grunt-known-options/1.1.0-1~bpo8+1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "node-grunt-known-options" * Package name: node-grunt-known-options Version : 1.1.0-1~bpo8+1 Upstream Author : Grunt Development Team * URL : https://github.com/gruntjs/grunt-known-options * License : MIT Section : web It builds those binary packages: node-grunt-known-options - known options used in Grunt To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-grunt-known-options Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-grunt-known-options/node-grunt-known-options_1.1.0-1~bpo8+1.dsc Changes since the last upload: * Rebuild for jessie-backports. I would like to backport node-grunt-cli to Jessie and this dependency needs to be backported first. Regards,
Re: Additional files/folders in package
hi, On 05/24/2017 09:44 AM, Andrey Rahmatullin wrote: > On Wed, May 24, 2017 at 08:56:12AM +0200, Muri Nicanor wrote: >> i'm in the process of upgrading usbguard to 0.7. In the new upstream >> usbguard-daemon.conf there are the folder >> /etc/usbguard/IPCAccessControl.d/ and the file >> /var/log/usbguard/usbguard-audit.log specified. I'm not sure what's the >> best way to create those: > Create the directory with debian/package.dirs. okey > Why do you need to create > the log file though? turns out i don't! > >> is there maybe a debhelper for logfiles (which creates logrotate configs >> for those files...)? > A logrotate config is a text file. You should create it yourself if it's > not shipped by the upstream. You can use dh_installlogrotate to install > it. oke, i'll do that thanks, muri signature.asc Description: OpenPGP digital signature
Re: Additional files/folders in package
On Wed, May 24, 2017 at 08:56:12AM +0200, Muri Nicanor wrote: > i'm in the process of upgrading usbguard to 0.7. In the new upstream > usbguard-daemon.conf there are the folder > /etc/usbguard/IPCAccessControl.d/ and the file > /var/log/usbguard/usbguard-audit.log specified. I'm not sure what's the > best way to create those: Create the directory with debian/package.dirs. Why do you need to create the log file though? > is there maybe a debhelper for logfiles (which creates logrotate configs > for those files...)? A logrotate config is a text file. You should create it yourself if it's not shipped by the upstream. You can use dh_installlogrotate to install it. -- WBR, wRAR signature.asc Description: PGP signature
Additional files/folders in package
Hello mentors, i'm in the process of upgrading usbguard to 0.7. In the new upstream usbguard-daemon.conf there are the folder /etc/usbguard/IPCAccessControl.d/ and the file /var/log/usbguard/usbguard-audit.log specified. I'm not sure what's the best way to create those: a) remove or comment those lines from the usbguard-daemon.conf file b) create them in a usbguard.postinst script (mkdir -p and touch in the configure part) c) create them in the build directory using d/rules and let dh_install handle the rest d) use dh_installdirs (and something similar for the logfile) is there maybe a debhelper for logfiles (which creates logrotate configs for those files...)? at the moment i'd use b), but maybe there are even better solutions? thanks and cheers, muri signature.asc Description: OpenPGP digital signature
Bug#863229: RFS: lua-torch-cutorch/0~20170511-g92e9c08-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lua-torch-cutorch" * Package name: lua-torch-cutorch Version : 0~20170511-g92e9c08-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libtorch-thc - libTHC.so for Torch framework (library) libtorch-thc-dev - libTHC.so for Torch framework (development) lua-torch-cutorch - CUDA backend for Torch framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-cutorch Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/l/lua-torch-cutorch/lua-torch-cutorch_0~20170511-g92e9c08-1.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-cutorch/0~20170511-g92e9c08-1/buildlog Changes since the last upload: lua-torch-cutorch (0~20170511-g92e9c08-1) experimental; urgency=medium * Import upstream snapshot. Note, please do *amd64* instead of source upload since this is a contrib package.
