Bug#983146: 983146 RFS: bung/3.51-1 [ITP] -- backup next generation
Changes since 3.2.7 Version 3.5.1 27 Feb 2023 * Issue 20 err_trap_mount_conf: when keyword Snapshot used in debug mode: mount_fs_spec_conf[i]: unbound variable Version 3.5.0 10 Feb 2023 * Issue 8: Notifications: create plug-in architecture Migration notes * rsync_bu destination and source computers must both run bung version 3.5.x Version 3.4.0 1 Feb 2023 * Issue 6: Do not generate an error when the mailx command is not available Migration notes * In case the mailx command is available but you do not want bung to use it: * Most scripts: use the "Email for report" keyword new value "none". More in the bung_common (5) man page * check_hotplug_usage: use the "Check hotplug usage" keyword "Email" sub-keyword new value "none". More in the check_hotplug_usage (5) man page Version 3.3.0 21 Jan 2023 * Feature 18: more retention policies. All backup scripts now remove old backups before backing up instead of after * Keywords MySQL and OpenLDAP can no longer be repeated in a single conffile * postgres_bu now also backs up database template1 * Documentation clarifications * rsync_restore: usability improvements Migration notes * In case the new retention policies better suit your needs, migrate to them. They are percent_usage[,min_old_backups] and retention=old_backups More about retention in individual scripts' man (5) pages * In the unlikely case of repeated keyword errors, workaround by splitting the conffile into conffiles with a single keyword and using them via hotplug_bu or super_bu's "Subsidiary script" Best Charles
Bug#983146: 983146 RFS: bung/3.2.6-5 [ITP] -- backup next generation
Dear Bastian > During the package build with libreoffice-common as Build-Dependency Thank you for guidance. Done. Uploaded to https://mentors.debian.net/package/bung, The QA information is now – Package uses debhelper-compat Debhelper compatibility level 13 – Package is the latest upstream version local:3.2.6 upstream:3.2.6 url: https://github.com/CharlesMAtkinson/bung/releases/download/3.2.6/bung_3.2.6.source_with_htm_and_pdf.tgz – Package is not native format:3.0 (quilt) – "Maintainer" email is the same as the uploader – Package has lintian informational tags bung I extra-license-file [usr/share/doc/bung/COPYING.gz] I possible-documentation-but-no-doc-base-registration I spare-manual-page [usr/share/man/man8/bung-common.8.gz] I systemd-service-file-missing-documentation-key [lib/systemd/system/bung.rm_old_logs.service] bung source I out-of-date-standards-version 4.5.1 (released 2020-11-17) (current is 4.6.1.0) I unused-entry-in-debian-source-include-binaries usr/share/doc/bung/Backup scripts next generation 3.2.x Programmer's Guide.htm [debian/source/include-binaries:1] usr/share/doc/bung/Backup scripts next generation 3.2.x Programmer's Guide.pdf [debian/source/include-binaries:3] usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm [debian/source/include-binaries:4] usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.pdf [debian/source/include-binaries:6] P very-long-line-length-in-source-file 1502 > 512 [usr/share/doc/bung/Backup scripts next generation 3.2.x Programmer's Guide.odt:115] 1703 > 512 [usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.odt:239] 2165 > 512 [usr/share/doc/bung/Backup scripts next generation Publisher's Guide.odt:3] X debian-watch-does-not-check-gpg-signature [debian/watch] X prefer-uscan-symlink filenamemangle s%(?:.*?)?v?(\d[\d.]*)\.source_with_htm_and_pdf\.tgz%@PACKAGE@-$1.tgz% [debian/watch:4] X upstream-metadata-file-is-missing – Package closes ITP bug bung: #985918 (Wishlist, ITP): ITP: bung -- backup next generation – No VCS field present – Package is not in Debian – Upstream-Contact missing from d/copyright author:None licenses:GPL-2.0+ Is there anything else you need me to fix? Best Charles
Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Dear Bastian Regards "Please use the *.source.tgz as source instead of *.source_with_htm_and_pdf.tgz", I assume you refer to the files at https://github.com/CharlesMAtkinson/bung/releases/tag/3.2.6. If that is not correct, please correct my assumption and disregard the rest of this mail. Regards "You should then export and install the .htm as documentation automatically", when and where do you want that automation to happen? In case you wanted it to be done while installing the .deb, it is not possible. The .htm files are created from .odt files using soffice from package libreoffice-common. Package libreoffice-common may not be installed on computers where the .deb will be installed. There is no way to create .htm files from .odt files on all computers where the .deb will be installed Best Charles
Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Dear Bastian I have uploaded a fixed version to https://mentors.debian.net/package/bung, The QA information now shows + Package uses debhelper-compat + Package is the latest upstream version + Package is not native – "Maintainer" email is the same as the uploader – Package has lintian errors bung [I class items snipped] E source-is-missing [usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm] P very-long-line-length-in-source-file [several, only for .odt and .pdf files] [X class items snipped] + Package closes ITP bug – No VCS field present – Package is not in Debian – Upstream-Contact missing from d/copyright I do not understand the E class item. "usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm" is present in bung_3.2.6.orig.tar.gz Is there anything else you need me to fix? Best Charles
Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Dear Bastian I have uploaded a fixed version to https://mentors.debian.net/package/bung, The QA information now shows + Package uses debhelper-compat + Package is the latest upstream version + Package is not native – "Maintainer" email is the same as the uploader – Package has lintian errors bung [I class items snipped] E source-is-missing [usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm] P very-long-line-length-in-source-file [several, only for .odt and .pdf files] [X class items snipped] + Package closes ITP bug – No VCS field present – Package is not in Debian – Upstream-Contact missing from d/copyright I do not understand the E class item. "usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm" is present in bung_3.2.6.orig.tar.gz Is there anything else you need me to fix? Best Charles
Bug#983146: 983146 RFS: bung/3.2.5-2 [ITP] -- backup next generation
Dear Bastian Thank you for your help The mentors upload has been fixed. I had accidentally uploaded to ftp.upload.debian.org instead of mentors.debian.net https://mentors.debian.net/package/bung/ QA information shows 'The uploader is not in the package's "Maintainer" or "Uploaders" fields'. I will fix that on the next upload The QA information shows lintian messages in the package and the source I will fix * The uploader is not in the package's "Maintainer" or "Uploaders" fields * The W messages * I extra-license-file * I typo-in-manual-page * I out-of-date-standards-version * P silent-on-rules-requiring-root * P uses-debhelper-compat-file * X debian-watch-does-not-check-gpg-signature * X upstream-metadata-file-is-missing I will consider fixing * X prefer-uscan-symlink I cannot fix * E source-is-missing Backup scripts next generation 3.2.x User Guide.htm is created by saving the .odt file in HTML format Best Charles
Bug#983146: 983146 RFS: bung/3.2.5-2 [ITP] -- backup next generation
Dear Bastian Thank you for your help The debian/changelog file's UNRELEASED has been changed to unstable Best Charles
Bug#983146: 983146 RFS: bung/3.2.4-1 [ITP] -- backup next generation
Dear Tobias Further to your 13 Nov 2021 message above ... The orig.tar.gz file is now in the required format The source build now has a watch file The git is publicly available at https://github.com/CharlesMAtkinson/bung The orig.tar.gz file is available from https://github.com/CharlesMAtkinson/bung_debian_packaging/releases Dear Geert You asked for proof that feedback gets follow-up. This is it, not as quickly as I would have liked. Migration to github and automating the release and publication procedures was not trivial Best Charles
Bug#983146: 983146 RFS: bung/3.2.1-1 [ITP] -- backup next generation
Dear Tobias Sorry for not responding to your 13 Nov 2021 message. I did not see it until Geert Stappers mentioned it on 18 Feb 2022 Dear Geert Thank you for your message Dear All I understand there are two blockers, the format of orig.tar and the absence of a watch file Regards the current orig.tar, it is the upstream tarball in the format used for installing before a .deb was developed. Do I rightly understand that is not what is required, that what is required is the in-development files? If so I will create a new orig.tar, being the content of https://github.com/CharlesMAtkinson/bung/tree/main/source When that doubt is resolved I will create 3.2.1-2 including a watch file Best Charles
Bug#983146: 983146 RFS: bung/3.2.1-1 [ITP] -- backup next generation
Dear readers bung 3.2.1 was released on 12 Feb 2022. Upgrading to the current release is always encouraged but bung 3.1.1 users need only do so if they want the new features The tarball and .deb are available from https://redmine.auroville.org.in/projects/bung/files. Documentation is available from https://redmine.auroville.org.in/projects/bung/documents *Changes since 3.1.1* The most important changes are rsync_bu now supports non-root user for remote rsync and Debian 8 Jessie is no longer supported. The User Guide now includes an Android backup example Bugfixes and new features * Documentation #12897 Missing postgresql_bu configuration sample * Bug #12900 .deb: postrm script: purge: /etc/opt/bung instead of /etc/bung * Task #12994 Examples: update Mikrotik hook scripts and templates * Feature #13503 bung: enable non-root user for remote rsync * Bug #13511 rsync_bu: hangs when there's no known_hosts entry for the remote host * Task #13504 run_remote_agent: reduce logging verbosity * Task #13509 All scripts: simplify the signal trapping and reporting code * Feature #13518 initialise_1.scrippet: unprivileged use: default the conf, log, PID and tmp_root dirs * Feature #13569 rsync_bu: log the rsync command in a format which can be run by copy and paste *Migration notes* * No configuration changes are required for migration from 3.1.x to 3.2.x * Debian 8 Jessie is no longer supported Best Charles
Bug#983146: 983146 RFS: bung/3.1.1-1 [ITP] -- backup next generation
To all who have contributed to this bug report: Antonio, Bart, Gurkan, Robin and Tobias Thanks for your help and your patience as I have naively struggled to comply with Debian standards. Apart from doc-base I think the package is now fully compliant. No sponsors have come forward. Please suggest how I might find one. Here's what I have done already ... I viewed https://wiki.debian.org/Teams and http://web.archive.org/web/20090908094500/http://krum.ethz.ch/ddc/teams-of-2007.txt but did not find any appropriate teams to ask for sponsorship I used https://packages.debian.org/search?keywords=backup=names=stable=all and https://packages.debian.org/search?keywords=backup=all=stable=all to find packages functionally related to bung and to note their maintainers. I haven't written to any of them yet, partly because it would be intrusive and partly because it is not obvious that just because they maintain a related package they would have any interest in sponsoring bung FWIW here's the list backupninja pkg-backupni...@lists.riseup.net mi...@riseup.net intrig...@debian.org jer...@riseup.net backuppc team+pkg-backu...@tracker.debian.org t...@debian.org a...@debian.org bacula-director pkg-bacula-de...@lists.alioth.debian.org cedar-backup2 and cedar-backup3 prono...@debian.org chiark-backup ijack...@chiark.greenend.org.uk dirvish p...@debian.org flexbackup k...@shore.net luckybackup pmatth...@debian.org mariadb-backup pkg-mysql-ma...@lists.alioth.debian.org o...@debian.org rdiff-backup cha...@ohmytux.com rsbackup rsbackup-ma...@lists.alioth.debian.org matt...@debian.org slbackup debian-edu-pkg-t...@lists.alioth.debian.org sunwea...@debian.org wer...@debian.org vbackup v...@v13.gr Best Charles
Bug#983146: 983146 RFS: bung/3.0.8-2 [ITP] -- backup next generation
Thanks for reviewing, tobi https://mentors.debian.net/package/bung/ is updated I fixed all the defects you identified (installed debhelper, debmake, and lintian from buster-backports) except ... d/source/metadata. The bung git repo is not (yet) publicly accessible so metadata cannot be implemented d/changelog. I did not understand Maybe useful: Use dc -r "" to update it and update the timestamp. doc-base was a challenge and I failed. The key difficulty was some of bung's docs have spaces in their file names (I believe in making things easy for people rather than computers). I tried several workarounds but nothing worked. In case they are of any value, my doc-base notes are below Best Charles doc-base notes * No "Format" for .odt files. Ref file:///usr/share/doc/doc-base/doc-base.html/interface.html#s2.3.2 > "2.3.2.2. Format sections". Maybe OK to use Text format, maybe not * No support for spaces in file names. file:///usr/share/doc/doc-base/doc-base.html/interface.html#s2.3.2 > "2.3.2.2. Format sections" > Files does not define the requirements/restrictions. Tried single and double quotes and backslash. Worked around by using glob expressions * https://wiki.debian.org/doc-base lists doc-base clients. Used https://www.debian.org/distrib/packages to search for them ** dochelp did not find the bung entries. Because of the globs? ** dwww required running Apache. Not convenient ** dhelp not packaged for Buster ** doc-central required running Apache. Not convenient ** yelp did not list any doc-base documents ** khelpcenter4 not packaged after Stretch * file:///usr/share/doc/doc-base/doc-base.html/interface.html refers to /usr/share/doc/dpkg/triggers.txt.gz but it did not exist * From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910783 "Remove doc-base recommendation" > However, it is clear that we do not think a lack of doc-base registration is a bug of severity greater than wishlist, which is what the current Policy wording implies * When globs were used in doc-base File values, lintian generated doc-base-file-references-missing-file * Tried to work around the need for globs by changing file names' spaces to underscores during the build * Then dpkg-source generated "warning: ignoring deletion of file" for each renamed file in the upstream tarball * Tried to work around by creating debian/source/options with include-removal * Then dpkg-source generated "error: aborting due to unexpected upstream changes" * Tried using dpkg-source --commit as suggested but got a 1 MB patch file
Bug#983146: 983146 RFS: bung/3.0.7-2 [ITP] -- backup next generation
Thanks tobi, I appreciate the guidance bung/3.0.7-2 is now at https://mentors.debian.net/package/bung (3.0.7-2 is signed, 3.0.7-1 was not)
Bug#983146: 983146 RFS: bung/3.0.7-1 [ITP] -- backup next generation
bung is now at version 3.0.7. The main change is an improved summary backup scripts next generation (bung): * Uses standard backup utilities mysqldump, pg_dump, rsync, slapcat and tar to create backups on local and remote file systems. * Is arbitrarily extensible via templates with integrated support for git. Templated examples are provided for backing up some Cisco and MikroTriek devices. * Supports hotplug storage devices such as USB disks. * Features LVM snapshots, file system mounting, on-screen notifications and report emails. * Features extensive logging designed to facilitate problem investigation. * For rsync backups, retains changed and deleted files thus providing a "rolling full" backup. * Is normally started by scheduler (anacron or cron) or by udev (after a hotplug storage device plug in event). * Is GPL-2.0+ licensed. * Is written in bash. * Was created in 2013 and is known to be used for backing up hundreds of laptops, PCs, routers and switches. As usual, the bung_3.0.7 files are available from https://redmine.auroville.org.in/projects/bung/files
Bug#983146: RFS: bung/3.0.6-1 [ITP] -- backup next generation
I have now updated the lintian pedantic clean source build. It is the bung_3.0.6-1 files at https://redmine.auroville.org.in/projects/bung/files Charles
Bug#983146: sponsorship-requests: Backup next generation (bung)
Hi Robin Thanks for the prompt reply. I tried hard to make a source .deb but did not manage to do so. Would you like me to share the system I use to create the .deb? bung was not a Debian package so I thought the appropriate place to install it was under /opt. If it becomes a Debian package then it should be installed in the conventional places. Best Charles On 20/02/2021 18:53, Robin Gustafsson wrote: Hi Charles, Where can I find the Debian source package? I found .deb files, but not how they're generated. Also, installing the files under /opt is disallowed for official packages. Regards, Robin
Bug#983146: sponsorship-requests: Backup next generation (bung)
Dear Maintainer, Please change the email address on this bug report from send_only.aurin...@auroville.org.in to b...@charlesmatkinson.org Best Charles Atkinson On 20/02/2021 08:34, Charles Atkinson wrote: Package: sponsorship-requests Severity: normal Dear Maintainer, bung has been developed over eight years as a campus backup utility, running on Debian and a few Ubuntu systems. It is known to be used on more than 100 computers Documentation includes man pages and, available from https://redmine.auroville.org.in/projects/bung/wiki/Bung_technology user and programmer guides Selected text from that page follows bung is a set of wrapper scripts for several backup utilities: * OpenLDAP (slapcat and tar) * mysqldump * pgdump * rsync bung also has: * A "sysinfo" facility to generate system information reports * Templated backups allowing custom backup commands. Example templates are provided for Cisco switches and MikroTik routers bung features: * Automated backup to hotplug devices when they are plugged in with on-screen notifications to both character terminals and X displays * Backup to remote file systems via ssh * Custom commands (hooks) to run before and after the backup itself * File system hierarchy standard (FHS) compliant installation under /opt. For cron jobs, documentation, the logcheck filter file and man pages, symlinks are created in the conventional places with targets under /opt. Fori convenience, /etc/opt/bung and /var/log/bung are created for configuration and logs * GPLv2 * Logging designed to ease production support * LVM snapshots * man pages * Mounting and unmounting local file systems * Remote ssh command validation Best Charles Atkinson
Bug#983146: sponsorship-requests: Backup next generation (bung)
Package: sponsorship-requests Severity: normal Dear Maintainer, bung has been developed over eight years as a campus backup utility, running on Debian and a few Ubuntu systems. It is known to be used on more than 100 computers Documentation includes man pages and, available from https://redmine.auroville.org.in/projects/bung/wiki/Bung_technology user and programmer guides Selected text from that page follows bung is a set of wrapper scripts for several backup utilities: * OpenLDAP (slapcat and tar) * mysqldump * pgdump * rsync bung also has: * A "sysinfo" facility to generate system information reports * Templated backups allowing custom backup commands. Example templates are provided for Cisco switches and MikroTik routers bung features: * Automated backup to hotplug devices when they are plugged in with on-screen notifications to both character terminals and X displays * Backup to remote file systems via ssh * Custom commands (hooks) to run before and after the backup itself * File system hierarchy standard (FHS) compliant installation under /opt. For cron jobs, documentation, the logcheck filter file and man pages, symlinks are created in the conventional places with targets under /opt. Fori convenience, /etc/opt/bung and /var/log/bung are created for configuration and logs * GPLv2 * Logging designed to ease production support * LVM snapshots * man pages * Mounting and unmounting local file systems * Remote ssh command validation Best Charles Atkinson
How to handle conffiles when renaming or splitting a package?
Hello everybody,
and happy new year !
I have recently split the mime-support package in two: media-types and
mailcap. But I wonder if I handled the conffiles correctly.
mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
package containing only a changelog and a copyright file, and depends on
media-types and mailcap. And these two packages declare a Breaks and
Replaces relationship against mime-support << 3.65.
As a result of the upgrade, the conffiles are now owned by the new
packages. But dpkg still keeps a record that the mime-support has
the "obsolete" version of them:
# dpkg-query -W -f='${Conffiles}\n' media-types
/etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530 /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n' mailcap
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n' mime-support
/etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
I have received reports from users who consider this a problem. Indeed,
in the case of mailcap it is potentially confusing as the conffile's MD5
sum has not changed.
On the other hand, once mime-support is purged, which is how
transitionnal packages eventually should be handled, the situation is
clean. So I am not sure if there is a problem here.
Is it needed to clean dpkg's database so that it does not report
obsolete conffiles for mime-support? (Actually, I would have expected
dpkg to do this automagically given the Breaks and Replaces
relationship.)
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work, https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy
Re: How to manage CPU-specific features in package ?
Le Sat, Apr 25, 2020 at 02:53:51PM -0400, Aaron Boxer a écrit : > > My library can use SIMD vector operations such as AVX2 if available on > system. > What is the best way of managing this ? Hello, maybe you can have a look at how other packages use `libsimde-dev`? https://wiki.debian.org/SIMDEverywhere Have a nice Sunday Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Riddled by debian-policy 8.1.1 about ldconfig
Le Thu, Sep 14, 2017 at 02:25:41PM +0200, Thomas Schmitt a écrit : > What is meant by "DEBIAN/triggers" in policy manual and man 5 deb-triggers ? > Is there supposed to be a "DEBIAN" directory under ./debian ? Hi Thomas, the `DEBIAN` directory is created in the process of building in binary packages. In the binary packages themselves, its contents become the contents of the `control.tar.gz` member. For a package "p", the file DEBIAN/triggers is installed in `/var/lib/dpkg/info/p.triggers`. You can find many real examples there. In particular, for libraries complying with the Policy, you will see that this file indeed "activate-noawait" the "ldconfig" trigger. For packages built using Debhelper, the triggers files is added by `dh_makeshlibs`, which explains why you can not see traces of it in the clean source package. I hope it clarifies. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: installing GUI launchers and mimes
Le Sun, Jul 30, 2017 at 11:55:20AM +0200, Narcis Garcia a écrit : > > Do you mean that with only having at the package: > ./usr/share/applications/xxx.desktop > ./usr/share/mime/packages/xxx.xml > triggers are automatically run? Hello Narcis, yes they will: $ grep usr/share/applications /var/lib/dpkg/triggers/File /usr/share/applications mime-support/noawait /usr/share/applications desktop-file-utils /usr/share/applications gnome-menus/noawait $ grep usr/share/mime/packages /var/lib/dpkg/triggers/File /usr/share/mime/packages shared-mime-info See /usr/share/doc/dpkg-dev/triggers.txt.gz for (a lot of) details. > Why transmission-gtk/postinst calls update-menus and update-mime ? Is it > some kind of compatibility measure? The short answer is: "because transmission-gtk/postinst is generated by debhelper fia dh_installmenu". $ cat /var/lib/dpkg/info/transmission-gtk.postinst #!/bin/sh set -e # Automatically added by dh_installmenu if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then update-menus fi I am not sure why this is still needed while there is already a dpkg trigger doing the work. Anyway, as noted elsewhere, the Debian menu system is being phased out. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: How to deal with arch-specific paths in .install files
Le Wed, May 03, 2017 at 11:36:01AM -0700, Shawn Sörbom a écrit : > > I have a package .install file where a library expects to go into /usr/lib/ > x86_64-gnu/[subdirectory] on amd64 systems. I realize this is not portable. > What regex can I use to substitute for the arch directory in my .install file? Hi Shawn, you can find an answer (and many alternatives) in the following wiki page: https://wiki.debian.org/Multiarch/Implementation Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Best GPG practices before sending computer to maintenance.
Hello everybody, the laptop that I use mainly for Debian development will go to hardware maintainance tomorrow. I will of course remove my .gnupg folder, but out of curiosity I wonder if there are better practices. The mass storage is a SSD that I am not going to remove it before sending the laptop. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: Review of firefox-branding-iceweasel
Le Tue, Apr 19, 2016 at 01:46:46PM -0700, Sean Whitton a écrit : > > "Every package must be accompanied by a verbatim copy of its copyright > information and distribution license in the file > /usr/share/doc/package/copyright." > > It then makes an *exception* to this verbatim rule: > > "Packages distributed under the Apache license (version 2.0), the > Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL > (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should > refer to the corresponding files under /usr/share/common-licenses, > rather than quoting them in the copyright file." > > Since you are not using /usr/share/common-licenses, your package doesn't > fall under this exception and so you need to include it in your > d/copyright file. Hi all, actually, the MPL-2 will be added to /user/share/common-licenses when a Policy Editor will find time to make it happen. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768292 So I suggest that it is fine to be forward-compatible with the future Policy :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Git-buildpackage question: tracking upstream git and tarballs
Le Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi a écrit : > > If I understand [1] and [2] correctly, one would need two upstream > branches : one originating from upstream, with the full commit history, > and one managed by gbp import-orig, which would contain upstream sources > imported as single tarballs commits. > > [1] http://www.eyrie.org/~eagle/notes/debian/git.html#combine > [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html > > I don't understand the reason for having two separate upstream branches. > Is there a specific reason against having a single upstream branch, > which would contain the full upstream commit history, and maintaining > the pristine-tar branch with a plain old "pristine-tar commit > " (since gbp import-orig would want to import the > tarball files and create a new tag, which both may conflict with the > upstream branch/tags) ? Hi Raphaël, if in your case it works well to pull updates directly from Upstream's repository and to use downloaded tarballs from the upstream website, then there is no problem to use pristine-tar directly instead of gbp import-orig, as you suggested. (The answer from Ferenc explains well why in some cases there can be problems caused by differences between the upstream repository and the upstream tarballs). If you do this and intend to make your source package's repository easy to use for collaborative maintenance, it will be good to document this workflow somewhere (perhaps README.source ?) since it is not standard. Otherwise, people may run gbp import-orig and waste time wondering why it did not work as expected. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: git-buildpackage pattern question
Le Mon, Mar 21, 2016 at 06:43:58PM -0700, Sean Whitton a écrit : > > In my usage of git-buildpackage, I've been using a different approach to > that suggested by Russ and I thought it might be useful to share it in > this thread. > > I think of (local) branches as things that I expect to make commits to, > and use tags to keep track of work done by upstream that is read-only > from my point of view. So in my repository I have all of upstreams tags > (1.0.0, 1.1.0, 1.0.2 etc.) and a master branch which contains both > upstream's code and my debian/ directory. There is no upstream branch. Hi Sean, not to nitpick your workflow itself, but I was wondering: with your approach, what is the advantage using git-buildpackage instead of simply `dpkg-buildpackage -i -I` ? For the sake of curiosity (and sorry to sidetrack the thread), what `gbp` commands are you still using in your workflow ? Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
[OT] Re: user want messages removed from mailing list
Le Wed, Nov 18, 2015 at 02:18:04PM +0100, Jakub Wilk a écrit : > > Reporting non-spam messages as spam is counter-productive. It won't help the > message disappear. But it will help actual spam messages to survive in our > archives. Hi Jakub, there are definitely precedents were messages containing private information that the poster did not want to send or regrets to have sent have been removed with the spam-removal interface. And I fail to see how it helps actual spam messages to stay, unless you are suggesting that by using the spam removal system for these purpose we will undermine it by demotivating or drain time from the people who use it for spam removal only, or that we will cause it to be more strongly moderated. I understand that listmasters do not have time to handle removal requests, but I think that we are being arrogant when we refuse for technical reasons. Especially with the trap situation that people tend to send removal requests to the debian-www address without knowing that it is also a publically archived mailing list. Some times I have the impression that our only answer is just shaming the requester. Anyway; there is not much to discuss. When I reads these requests, I tend to mark the message as spam. And sometimes it works. Cheers, -- Charles
Re: user want messages removed from mailing list
Le Mon, Nov 16, 2015 at 09:49:51PM +0800, Alex Vong a écrit : > > A user says he wasn't aware that the mailing list is public and want > his conversion with me and another person removed. I have replied to > him stating that the mailing list is like a public forum, everyone can > read it. He hasn't replied yet. But if he insisted on having the > conversation removed, what should I do? Hi Alex, You can mark it as spam and cross fingers that other people do the same and the spam cleaners (everybody's help is welcome by the way) feel compassion. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: cowbuilder/pbuilder: require newer version from experimental
Le Tue, Oct 27, 2015 at 03:11:08PM +0100, Ole Streicher a écrit : > > to build an "experimental" version of one of my packages, I need to > specify a package that is in unstable (1.0.5-1) and in experimental > (1.1~b1-1), and I need the experimental version here. Hi Ole, this is a bit off-topic answer, but if you use sbuild --build-dep-resolver=aptitude, you should be able to satisfy the dependency on the package in experimental. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Best practices for downloader packages
Le Tue, Aug 18, 2015 at 03:47:13PM +0200, Ole Streicher a écrit : After lunch, someone pointed out that the policy only requires that packages that download *software* need to go to contrib. Since my one would download *data* only, it would be probably suitable for main. Hi Ole, I doubt that the intention of the policy is to distinguish data and software here. Also, the current interpretation of the DFSG is that data is software. Altogether, in the case of your package, I think that it is a matter of taste. In my point of view, there is nothing wrong putting it in contrib, to represent that the access to the data is not as easy as if it were distributed inside the package. One of the points of Free software is that is can not be taken away from the user, and if one has a full copy of the Debian archive, it is possible to rely on all the programs and data in the main section. For downloader packages, however, they can become useless at any time, and the user has no control over this. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: doc-base for more than one document
Le Fri, Jun 19, 2015 at 04:26:58PM +0200, Ole Streicher a écrit : I am a bit confused on how I can register more than one document for one package. Hi Ole, one file per document; see the emboss package for instance. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20150620062414.gc19...@falafel.plessy.net
Re: Not able to pull dependencies for tests ran on ci.debian.net.
Le Tue, Jun 16, 2015 at 01:52:52PM +0200, Dominique Dumont a écrit : from the logs, tabix package is not installed. Neither samtools or samtools-test depends on tabix. Looks like ci does not install build dependencies... Thanks Dominique, but I would have expected tabix to be installed because the file debian/tests/control declares “Depends: @, tabix”. Am I misunderstanding how this control file is used ? Cheers, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20150617082105.ga...@falafel.plessy.net
Not able to pull dependencies for tests ran on ci.debian.net.
Good evening everybody,
I am probably missing something obvious, but I have simple problem with the
samtools package, where the regression tests depend on the tabix package for
the bgzip command, and fail on ci.debian.net despite my attempt to set the
dependency properly...
$ curl
http://anonscm.debian.org/cgit/debian-med/samtools.git/plain/debian/tests/control
Tests: samtools-test
Depends: @, tabix
Restrictions: allow-stderr
$ curl --silent --compressed
http://ci.debian.net/data/packages/unstable/amd64/s/samtools/20150607_002702.autopkgtest.log.gz
| tail -n15
Setting up samtools-test (1.1-1) ...
Setting up adt-satdep (0) ...
Processing triggers for libc-bin (2.19-18) ...
adt-run [00:27:23]: test samtools-test: [---
The command failed [32512]: cat /tmp/YHnFtIRjxI/bgzip.dat | bgzip -ci
-I/tmp/YHnFtIRjxI/bgzip.dat.gz.gzi /tmp/YHnFtIRjxI/bgzip.dat.gz
out:
err:/bin/bash: bgzip: command not found
at ./test.pl line 67.
main::error(The command failed [32512]: cat /tmp/YHnFtIRjxI/bgzip.dat
| b..., out:\x{a}, err:/bin/bash: bgzip: command not found\x{a}\x{a})
called at ./test.pl line 138
main::cmd(cat /tmp/YHnFtIRjxI/bgzip.dat | bgzip -ci
-I/tmp/YHnFtIRjxI/b...) called at ./test.pl line 300
main::test_bgzip(HASH(0x1951e78)) called at ./test.pl line 35
adt-run [00:27:24]: test samtools-test: ---]
adt-run [00:27:24]: test samtools-test: - - - - - - - - - - results - - -
- - - - - - -
samtools-testFAIL non-zero exit status 127
Does anybody spot what I have been missing ?
Have a nice day
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
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/2015061657.ga19...@falafel.plessy.net
Re: dep5-copyright-license-name-not-unique
Le Tue, Mar 03, 2015 at 03:59:31PM +0100, Helge Kreutzmann a écrit : Hello, I recently got lots of errors for the debian/copyright files of my two packages using the machine style copyright. The expanded version states This paragraph define an already defined license., however the paragraphs I checked only use GPL-2+. Hello Helge, I think that the lintian tag is either too strict or too severe, given that the machine-readable format permits to repeat the long description in multiple Files paragraphs. I opened https://bugs.debian.org/779676 about this. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20150303222139.ga14...@falafel.plessy.net
Re: launchpad for debian and autobuilders
Le Fri, Dec 12, 2014 at 09:15:44AM +0100, Leopold Palomo-Avellaneda a écrit : I build my packages with pbuilder, but I'm looking for an automatic place to build packages for debian. Dear Leopold, how about Elida ? https://packages.debian.org/sid/elida Cheers, -- Charles -- 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/20141212082034.gi3...@falafel.plessy.net
Re: Install files based on architecture?
Le Sat, Sep 27, 2014 at 06:55:03PM +0800, Bamm a écrit : Is it possible for the debian/install file to install a file based on architecture? Perhaps something like this? bin/$arch/* usr/bin Where $arch is either i386 or amd64? Hello Bamm, you can have a look at dh-exec and how it is used in the particular case of multi-architecture packages. https://wiki.debian.org/Multiarch/Implementation But as Paul noted, wildcards are enough as long as you do not need $arch to be in the target. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140927113459.gc2...@falafel.plessy.net
Re: Samtools fails to build on several architectures [nore...@buildd.debian.org: failed i386 build of samtools 1.0-1]
Le Tue, Sep 23, 2014 at 02:44:16PM +0200, Jakub Wilk a écrit :
samtools stats displays help, but only if stdin is a terminal. If
it is not, it'll read data from it:
if ( !bam_fname )
{
if ( isatty(STDIN_FILENO) )
error(NULL);
bam_fname = -;
}
Brilliant, many thanks !
The issue was then quickly solved upstream.
https://github.com/samtools/samtools/issues/300
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
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/20140925000902.ga2...@falafel.plessy.net
Re: Packaging from upstream's Git repository.
Dear Yukiharu and Jeremy, thanks for your answers. Yes, I know about git-buildpakcage and will use it in last ressort. There are multiple reasons why I prefer to base my packages on the upstream Git repository when it exists. First, in my experience, this tremendously eases the exchange of patches between us and upstream. Second, some upstreams start to prefer releasing tags instead of tarballs, especially for release candidates. Lastly, the Git repository is the source, while some files in the tarball are autogenerated. While we have a long-standing tolerance for some kind of autogenerated files, I think that it is preferable to use the source directly. So, are there other suggestions ? Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140713044722.gg12...@falafel.plessy.net
Re: Licensing question
Le Fri, Jul 11, 2014 at 11:21:24AM -0400, Paul Tagliamonte a écrit : I'll of course defer to Charles' ability to understand french, so working from the English translation (which is to say, I might be missing something), I don't see the same issues he does. Both the ISC and MIT/Expat license don't explicitly allow distribution of modified works, but it's pretty implicit: Hi all, the essence of my conclusion in 2012 was: “in doubt, ask Upstream”. Sorry that it was not clear. Also, if after reading the email of Jonathan Keller in the same thread you still have no doubts, go ahead with your conclusion; the worst case scenario is only to have to remove the packages from our Project's main archive later. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140711231753.ga12...@falafel.plessy.net
Packaging from upstream's Git repository.
Hello everybody, I am trying to package the new 'datamash' tool. http://www.gnu.org/software/datamash/ I am currently in contact with the upstream author about how to make the Debian source package. I would prefer to propose him a solution where the sources used by Debian are directly his Git repository, intead of using git-import-orig to import tarballs made by ‘make distcheck’, since the first solution obviously enhances the possibility to exchange patches. I am blocking on the fact that he uses gnulib in a way that the version number of his program is expressed only via a Git tag. Thus, given that Debian source package are based on tar archives, the version number is lost unless I use the “sources” produced by ‘make distcheck’. Does anybody know a simple solution to that problem ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140712044552.ge12...@falafel.plessy.net
Re: Help for watch file needed
Le Sun, Jun 29, 2014 at 11:43:47AM +0200, Andreas Tille a écrit : At first I do not understand why uversionmangle=s/\./-/g does not work: $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=uversionmangle=s/\./-/g http://thegrantlab.org/bio3d/download/download-bucket .*bio3d-v([-.0-9]+) -- Found the following matching hrefs: /bio3d/download/download-bucket?download=1:bio3d-v2-0-1 (2-0-1) /bio3d/download/download-bucket?download=1:bio3d-v2-0-1 (2-0-1) Newest version on remote site is 2-0-1, local version is 2.0-1 = remote site does not even have current version -- Scan finished Hi Andreas, shouldn't it be s/-/./g instead ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140629095848.ga22...@falafel.plessy.net
Re: script-with-language-extension
Le Mon, Mar 10, 2014 at 03:19:51PM +0800, Thomas Goirand a écrit : On 03/10/2014 04:49 AM, Salvo Tomaselli wrote: Not sure if fixing it by renaming the files is what you want to do. I have such a warning in xinetd and honestly I just ignore it because I don't think that renaming scripts after they have been there for many years is a good idea. Besides that's the upstream name so that's how they will be probably called in other distributions too I guess. The Debian policy manual don't agree with you, AFAIR. Hi Thomas, This is very unfortunate. I have ashamed myself sending scripts to colleagues that did not work on their platform, just because I developed them on Debian, which corrects file names unilaterally. I would prefer my colleagues to know Debian for being rock solid and secure, rather than know it for being incompatible by design with the rest of the Unix world. Cheers, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140310072711.gc9...@falafel.plessy.net
How to selectively silence git-multimail messages ?
Le Sat, Jan 25, 2014 at 10:55:16AM +0800, Paul Wise a écrit : The news are collected on http://wiki.debian.org/DeveloperNews Email notifications for git commits on git.debian.org - […] -- Raphaël Hertzog [1] http://wiki.debian.org/Alioth/Git#Commit_mails_with_diff [2] https://github.com/mhagger/git-multimail/ This was an excellent improvement, many thanks to Raphaël for this. Sometimes, I can guess in advance that a push will generate a flood of emails that will not be very relevant at best and annoying at worse on my packaging team's mailing list. For instance, merges from upstream's master branch, with hundreds of commits that do not change the contents of the debian directory. Sometimes, to avoid them, I log on Alioth and disable temporarly the commit hook. Would anybody be able to improve the system so that, when pushing with the --quiet option, the individual emails for each commits will be skipped ? Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125053149.gh24...@falafel.plessy.net
Re: (uscan) Files-Excluded mecanism documentation ?
Le Thu, Dec 12, 2013 at 04:38:20PM +0100, Andreas Tille a écrit : http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ with no luck so far. I received the answer from DEP5 drivers that this format (version 1.0) will not be changed. Hi Andreas, The DEP 5 work is finished, and I think that its' drivers opinion on the contents of http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ does not have more weight than the one of other developers, including yours. This said, I think that going for a 1.1 update is the best solution. It is hard to say how long it will take, but in theory, it can be as fast as providing a patch to #685506, have it accepted, and upload an updated debian-policy package. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213005921.ga25...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Fri, Nov 22, 2013 at 09:31:25AM +0100, Andreas Tille a écrit : On Fri, Nov 22, 2013 at 09:10:44AM +0100, Raphael Hertzog wrote: On Fri, 22 Nov 2013, Andreas Tille wrote: $ gbp-clone ssh://git.debian.org/git/debian-med/htslib.git $ cd htslib (debian/unstable) $ git branch * debian/unstable develop pristine-tar (debian/unstable) $ git-buildpackage (debian/unstable) $ lintian -I --pedantic ../build-area/htslib_0.2.0~rc4-1_amd64.changes The mere fact that the generated files are in ../build-area/ means that you're using --git-export-dir (via ~/.gbp.conf) and thus you are building in a directory that doesn't have the .git dir. It's an export (with git archive) that is unpacked in ../build-area/package/ that you use as build directory. Well, that's correct. So trying again: $ cd .. $ ln -s build-area/htslib_0.2.0~rc4.orig.tar.gz $ cd htslib (debian/unstable) $ pdebuild Hi Andreas, I suspect that pdebuild is also using either an export or an unpacked source package. I think that if you use dpkg-buildpackage directly, you will reproduce the problem. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131122090851.gi16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Thu, Nov 21, 2013 at 09:00:48AM +0100, Andreas Tille a écrit : PS: Alioth is back online and I might have a look later this day if you would commit there. Thanks a lot ! gbp clone git.debian.org:/git/debian-med/htslib.git Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131121082926.gf16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Thu, Nov 21, 2013 at 11:26:24AM +0100, Andreas Tille a écrit : On Thu, Nov 21, 2013 at 05:29:26PM +0900, Charles Plessy wrote: gbp clone git.debian.org:/git/debian-med/htslib.git When doing `git-buildpackage` (which for sure includes the .git dir) I can not see the effect you are describing. The only thing lintian (and I) are more concerned about is: E: libhts0: symbols-file-contains-current-version-with-debian-revision on symbol cram_index_build@Base W: libhts0: symbols-file-contains-debian-revision on symbol bam_mplp_init_overlaps@Base and 1 others I personally would simply drop the symbols file since it seems to introduce more harm than good. Hi Andreas, this is strange, in my case, from a fresh clone, and when building with git buildpackage -us -uc, I see the hardening-no-relro tag. $ lintian -I --pedantic ../htslib_0.2.0~rc4-1_amd64.changes I: htslib source: quilt-patch-using-template-description debian-changes W: htslib source: newer-standards-version 3.9.5 (current is 3.9.4) W: libhts0: hardening-no-relro usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 P: libhts0: no-upstream-changelog E: libhts0: symbols-file-contains-current-version-with-debian-revision on symbol cram_index_build@Base W: libhts0: symbols-file-contains-debian-revision on symbol bam_mplp_init_overlaps@Base and 1 others P: libhts-dev: no-upstream-changelog W: libhts-dev: manpage-has-errors-from-man usr/share/man/man5/vcf.5.gz file `standard input', around line 15: P: htslib-test: no-upstream-changelog For the tags related to the symbols file, this is because the package is work in progress. I pull upsteam commits as they go and only update the version number when upstream makes new tags, therefore Debian revisions contain changes to the library's symbols. Given that the API is not yet stable, I understand that the symbols file is not yet useful, but I prefer having it in the package now so that I do not forget to add it when I start to upload packages built on the htslib-dev package. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131122052333.gh16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Wed, Nov 20, 2013 at 10:24:29PM +0100, Andreas Tille a écrit : without having checked out the repository and diving into it: Can you post a diff of the two build logs? Hi Andreas, here it is (attached). Could the problem be a side effect of the test suite ? Cheers, -- Charles --- with-.git 2013-11-21 09:32:14.244499056 +0900 +++ without-.git2013-11-21 09:34:12.908497923 +0900 @@ -150,15 +150,6 @@ dh_auto_test make -j1 test make[2]: Entering directory `/tmp/htslib' -echo '#define HTS_VERSION debian/0.2.0_rc3-1-38-g9469458' version.h -gcc -g -Wall -O2 -I. -DSAMTOOLS=1 -c -o hts.o hts.c -ar -rc libhts.a kfunc.o knetfile.o kstring.o bgzf.o faidx.o hfile.o hfile_net.o hts.o sam.o synced_bcf_reader.o vcf_sweep.o tbx.o vcf.o vcfutils.o cram/cram_codecs.o cram/cram_decode.o cram/cram_encode.o cram/cram_index.o cram/cram_io.o cram/cram_samtools.o cram/cram_stats.o cram/files.o cram/mFILE.o cram/md5.o cram/open_trace_file.o cram/pooled_alloc.o cram/sam_header.o cram/string_alloc.o cram/thread_pool.o cram/vlen.o cram/zfio.o -ranlib libhts.a -gcc -pthread -o test/fieldarith test/fieldarith.o libhts.a -lz -gcc -o test/hfile test/hfile.o libhts.a -lz -gcc -pthread -o test/test_view test/test_view.o libhts.a -lz -gcc -pthread -o test/test-vcf-api test/test-vcf-api.o libhts.a -lz -gcc -pthread -o test/test-vcf-sweep test/test-vcf-sweep.o libhts.a -lz test/fieldarith test/fieldarith.sam test/hfile cd test ./test_view.pl @@ -456,11 +447,11 @@ Failures 0 cd test ./test.pl test_vcf_api: - /tmp/htslib/test/test-vcf-api /tmp/Vvj_N60T4W/test-vcf-api.bcf + /tmp/htslib/test/test-vcf-api /tmp/cUKPv4vctM/test-vcf-api.bcf .. ok test_vcf_sweep: - /tmp/htslib/test/test-vcf-sweep /tmp/Vvj_N60T4W/test-vcf-api.bcf + /tmp/htslib/test/test-vcf-sweep /tmp/cUKPv4vctM/test-vcf-api.bcf .. ok @@ -495,10 +486,6 @@ make -j1 install DESTDIR=/tmp/htslib/debian/tmp AM_UPDATE_INFO_DIR=no prefix=/usr PACKAGE_VERSION=0.2.0\~rc4-1 make[2]: Entering directory `/tmp/htslib' mkdir -p /tmp/htslib/debian/tmp/usr/include/htslib /tmp/htslib/debian/tmp/usr/lib /tmp/htslib/debian/tmp/usr/share/man/man5 -echo '#define HTS_VERSION 0.2.0~rc4-1' version.h -gcc -g -Wall -O2 -I. -DSAMTOOLS=1 -fpic -c -o hts.pico hts.c -gcc -shared -Wl,-soname,libhts.so.0 -o libhts.so kfunc.pico knetfile.pico kstring.pico bgzf.pico faidx.pico hfile.pico hfile_net.pico hts.pico sam.pico synced_bcf_reader.pico vcf_sweep.pico tbx.pico vcf.pico vcfutils.pico cram/cram_codecs.pico cram/cram_decode.pico cram/cram_encode.pico cram/cram_index.pico cram/cram_io.pico cram/cram_samtools.pico cram/cram_stats.pico cram/files.pico cram/mFILE.pico cram/md5.pico cram/open_trace_file.pico cram/pooled_alloc.pico cram/sam_header.pico cram/string_alloc.pico cram/thread_pool.pico cram/vlen.pico cram/zfio.pico -lz -ln -sf libhts.so libhts.so.0 install -p -m 644 libhts.so /tmp/htslib/debian/tmp/usr/lib/libhts.so.0.2.0~rc4-1 ln -sf libhts.so.0.2.0~rc4-1 /tmp/htslib/debian/tmp/usr/lib/libhts.so ln -sf libhts.so.0.2.0~rc4-1 /tmp/htslib/debian/tmp/usr/lib/libhts.so.0 @@ -660,7 +647,7 @@ dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libhts0/DEBIAN/symbols doesn't match completely debian/libhts0.symbols --- debian/libhts0.symbols (libhts0_0.2.0~rc4-1_amd64) -+++ dpkg-gensymbolskXM3kh 2013-11-21 09:32:00.312499189 +0900 dpkg-gensymbols4DQT53 2013-11-21 09:34:08.056497969 +0900 @@ -230,6 +230,7 @@ cram_huffman_encode_int0@Base 0.2.0~rc3 cram_huffman_encode_int@Base 0.2.0~rc3 @@ -675,12 +662,12 @@ rm -f debian/htslib-test/DEBIAN/shlibs dh_shlibdeps dpkg-shlibdeps -Tdebian/libhts0.substvars debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0\~rc4-1 -dpkg-shlibdeps: warning: symbol exp used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries -dpkg-shlibdeps: warning: symbol pthread_join used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries -dpkg-shlibdeps: warning: symbol pthread_kill used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol pthread_create used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries +dpkg-shlibdeps: warning: symbol exp used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol lgamma used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries +dpkg-shlibdeps: warning: symbol pthread_kill used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol log used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none
No relro when building from inside a Git package ?
Dear all, I am experience a strange variation when building package from a Git repository or from the same source with the .git directory deleted. In the first case I have the Lintian warning 'libhts0: hardening-no-relro usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1', but not in the second case. The only git-dependant code that I found is to create a package version, but I override it in debian/rules by the Debian package's version. In Makefile: ifneq $(wildcard .git) original_version := $(PACKAGE_VERSION) PACKAGE_VERSION := $(shell git describe --always --dirty) In debian/rules: override_dh_auto_build: dh_auto_build -- \ CFLAGS=$$(dpkg-buildflags --get CFLAGS) \ CPPFLAGS=-I. -DSAMTOOLS=1 $$(dpkg-buildflags --get CPPFLAGS) \ LDFLAGS=$$(dpkg-buildflags --get LDFLAGS) \ PACKAGE_VERSION=$(DEB_VERSION) override_dh_auto_install: dh_auto_install -- prefix=/usr PACKAGE_VERSION=$(DEB_VERSION) (Digression: I do this because after tagging a debian revision, for instance 'debian/0.2.0_rc3-1', the package will fail to build from the Git repository since the tag becomes used for the soversion of the library, and the slash is mistaken as a directory separator. Is there a smart solution to this problem ?) You can get the source with 'gbp clone https://github.com/Debian/htslib'. Does anybody see why the hardening-no-relro is triggered when building in presence of the .git directory ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131120054439.gb16...@falafel.plessy.net
Is it still needed to pre-depend on multiarch-support ?
Hello everybody, now that Wheezy has been released, I am wondering if it is still needed to pre-depend on multiarch-support, especially for a new package. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131108051240.gb9...@falafel.plessy.net
Re: [Debian-med-packaging] Please help: sra-sdk
Le Tue, Oct 22, 2013 at 08:43:05PM +0200, Andreas Tille a écrit : I have done the changes needed to build sra-sdk in an unstable chroot manually. It remains totally unclear to me why the build fails with pbuilder but works in a minimal unstable chroot anyway. Charles, if you can build the package, could you at least run your test to confirm whether the upstream code leads to the same results as our current version? Thanks Andreas, I tested the 'fastq-dump' command using the file at the URL below, and this time it worked. http://ftp-trace.ncbi.nlm.nih.gov/sra/sra-instant/reads/ByExp/sra/SRX/SRX001/SRX001881/SRR006565/SRR006565.sra I can not upload from work, becaues I removed my GPG key from my Debian computer after I started to share administrative privileges with a colleague, so if you are faster than me, please do not hesitate to upload. Just pull the most recent changes before, as I updated the symbols file. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131023010012.gf17...@falafel.plessy.net
Re: DFSG and assembler code
Le Wed, Aug 21, 2013 at 10:01:29AM +0200, Andreas B. Mundt a écrit : To be able to compile the program with standard tools, the pre-compiled code of the ROM-dumpers is included in the source. This code needs to be removed for DFSG reasons. Hi Andreas, note that the DFSG do not imply that we need to remove the pre-compiled code from the source package. If 1) it can be redistributed; 2) its source code is provided; 3,4) its modification is allowed in practical terms; 5,6) there are no unreasonable restrictions on how to use it, and 7,8,9) its license is not awkward, then the work is Free according to the DFSG. Nevertheless, our current quality standards for the binary packages is that each file must be rebuildable from source, and for the ROMs discused here, without the proper compiler in Debian it is not possible. So in practice, this pre-compiled code can not be added to the binary packages, but I would like to stress that it is not because of the DFSG. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821133612.gb20...@falafel.plessy.net
Re: How to handle a package requiring external test data for its test suite?
Le Tue, Jun 18, 2013 at 08:10:29AM +0900, Thomas Moulard a écrit : I am currently packaging a computer vision software[1] which test suite requires external data (images). Considering the weight of the images (~75Mb) compared to the package size (a few Mb) they decided to distribute them separately. Dear Thomas, Have you considered running the tests with autopkgtest ? http://dep.debian.net/deps/dep8/ Then, you can either download the data or install it from a separate data package. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617233325.ga25...@falafel.plessy.net
A smart post-commit hook to cherry-pick only Debian changes ?
Hello everybody, With Git, I just created an email deluge by merging an upstream branch in the master branch of the repository where I maintain the euca2ools package, and pushing to Alioth, which sent hundreds of commit messages on our commit mailing list... Does anybody knows a good post-commit hook that will only send an email for the changes related to the Debian packaging ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616025449.gb7...@falafel.plessy.net
Re: What the proper way to update debian/changelog
Le Fri, May 24, 2013 at 02:14:39AM +, T o n g a écrit : Not complaining, Debian has lot of good documents. Just that they are not to my taste. :-) They are written in the reference book style, whereas I more prefer a cook book style. :-) Still not complaining -- We've got to appreciate what we already have so far. Hi, have you considered the following tutorial ? http://www.debian.org/doc/devel-manuals#packaging-tutorial Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130524042425.ga7...@falafel.plessy.net
testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 just testing to make sure the mail goes through now. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGAzFQACgkQIUUjp07y+ZbAOwCeMD2rcK3s791YoT7TB0dLsryO KDoAnib33PJ7JvAKA0KlJA5yf+t/PfQB =UeVM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/itsig.68336f157a.5180cc54.8040...@itadmins.net
Bug#706361: gti review
Le Wed, May 01, 2013 at 05:37:50PM +1000, Dmitry Smirnov a écrit : ## debian/copyright License name MIT is incorrect even though upstream may refer to this license as such. MIT is considered ambiguous by the Free Software Foundation. copyright-format-1.0 specification recommends to label newer MIT license as Expat however this is an older variant so it would be better called MIT-old-style or similar. See http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ https://en.wikipedia.org/wiki/MIT_License Hi all, to be comprehensive, there are also the Software Package Data Exchange project and the Open Source Initiative which both agree on a reference MIT license: http://opensource.org/licenses/MIT http://spdx.org/licenses/MIT So if it matches the above, it may be fair to call it MIT if Upstream calls it MIT. In the case of gti, the license does not match the text of the MIT or Expat license, therefore it is better to use an arbitrary short name. Something like gti, or MIT-like (as Upstream calls it), etc. would be enough. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130501084219.gc19...@falafel.plessy.net
Re: Debian Preseeding: prevent particular package from being installed
Le Tue, Mar 19, 2013 at 11:56:19AM +0100, Konrad Vrba a écrit : I am using Debian preseeding for automated installations (from PXE) in my preseed config file, I have the following line, to install only the minimum number of packages: tasksel tasksel/first multiselect d-i base-installer/install-recommends boolean false This however still installs some packages which I don't want. My question is: how does the installation script decide which packages will be installed? how can I modify this list? can I prevent specific package to be installed or, is there some other Debian mailing list, which would be more appropriate for my question? Hi Konrad, on the debian-b...@lists.debian.org there are people who are the most likely to be able to answer your question, but before asking there it may be useful to ask first on a debian user mailing list, where there may be people experienced with preseeding as well. I am not sure if it will work, but have you tried d-i base-installer/excludes ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130320060449.ge30...@falafel.plessy.net
Re: Changelog etiquette for upstream patches
Le Fri, Mar 01, 2013 at 10:05:52PM +, Tony Houghton a écrit : The thing is there isn't a separate patch in the debian packaging or elsewhere in the pending release tarball because I've applied the patch to the code upstream. Dear Tony, for changes made upstream, you can thank the contributor in the upstream changelog. It is not necessary to repeat the information in the Debian changelog. If there was a Debian bug associated to the issue, you can mention its number together with the mention of a New upstream version. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302005250.ga12...@falafel.plessy.net
Re: Why is it so hard to get sponsors.....?
Le Thu, Feb 28, 2013 at 01:04:39PM -0430, PICCORO McKAY Lenz a écrit : I've noticed that some reports have response as is not critical, is still working, or else not reproducible, or better u can made a patch u can made a fix u ca... u can.. u do that co DD/DM has no time!! NO TIME!?? Hi Lenz, with time, DDs tend to meet loved ones, make children, be promoted at work, have new passions, develop new talents not related to software, take care of their old relatives, etc. If you have time to dedicate to packaging, please step up and help the teams you mentionned. What DDs who become short in time make sure in these teams, is that the infrastructure and learning curves are as easy as possible for newcomers, in order to to help others to contribute where they can not do themselves anymore. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301035115.gc12...@falafel.plessy.net
Exact matches in files in control data format.
Hello everybody, I am trying to parse the tasks files in tasks directory of the tasksel package: I would like to list all the tasks that are in the l10n section and enhance the desktop task. Example: Task: japanese-desktop Enhances: desktop, japanese Section: l10n Key: task-japanese-desktop Using grep-dctrl, I tried the following command (with contortions to avoid the po directory and the README). find . -maxdepth 1 -type f | xargs grep -l '^Task:' | xargs grep-dctrl --exact-match -FSection l10n \ --and \ --exact-match -FEnhances desktop \ -sTask -n Unfortulately, this only returns me the tasks that enhance the desktop task and nothing else, like in the following. Task: british-desktop Test-lang: en_GB Enhances: desktop Section: l10n Key: task-british-desktop However, if I relax the search, I also get tasks that enhance gnome-desktop, like the following: Task: japanese-gnome-desktop Enhances: gnome-desktop, japanese-desktop Section: l10n Key: task-japanese-gnome-desktop Does anybody know a workaround ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130227140023.ga13...@falafel.plessy.net
Re: RFS: libengsas packages
Le Tue, Feb 26, 2013 at 08:56:11AM +0100, Helmut Grohne a écrit : On Mon, Feb 25, 2013 at 06:58:22PM +0100, Anton Gladky wrote: On 02/25/2013 05:37 PM, Andrew Shadura wrote: 6) Copyright-file must be in DEP-5 format. Please don't say 'must' when you're speaking about what's actually a recommendation, not a rule. Thanks. ok, agree, my typo. But I think it is desirable to ask for DEP-5 for new uploads. In addition it is not even possible to use DEP-5 for every case. http://lists.debian.org/debian-devel-games/2013/02/msg00065.html is a recent example where a license cannot be reformatted to fit into DEP-5, because it expressly prohibits modification. (I have to admit that this is non-free.) Hi all, in case of Steam, I do not think that including a copy of the license in a debian copyright file following the machine-readable format constitutes an alteration of the license. First, the original file in the sources is unmodified. Second, indentation and escape of empty lines is not a modification of the license, but a formatting to allow the retreival of the pristine text using dedicated software. For instance, the tool config-edit displays license texts after converting them back to plain text. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130226083157.ga23...@falafel.plessy.net
Package install location for 0700 Directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, My name is Chuck and I am new to the list. I am currently working on building a package based on the ClusterLabs Hawk web GUI. Thanks to the people in #debian-mentors I have most of the package complete. It works perfectly in Squeeze and I will be starting builds for Wheezy today or tomorrow. However, I still have 1 problem. This package controls entire clusters (corosync, pacemaker, et al) and thus is designed with directory rights of 0700 for user hacluster (user used to run corosync). The problem is that 0700 directories are against policy in /usr/share. However, lighttpd is the delivery agent for the package and such apps (phpmyadmin and other web gui's) are usually installed in /usr/share. If I set the directories at 755 then there is the possibility that any service/script could execute files in the directory and thus control the cluster. I had considered moving it all to /var/lib but that doesn't seem to be correct to me. Is there a better location for the install where I can actually set 0700 permissions? Thanks for your comments and ideas, Charles Williams -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEYvg0ACgkQIUUjp07y+Zbj0ACfY/mbVMtpIxIyouT18kETpyIy EisAoKHF0kxNOrTt2xrvGr7FICFAcvK6 =0xgA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5118be0e.2040...@itadmins.net
Re: Package install location for 0700 Directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, Please excuse me for not posting something as obvious as the link to the package. http://packages.itadmins.net/debian/pool/main/h/hawk/hawk_0.5.2-0squeeze1.dsc as you can see it is currently for squeeze (my production servers) but I will be porting to wheezy as soon as I get this situation taken care of. This is just a web gui to the cluster and operates just peachy without the gui. However, that said, corosync/pacemaker/heartbeat can be a bit time consuming and the gui can help an admin save some of that time. The security of the cluster itsself (security between the nodes in the cluster) has nothing directly to do with the gui except that one can access the cluster through the gui. This is not unlike other web gui's which offer similar functionality (webmin, confixx hsphere to name a few). The point is to make the install as secure as possible while retaining the ease of functionality. Chuck On 02/11/2013 01:30 PM, Paul Wise wrote: Could you link to your source package so we can see what you are talking about? I would expect a network service to use proper authentication methods like RSA keys of some form (SSH/OpenPGP/X.509), is this cluster thing really having no authentication and using file permissions to protect the service? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEY7YsACgkQIUUjp07y+ZYjJACgviHkvRHhkmJTMizgRgylqok+ O2oAnA0zEal3EoQ4RnF4ByT0qS2Xb9fS =vPzh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5118ed91.3070...@itadmins.net
Re: xdg menu entries
Le Thu, Feb 07, 2013 at 03:50:58PM +1000, Steven Hamilton a écrit : 1) How are XDG .desktop files handled. What is Debian policy regarding these? 2) Is it acceptable to create a .desktop file for the game, or more appropriately, is it acceptable to create a shell script in /usr/games/ that can execute the Mari0 game with a single command? That way people can run it from a command line. Dear Steve, the best solution for the menu entry is to write a .desktop file and send it upstream, so that their build system will install it in the appropriate directory for all users. In the meantime, you can ship it in the Debian part of the source package, and install it in /usr/share/applications. Dpkg triggers will take care of everything else. There is currently no policy for FreeDeskotop (XDG) menu files, however the format has a nice speficication for you to follow. http://standards.freedesktop.org/desktop-entry-spec/latest/ In addition, the program `desktop-file-validate`, from the desktop-file-utils package, will be useful for you to check your Desktop entry file before sending it upstream and distributing in Debian. (For the possibility to drop a script in /usr/games, I have no comment to make). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130207060242.ga6...@falafel.plessy.net
Re: [Debian-med-packaging] Bug#699260: Help (Was: Bug#699260: r-cran-genabel: FTBFS: error: subscript out of bounds)
tag 699260 confirmed severity 699260 grave thanks Le Tue, Jan 29, 2013 at 01:28:36PM -0600, Dirk Eddelbuettel a écrit : Also, CRAN has 1.7-3, you guys are at 1.7-0 of GenABEL. Maybe this even changed upstream... Indeed :) +*** v. 1.7-3 (2013.01.09) + +(2013.01.09) +Commented the parts related to non-additive GC in qtscore +Removed calls to 'attach' from multiple procedures +Decrease of running time for long-running examples (GC_ovdom,GC,check.marker,Xfix,srdta) + +(2013.01.07) +Fixing the problem which prevents the package from loading while checking the version on CRAN I confirm that 1.7-0 fails and 1.7-3 builds. Also, the error also affects the binary package (version 1.7-0), rendering it useless. Our choices are: a) distribute 1.7-3 in Wheezy (note that the diff is not small), b) backport the correction, and c) remove r-cran-genabel from Wheezy. I volunteer for a), and I am neutral with b) and c). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130130044725.ga27...@falafel.plessy.net
Re: Maintainer address for collab-maint team maintained packages
Le Mon, Nov 19, 2012 at 06:54:26PM +0100, Arno Töll a écrit : On 11/19/2012 03:28 PM, Marc Haber wrote: package@packages.debian.org seems to add that header automatically before forwarding to the PTS, but using that address as Maintainer: is a lintian _error_ (not even a warning) (Severity: serious, Certainty: certain). Thing is, you can't use the QA forwarder because it relies on your source control field to learn about actual forwardings. If you would add right that address, the result would be an infinite loop because you would essentially forward mail to package@packages.debian.org to package@packages.debian.org. I hope it is clear why this won't work. Hi all, I think that the best way forward would be to fix the PTS and remove the infinite loop. This would be tremendously useful for many packages that are collectively maintained. I have no time to do it myself, but see the following wiki page to contribute. http://wiki.debian.org/qa.debian.org/pts Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121119230404.gb10...@falafel.plessy.net
Re: Once more: Need help updating my DM upload permissions
Le Fri, Nov 16, 2012 at 10:32:29AM +0100, Thomas Friedrichsmeier a écrit : I am a Debian Maintainer, working on a single package, rkward[1]. As my former sponsor appears to be MIA, I have previously posted to debian- mentors[2,3], asking for help adjusting my upload permissions to the new management interface[4] (for details on what I need a DD to do, refer to [2]). Hi Thomas, In 2009 I encouraged you to apply for DM and my opinion has not changed since. I just granted you upload privileges on rkward. For #689982, it can be corrected by uploading to wheezy-proposed-updates if need is. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121117114502.gc29...@falafel.plessy.net
Re: asking for package removal
Le Fri, Sep 21, 2012 at 11:42:23AM -0300, gustavo panizzo gfa a écrit : hello i was going through the list of rc bugs for wheezy and i found #687579. while i think the package should be removed (dead upstream, doesn't work with wheeze version of it's dependencies) i'm not the maintainer. how long do i have to wait to maintainer to reply before ask to ftp team to remove the package? can i (neither maintainer, uploader or DD) ask for removals? is nothing personal with the package or the maintainer, is was just doing QA. thanks PS: i wasn't sure if send this to mentors or qa Hi, It looks like the maintainer of abby has recently packaged a replacement, nomnom. Since this shows he is still active, I recommend to wait two weeks for his answer to the proposition to remove the package, that you made in http://bugs.debian.org/687579#10. In the absence of answer, debian-qa is an appropriate list to discuss further the removal. If there a consensus for it, you can submit the request yourself to the FTP team. But I think you were right to use debian-mentor for asking for a general advice. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120922033211.ge8...@falafel.plessy.net
Re: How to remove a package from unstable
Le Sat, Sep 15, 2012 at 04:04:19PM +0200, Olе Streicher a écrit : I accidently uploaded a package to unstable (python-cpl) that should have gone to experimental. How can I remove that from unstable but not from testing? Dear Ole, if the presence of this package is really disruptive, you can re-upload the previous version using an epoch. But if the problem is only that you wanted to keep unstable in sync with testing in case you need to correct a RC bug, then it is better to leave the package as it is: there is still the possibility of updates through testing-proposed-updates. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917235904.gc25...@falafel.plessy.net
Re: Need help for watch file
Le Fri, Sep 14, 2012 at 04:21:33PM +0200, Andreas Tille a écrit : version=3 opts=\ dversionmangle=s/[~\+]dfsg//,\ downloadurlmangle=s/VolView-([\d\.]+)-Linux-x86_64.sh/VolViewSrc.tar.gz/,\ filenamemangle=s/VolView(-[\d\.]+)-Linux-x86_64.sh/VolViewSrc$1.tar.gz/ \ http://www.kitware.com/products/vvdownload.html \ http://www.kitware.com/VolView/files/VolView-([\d\.]+)-Linux-x86_64.sh -- Downloading updated package http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz uscan warning: ../http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz does not appear to be a compressed file; the file command says: ERROR: cannot open `../http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz' (No such file or directory) Hi Andreas, the problem here is that uscan sees the file name as: http://www.kitware.com/VolView/files/VolView-3.4-Linux-x86_64.sh Your filenamemangle regular expression turns it into: http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz A second expression is needed to remove the URL part. With the following, filenamemangle=s/VolView(-[\d\.]+)-Linux-x86_64.sh/VolViewSrc$1.tar.gz/;s|http://www.kitware.com/VolView/files/|| Uscan now sees the file name as VolViewSrc-3.4.tar.gz Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120915004102.ga31...@falafel.plessy.net
Problems converting Subversion-managed source package to Git.
Dear all, I am trying to change the repository type of Debian Med's velvet package from Subversion to Git. I have followed the instructions from the Debian wiki, which usually work well for me. http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git To my surprise, this time a long string of commits, from d3677cd5346ef36bad621f29c5fe54ca8441ee6c to f22edca1abc3dfb1dd32e2b1713a5b6b1763c714, was not attached to the master branch, as indicated by their absence in git log, or the discontinuation in 'gitk --all'. Does anybody know the reason and a way to repair ? I have uploaded the repository at git://git.debian.org/debian-med/velvet.git Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120914042240.ga12...@falafel.plessy.net
Re: Any script to populate debian/copyright file ?
On Mon, Jul 16, 2012 at 9:41 AM, gustavo panizzo gfa g...@zumbi.com.arwrote: cd /usr/share/doc find . -name copyright |xargs grep 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/' Le Mon, Jul 16, 2012 at 10:35:03AM -0400, Aliaksei Sheshka a écrit : Sorry, but not helpful. They only represent ~13% on nearly default Wheezy setup Dear Aliaksei, you can find more examples in the following repository: http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/ There, 1,047 out of 3,302 copyright files declare that they follow the machine-readable format version 1.0. These files are refreshed each time the package is uploaded, and sometimes more often, as they are picked directly from the package's VCS. See the following URL for details. http://wiki.debian.org/UpstreamMetadata Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716220655.gc2...@falafel.plessy.net
Re: how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)
Le Sun, Jul 15, 2012 at 11:25:14AM +, Bart Martens a écrit : I would mention this in debian/changelog : * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx. But I don't know how detailed such information must be for debian-policy. Sometimes it is useful to also mention the reasons. I'm adding debian-mentors in cc so that other sponsors can comment if they want to. Hi all, Policy's section 4.4 indicates that Changes in the Debian version of the package should be briefly explained in the Debian changelog file debian/changelog. In that sense, the entry Remove unused build-deps is already quite informative as it provides the explanation for the change: the entries were not used. For packages that I maintain in a Git repository, I tend to become brief like this in my changelogs, and more verbose in the corresponding commits, for which the changelog mentions the first numbers of the hash ID. But this is a matter of taste; all in all, it does not cost much to fill up the changelog line with more information. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120715114924.ge32...@falafel.plessy.net
Re: Multilicense `debian/copyright` file
Le Sat, Jul 14, 2012 at 01:09:21AM -0400, Aliaksei Sheshka a écrit : Hi debian-devel list! Please help me to write a proper `debian/copyright` file. Original COPYING file says: Several parties hold copyright to various parts of IRRToolSet. One or more of the following licenses may apply to the code contained within this distribution. 1. USC (and occasionally USC/IBM) license . 2. RIPE NCC license 3. GNU General Public License version 2 ... What should put in the `debian/copyright` then ? Dear Aliaksei, your question is more suited for the debian-mentors@lists.d.o list, so I am transferring the discussion there. The Debian Policy's section 12.5 describes the requirements for the Debian copyright file. http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Note that it is not required to list exhaustively which file names correspond to which license, and that years of publication for one copyright holder may be gathered together. If you want to browse many Debian copyright files, you can have a look at the following repository: http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/ (More information about this project at http://wiki.debian.org/UpstreamMetadata ) Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714062617.gg8...@falafel.plessy.net
Re: Bug#675701: RFS: ptop
Le Sun, Jun 24, 2012 at 06:37:42AM +, Bart Martens a écrit : Files: filename1, filename2 for exceptions. Actually, it should be: Files: filename1 filename2 (The separator is a space, not a comma plus a space). Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624065911.gf6...@falafel.plessy.net
Re: Bug#677013: RFS: time
Dear Bob, you can find many recent copyright files in the following subversion repository. http://svn.debian.org/viewvc/collab-qa/packages-metadata/ Each time a binary package is uploaded, its copyright file is refreshed in this Subversion repository if the source package was itself stored in a VCS. http://wiki.debian.org/UpstreamMetadata For the Machine-readable copyright format (DEP 5), ther is no field to record upsteam authors, because it is widely accepted that this is not required by the Policy, that is: the FTP team accepts new packages not doing so, and no bugs are filed against packages that are not doing so. But if you wish, you can either use the Comment field as you did, or use an extra field: The syntax of the file is the same as for other Debian control files, as specified in the Debian Policy Manual. See its section 5.1 for details. Extra fields can be added to any paragraph. No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. Future versions of the debian/copyright specification will attempt to avoid conflicting specifications for widely used extra fields. Lastly, note that your current copyright file does not have a valid syntax as spaces are not allowed in short license names. The tool 'cme' frome Dominique Dumont's excellent libconfig-model-perl package, will assist you for further syntax checking. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623073100.gf16...@falafel.plessy.net
Re: Bug#678468: RFS: sgml-data/2.0.7 [RC] [QA] -- common SGML and XML data
Le Sat, Jun 23, 2012 at 02:30:38PM +0200, Helmut Grohne a écrit : On Sat, Jun 23, 2012 at 02:55:40PM +0300, Boris Pek wrote: * The description still contains the homepage. Hmm, is it a problem? I don't see nothing about it in the Debian Policy [1]. That lintian note was about missed homepage field which is possibly present in description. [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description This is not a problem. The information is just redundant, i.e. it adds no value to the description. But this is just my opinion. Hi all, perhaps one of the problems it causes is that, when the homepage changes, the long description changes, which will spend a bit of time of the translators, just for them to acknowledge that there is nothing to translate ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623124033.ga18...@falafel.plessy.net
Re: Maintainer of GNS3 Missing-in-Action, I volunteer
Le Tue, May 15, 2012 at 06:41:58PM -0400, Alexey Eromenko a écrit : Hi All ! GNS3 package is Debian has not been updated in the last year, and the Debian maintainer, Erik Wenzel, went MIA. (doesn't answer to emails for last few months) Hi Alexey, According to his QA page, the maintainer of gns3 uploaded another package (aggregate) 15 days ago. He is therefore not MIA. Perhaps you can try again to contact him in #665979, with a short summary of the pros and cons of releasing with 0.7.4 or 0.8.2 ? Note that since Debian has a release cycle that is roughly two years, gns3 will be eventually outdated in Stable anyway. But we have backports.debian.org for bringing new upstream stable versions to the users of Debian stable, so your work as upstream developer can be accessble to them through the Debian archive. Have a nice day, and thanks for your care of the gns3 package. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515225252.ga30...@falafel.plessy.net
About the field Choices-C Debconf templates.
Hello everybody, years after becoming DD, I am learning Debconf... amazing. I could not find an explanation for the Choices-C field in debconf-devel(7) nor the Developers Reference. Is that field clearly defined somewhere ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515234256.gb30...@falafel.plessy.net
Re: is wheezy frozen already?
Le Mon, May 14, 2012 at 03:49:41PM +0200, Andreas Tille a écrit : On Sat, May 12, 2012 at 09:57:42AM +, Daniel Pocock wrote: I notice that packages have not been taken from the queue for 3 weeks: http://ftp-master.debian.org/new.html I'd rather see a correlation to the fact that some members of the ftpmaster team might be short in time for private reasons than to the freeze date. It might be that some Do you need some help I could offer in terms of 2-3 hours per week to ftpmaster team would be welcome. Hi all, when the NEW queue is long, this leaves us some time to make a pre-review to ease the work of the FTP team, by reducing the number of errors they have to deal with. http://wiki.debian.org/CopyrightReview Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514222609.ga24...@falafel.plessy.net
Re: is wheezy frozen already?
Le Tue, May 15, 2012 at 01:09:32AM +0200, Arno Töll a écrit : On 15.05.2012 00:26, Charles Plessy wrote: when the NEW queue is long, this leaves us some time to make a pre-review to ease the work of the FTP team, by reducing the number of errors they have to deal with. how would you do that, given packages in NEW aren't publicly accessible on purpose? In my experience, I rarely encountered a package in NEW where neither the upstream archive nor the debian directory were downloadable from somewhere else. A very large number of packages have at least their debian directory stored in a publicly-accessible VCS, and the changes file indicates the MD5 sum of the upstream source archive, so all in all, in most of the cases a review is possible. And as you noted, the packages are also often available on mentors.d.n. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514233658.gc24...@falafel.plessy.net
What is the best way for disabling a service from another package ?
Dear all, I am porting to Debian a package that uses dpkg-divert in its maintainer scripts to disable a service provided by another package, by moving out the other package's upstart script. I can keep the commands as they are, since the target package does not exist in Debian, but this made me curious how to actually do these kind of operations, when package A must in a way modify package B's starting behavior or configuration. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504215551.ga9...@falafel.plessy.net
Bug#659522: RFS: prelink/0.0.20111012-1 [ITA] - ELF prelinking
Le Sat, Mar 03, 2012 at 12:23:20AM +0100, Daniel Martí a écrit : A new package is available at mentors as shown below: http://mentors.debian.net/debian/pool/main/p/prelink/prelink_0.0.20111012-1.dsc Since the lintian description tells me to contact upstream before patching with quilt (which would give extra work), I've sent a mail to Jakub about the subject. I'll wait a week or two for his answer. For the time being, the newer upload seems to be fine apart from those two warnings. I'd be very glad if someone sponsored this package for me. Dear Daniel and everybody, I am interested in prelink because of #643967 and #505906 (which pollutes my mailbox with a daily notification from a system I co-administrate). As a first step when inspecting the package, I compared the 'original' source archive that you uploaded, with the one that looks like being the upstream one. http://mentors.debian.net/debian/pool/main/p/prelink/prelink_0.0.20111012.orig.tar.gz http://people.redhat.com/jakub/prelink/prelink-20111012.tar.bz2 Can you explain why they differ ? Is it the Lintian description that confused you to repack the archive instead of patching it ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120428035339.ga16...@plessy.org
Re: how to adopt a non-orphaned package?
Le Wed, Apr 25, 2012 at 06:24:06PM +1000, Dmitry Smirnov a écrit : What would be the best practice to adopt a package which was not properly orphaned? My particular concern is about 'autofs5' package which was not updated for years since squeeze release due to maintainer inactivity. Dear Dmitry, judging from the maintainer's QA page, he looks totally inactive indeed. For the package you would like to adopt, consider that one day, you may be the inactive person as well, and call for co-mainainers or maintainance in an existing team, so that the same situation does not happen again. You can for instance send an Intend to Hijack email to debian-devel, and CC it to the persons who contributed NMUs and patches in the BTS, explaining what you already explained here, and add that the package has already been NMUed 2 times. Then, get the package sponsored with you and others as maintainers. You can keep the current maintainer in the list as well, to show that he is welcome to work on the package if he can come back to Debian. But while this would solve the problem with autofs5, this will not solve the problem with the otehr packages. You will do a great service to Debian if in parallel you follow the guidelines that Paul pointed you to, and help the QA and MIA teams to take care of the other packages. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425101008.gc9...@falafel.plessy.net
Modifications of the changelog.
* Do not modify previous changelog entries, especially not in NMUs. Hi all, are there concrete problems caused by modifying previous changelog entries ? I do it from time to time, of course not when the diff has to be carefully inspected by others as it would be a distraction, and I have not found it causing breakages. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120421073546.gb31...@falafel.plessy.net
Re: Modifications of the changelog.
Le Sun, Apr 22, 2012 at 12:22:43PM +1000, Ben Finney a écrit : Charles Plessy ple...@debian.org writes: are there concrete problems caused by modifying previous changelog entries ? Doing that breaks the entirely reasonable expectation: that a changelog only ever accumulates entries for the latest release, and nothing in earlier releases has changed since the last time the recipient read them. Hi Ben, What is that expectation for ? I find it dogmatic written like this. If it breaks software, especially in Debian's infrastructure, that would be a key reason for not changing any byte. Otherwise, while there is probably better things to do in life than spellchecking a changelog, I admit that once I went through the first entry, I sometimes correct the ones below. I also remove trailing spaces that distract my eyes when colored in purple by my editor, and for the packages in Git, I sometimes added the first seven numbers of the commit hash to past entries. I also have added missing hashes so that when browsing the changelog on packages.d.o, one can have a nice hyperlink to bug reports, etc. I am not advocating that other people should do this, but I think that, especially on debian-mentors, strong statements about what everybody must not do should come with explanations about the reason, if possible argumented with concrete examples of the problems caused. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422023931.ge19...@falafel.plessy.net
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 03:57:59PM +0200, Thibaut Paumard a écrit : I believe it is generally accepted that every file that can be (re)generated during the build process should be, for various reasons. Hi all, I think that there is a consensus that generated files must be regenerable, and that it is a bug if their build system is broken. The best way to ensure this is to regenerate them at build time, however it is not a requirement. In particular, I do not see advantages in distributing rebuilds that would for instance only update time stamps. It is increasing debdiffs and heating the planet for no benefit. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419142040.ga30...@falafel.plessy.net
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 05:02:13PM +0200, Thibaut Paumard a écrit : Le 19/04/12 16:20, Charles Plessy a écrit : I think that there is a consensus that generated files must be regenerable, and that it is a bug if their build system is broken. The best way to ensure this is to regenerate them at build time, however it is not a requirement. In particular, I do not see advantages in distributing rebuilds that would for instance only update time stamps. It is increasing debdiffs and heating the planet for no benefit. File timestamps won't show up in debdiff. At the very least, the maintainer should (IMNSHO) regenerate the files himself and check that they match what ends-up being distributed. And he should also document this process in debian/README.source. Honestly, I think it's simpler and less error-prone to just distribute the regenerated files. But as you said, it's not a policy requirement. There are other timestamps. Some documents contain the date where they were built, as an indication for the last time they were modified. For the packages I maintain, where I wrote manpages in DocBook XML, I do not regenerate them at each build and store the generated nroff code in the VCS where the package is maintained. This has the additional advantage that the package does not need to build-depend on the DocBook toolchain. debian/rules contains a target to rebuild, plus a comment explaining which packages to install. The point I am trying to make is that there is no single rule that has to be strictly followed by eveybody in all cases. Otherwise we would fall in the same selective blindess as for the freeness of pictures, videos, music and scientific data. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120420001744.ga13...@falafel.plessy.net
Re: adding a new file using (d)quilt
Le Thu, Apr 12, 2012 at 12:50:23PM +0200, Gerber van der Graaf a écrit : Hi, for packaging freefoam-user-doc I intend to include the static file UsersGuide.pdf.gz as asymptote is currently broken. Dear Gerber, it will be much simpler for you to include it directly in the debian tarball using the dpkg format 3.0 (quilt). In contrary to what the name suggests, this will not be done using quilt. See the manual page of dpkg-source for more details. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412111348.ge14...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Sat, Apr 07, 2012 at 04:46:33PM +0400, Vladimir Stavrinov a écrit : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659047 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652718 http://mentors.debian.net/package/rpg Hi, There is no need to rename bugs and mentors uploads retroactively. If repagen is accepted in Debian, it will close #652718 and #659047, and this is enough to make the link. The mentors URL (in my understanding) will not persist. This said, for your information, you can easily retitle bugs from the command line with the bts program in the devscripts package. http://sourceforge.net/projects/rpg/ There can be discrepancies between Debian's package name and the upstream name. For instance, I packaged the program last in the package last-align. Conversly, I packaged the program bwa in the package bwa, but on SourceForge (and only there) it is called bio-bwa. As a side note, I think that the comments about security in this thread are very relevant. If your package were accepted in Debian, it would need to meet Debian's and Debian's users expectations, not only your vision as an upstream developer. This means that if some design choices are perceived as flaws from Debian's point of view, somebody will have to do some work to correct the package in Sid and perhaps in Stable. That is one of the reasons for the reluctance to accept your package. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120408000525.ga24...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Fri, Apr 06, 2012 at 07:04:08PM +0400, Vladimir Stavrinov a écrit : On Fri, Apr 6, 2012 at 3:34 AM, Charles Plessy ple...@debian.org wrote: I also think that we should refrain from using short and common names for the What about repagen i.e. REadable PAssword GENerator ? Is it OK.? That is nice. Good luck for solving the other problems raised in that thread and finding a sponsor. Debian has thousands of packages. Each of them has an imprint on our ecosystem. Consider for instance that if one day you suddenly can not contribute anymore, somebody else will need to care of the package. Summed together, even removals takes time. In the future, Debian wants to set up a personal package archive system like in Ubuntu. That would be an ideal first stage for packages like yours, where they can demonstrate they have an audience, before entering the main distribution. This said, it is good to pick a unique name in advance, and repagen illustrates well the point of the package. It looks like that there is a trademarked cosmetic of the same name, but fields of use are different enough. Or pehraps unreadable passwords are bad for the skin in the long term ;) Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120407001444.ga3...@falafel.plessy.net
Re: installing desktop file and icon
Le Fri, Apr 06, 2012 at 04:14:49PM -0800, Christopher Howard a écrit : Hi. I have source code that comes with a freedesktop-style .desktop file and svg icon. I know they need to go in /usr/share/applications and /usr/share/pixmaps (respectively). In the deb package which I am making, what should I put in the deb's rules file so that these are properly installed? Dear Christopher, thanks to dpkg triggers, everything needed is run when dpkg detects that it adds a file in /usr/share/applications. $ grep applications /var/lib/dpkg/triggers/File /usr/share/applications gnome-menus /usr/share/applications desktop-file-utils You only need to install the files like any other files. Developers using debhelper would for instance use dh_install(1) for this. Note that since /usr/share/applications and /usr/share/pixmaps are standard directories, it would be best that make install simply install them at the same time as the other files. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120407003246.gb3...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Thu, Apr 05, 2012 at 07:05:16PM +0400, Vladimir Stavrinov a écrit : But there no package named rpg. Hi, I also think that we should refrain from using short and common names for the packages. That there is no package named rpg does not say that it is free for you, it says that there was self-discipline and peer pressure up to now to avoid it. Package names need to be thought forward, not on a first-arrived first-served manner. In your case, rpg-password or other suffixes can be used to increase the length a complexity of the package names. To convey the pristine name of the software that is packaged, there are other ways such as the AppStream and Component Metadata for Debian and Upstream metadata gathered with yaml (UMEGAYA) projects. http://wiki.debian.org/AppStreamDebianProposal http://wiki.debian.org/UpstreamMetadata Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120405233404.gb17...@falafel.plessy.net
Re: Signing a .deb later?
Le Wed, Apr 04, 2012 at 07:55:09AM +0200, Thibaut Paumard a écrit : Le 04/04/12 01:01, Christopher Howard a écrit : So, my first question: Is there some nifty command or trick to (properly) GPG sign a .deb package /after/ I've finished making it? You can't sign your binary packages. What you can sign is the .dsc (source package) and .changes (upload file). You sign them using debsign. Actually, there is a binary package signing tool, but it looks rather abandonned… http://manpages.ubuntu.com/manpages/precise/en/man1/debsig-verify.1.html Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404065009.gf12...@falafel.plessy.net
Re: Advice on use of patch system while hacking
Le Sun, Apr 01, 2012 at 01:30:41PM -0700, Ross Boylan a écrit : It's not my package, and for reasons of courtesy to the maintainer and (I thought) minimizing work for myself I didn't want to make any unncessary changes. Actually, since the maintainer of noweb does not seem to have made uploads for a long time, perhaps you can check if he is still interested or available; otherwise it is a good moment to take over the package or transfer it to a team that would like to adopt it, possibliy with more extensive modifications (for instance merging Ubuntu's changes). Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402020810.gb7...@falafel.plessy.net
Re: Debian-friendly upstream best practices?
Le Wed, Mar 28, 2012 at 02:29:22PM +0200, Michael Wild a écrit : The only unpleasant side-effect I can think of is that git-dch will probably be a bit noisy. Same for the commit emails. This is one of the reasons I still import tarballs from upstream projects that are maintained with Git: I did not manage to find how to avoid sending a deluge of commit emails when pushing the upstream branch to Alioth. Also, they are sent with the commiter's name as sender, which gives the wrong impression he is the one who pushed the upstream changes to the Debian package. Any hint ? -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120328130646.gd1...@falafel.plessy.net
Re: how to manage d/changelog for updated but not yet sponsored package
Le Mon, Feb 13, 2012 at 11:53:45AM +0100, Jakub Wilk a écrit : * Ben Finney ben+deb...@benfinney.id.au, 2012-02-13, 13:40: I want to keep trace of it in the d/changelog by keeping my first version entry and adding a second entry. Can I do that ? Will it confuse some Debian robots ? It's fine. I consider uploading the package to ‘mentors.debian.net’ a release of the package, since at that point interested people (e.g. reviewers) can rely on it, and the version should refer uniquely to what I uploaded at that time. Be aware, though, that some people disagree (on the grounds that it's not a new version until it enters Debian). I believe that vast majority of sponsors disagree. Note however that the FTP team does not reject such packages. I tend to keep the changelog entries of packages that have been released outside Debian for the public. However, I revert all previous “unstable” entries to “UNRELEASED” to clearly mark that these packages were not in the Debian archive. Have a nice day, Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213110711.gd25...@falafel.plessy.net
Re: Files permission in the debian directory
Le Mon, Feb 13, 2012 at 04:05:11PM +0100, fre...@free.fr a écrit : What are the recommended permissions for all the files that reside inside the debian directory ? I've not found any documentation about it, except for debian/rules. Dear Fred, the Dpkg source format version 1.0 does not support other files than debian/rules to be executable, so I recommend that unless strictly needed, you do not rely on files in debian/ to be executable, especially if you suspect that your package might be backported by users on local installations that are too old for supporting the 3.0 (quilt) format. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213235945.ga9...@falafel.plessy.net
