Re: Verifying dep-5
On Sat, May 28, 2016 at 4:04 PM, Johannes Schauer wrote: > Having such a reliable tracing method would give us the ability to reliably > infer copyright information as well as generating structured build logs > (knowing for each line in the build log the process (tree) that created it). > > Both of these would also tremendously help debugging problems. For example, > for > fixing reproducible build problems, I was often puzzled which program actually > created a file that I was interested in for a source package that I am not > familiar with. Thanks for these other use-cases, very interesting. > Unfortunately though, there seems to be no way to reliably trace process > execution and read/write/open/close system calls without either sometimes > missing information or breaking builds... I expect this would need some support from the kernel being run under. OTOH I don't think a tracing mechanism is what is needed though, since the kernel cannot know what the program is doing with each file being read/written by the program. These sort of semantics (input, output and code) are only known by the program that is doing the transformations. Especially when you factor in shell scripts and other things, the semantics get complicated. Kernel support would definitely be useful though. Perhaps we could have a brainstorm/BoF about this at a DebConf some time. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#825710: ITP: libmojo-pg-perl -- module to make PostgreSQL fun to use with Mojolicious
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmojo-pg-perl Version : 2.27 Upstream Author : Sebastian Riedel * URL : https://metacpan.org/release/Mojo-Pg * License : Artistic-2.0 Programming Lang: Perl Description : module to make PostgreSQL fun to use with Mojolicious Mojo::Pg is a wrapper around DBD::Pg that makes PostgreSQL a lot of fun to use with the Mojolicious real-time web framework. Features of note include URL-based database connections, automatic transaction rollback support, database migrations written in plain SQL, and asynchronous triggers. Support for Mojo::Pg is present in the Minion job queue for Mojolicious. The package will be maintained under the umbrella of the Debian Perl Group.
Re: package versions with snapshots/branch updates (was: Re: Accepted gcc-5 5.3.1-21 (source) into unstable)
On Sun, May 29, 2016 at 01:37:00AM +0500, Andrey Rahmatullin wrote: > On Sat, May 28, 2016 at 07:44:11PM +0200, Rene Engelhard wrote: > > e.g. if you have a package 1.0 and add a complete branch update as a patch > > (or upgrade to a snapshot) one should do a 1.0+gitYYYDDMM-1 or whatever > > format > > you choose. Not 1.0-15 or so. > Here the question is "if you package unreleased changes, should they go to > orig.tar or to debian.tar, am I right? It boils down to that, but it's not that strict. I just want the version of the package be correct. It's theoretically possible to add the stuff as a patch to 1.0-15 and still make the binary packages 1.0+something-1. Which is a hack and confuses people, but it's possible. A .orig is cleaner, though, sure. > > That's what I just saw on debian-devel-changes: > > > > On Sat, May 28, 2016 at 04:48:47PM +, Matthias Klose wrote: > > [...] > > > Changes: > > > gcc-5 (5.3.1-21) unstable; urgency=medium > > > . > > >* GCC 5.4.0 release candidate 1. > [...] > > A 5.4.0 rc1 in a package versioned 5.3.1-21? > [...] > > Package versions should actually tell the correct version... > Here the question is "should the package upstream version be the same as > what the software reports/written in version.h", am I right? Maybe, but that imho is too specific. version.h might contain 2.3 instead of 2.3.5 (to invent some versions), and you wouldn't say "keep 2.3" as version. But having a 5.4.0 rc1 in a 5.3.1-x is wrong for me. Regards, Rene
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi, 2016-05-18 2:21 GMT+02:00 Guillem Jover : > On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote: >> I'm not a fan myself for turning on hardening flags in the compiler itself, >> but if you do that, then dpkg issues like https://bugs.debian.org/823869 >> need to be addressed (whether all obscure build systems picking these up, or >> not). > > That bug report is not relevant in its current form, as explained > there. > > If the default changes in the Debian default compiler, then I'll just > make the +pie option a no-op and change -pie to set -fno-PIE, so that > the options are only added when they are expected. > > The difference with that request is that it would currently add > -fno-PIE for most packages that do not change the default flags, > which might break their build-systems. Thank you Guilllem. Matthias, are you OK with the resolution of #823869 and would you be OK with using --enable-default-pie for GCC if dpkg adopts the solution described above? Cheers, Balint
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi, 2016-05-16 13:09 GMT+02:00 Christoph Egger : > Hi! > > Iustin Pop writes: >> - that bug seems to have been opened in the context of custom patches to >> GCC, back in 2009-2012 >> - the CTTE seems to have made an informal decision (see last update >> #272) on that topic > > And most importantly > > - the tech-ctte primarily refused to override the maintainer. And the > maintainer's primary objection was the patch not being upstream. Thanks for pointing that out. I have re-read the whole bug log [1] and I agree that since CTTE made and informal decision we don't have to reopen the discussion there. (I assume most of the CTTE members are reading this list, too, please speak up if I'm mistaken here.) In the best scenario Matthias and Guillem can agree on a solution and a test build can be run to see which packages need patching. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688
Re: package versions with snapshots/branch updates (was: Re: Accepted gcc-5 5.3.1-21 (source) into unstable)
On Sat, May 28, 2016 at 07:44:11PM +0200, Rene Engelhard wrote: > e.g. if you have a package 1.0 and add a complete branch update as a patch > (or upgrade to a snapshot) one should do a 1.0+gitYYYDDMM-1 or whatever format > you choose. Not 1.0-15 or so. Here the question is "if you package unreleased changes, should they go to orig.tar or to debian.tar, am I right? > That's what I just saw on debian-devel-changes: > > On Sat, May 28, 2016 at 04:48:47PM +, Matthias Klose wrote: > [...] > > Changes: > > gcc-5 (5.3.1-21) unstable; urgency=medium > > . > >* GCC 5.4.0 release candidate 1. [...] > A 5.4.0 rc1 in a package versioned 5.3.1-21? [...] > Package versions should actually tell the correct version... Here the question is "should the package upstream version be the same as what the software reports/written in version.h", am I right? -- WBR, wRAR signature.asc Description: PGP signature
package versions with snapshots/branch updates (was: Re: Accepted gcc-5 5.3.1-21 (source) into unstable)
Hi, I have seen various packages (mostly from the same maintainer, though) which do branch updates in a imho wrong way. Updates to a stable branch fixes or backporting fixes is OK. I don't deny that or so. But the package IMHO should have a correct version then. e.g. if you have a package 1.0 and add a complete branch update as a patch (or upgrade to a snapshot) one should do a 1.0+gitYYYDDMM-1 or whatever format you choose. Not 1.0-15 or so. That's what I just saw on debian-devel-changes: On Sat, May 28, 2016 at 04:48:47PM +, Matthias Klose wrote: [...] > Changes: > gcc-5 (5.3.1-21) unstable; urgency=medium > . >* GCC 5.4.0 release candidate 1. > * Update to SVN 20160528 (r236840, 5.3.1) from the gcc-5-branch. > - Fix PR libstdc++/69703, PR libstdc++/71038, PR libstdc++/71036, >PR libstdc++/71037, PR libstdc++/71005, PR libstdc++/71004, >PR libstdc++/70609, PR target/69634, PR middle-end/68142, >PR middle-end/69845, PR rtl-optimization/68814, PR lto/69003, >PR ipa/66487, PR target/69252, PR target/67973 (x86), >PR middle-end/67278, PR target/67278 (x86), PR tree-optimization/69720, >PR tree-optimization/67921, PR middle-end/70941, PR middle-end/70931, >PR tree-optimization/70623, PR tree-optimization/70780, PR c++/70347, >PR c++/70466, PR fortran/71204, PR fortran/69603, PR libffi/65567, >PR libstdc++/70762. >* Update the ibm branch to 20160526. A 5.4.0 rc1 in a package versioned 5.3.1-21? This is even worse since the last gcc/python/... upgrades which "just" upgraded to SVN revision X without bumping the base version. I'll be attacked nevertheless claiming this would be attack but this is NOT against a specific maintainer though somewhow that mostly happened in those packages, but a general problem. Package versions should actually tell the correct version... I think we should amend the policy to make that clear. Regards, Rene
Processed: Re: Bug#825624: Raspbian not mentioned in bug categories :-(
Processing control commands:
> reopen -1
Bug #825624 {Done: Marcin Kulisz } [general] general:
Raspbian not mentioned in bug categories :-(
Bug reopened
Ignoring request to alter fixed versions of bug #825624 to the same values
previously set
> reassign -1 tracker.debian.org
Bug #825624 [general] general: Raspbian not mentioned in bug categories :-(
Bug reassigned from package 'general' to 'tracker.debian.org'.
Ignoring request to alter found versions of bug #825624 to the same values
previously set
Ignoring request to alter fixed versions of bug #825624 to the same values
previously set
> severity -1 wishlist
Bug #825624 [tracker.debian.org] general: Raspbian not mentioned in bug
categories :-(
Ignoring request to change severity of Bug 825624 to the same value.
--
825624: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825624
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#825624: Raspbian not mentioned in bug categories :-(
Control: reopen -1 Control: reassign -1 tracker.debian.org Control: severity -1 wishlist On Sat, May 28, 2016 at 11:57:19AM +, Debian Bug Tracking System wrote: > Your message dated Sat, 28 May 2016 13:24:33 +0200 > with message-id <20160528112433.GB4474@bashton004> > and subject line > has caused the Debian Bug report #825624, > regarding general: Raspbian not mentioned in bug categories :-( > to be marked as done. Reopened > Rasbian is not mentioned in reportbug cause it's not Debian. > > It is a derivative maintained outside of Debian, so if you want to file a bug > against it please have a look at this website 1st: > https://www.raspbian.org/RaspbianBugs IMO should the gap between Raspbian and Debian not exist. My wish is that https://tracker.debian.org/pkg/PACKAGENAME gets a Raspbian section like the Ubuntu section. Cheers Geert Stappers signature.asc Description: Digital signature
Bug#825624: marked as done (general: Raspbian not mentioned in bug categories :-()
Your message dated Sat, 28 May 2016 13:24:33 +0200 with message-id <20160528112433.GB4474@bashton004> and subject line has caused the Debian Bug report #825624, regarding general: Raspbian not mentioned in bug categories :-( to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 825624: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825624 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Bugreport to Raspbian * What exactly did you do (or not do) that was effective (or ineffective)? Checking bug categories. * What was the outcome of this action? Nothing * What outcome did you expect instead? A category in bug categories for Rasbian? :-> *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Thomas, Rasbian is not mentioned in reportbug cause it's not Debian. It is a derivative maintained outside of Debian, so if you want to file a bug against it please have a look at this website 1st: https://www.raspbian.org/RaspbianBugs -- |_|0|_| | |_|_|0| "Heghlu'Meh QaQ jajVam" | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature --- End Message ---
Bug#825641: ITP: libtest-needs-perl -- module to skip tests when modules are not available
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-needs-perl Version : 0.002000 Upstream Author : haarg - Graham Knop (cpan:HAARG) * URL : https://metacpan.org/release/Test-Needs * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to skip tests when modules are not available Test::Needs allows one to skip test scripts if modules are not available. The requested modules will be loaded, and optionally have their versions checked. If the module is missing, the test script will be skipped. Modules that are found but fail to compile will exit with an error rather than skip. If used in a subtest, the rest of the subtest will be skipped. If the "RELEASE_TESTING" environment variable is set, the tests will fail rather than skip. Subtests will be aborted, but the test script will continue running after that point. The package will be maintained under the umbrella of the Debian Perl Group. signature.asc Description: Digital Signature
Re: Bug#825623: ITP: json -- JSON for Modern C++
hello, On 05/28/2016 12:17 PM, Christian Seiler wrote: > Hi, > > On 05/28/2016 11:56 AM, Muri Nicanor wrote: >> * Package name: json > > I would suggest maybe calling the Debian package something else, > because 'json' is really, really generic, and while the library > you're packaging looks extremely nice (thanks for bringing it to > my attention), I don't think it makes sense to have it reserve > the 'json' package name. > > Since the C++ namespace is called nlohmann (see the code example > using json = nlohmann::json), you could perhaps call the source > package nlohmann-json, with it creating a binary package called > libnlohmann-json-dev - or similar. yes, you're totally right! thanks for the tip with the namespace, i'll call the package as you suggested. cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: Verifying dep-5
On Sat, May 28, 2016 at 02:18:51AM +0300, Dmitry Bogatov wrote: > But seems we do not have tools to check it. Probably, we need some way > to mark licenses of whole binary packages. WDYT? You're correct that we have no way to document the licenses of binaries. The Policy is currently only concerned to document licenses at the source (files) level. Note that having a human-maintained documentation of the license of each binary we ship is not enough to properly do the checking you've in mind. Tracking licensing information across builds is actually an open research question on which various teams around the world are working---on various angles: formalizing dependencies across builds, dynamically tracking builds using syscall tapping, inspecting built binaries ex post, etc. There are prototypes of all these things around, but TTBOMK they are all very limited (e.g., restricting to a specific build system and/or a programming language) and as such by no mean generic enough to scale to the size and diversity we have in Debian. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Bug#825623: ITP: nlohmann-json -- JSON for Modern C++
Control: retitle -1 ITP: nlohmann-json -- JSON for Modern C++ Hi again, On 05/28/2016 12:48 PM, Muri Nicanor wrote: > On 05/28/2016 12:17 PM, Christian Seiler wrote: >> On 05/28/2016 11:56 AM, Muri Nicanor wrote: >>> * Package name: json >> Since the C++ namespace is called nlohmann (see the code example >> using json = nlohmann::json), you could perhaps call the source >> package nlohmann-json, with it creating a binary package called >> libnlohmann-json-dev - or similar. > > yes, you're totally right! thanks for the tip with the namespace, i'll > call the package as you suggested. Great, and thanks for your work on this. usbguard looks very interesting from the description, I'll definitely take a look once it's in the archive. :-) I've retitled the ITP for you. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#825625: ITP: usbmon -- commandline linux usbmon interface and api
Package: wnpp Severity: wishlist Owner: Muri Nicanor * Package name: usbmon Version : Upstream Author : Radovan Sroka * URL : https://github.com/radosroka/usbmon * License : GPL Programming Lang: C++ Description : commandline linux usbmon interface and api - This c++ library is a build dependency for usbguard (see #791919 and #825302) - I plan to maintain the package by myself, any help is appreciated cheers, -- muri signature.asc Description: OpenPGP digital signature
Bug#825624: general: Raspbian not mentioned in bug categories :-(
Package: general Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Bugreport to Raspbian * What exactly did you do (or not do) that was effective (or ineffective)? Checking bug categories. * What was the outcome of this action? Nothing * What outcome did you expect instead? A category in bug categories for Rasbian? :-> *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Bug#825623: ITP: json -- JSON for Modern C++
Hi, On 05/28/2016 11:56 AM, Muri Nicanor wrote: > * Package name: json I would suggest maybe calling the Debian package something else, because 'json' is really, really generic, and while the library you're packaging looks extremely nice (thanks for bringing it to my attention), I don't think it makes sense to have it reserve the 'json' package name. Since the C++ namespace is called nlohmann (see the code example using json = nlohmann::json), you could perhaps call the source package nlohmann-json, with it creating a binary package called libnlohmann-json-dev - or similar. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#825623: ITP: json -- JSON for Modern C++
Package: wnpp Severity: wishlist Owner: Muri Nicanor * Package name: json Version : 2.0 Upstream Author : Niels Lohmann * URL : https://github.com/nlohmann/json * License : MIT Programming Lang: C++ Description : JSON for Modern C++ JSON library with Intuitive syntax, Trivial integration and Serious testing - this library is a build dependency for the usbguard package (see #791919 and #825302) - i plan to maintain the package by myself cheers, -- muri signature.asc Description: OpenPGP digital signature
Bug#825620: ITP: quex -- Quex, a lexical analyzer generator
Package: wnpp Severity: wishlist Owner: Muri Nicanor * Package name: quex Version : 0.65.11 Upstream Author : Frank-Rene Schäfer * URL : http://quex.sourceforge.net/ * License : GPL Programming Lang: Python, C++ Description : Quex, a lexical analyzer generator Quex is a tool to generate lexical analyzers. A lexical analyzer is a program that transforms a stream of characters into a stream of 'atomic chunks of meaning', so called tokens. - the c++ files shipped by this package are a build dependency for the usbguard package - i plan to maintain this package by myself. i do this, because quex is a build dependency for usbguard (see #791919 and #825302). if anyone else wants to take this, i'm happy to give it away ;) cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: Verifying dep-5
Hi, Quoting Paul Wise (2016-05-28 06:45:44) > I think it would be interesting to automatically track how each file > in a binary package was created and which files they were derived > from. Then we could automatically generate proper copyright files for > binary packages. That is a hard project so... I was investigating this problem last year and as far as my research went, there is no tracing method in existence which reliably traces system calls in general, file system access or read/write operations while keeping track of the acting pid that is 100% reliable. The methods I found either were not transparent (and would thus break test suites) or suffered from race conditions where it was possible to register an operation but miss the pid the operation was carried out by or dropped operations if they occurred with a too-high frequency... Having such a reliable tracing method would give us the ability to reliably infer copyright information as well as generating structured build logs (knowing for each line in the build log the process (tree) that created it). Both of these would also tremendously help debugging problems. For example, for fixing reproducible build problems, I was often puzzled which program actually created a file that I was interested in for a source package that I am not familiar with. Unfortunately though, there seems to be no way to reliably trace process execution and read/write/open/close system calls without either sometimes missing information or breaking builds... cheers, josch signature.asc Description: signature
Re: Verifying dep-5
Quoting Dmitry Bogatov (2016-05-28 07:47:31) > > [add debian-devel back to cc] > >> Regarding _declaring_ appropriate DEP5 hints, with machine-readable >> DEP5 = copyright format you can declare a license in the _header_ >> section to = indicate the effective license caused by "infection" of >> indivifual parts = on the whole of the binary product. > > Almost sufficent, but not general enough. I don't follow, but instead of elaborating further here, see below... > Just an idea: new field in Package: stanza in d/control: > `Effective-License', which specify which terms you must comply with if > you use this library. In my case, I would leave debian/copyright > alone, and add `Effective-License: GPL-2+' to libghc-missingh-dev. > > And add rule, that Effective-License defaults to License in header, > which defaults to the most strict of licenses of individual files. > Add tool, that implement this rule. Hmm, it is complicated. > > Thoughts? > >> Also note that DEP5 format is only optional, so such automated = >> checks, even if/when existing, would not cover Debian as a whole. > > Is there no plans to push it into policy? I guess further progress to copyright format is driven by bugreports against debian-policy. Therefore I suggest you to file a bugreport if you feel there is substance for change. Since generally Policy reflects reality of Debian rather than steering changes to it, you might consider "backing" such bugreport by active use of your proposed new field: Copyright format explicitly permit the use of unofficial fields. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
