Bug#825505: ITP: golang-github-cenk-rpc2 -- Bi-directional RPC in Go (Golang)

2016-05-27 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: golang-github-cenk-rpc2 Version : 0.0~git20160427.0.7ab76d2e88c7-1 Upstream Author : Cenk Altı * URL : https://github.com/cenk/rpc2 * License : Expat Programming Lang: Go Description

Bug#825503: ITP: golang-github-socketplane-libovsdb -- An OVSDB Client Library written in Golang

2016-05-27 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: golang-github-socketplane-libovsdb Version : 0.1+git20160503.9.d4b9e7a53548-1 Upstream Author : SocketPlane * URL : https://github.com/socketplane/libovsdb * License : Apache-2.0

Bug#825183: ITP: gobgp -- BGP implemented in the Go Programming Language

2016-05-24 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: gobgp Version : 1.7-1 * URL : https://github.com/osrg/gobgp * License : Apache-2.0 Programming Lang: Go Description : BGP implemented in the Go Programming Language GoBGP is an open

Bug#825164: ITP: golang-github-eapache-channels -- Golang channel helpers and special types

2016-05-24 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: golang-github-eapache-channels Version : 1.1.0 Upstream Author : Evan Huus * URL : https://github.com/eapache/channels * License : Expat Programming Lang: Go Description : Golang

Re: trying to use wireless not from gnome... what's the incantation?

2016-05-23 Thread Vincent Bernat
❦ 23 mai 2016 12:10 +0200, Adam Borowski  : >> > NM is closely tied to Gnome so regressions in non-Gnome use aren't >> > surprising. >> Login in Gnome once, activate wifi and ask that the connection should be >> used by >> all users. >> Then NM will save the password some were so that it connect

Bug#823200: ITP: python-poyo -- lightweight (subset of) YAML parser for Python

2016-05-02 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-poyo Version : 0.2.0 Upstream Author : Raphael Pierzina * URL : https://github.com/hackebrot/poyo/ * License : Expat Programming

Re: Bug#821035: ITP: luksipc -- LUKS in-place conversion tool

2016-04-17 Thread Vincent Bernat
❦ 17 avril 2016 18:07 +0200, Philipp Kern  : >> I intend to also provide an initramfs hook to make the conversion of a >> root filesystem for simple cases only (notably cloud payload). > > I am still a little bit scared by this tool. If it would optionally > persist the block it is currently rewr

Bug#821035: ITP: luksipc -- LUKS in-place conversion tool

2016-04-14 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: luksipc Version : 0.04 Upstream Author : Johannes Bauer * URL : http://johannes-bauer.com/linux/luksipc/ * License : GPL-3 Programming

Re: gitlab package (was Re: Opt out style recommends)

2016-04-11 Thread Vincent Bernat
❦ 11 avril 2016 15:18 +0530, Pirate Praveen  : > 2.automating ssl was not possible before letsencrypt. Now you just > need to click/press yes button to get an encrypted service running. > > And for those who do not want it, the default is 'no' for both ssl and > letsencrypt. > > It would be a

Re: golang naming scheme

2016-03-31 Thread Vincent Bernat
❦ 31 mars 2016 15:22 -0400, Holger Levsen  : >> That's one of the reasons why so many people use github, since that URL is >> less likely to change. > > less likely, but imagine 3000 golang packages in the archive in 5 years and > then github is bought by google and renamed to goolab. or whatever

Re: Upgrading xrdp

2016-03-08 Thread Vincent Bernat
❦ 8 mars 2016 15:03 +0100, Andreas Tille  : > since I need an up to date xrdp at work I upgraded the packaging in > collab-maint to the latest upstream version. Considering the package is > in collab-maint I guess it is OK for you that I added myself to > Uploaders. It would be nice if you cou

Bug#817048: ITP: jo -- command-line processor to output JSON from a shell

2016-03-07 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: jo Version : git snapshot Upstream Author : Jan-Piet Mens * URL : https://github.com/jpmens/jo * License : GPL-2+ Programming Lang: C

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

2016-03-05 Thread Vincent Bernat
❦ 6 mars 2016 04:22 +0100, Pierre-Elliott Bécue  : >> > Mmh, take a look at other debian packages. It is quiet common that python >> > packages uses sphinx as documentation framework. So it should be a already >> > solved issue - maybe ask python-debian. >> >> The easiest solution is to add '

Re: mkdocs locale error building djangorestframework

2016-01-25 Thread Vincent Bernat
❦ 26 janvier 2016 11:57 +1100, Brian May  : > I probably should change the line from: > > LANG=C.UTF-8 mkdocs build && mv site docs.debian/html > > To something like: > > LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html This may not apply to your case, but there is a loca

Re: support for merged /usr in Debian

2016-01-17 Thread Vincent Bernat
❦ 17 janvier 2016 11:25 +0100, Marc Haber  : >>Of course, vlan1 is up because with networkd, configuring the "netdev" makes >>it up while in Debian, setting the IP makes it up. However, I don't see >>you whining about the lack of flexibility in Debian where you cannot >>execute a command when the

Re: support for merged /usr in Debian

2016-01-16 Thread Vincent Bernat
❦ 16 janvier 2016 17:37 +0100, Marc Haber  : >>You seem to always take vague examples to avoid being contradicted. You >>can execute any unit before and after network is setup through the >>dependency system. > > Show me how to set a certain option to a VLAN interface that is > created by /etc/sy

Re: support for merged /usr in Debian

2016-01-16 Thread Vincent Bernat
❦ 16 janvier 2016 16:38 +0100, Marc Haber  : > It's simply unproductive to first having to argue with upstream if one > needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_ > to wait for the next Debian stable release for this possibility to > become available, if I need to set t

Re: support for merged /usr in Debian

2016-01-03 Thread Vincent Bernat
❦ 3 janvier 2016 22:30 +0100, Eric Valette  : >> The problem of getting /usr mounted before things start using it is mostly >> separate from the question of whether we want to merge it with /bin and >> /lib. This thread is more about the latter than the former. (Obviously, >> mounting /usr ear

Re: support for merged /usr in Debian

2016-01-03 Thread Vincent Bernat
❦ 4 janvier 2016 00:03 +1300, Daniel Reurich  : >>> Then why is it that since the introduction of systemd is having /usr on >>> a separate partition suddenly considered evil and systemd complains >>> loudly about it. It always has worked and does work fine for me with >>> sysvinit >> >> system

Re: support for merged /usr in Debian

2016-01-01 Thread Vincent Bernat
❦ 1 janvier 2016 13:29 +0100, Simon Richter  : >> Is there any use case that requires supporting unmerged systems? > > Booting without an initrd, which is important for resource-constrained > embedded systems. Do you also require a separate /usr for those systems? -- The human race has one rea

Re: Automatic dbgsym packages built by default as of today!

2015-12-19 Thread Vincent Bernat
❦ 19 décembre 2015 23:26 GMT, Niels Thykier  : > * Currently only experimental and unstable will have dbgsym packages. >- We need changes to Britney to add them to testing. For experimental, would it be possible to set "Not-Automatic: yes", so that debug packages work in the same way than r

Re: Automatic dbgsym packages built by default as of today!

2015-12-19 Thread Vincent Bernat
❦ 19 décembre 2015 23:26 GMT, Niels Thykier  : > As of today, dak supports the dbgsym packages built by debhelper and > with debhelper/9.20151219 they are now built by default! With this, a > decade old idea is now implemented and available for general > consumption[1]. :) That's great! Many th

Re: dbconfig-common: near future change in dependency stack

2015-12-06 Thread Vincent Bernat
❦ 6 décembre 2015 14:23 +0100, Paul Gevers  : > TL;DR;2 should the new dbconfig- packages recommend or suggest > the database server packages? Suggest. Otherwise, your plan looks just fine. -- All generalizations are false, including this one. -- Mark Twain signature.asc Des

Re: Accepting cloud enablement package updates into Stable

2015-11-28 Thread Vincent Bernat
❦ 28 novembre 2015 21:26 +0100, Thomas Goirand  : > After this discussion, I'm still not sure what needs to be done in the > init script. Should we do: > > -# Required-Start:$local_fs $remote_fs > +# Required-Start: > # Required-Stop: > +# X-Start-Before:networking > -# Default-Start:

Re: Accepting cloud enablement package updates into Stable

2015-11-27 Thread Vincent Bernat
❦ 27 novembre 2015 14:33 +0100, Thomas Goirand  : >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784083#40 >> >> So I don't really get your complaint. > > Oh, thanks for pointing this out. > > So if I understand correctly, just adding $network to the line: > > # Required-Start:$local_

Re: Bug#800769: pbuilder: conffiles not removed

2015-10-12 Thread Vincent Bernat
❦ 12 octobre 2015 17:45 +0200, Jakub Wilk  : > I'd suggest to do something very simple instead: > In pbuilder's postinst, if pbuilder-uml status is not-installed, > simply rm -f /etc/pbuilder/pbuilder-uml.conf. If for some reason, a user has put a file with this exact same name here, it would be

Re: pro-active removals

2015-09-17 Thread Vincent Bernat
❦ 17 septembre 2015 10:55 +0200, Andreas Henriksson  : >> Why? The vlan package is not needed since at least Wheezy to configure >> VLANs on devices since the program "ip" can do everything the same or >> even better. >> >> Also ifupdown was changed to be able to configure VLANs using "ip" >> d

Bug#799044: ITP: python-hypothesis -- advanced Quickcheck style testing library for Python

2015-09-15 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-hypothesis Version : 1.11.0 Upstream Author : David R. MacIver * URL : https://github.com/DRMacIver/hypothesis * License : MPL 2.0

Re: is the whole unstable still broken by gcc-5?

2015-09-12 Thread Vincent Bernat
❦ 12 septembre 2015 21:55 +0300, Виталий Филиппов  : > Can you please tell when everything will be fixed i.e. when all packages > will be rebuilt with newer gcc? And can you please NOT upload such > "breaking updates" in the future before testing everything that's broken > in experimental?.. Beca

Re: Security concerns with minified javascript code

2015-09-04 Thread Vincent Bernat
❦ 4 septembre 2015 09:32 +0100, Neil Williams  : [Applying patch to pre-minification source] >> This will become more difficult with jQuery 3.x (due to ES6 to ES5 >> transformation). But manual adaptation should stay straightfoward >> ("transpilation" only does local transformation). > > Are the

Re: Security concerns with minified javascript code

2015-09-04 Thread Vincent Bernat
❦ 4 septembre 2015 08:29 +0100, Neil Williams  : >> > 2. Many javascript packages cannot be build from source with the >> > tools in main. >> >> This is the one I don't agree. For me, pre-minification source is >> source code. If you show the pre-minification version of jQuery, many >> people w

Re: Security concerns with minified javascript code

2015-09-03 Thread Vincent Bernat
❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath  : >>> Because you know you have the right and the ability to be a part of the free >>> software community that created the software. That is why you are running >>> Debian and don't have contrib or non-free in your sources.list. >>> >>> From your m

Re: Security concerns with minified javascript code

2015-09-03 Thread Vincent Bernat
❦ 3 septembre 2015 17:22 GMT, Bas Wijnen  : > Because you know you have the right and the ability to be a part of the free > software community that created the software. That is why you are running > Debian and don't have contrib or non-free in your sources.list. > > From your mails it is clea

Re: Security concerns with minified javascript code

2015-09-03 Thread Vincent Bernat
❦ 3 septembre 2015 21:03 +1000, Dmitry Smirnov  : >> Without minification, we'll just ship packages that people won't >> use. Why would I run a crippled installation of Wordpress that will >> drive of part of my users to another competitor? > > Sorry but that feels like exaggeration. Maybe it is

Re: Security concerns with minified javascript code

2015-09-02 Thread Vincent Bernat
❦ 3 septembre 2015 12:23 +1000, Dmitry Smirnov  : >> Amazon did a study that showed every ~100ms of page load >> delay lost them 1% in sales. > > It could be that small percentage of Amazon users are impulsive trigger-happy > buyers. :) > However that conclusion is probably wrong due to number

Re: Security concerns with minified javascript code

2015-09-02 Thread Vincent Bernat
❦ 2 septembre 2015 10:18 +0200, Samuel Thibault  : >> Or maybe you propose to just ship the whole "node_modules" directory >> (which has all the dependencies) with jQuery sources? > > That'd be a lot better than nothing. OK. Also, node_modules for jQuery is 76M (for 3.x, 70M for 2.x). I still f

Re: Security concerns with minified javascript code

2015-09-02 Thread Vincent Bernat
❦ 2 septembre 2015 09:54 +0200, Samuel Thibault  : >> If you talk about Grunt, > > That's what I'm talking about. > >> Grunt comes with a lot of plugins (and does almost nothing without >> those) and each upstream will require different plugins with different >> versions (Grunt plugin versions a

Re: Security concerns with minified javascript code

2015-09-02 Thread Vincent Bernat
❦ 2 septembre 2015 09:28 +0200, Samuel Thibault  : >> Healthy language communities have their own metadata systems and >> standardized build systems that allow Debian packaging to be nearly >> automated, *provided* that we use the same unit of distribution as >> upstream. > > I understand that u

Re: Security concerns with minified javascript code

2015-09-02 Thread Vincent Bernat
❦ 2 septembre 2015 09:32 +0300, Lars Wirzenius  : > However, I want to raise the point that upstreams do not always make > sensible decisions, and if they don't, it's good to raise that with > them. For example, there was recently an ITP bug for > node-number-is-nan. Upstream source code is at >

Re: Security concerns with minified javascript code

2015-09-01 Thread Vincent Bernat
❦ 1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud  : > I think we should take a strong move there and exercise (as well as > justify to the outer world) our free software right to recompile the > software that we ship to our users: this could mean to only merge & gzip > JS files if minifyi

Re: Security concerns with minified javascript code

2015-09-01 Thread Vincent Bernat
❦ 1 septembre 2015 13:45 -0500, Gunnar Wolf  : >> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not >> require only minification. They require transpiling (convert from ES6 to >> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency >> handling (through loade

Re: Security concerns with minified javascript code

2015-09-01 Thread Vincent Bernat
❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath  : >>> Couldn't we just use the non-minified versions in most situations? A >> >> Not for anything which has actual users over the network. > > Why? (Don't forget about gzip encoding). See: https://mathiasbynens.be/demo/jquery-size -- Don't sacrif

Re: Security concerns with minified javascript code

2015-09-01 Thread Vincent Bernat
❦ 31 août 2015 11:21 -0400, Marvin Renich  : >> > However, this is a readable source code that will accomodate any >> > modification that a end user will deem necessary. > > I intentionally did not look at the file referred to above, and have no > idea whether I would consider it to be a "preferr

Re: Security concerns with minified javascript code

2015-08-30 Thread Vincent Bernat
❦ 30 août 2015 11:52 GMT, Bas Wijnen  : >> However, this is a readable source code that will accomodate any >> modification that a end user will deem necessary. > > That is not the only reason that we want the user to have source. > They are not some detached "customer". When we make changes to

Re: Security concerns with minified javascript code

2015-08-30 Thread Vincent Bernat
❦ 29 août 2015 19:12 -0700, Steve Langasek  : > Yet you try to compare this with autoconf. Even if we tolerated configure > scripts today in the archive that we can't rebuild using the software in > Debian (which by and large we do *not* tolerate - because we've learned our > lesson), there's a

Re: Security concerns with minified javascript code

2015-08-28 Thread Vincent Bernat
❦ 28 août 2015 17:37 +0100, Steve McIntyre  : >>The problem is that this *is* usable for nearly all the people who >>currently use it, who just run one command to install it and have all >>those dependencies pulled from a remote repo for them. Because the >>dependency installation process is so

Re: Security concerns with minified javascript code

2015-08-28 Thread Vincent Bernat
❦ 28 août 2015 12:03 +0200, Samuel Thibault  : > I wonder why mere gzip compression is not used. Don't all browsers > support Accept-Compress: gzip? Minification saves some additional bytes. About 10% (when gzipped). -- If you tell the truth you don't have to remember anything.

Re: Security concerns with minified javascript code

2015-08-28 Thread Vincent Bernat
❦ 28 août 2015 10:32 +0100, Neil Williams  : > I still find it hard to believe that *so* much code is required to > minify JS. The excuse that JS is "moving fast" is nonsense. The reality > would appear to be that nobody actually *cares* about the mess, they > just use it. It's a feature. The JS

Re: Security concerns with minified javascript code

2015-08-28 Thread Vincent Bernat
❦ 28 août 2015 10:29 +0200, Samuel Thibault  : >> What will happen is that maintainers will fallback to the second less >> horrible solution and cripple the package (by using an older version of >> the JS lib for example) to allow it to stay in main. > > Why would they want to stay in main? [...

Re: Security concerns with minified javascript code

2015-08-28 Thread Vincent Bernat
❦ 28 août 2015 08:22 +0100, Philip Hands  : >>> Or alternatively, by packaging the minifier that is being used with the >>> package >>> that needs it. Yes, that's a horrible idea with lots of code duplication, >>> but >>> if I understand the problem, every JS file must be minified with the exa

Re: Security concerns with minified javascript code

2015-08-27 Thread Vincent Bernat
❦ 28 août 2015 01:46 GMT, Bas Wijnen  : > Or alternatively, by packaging the minifier that is being used with the > package > that needs it. Yes, that's a horrible idea with lots of code duplication, but > if I understand the problem, every JS file must be minified with the exact > version of t

Re: Security concerns with minified javascript code

2015-08-27 Thread Vincent Bernat
❦ 27 août 2015 22:04 GMT, Bas Wijnen  : >> > The minifier is a compiler. If it's not in main, files that are compiled >> > with >> > it cannot be in main. For javascript, the easy solution is to not use the >> > compiler. Non-minified code works fine. >> >> Non-minified code is decomposed in

Re: Security concerns with minified javascript code

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 09:27 -0700, Russ Allbery  : >>> In the Debian context, the problem is hard. But if you allow network >>> access and execution of arbitrary code recovered from some random >>> registry, rebuilding the minified version from the unminified one is >>> quite trivial. > >>> I know how i

Re: system upgrade by systemd

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 14:17 +0200, Michael Meskes  : >> There doesn't seem to have a bug report for this. This would be a better >> place to discuss this issue. > > Please tell me which package is the one misbehaving and I gladly report it. > But so far I have yet to figure that our. I would have said

Re: Security concerns with minified javascript code

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 13:01 +0100, Ian Jackson  : >> It's "unfair" to ask packages using JS stuff to be >> "perfect" right now while the difficulties are far greater. > > I'm sorry to say that the very fact that the difficulties are more > severe is an argument /against/ tolerating un-rebuilt minified j

Re: Security concerns with minified javascript code

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 12:09 +0100, Philip Hands  : > I note that this page: > > https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt > > was last touched in March, before the last thread in which you told us > that packaging grunt is very hard: > > https://lists.debian.org/debian-devel/2015/04/msg0

Re: Security concerns with minified javascript code

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 20:58 +1000, Riley Baird  : >> I would also like to stress that all this stuff is DFSG-compliant. > > Doesn't the DFSG require source code, as well as a free license? Yes and both of them are here. Only the build method is either unavailable, unspecified or needing network connec

Re: Security concerns with minified javascript code

2015-08-26 Thread Vincent Bernat
❦ 26 août 2015 09:04 +0200, Simon Josefsson  : Notably, one of the tool is Grunt and its myriad of plugins. Even if Grunt was in Debian, we would also need Gulp, then Broccoli, because in Javascript, there is always someone thinking that it should be possible to do better. We need

Re: Security concerns with minified javascript code

2015-08-25 Thread Vincent Bernat
❦ 26 août 2015 15:44 +1000, Riley Baird  : >> For years, we have been able to ship generated files without checking if >> they can really be built from sources (for example, autoconf stuff). And >> JS stuff should comply to stricter standards from day one? > > JS stuff has been in Debian for a

Re: system upgrade by systemd

2015-08-25 Thread Vincent Bernat
❦ 26 août 2015 05:23 +0200, Michael Meskes  : >> Looks like it's probably worth uninstalling all of the packagekit >> stuff if you don't want this horrendous anti-feature. > > Turns out I had only packagekit itself installed. Shouldn't its > description mention this "horrendous anti-feature"? I c

Re: Security concerns with minified javascript code

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 22:46 +0100, Steve McIntyre  : >>Notably, one of the tool is Grunt and its myriad of plugins. Even if >>Grunt was in Debian, we would also need Gulp, then Broccoli, because in >>Javascript, there is always someone thinking that it should be possible >>to do better. We need to leave

Re: Security concerns with minified javascript code

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 22:37 GMT, Bas Wijnen  : >> We need to leave the Javascript ecosystem mature a bit more but in the >> meantime, a bit of tolerance would be appreciated > > The minifier is a compiler. If it's not in main, files that are compiled with > it cannot be in main. For javascript, the ea

Re: Security concerns with minified javascript code

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 17:58 GMT, Bas Wijnen  : > I don't see why javascript minification would be different from C compilation > in a way that would lead to a different way of handling it. Playing a bit of devil's advocate here, but... It has already been said numerous time in the past, for some Javas

Re: system upgrade by systemd

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 18:03 +0200, Vincent Bernat  : >> Can anyone tell me which package/configuration is reponsible for systemd >> running a package upgrade during bootup? I certainly never willingly >> configured this feature, but still have it. And for the second time it >>

Re: system upgrade by systemd

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 17:18 +0200, Michael Meskes  : > Can anyone tell me which package/configuration is reponsible for systemd > running a package upgrade during bootup? I certainly never willingly > configured this feature, but still have it. And for the second time it > destroyed my system by deinsta

Re: Security concerns with minified javascript code

2015-08-25 Thread Vincent Bernat
❦ 25 août 2015 16:04 +0200, Jakub Wilk  : >>> I believe the blog post below has relevance to Debian's stance on >>> including minified JavaScript in packages: >>> >>>https://zyan.scripts.mit.edu/blog/backdooring-js/ >>> >>> To me the problem suggests that it is important from a security and >>> a

Re: Raising the severity of reproduciblity issues to "important"

2015-08-24 Thread Vincent Bernat
❦ 24 août 2015 22:30 +0100, Colin Tuckley  : >> We have pushed other archive-wide goals that were not shared by >> all upstreams. For example, we have enabled hardening build flags >> on almost all packages and for packages that don't obey to the >> appropriate flags, bugs with severity "importan

Re: Raising the severity of reproduciblity issues to "important"

2015-08-24 Thread Vincent Bernat
❦ 24 août 2015 21:12 +0100, Colin Tuckley  : >> Well, I object strongly. > > Same here, in my view reproducibility is a 'nice to have' it should > *never* be forced on a package. > > We are in the business of packaging upstream software for > distribution. We should not make arbitrary changes to

Bug#796221: ITP: php-net-ldap3 -- Object oriented interface for searching and manipulating LDAP entries

2015-08-20 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: php-net-ldap3 Version : 1.0.3 Upstream Author : Jeroen van Meeuwen * URL : https://git.kolab.org/diffusion/PNL/php-net_ldap.git * License

Re: How to update control file time stamps

2015-08-16 Thread Vincent Bernat
❦ 16 août 2015 17:54 +0200, Malte Forkel  : >> wasn't there a command to update the time stamps of control files in the >> debian directory? >> >> Thanks, >> Malte >> >> > > Sorry for being unclear. > > Some of the control files used for packaging end with a time stamp that > also includes the

Re: Facilitating external repositories

2015-08-12 Thread Vincent Bernat
❦ 12 août 2015 23:12 GMT, Anthony Towns  : > - PPAs: Debian hosted, but more loosely controlled. experimental gone >wild? maybe third party uploads? probably only free things? It could also be backports that don't fit the backport policy. -- I have never let my schooling interfere with my

Re: Debian with HiDPI / 4K displays

2015-08-12 Thread Vincent Bernat
❦ 12 août 2015 15:30 +0200, Ondřej Surý  : > Try Debian stretch - it mostly works out of the box with GNOME 3.16 > without tweaking anything. I am running on: > > dimensions:3200x1800 pixels (846x476 millimeters) > > with internal display and simple FullHD on external and the only thing > t

Re: Debian with HiDPI / 4K displays

2015-08-10 Thread Vincent Bernat
❦ 10 août 2015 23:29 +0200, Simon Kainz  : >>> This handles the majority of programs I use. A few notable >>> exceptions: gitk scales up some but not all of its fonts >>> (reported as a bug), Celestia's and stellarium's in-rendering >>> text (reported as bugs), old X utilities like >>> xcalc/xco

Re: Debian with HiDPI / 4K displays

2015-08-09 Thread Vincent Bernat
❦ 9 août 2015 16:28 +0200, Daniel Pocock  : > b) it needs to be tweaked in more than one place (e.g. xrdb + Iceweasel > + other places) Yes, that's unfortunate. If GTK people could explain Iceweasel and Chromium people how they should handle it, it would lessen the amount of manual configuratio

Re: Debian with HiDPI / 4K displays

2015-08-09 Thread Vincent Bernat
❦ 8 août 2015 18:11 -0700, Josh Triplett  : > This handles the majority of programs I use. A few notable exceptions: > gitk scales up some but not all of its fonts (reported as a bug), > Celestia's and stellarium's in-rendering text (reported as bugs), old X > utilities like xcalc/xconsole/xedi

Re: Debian with HiDPI / 4K displays

2015-08-08 Thread Vincent Bernat
❦ 8 août 2015 20:58 +0200, Daniel Pocock  : > The hardware setup was quite straightforward as I chose to buy a new > graphics card with 4K support and a relatively new monitor. The > graphics card and monitor both support DisplayPort 1.2 so I just hook > them up with the standard cable. > > The

Re: Ad-hoc survey of existing Debian git integration tools

2015-08-05 Thread Vincent Bernat
❦ 5 août 2015 18:56 GMT, Thorsten Glaser  : >> There are two variants. One does have the patches under debian/patches/ >> (although this does not mix well with VCS IMO, so I don’t usually use >> it), in which case either the applied or unapplied source tree may be >> in the VCS. Both are troubli

Re: Ad-hoc survey of existing Debian git integration tools

2015-07-30 Thread Vincent Bernat
❦ 30 juillet 2015 11:54 +0100, Ian Jackson  : >> > Do your published git branches contain the patches-applied or >> > patches-unapplied tree ? >> >> Without using "gbp pq", the published git branches are patches-unapplied >> trees. > > Then to use dgit push, you must use gbp pq. > > Do you see w

Re: Ad-hoc survey of existing Debian git integration tools

2015-07-29 Thread Vincent Bernat
❦ 30 juillet 2015 01:09 +0100, Ian Jackson  : >> There is a patch management system but I think that most people (at >> least me) are just using gbp with plain/normal quilt. > > Do your published git branches contain the patches-applied or > patches-unapplied tree ? Without using "gbp pq", the p

Re: Ad-hoc survey of existing Debian git integration tools

2015-07-29 Thread Vincent Bernat
❦ 29 juillet 2015 13:48 +0100, Ian Jackson  : >> > If you are an NMUer or a downstream using dgit, you should usually >> > make plain git commits (with no changes to the patch stack). dgit >> > will generate a separate patch for each of your commits. You should >> > leave rebasing/squashing/ref

Bug#793807: ITP: asyncssh -- asynchronous client and server implementation of SSHv2 for Python's asyncio

2015-07-27 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: asyncssh Version : 1.2.0 Upstream Author : Ron Frederick * URL : https://github.com/ronf/asyncssh * License : Eclipse Public License

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’

2015-07-11 Thread Vincent Bernat
❦ 10 juillet 2015 22:00 GMT, Jeremy Stanley  : > Simulating Gerrit's behaviors in this regard would probably not > satisfy the desire for a "replacement for pull requests" however > since Gerrit assumes a LKML-esque "rebase your patch until you get > it right" approach rather than the "keep stack

Re: prebuild javascript objects in source

2015-07-08 Thread Vincent Bernat
❦ 8 juillet 2015 12:54 +0200, Michael Meskes  : > what am I supposed to do with prebuilt javascript objects in my source tree > that do not appear to come with sources? None of those are actually used or > installed for that matter, but they are part of the source tree and lintian > complains ab

Re: Proposal: enable stateless persistant network interface names

2015-06-29 Thread Vincent Bernat
❦ 29 juin 2015 22:29 +0200, Thomas Goirand  : >>> So your proposal is: if the default is unusable (like above), then the >>> poor user has to find a way to fix that... I'm not convince that this is >>> what we want. I'd very much prefer a usable default. >> Me too, but there is none that we can u

Re: Status on ddeb support in Debian

2015-06-29 Thread Vincent Bernat
❦ 29 juin 2015 18:17 +0200, Niels Thykier  : > * Only known blocker is missing archive/dak support. Is any help needed here? -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

2015-06-16 Thread Vincent Bernat
❦ 16 juin 2015 15:50 +0200, Guillem Jover  : > In any case, barring better documentation or guides, using example > implementations simpler than glibc might be useful to people. So I > offer libbsd, but I'm sure there are many others. We could perhaps > even create a wiki page listing some of tho

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

2015-06-16 Thread Vincent Bernat
❦ 15 juin 2015 20:20 -0700, Russ Allbery  : >>> To avoid confusing myself further, Russ and Neil, are you both talking >>> about the "debian/symbols" files? I thought Russ might have been >>> talking about "versioned symbols at DSO level" (e.g. symbol@LOW0 vs >>> symbol@LOW1). > >> I'm pretty su

Re: Facilitating external repositories

2015-06-06 Thread Vincent Bernat
❦ 6 juin 2015 13:48 +0800, Paul Wise  : >> the software is far to volatile (e.g. important bug fixes on a weekly basis) > > We have a place for such software: experimental Won't work for users needing the software on a stable release. -- Use recursive procedures for recursively-defined data st

Bug#787114: ITP: pytest-httpbin -- Test an HTTP library against a local copy of httpbin.org

2015-05-28 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: pytest-httpbin Version : 0.0.6 Upstream Author : Kevin McCarthy * URL : https://github.com/kevin1024/pytest-httpbin * License : Expat

Bug#787113: ITP: httpbin -- HTTP Request and Response Service

2015-05-28 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: httpbin Version : 0.2.1 Upstream Author : Runscope Community * URL : https://github.com/Runscope/httpbin * License : ISC Programming Lang

Bug#787015: ITP: libcbor -- C library for parsing and generating CBOR (RFC 7049)

2015-05-27 Thread Vincent Bernat
Package: wnpp Severity: wishlist Owner: Vincent Bernat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: libcbor Version : 0.3.1 Upstream Author : Pavel Kalvoda * URL : https://github.com/PJK/libcbor * License : MIT Programming Lang: C

Re: please use signed git commits (and tags)

2015-05-26 Thread Vincent Bernat
❦ 26 mai 2015 14:38 -0300, Henrique de Moraes Holschuh  : >> A solution to this without history rewriting is to tag the commits you >> want to sign. >> >> You could tag any commit at any time, and sign that tag. Impractical if >> you want to retroactively sign a huge swathe of commits, but not b

Re: static linking

2015-05-19 Thread Vincent Bernat
❦ 19 mai 2015 09:30 +0800, Paul Wise  : > I have prepared a short document on static linking and Debian, with the > aim to reduce existing static linking, document unavoidable static > linking and find ways to mitigate unavoidable static linking. > > https://wiki.debian.org/StaticLinking I have

Re: Modern Debian packaging system for DevOps: does it exist?

2015-05-15 Thread Vincent Bernat
❦ 15 mai 2015 17:57 +0200, gregor herrmann  : >> A good timesaver is to have libeatmydata or similar. But this is still >> slow. For example, the manual page step. > > For pbuilder/cowbuilder I'm using the following hook: > > % cat /var/cache/pbuilder/hooks/D10-man-db > #!/bin/sh > # Don't rebui

Re: Modern Debian packaging system for DevOps: does it exist?

2015-05-15 Thread Vincent Bernat
❦ 15 mai 2015 08:19 +0100, Neil Williams  : >> For some packages, installing the dependencies can take more time than >> building the package. > > An inevitable cost of building software that has a significant stack of > dependencies. However, each of those dependencies needs to be cleaned > up

Re: Experimental ddeb support in debhelper and lintian

2015-05-14 Thread Vincent Bernat
❦ 4 avril 2015 10:54 +0200, Niels Thykier  : > * There is an experimental branch for debhelper to generate these >automatically available. >- Requires a "export DH_BUILD_DDEBS=1" to trigger the code path >- It applies to *all* compat levels. >- Trying to get the reproducible tea

Re: Modern Debian packaging system for DevOps: does it exist?

2015-05-14 Thread Vincent Bernat
❦ 14 mai 2015 17:22 +0300, Исаев Виталий  : > Regarding the state of containers after the finish of the build > process: we surely don't need them anymore. Every container is used > just once and removed after a while. We have docker image with > preinstalled compilers and packaging toolchain. Al

Re: Modern Debian packaging system for DevOps: does it exist?

2015-05-14 Thread Vincent Bernat
❦ 14 mai 2015 14:57 +0100, Neil Williams  : >> More seriously, but this needs some additional work, it should be >> easier to manage persistent build dependencies. The first time you >> build a package, it retrieves and install all deps. The second time, >> the build environment is already here.

Re: Modern Debian packaging system for DevOps: does it exist?

2015-05-14 Thread Vincent Bernat
❦ 14 mai 2015 14:02 +0100, Neil Williams  : >> 1. Gitlab; >> 2. Isolated build environment inside Docker containers (where we >> usually do `git clone && mk-build-deps && debuild`); >> 3. Aptly; >> 4. Self-written Python scripts linking all these components; > > What is the reason for doc

Re: Proposal: enable stateless persistant network interface names

2015-05-10 Thread Vincent Bernat
❦ 10 mai 2015 10:45 -0400, The Wanderer  : >> Do you speak about ifupdown? It's Debian only. eth* interfaces is >> not *nix at all since all BSD are using per-driver naming >> convention. > > Upon consideration, I suspect that I've been making - at least - the > following three assumptions: > > *

<    1   2   3   4   5   6   7   >