Bug#918507: marked as done (RFS: osmose-emulator/1.4-1 - Sega Master System and Game Gear console emulator)
Your message dated Wed, 23 Jan 2019 09:10:02 +0200 with message-id <00099231-3ac7-7d27-a133-4573b1966...@debian.org> and subject line Uploaded has caused the Debian Bug report #918507, regarding RFS: osmose-emulator/1.4-1 - Sega Master System and Game Gear console emulator 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.) -- 918507: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "osmose-emulator" * Package name: osmose-emulator Version : 1.4-1 Upstream Author : Carlos Donizete Froes * URL : https://gitlab.com/coringao/osmose-emulator * License : GPL-3+ Section : games It builds those binary packages: osmose-emulator - Sega Master System and Game Gear console emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/osmose-emulator Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-emulator_1.4-1.dsc More information about osmose-emulator can be obtained from https://gitlab.com/coringao/osmose-emulator/wikis. Changes since the last upload: osmose-emulator (1.4-1) unstable; urgency=medium * New upstream release (Closes: #868499) * Switch to compat level 12 * debian/control: + Bump debhelper compat to 12 + Declare compliance with Debian Policy 4.3.0 Regards, Carlos Donizete Froes [a.k.a coringao] --- End Message --- --- Begin Message --- Looks good, uploading...--- End Message ---
Re: Bug#920218: RFS: webcamoid/8.5.0+dfsg-1
On 2019-01-22, Herbert Fortes wrote: > akqml - full featured webcam capture application - qml module shouldn't this be called qml-module-something instead ? > libavkys-dev - full featured webcam capture application - dev Who are the consumers/users of this ? > webcamoid-plugins - full featured webcam capture application - plugins And this? /Sune
Bug#919433: marked as done (RFS: ca-certificates/20190110 [RC;Security])
Your message dated Wed, 23 Jan 2019 02:45:00 +0100
with message-id <20190123014500.gm18...@sym.noone.org>
and subject line Re: Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
has caused the Debian Bug report #919433,
regarding RFS: ca-certificates/20190110 [RC;Security]
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.)
--
919433: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919433
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "ca-certificates"
* Package name: ca-certificates
Version : 20190110
* License : GPL-2+, MPL-2.0
Section : misc
It builds those binary packages:
ca-certificates - Common CA certificates
ca-certificates-udeb - Common CA certificates - udeb (udeb)
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/ca-certificates
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/ca-certificates/ca-certificates_20190110.dsc
Changes since the last upload:
ca-certificates (20190110) unstable; urgency=high
* debian/control:
Depend on openssl (>= 1.1.1).
Set Standards-Version: 4.3.0.1.
Set Build-Depends: debhelper-compat (= 12); drop d/compat
Remove trailing whitespace from d/changelog.
* debian/ca-certificates.postinst:
Fix permissions on /usr/local/share/ca-certificates when using symlinks.
Closes: #916833
* sbin/update-ca-certificates:
Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl
rehash` from exiting with an error. Closes: #895482, #895473
This will also fix removal of user CA certificates from /usr/local
without
needing to run --fresh. Closes: #911303
* mozilla/{certdata.txt,nssckbi.h}:
Update Mozilla certificate authority bundle to version 2.28.
The following certificate authorities were added (+):
+ "GlobalSign Root CA - R6"
+ "OISTE WISeKey Global Root GC CA"
The following certificate authorities were removed (-):
- "Certplus Root CA G1"
- "Certplus Root CA G2"
- "OpenTrust Root CA G1"
- "OpenTrust Root CA G2"
- "OpenTrust Root CA G3"
- "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
- "Visa eCommerce Root"
-- Michael Shuler Thu, 10 Jan 2019 19:31:31 -0600
--
Kind regards,
Michael
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Hi Michael,
Michael Shuler wrote:
> * Package name: ca-certificates
> Version : 20190110
Uploaded.
Thanks again for your work on especially this release.
> * sbin/update-ca-certificates:
> Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl
> rehash` from exiting with an error. Closes: #895482, #895473
> This will also fix removal of user CA certificates from /usr/local without
> needing to run --fresh. Closes: #911303
This fix indeed worked for my two machines where the previous upload
failed to configure properly. Yay!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE--- End Message ---
Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
Hi Pierre-Elliott, Pierre-Elliott Bécue wrote: > Did you find the time to review these changes? Working on it this moment. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
Le mardi 22 janvier 2019 à 13:09:21+0100, Axel Beckert a écrit : > Hi Michael, > > Michael Shuler wrote: > > * debian/ca-certificates.postinst: > > Fix permissions on /usr/local/share/ca-certificates when using symlinks. > > Closes: #916833 > > * sbin/update-ca-certificates: > > Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl > > rehash` from exiting with an error. Closes: #895482, #895473 > > This will also fix removal of user CA certificates from /usr/local > > without > > needing to run --fresh. Closes: #911303 > > This sounds very promising, thanks! > > Will test it on the two of my affected machines probably this evening > and sponsor it if there aren't any blockers (which I don't expect :-). > > (If any other DD is quicker, feel free to sponsor the package, if I > haven't done it by then. :-) Hi Axel, Did you find the time to review these changes? If you're busy, I'll take care of the upload, but I have no instance where to test the current changes. Best regards, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Use SBuild to run post-build tools (autopkgtest, piuparts, …) in build area
Howdy all, How do I specify the build area (‘sbuild(1)’ manual says use the ‘--build-dir’ option), and have the correct paths generated for the post-build tools? When I invoke an SBuild run: sudo sbuild --build-dir=../build-area/ --dist unstable --source --arch-all --run-lintian --run-piuparts --run-autopkgtest ../build-area/foo_3.4.5-2.dsc The package builds correctly. But when the same SBuild run then invokes Lintian, PIUParts, and AutoPkgTest, only Lintian receives the correct path for files. The post-build commands fail with an error indicating they could not find the specified file. = $ sudo sbuild --build-dir=../build-area/ --dist unstable --source --arch-all --run-lintian --run-piuparts --run-autopkgtest ../build-area/foo_3.4.5-2.dsc sbuild (Debian sbuild) 0.78.0 (09 January 2019) on jasmine […] Build finished at 2019-01-23T00:08:13Z Finished I: Built successfully +--+ | Changes | +--+ [… success …] +--+ | Buildinfo| +--+ [… success …] lintian --- I: Lintian run was successful. +--+ | Post Build | +--+ piuparts 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts is wrong. 0m0.0s INFO: -- 0m0.0s INFO: piuparts version 0.96 starting up. 0m0.0s INFO: Command line arguments: /usr/sbin/piuparts ../build-area//foo_3.4.5-2_amd64.changes 0m0.0s INFO: Running on: Linux jasmine 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 0m0.0s WARNING: /build-area/foo_3.4.5-2_amd64.changes is not readable. Skipping. […] 0m0.0s ERROR: piuparts run ends. E: Piuparts run failed. autopkgtest --- usage: autopkgtest [options] [testbinary ...] testsrc -- virt-server [options] autopkgtest: error: ../build-area//foo_3.4.5-2_amd64.changes is invalid and does not contain Files: E: Autopkgtest run failed. […] = How can I use the ‘--build-dir’ option as intended, *and* have SBuild tell the post-build tools the correct paths to the files it generated in the build area? -- \ “Do unto others twenty-five percent better than you expect them | `\ to do unto you. (The twenty-five percent is [to correct] for | _o__)error.)” —Linus Pauling's Golden Rule | Ben Finney
Bug#920218: RFS: webcamoid/8.5.0+dfsg-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "webcamoid". It is a upload to experimental. To test the new .symbols file, install via apt and run the software. My key is not in the archive yet. The new release closes two important bugs: https://github.com/webcamoid/webcamoid/issues/142 https://github.com/webcamoid/webcamoid/issues/108 * Package name: webcamoid Version : 8.5.0+dfsg-1 Upstream Author : Gonzalo Exequiel Pedone * URL : https://github.com/webcamoid/webcamoid * License : GNU General Public License v3.0 Section : video It builds those binary packages: akqml - full featured webcam capture application - qml module libavkys-dev - full featured webcam capture application - dev libavkys8 - full featured webcam capture application - library webcamoid - full featured webcam capture application webcamoid-data - icons and locale files for webcamoid webcamoid-plugins - full featured webcam capture application - plugins To access further information about this package, please visit the following URL: https://mentors.debian.net/package/webcamoid Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_8.5.0+dfsg-1.dsc More information about webcamoid can be obtained from https://github.com/webcamoid/webcamoid. Changes since the last upload: * New upstream version 8.5.0+dfsg * debian/control: - Update Build-Depends and Webcamoid pkg Depends - Bump Standards-Version from 4.2.1 to 4.3.0 * debian/copyright: - Update year for myself and upstream * debian/clean: - Remove libAkQml.so file * debian/gbp.conf: - Remove sign-tags * debian/watch: - Add repacksuffix,repack,compression to opts - dversionmangle: remove number 1 from +dfsg * debian/patches: - Remove upstream patches - Add patch for .desktop file * Add new .symbols file * debian/webcamoid-data.install: - StandAlone does not have .json and effects.xml files Regards, Herbert
Bug#917724: marked as done (RFS: budgie-extras/0.7.0-1)
Your message dated Tue, 22 Jan 2019 21:22:37 +0200 with message-id and subject line Uploaded has caused the Debian Bug report #917724, regarding RFS: budgie-extras/0.7.0-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.) -- 917724: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917724 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "budgie-extras" * Package name: budgie-extras Version : 0.7.0-1 Upstream Author : Ubuntu Budgie Developers * URL : https://github.com/ubuntubudgie/budgie-extras * License : GPL-3+ Section : misc It builds those binary packages: budgie-app-launcher-applet - Applet to provide an alternative means to launch applications budgie-clockworks-applet - Applet to display clock across multiple time zones budgie-countdown-applet - Applet providing a countdown capability on the Budgie Desktop budgie-dropby-applet - Applet to popup when a USB device is connected budgie-extras-common - Shared component of budgie-extras applets budgie-hotcorners-applet - Applet providing hotcorners capabilities for the Budgie Desktop budgie-kangaroo-applet - Applet to allow quick file-browsing budgie-keyboard-autoswitch-applet - Applet adding the ability to set a different keyboard layout per budgie-previews-applet - Applet providing window previews capabilities for the Budgie Desk budgie-quicknote-applet - Applet providing simple notes capability for the Budgie Desktop budgie-recentlyused-applet - Applet displays files recently accessed for the Budgie Desktop budgie-rotation-lock-applet - Applet to lock or unlock the screen rotation budgie-showtime-applet - Applet displaying date and time on the Budgie Desktop budgie-trash-applet - Applet allows access to trash capabilities for the Budgie Desktop budgie-weathershow-applet - Applet to display the weather and forecast budgie-window-mover-applet - Applet allows moving windows between workspaces for the Budgie De budgie-workspace-overview-applet - Applet providing quick access to workspaces for the Budgie Deskto budgie-workspace-wallpaper-applet - Applet providing per workspace wallpaper To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-extras Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.7.0-1.dsc Notes: I am the debian maintainer - this request is due to the new/changed binaries which is not part of my upload rights lintiian -i -I --pedantic run on the built source and is lintian free check-all-the-things run on the source and corrections made to the source pbuilder-dist run to ensure builds correctly for unstable This upload introduces new built binaries to be authorised by archive-admins via the NEW queue: - budgie-weathershow-applet - budgie-extras-common Changes since the last upload: * New release - See ChangeLog * Packaging Changes - remove unneeded clockworks doc - drop existing patchset since now included in the new release - Control: budgie-weather-applet build and runtime dependencies updated due to python to Vala rewrite - Control: Add budgie-extras-common build together with dependency updates for several applets where they share the extras common component - Control: several build install changes where budgie-extras-common now replaces individual component installations - Copyright: updates due to extra licensing for the release including year change - Control: Bump StandardsVersion - no changes required Regards, David Mohammed --- End Message --- --- Begin Message --- Looks good, uploading...--- End Message ---
Bug#920039: Fwd: Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
-- Forwarded message - From: Archisman Panigrahi Date: Tue, Jan 22, 2019 at 8:15 PM Subject: Re: Bug#920039: RFS: brightness-controller/2.2.3 [ITP] To: Adam Borowski Hi, I have uploaded version 2.2.3-1. Now the /usr/bin calls the interpreter python to run /usr/share/brightness-controller/init.py. Thanks, Archisman On Tue, Jan 22, 2019 at 8:05 PM Adam Borowski wrote: > On Tue, Jan 22, 2019 at 07:54:45PM +0530, Archisman Panigrahi wrote: > > On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski > wrote: > > > > > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > > > > I am not sure about the native package issue. Has it got something to > > > > do with /debian/source/format? I did not exactly understand what is > > > > the difference between native and quilt, so went for native. Any > > > > suggestion is welcome. > > > > > > The "native" format is adequate only when there's no separate upstream > (and > > > often not even then); in this case you are packaging Amit's software > that > > > has proper releases, tarballs, and all proper trappings. > > > > > > The packaging is supposed to be composed of two pieces: > > > * the upstream (.orig) tarball > > > * a packaging tarball, that includes the debian/ dir and a (possibly > empty) > > > patch series > > > > > > This was somewhat different with the 1.0 format, but you don't want it > -- > > > even if you (like me) despite quilt, the "3.0 (quilt)" format with a > single > > > patch is strictly better than 1.0. > > > > I am now using 3.0 (quilt). I have uploaded a new release (under the same > > version number), please check. > > There is some lintian error > > "debian-changelog-version-requires-debian-revision". Is it due to the > fact > > that the debian/changelog in .orig.tar.gz > > Lintian has a nice set of explanations for its error messages, they get > enables by "-I". These tend to be better than one-paragraph responses > reviewers like me reply with (even though an automated tool is not as good > at understanding the context). > > In this case, the version number should end in "-1". > > > init.py calls other python files in usr/share/brightness-controller/ui > and > > usr/share/brightness-controller/util, so I want init.py > > to be in usr/share/brightness-controller/ as well. Otherwise I will need > to > > import them across directories which I want to avoid. > > That's a Python specific question, I can't answer those. I'm afraid that I > need to pass you to other people on this mailing list. If you happen to > have any Perl questions, though... > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands > ⢿⡄⠘⠷⠚⠋⠀ for Privacy. > ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 07:54:45PM +0530, Archisman Panigrahi wrote: > On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski wrote: > > > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > > > I am not sure about the native package issue. Has it got something to > > > do with /debian/source/format? I did not exactly understand what is > > > the difference between native and quilt, so went for native. Any > > > suggestion is welcome. > > > > The "native" format is adequate only when there's no separate upstream (and > > often not even then); in this case you are packaging Amit's software that > > has proper releases, tarballs, and all proper trappings. > > > > The packaging is supposed to be composed of two pieces: > > * the upstream (.orig) tarball > > * a packaging tarball, that includes the debian/ dir and a (possibly empty) > > patch series > > > > This was somewhat different with the 1.0 format, but you don't want it -- > > even if you (like me) despite quilt, the "3.0 (quilt)" format with a single > > patch is strictly better than 1.0. > > I am now using 3.0 (quilt). I have uploaded a new release (under the same > version number), please check. > There is some lintian error > "debian-changelog-version-requires-debian-revision". Is it due to the fact > that the debian/changelog in .orig.tar.gz Lintian has a nice set of explanations for its error messages, they get enables by "-I". These tend to be better than one-paragraph responses reviewers like me reply with (even though an automated tool is not as good at understanding the context). In this case, the version number should end in "-1". > init.py calls other python files in usr/share/brightness-controller/ui and > usr/share/brightness-controller/util, so I want init.py > to be in usr/share/brightness-controller/ as well. Otherwise I will need to > import them across directories which I want to avoid. That's a Python specific question, I can't answer those. I'm afraid that I need to pass you to other people on this mailing list. If you happen to have any Perl questions, though... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#917629: RFS: xhk/1.0-1
On Mon, 21 Jan 2019 20:33:55 + Kieran Bingham wrote: > > But documentation still have to be improved -- manpage is almost > > unreadable and refers to non-existent info manual. I think in current > > state this package is not ready for upload. > > I thought Kentaro had already updated this ? > > He's handling the packaging so I'll let him continue. I've updated package because v1.1 (which include updated manpage) has been released. https://mentors.debian.net/debian/pool/main/x/xhk/xhk_1.1-1.dsc Regards,
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski wrote: > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > > I am not sure about the native package issue. Has it got something to > > do with /debian/source/format? I did not exactly understand what is > > the difference between native and quilt, so went for native. Any > > suggestion is welcome. > > The "native" format is adequate only when there's no separate upstream (and > often not even then); in this case you are packaging Amit's software that > has proper releases, tarballs, and all proper trappings. > > The packaging is supposed to be composed of two pieces: > * the upstream (.orig) tarball > * a packaging tarball, that includes the debian/ dir and a (possibly empty) > patch series > > This was somewhat different with the 1.0 format, but you don't want it -- > even if you (like me) despite quilt, the "3.0 (quilt)" format with a single > patch is strictly better than 1.0. I am now using 3.0 (quilt). I have uploaded a new release (under the same version number), please check. There is some lintian error "debian-changelog-version-requires-debian-revision". Is it due to the fact that the debian/changelog in .orig.tar.gz says it was released for bionic (Ubuntu 18.04) while I changed it to unstable while packaging? I am not sure why this error appeared. > > > No such executable file is needed to run this software. The > > /usr/bin/brightness/controller calls the file > > /usr/share/brightness-controller/init.py (which has been marked > > executible with chmod +x), which can calls python to run itself. > > Yeah, but you're supposed to install the executable into /usr/bin. What > your current package does is a text file without the +x bit, that's not > going to work. In some complex cases it might be reasonable to have a > wrapper but here I don't see a reason to not install to /usr/bin directly
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > I am not sure about the native package issue. Has it got something to > do with /debian/source/format? I did not exactly understand what is > the difference between native and quilt, so went for native. Any > suggestion is welcome. The "native" format is adequate only when there's no separate upstream (and often not even then); in this case you are packaging Amit's software that has proper releases, tarballs, and all proper trappings. The packaging is supposed to be composed of two pieces: * the upstream (.orig) tarball * a packaging tarball, that includes the debian/ dir and a (possibly empty) patch series This was somewhat different with the 1.0 format, but you don't want it -- even if you (like me) despite quilt, the "3.0 (quilt)" format with a single patch is strictly better than 1.0. > No such executable file is needed to run this software. The > /usr/bin/brightness/controller calls the file > /usr/share/brightness-controller/init.py (which has been marked > executible with chmod +x), which can calls python to run itself. Yeah, but you're supposed to install the executable into /usr/bin. What your current package does is a text file without the +x bit, that's not going to work. In some complex cases it might be reasonable to have a wrapper but here I don't see a reason to not install to /usr/bin directly. In any case, a script needs to declare a hashbang with an explicit interpreter -- even though shells can execute a script without such a hashbang, relying on this is not allowed in Debian as it'd be unreliable if the user's shell is something weird. > I am not the main developer of the software (Amit Seal Ami > is), but am one of the major contributors. My > name is included in the list of contributors under > /usr/share/brightness-controller/about.py. All copyright holders (ie, contributors with non-trivial parts) need to be listed or at least referred to. > Can I edit the package description (to remove license information, > etc.) and release the next version? Would that work, or do I have to > make another RFS for it? Yeah, please do. You're not supposed to bump the version number while doing so (unless there's a really good reason), and neither you need another RFS. You can update this one until an upload to the archive has actually happened. > And, this is not compatible with Python 3 yet. That's good for Buster but it'll need to be updated after. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919433: RFS: ca-certificates/20190110 [RC;Security]
Hi Michael, Michael Shuler wrote: > * debian/ca-certificates.postinst: > Fix permissions on /usr/local/share/ca-certificates when using symlinks. > Closes: #916833 > * sbin/update-ca-certificates: > Remove orphan symlinks found in /etc/ssl/certs to prevent `openssl > rehash` from exiting with an error. Closes: #895482, #895473 > This will also fix removal of user CA certificates from /usr/local without > needing to run --fresh. Closes: #911303 This sounds very promising, thanks! Will test it on the two of my affected machines probably this evening and sponsor it if there aren't any blockers (which I don't expect :-). (If any other DD is quicker, feel free to sponsor the package, if I haven't done it by then. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
Hi, I am not sure about the native package issue. Has it got something to do with /debian/source/format? I did not exactly understand what is the difference between native and quilt, so went for native. Any suggestion is welcome. No such executable file is needed to run this software. The /usr/bin/brightness/controller calls the file /usr/share/brightness-controller/init.py (which has been marked executible with chmod +x), which can calls python to run itself. I am not the main developer of the software (Amit Seal Ami is), but am one of the major contributors. My name is included in the list of contributors under /usr/share/brightness-controller/about.py. Can I edit the package description (to remove license information, etc.) and release the next version? Would that work, or do I have to make another RFS for it? And, this is not compatible with Python 3 yet. Let me know. Archisman On 1/22/19, Adam Borowski wrote: > On Tue, Jan 22, 2019 at 11:16:09AM +0100, Adam Borowski wrote: >> The package installs no useful executables, >> /usr/share/brightness-controller/init.py has no x bit and its only >> contents > > /usr/bin/brightness-controller that is. > >> is "/usr/share/brightness-controller/init.py\n". > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands > ⢿⡄⠘⠷⠚⠋⠀ for Privacy. > ⠈⠳⣄ > -- *Archisman Panigrahi. * *I am learning Software Developing.* *My Code: *https://github.com/apandada1/ *Supporting Greener Computing* - Do you really need to print this email?
Re: cmake issue with minia: include could not find load file (GatbCore)
On Mon, Jan 21, 2019 at 07:58:29PM -, Sune Vuorela wrote: > On 2019-01-21, Andreas Tille wrote: > > Is there any way to make cmake more verbose where it is seeking for files > > to include? > > cmake --trace > > at least give you more debugging info than you could ever wish for. Thanks a lot, that was very helpful, Andreas. -- http://fam-tille.de
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 11:16:09AM +0100, Adam Borowski wrote: > The package installs no useful executables, > /usr/share/brightness-controller/init.py has no x bit and its only contents /usr/bin/brightness-controller that is. > is "/usr/share/brightness-controller/init.py\n". -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 01:41:49AM +0530, Archisman Panigrahi wrote: > * Package name: brightness-controller >Version : 2.2.3 > brightness-controller - Easily adjust your display brightness Hi! Why is this a native package if it's in no way specific to Debian only? The package installs no useful executables, /usr/share/brightness-controller/init.py has no x bit and its only contents is "/usr/share/brightness-controller/init.py\n". I wonder why the source package has a FHS-ish layout. This might be acceptable (but certainly atypical), but suggests something wrong is going on. At least some Python files have been generated but don't get regenerated during the build. The copyright file lacks at least yourself. That's ok only if you're doing the packaging as a part of your work duties, but I have doubts that "Amit Seal Ami " is your employer. The package's description is not supposed to talk about license, the upstream's github nor how to report bugs. Likewise, it's not a place to ask for review. It's probably a bad idea to use Python [2] in the packaging of a new program. While Python 2 is still supported for Buster, it'll be dropped early in the next release cycle. There's no man page. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
