Re: OpenSSL 1.1.0
On 2016-11-15.00:16, Adrian Bunk wrote: > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid > free." > or #843988 will be a common sight on the list of RC bugs for several > months in any scenario with OpenSSL 1.1 as default. > > ... > > 2. move the stretch release schedule by 6-12 months to have >only OpenSSL 1.1 in stretch So with OpenSSL 1.1 in stretch, the release schedule is going to move by 6-12 months regardless? -- Regards, Scott. signature.asc Description: Digital signature
Multipath (SAN disk) support broken in jessie
Hi I am trying to set up a automatic PXE install of jessie on physical servers connected to a SAN. My problem is that multipath support seems to be very broken in jessie, and after fixing the first problems, I am now stuck, as the install seems to work but the server can not find its root filesystem after reboot. The first problem is that the multipath udeb is broken as described in bug #779579, the bug is closed, but the problem is actually not fixed, so I have opened a new bugreport #843885 to see if we can get it fixed for real. Maybe it is fixed, but the fix has not been ported to the netboot images. The second problem is in the disk-detect udeb, which can not find the multipath device that is found, the reason is a rename of mpath0-9 to mpatha-z, there is a bug report for that #806713, and after that the parted-multipath also needs to be patched for the same. Now the rest of the install seems to work fine, but after reboot, the server will not start, as it can not find its root, the problem may have to do with the naming of partitions as in this bug report #827308, but does that mean that I will have to give up on getting jessie to install on multipath disks, and wait for stretch ? Best regards Allan Jacobsen
Re: OpenSSL 1.1.0
Quoting Adrian Bunk (2016-11-14 23:16:14) > On Mon, Nov 14, 2016 at 07:10:00PM +, Niels Thykier wrote: >> Marco d'Itri: >>> On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and have libssl1.1-dev around for anyone who can really do the switch. >>> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a >>> very bad default for next year's release. >>> Bad enough that I would have to use a different distribution for >>> some web servers. [...] > For Apache, the choices available are: > 1. no ChaCha20 in Apache in stretch > 2. move the stretch release schedule by 6-12 months to have >only OpenSSL 1.1 in stretch > 3. apply ChaCha20 patches to OpenSSL 1.0.2 4. use libapache2-mod-gnutls? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Re: OpenSSL 1.1.0
On 2016-11-15 11:59, Jonas Smedegaard wrote: 4. use libapache2-mod-gnutls? that might work for you, but its nothing the common debian user will do. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: OpenSSL 1.1.0
On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: > On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev > > and have libssl1.1-dev around for anyone who can really do the switch. > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very > bad default for next year's release. > Bad enough that I would have to use a different distribution for some > web servers. That's why I wrote: And if we **really** need to switch to libssl1.1 then we **really** need to delay the release by 6 months as a very minimum, maybe 1 year. Yes, I also know that it sounds awful, but do we have another way out? -- Ponga su mano en una estufa caliente por un minuto, y le parecerá como una hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto. ¡Eso es relatividad!. Albert Einstein (1879-1955) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.1.0
On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote: [snip] > (It's fine if packages which depend on libssl-dev get an RC-bug if they > can't be compiled with OpenSSL 1.1. Packages which can't be ported > should explicitly depend on libssl1.0-dev. That way we'll make progress > towards a point where we can start a smooth transition.) I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev means that some apps/libs will get automatically recompiled and some of them might even not FTBFS (because for example, they are ready to use 1.1). That means we left the door open to crashes due to mixed libssl versions. By letting libssl-dev provide libssl1.0 we do not open this door, and we let maintainers decide on a per-basis case. -- You are the Doc, Doc! Marty McFly To Dr. Emmett Brown, Back to the Future III Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.1.0
On 2016-11-15 14:43, Lisandro Damián Nicanor Pérez Meyer wrote: I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev means that some apps/libs will get automatically recompiled and some of them might even not FTBFS (because for example, they are ready to use 1.1). If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug that should be fixed anyway. There is no real reason not to support both versions. That means we left the door open to crashes due to mixed libssl versions. By letting libssl-dev provide libssl1.0 we do not open this door, and we let maintainers decide on a per-basis case. And we have to maintain two openssl versions trough the release cycle. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: OpenSSL 1.1.0
On martes, 15 de noviembre de 2016 14:52:15 ART Bernd Zeimetz wrote: > On 2016-11-15 14:43, Lisandro Damián Nicanor Pérez Meyer wrote: > > I *really* disagree with that. Swtiching libssl-dev to provide > > libssl1.1-dev > > means that some apps/libs will get automatically recompiled and some of > > them > > might even not FTBFS (because for example, they are ready to use 1.1). > > If a 1.1.0 ready package ftbfs when libssl-dev points to 1.0 it is a bug > that > should be fixed anyway. There is no real reason not to support both > versions. A bug which, IMO, should not be RC right now, but switching libssl-dev to provide libssl1.1 *now* will probably hide crashes in the case I described above. So yes, I agree with you, I just don't agree this is the right time. Doing it as soon as the buster release cycle starts it's just fine. > > That means we left the door open to crashes due to mixed libssl > > versions. > > > > By letting libssl-dev provide libssl1.0 we do not open this door, and > > we let > > maintainers decide on a per-basis case. > > And we have to maintain two openssl versions trough the release cycle. For stretch we will already have, except we delay the release by ~1 year. Which again, if it's deemed necessary, then we should consider it. -- Una vez que hemos eliminado lo imposible, lo que queda, por improbable que parezca, es la verdad. Sherlock Holmes Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.1.0
On Tue, Nov 15, 2016 at 10:43:07AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote: > [snip] > > (It's fine if packages which depend on libssl-dev get an RC-bug if they > > can't be compiled with OpenSSL 1.1. Packages which can't be ported > > should explicitly depend on libssl1.0-dev. That way we'll make progress > > towards a point where we can start a smooth transition.) > > I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev > means that some apps/libs will get automatically recompiled and some of them > might even not FTBFS (because for example, they are ready to use 1.1). > > That means we left the door open to crashes due to mixed libssl versions. I probably didn't state that clear enough: I don't think libssl-dev should provide libssl1.1-dev. But building packages - purely for testing purposes - against libssl1.1-dev and reporting any issues is a good thing, and I even think such bugs could be marked RC, to make sure we make progress. At the same time, I don't want to remove packages which can't be ported quickly. Therefore, either these bugs can't be RC, or there must be an easy way for maintainers to opt out. One way of such an opt-out would be changing the dependency to libssl1.0-dev. However, the quoted paragraph was meant as a side-note only. It's not important, at the moment. The one thing we should decide *quickly* is if we want to revert libssl-dev back to 1.0, or if we want to delay the freeze by several months. > By letting libssl-dev provide libssl1.0 we do not open this door, and we let > maintainers decide on a per-basis case. Yes, and we avoid cases like with libcurl3, where the recompile to libssl1.1 broke ABI compatibility of libcurl3 without notice. Jan
Re: OpenSSL 1.1.0
On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: > > On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: > > > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev > > > and have libssl1.1-dev around for anyone who can really do the switch. > > I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a very > > bad default for next year's release. > > Bad enough that I would have to use a different distribution for some > > web servers. > > That's why I wrote: > > And if we **really** need to switch to libssl1.1 then we **really** need to > delay the release by 6 months as a very minimum, maybe 1 year. > > Yes, I also know that it sounds awful, but do we have another way out? Yes, patching the OpenSSL 1.1 features that are really needed into the Debian OpenSSL 1.0.2 package. For ChaCha20 that's existing patches that are already being used elsewhere. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: OpenSSL 1.1.0
On Tue, Nov 15, 2016 at 07:03:28PM +1100, Scott Leggett wrote: > On 2016-11-15.00:16, Adrian Bunk wrote: > > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid > > free." > > or #843988 will be a common sight on the list of RC bugs for several > > months in any scenario with OpenSSL 1.1 as default. > > > > ... > > > > 2. move the stretch release schedule by 6-12 months to have > >only OpenSSL 1.1 in stretch > > So with OpenSSL 1.1 in stretch, the release schedule is going to move by > 6-12 months regardless? Shipping OpenSSL 1.1 as security-supported technology preview in stretch, and a few packages that both work with OpenSSL 1.1 and do not have inter(r)dependencies with packages that don't work properly with OpenSSL 1.1 could use it - that would be possible without negative impact on the release schedule. > Regards, > Scott. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#844424: ITP: ruby-airbrussh -- Airbrussh pretties up your SSHKit and Capistrano output
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: ruby-airbrussh Version : 1.1.1 Upstream Author : Matt Brictson * URL : https://github.com/mattbrictson/airbrussh * License : MIT Programming Lang: Ruby Description : Airbrussh pretties up your SSHKit and Capistrano output Airbrush is a replacement log formatter for SSHKit that makes Capistrano output much easier on the eyes. It Provides concise, useful log output that is easy to read. This package is a new dependency for capistrano, it will be maintained inside the pkg-ruby-extras team.
Re: OpenSSL 1.1.0
Lots of people have posted in this thread that they see problems with our current approach to the openssl transition. Do the openssl maintainers have an response ? Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: libc recently more aggressive about pthread locks in stable ?
On Mon, Nov 14, 2016 at 10:31:18AM +0100, Gert Wollny wrote: > Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes > Holschuh: > > > > > > > > Unfortunately, when hardware lock elision support was added to glibc > > upstream, libpthreads was *not* changed to properly assert() this > > forbidden condition on the non-hardware-elision codepaths. Such an > > assert() would have given us consistent behavior, thus flushing the > > bugs out in the open... at the cost of a performance hit (I have no > > idea how severe), and much screaming. > > An alternative to find problems with (un-)locking should be to compile > the program in question with -fsanitize=thread (on amd64) and run it. > > Unfortunately, in current unstable with thread sanitizer one might get > #796246 (at least I had this). Does "-fsanitize=thread -no-pie" work for you? > Best, > Gert cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: OpenSSL 1.1.0 / transition process
On 15/11/16 16:54, Ian Jackson wrote: > Lots of people have posted in this thread that they see problems with > our current approach to the openssl transition. > > Do the openssl maintainers have an response ? I just started looking at this thread 2 minutes ago. I really don't know where to start. Would the OpenSSL maintainers and/or release managers consider making a wiki page about the transition with the most common questions about it, similar to the upstream wiki but with a Debian focus? The questions which come to my mind (and may already be answered): - will it definitely go ahead for stretch? - will the stretch freeze and release dates be delayed to allow people to catch up? - is it expected that package maintainers spend time patching for this, or we can wait for upstreams to support it? - given the huge number of packages listed on the transition page, I couldn't help feeling that it would be useful to be able to get some reports about how many packages have now had a bug forwarded upstream, how many upstreams have released a newer version with the fix, how many upstreams have a fix that is not released, etc Wearing my upstream hat, I do hope to ensure my own packages support it sooner rather than later. Some of them will go into NEW though because they have ABI or API version numbers in the binary package names, so they won't be available immediately. Regards, Daniel
Re: DEP14 policy for two dots
FTR, I answered most questions about "why not dgit?" in the thread I just moved to vcs-pkg-discuss only[1]. For some specific questions here: On Thu, Nov 10, 2016 at 12:31:31AM +, Ian Jackson wrote: > dgit can work on Ubuntu too, in a readonly mode. (It would be nice to > make `dgit push' work on Ubuntu but that requires a suitable git > server, and some configration on the dgit client side.) A key difference with our system is that no infrastructure is required. It's distributed (-able), with no special git remote. > The --skip-patches is a vital difference. > Has the decision to use --skip-patches been definitively taken ? For now, to fulfill our use case, yes. In the general case, no, not at all. Probably the best place to enter into this would be in a reply to my fuller explanation of the reasons in [1]. > I would like to beg you to reconsider this, in the strongest possible > terms. --skip-patches generates a patches-unapplied tree. > > A patches-unapplied tree: Sorry, I missed reference to this list when I wrote [1]. I'll study these and consider how they related to my reasons later. > If you are making patches-unapplied trees I think you cannot possibly > be representing the quilt patch stack of a `3.0 (quilt)' source > package as a series of git commits. Correct. This has not been our goal. > Representing a `3.0 (quilt)' package that way is desirable, as it > means that `git blame' and `git log' can be used to see which patches > do what. In contrast, in our Ubuntu development workflow, what you mention is not a requirement, but what is a requirement is to use "git blame" and "git log" to see when the quilt patches applied were altered. We don't want to drill down as far as you are suggesting; instead, we want the information at one level removed. Robie signature.asc Description: PGP signature
Bug#844436: ITP: obsub -- Python module that implements the observer pattern via a decorator
Package: wnpp Severity: wishlist Owner: Free Ekanayaka * Package name: obsub Version : 0.2.0 Upstream Author : Eduard Bopp * URL : https://github.com/aepsil0n/obsub * License : CC0 Programming Lang: Python Description : Python module that implements the observer pattern via a decorator This module can decorate functions or modules so they become "observable". Consuming code can subscribe callbacks to these decorated callables, which will be triggered everytime the callables are invoked.
Multipath (SAN disk) support broken in jessie
Hi I am trying to set up a automatic PXE install of jessie on physical servers connected to a SAN. My problem is that multipath support seems to be very broken in jessie, and after fixing the first problems, I am now stuck, as the install seems to work but the server can not find its root filesystem after reboot. The first problem is that the multipath udeb is broken as described in bug #779579, the bug is closed, but the problem is actually not fixed, so I have opened a new bugreport #843885 to see if we can get it fixed for real. Maybe it is fixed, but the fix has not been ported to the netboot images. The second problem is in the disk-detect udeb, which can not find the multipath device that is found, the reason is a rename of mpath0-9 to mpatha-z, there is a bug report for that #806713, and after that the parted-multipath also needs to be patched for the same. Now the rest of the install seems to work fine, but after reboot, the server will not start, as it can not find its root, the problem may have to do with the naming of partitions as in this bug report #827308, but does that mean that I will have to give up on getting jessie to install on multipath disks, and wait for stretch ? Best regards Allan Jacobsen
Re: Multipath (SAN disk) support broken in jessie
Hi, On Tue, Nov 15, 2016 at 08:49:15AM +0100, Allan Jacobsen wrote: > that mean that I will have to give up on getting jessie to install on > multipath disks, and wait for stretch ? From >10 Years of experience with installer issues: Yes Once the release is out my experience is that those niche bugs will not get any attention or fixing. So you better work around those bugs ... The installer is scriptable and i have tons of classes working around bugs in the last releases. You better start testing Stretch NOW and report bugs ASAP. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away signature.asc Description: Digital signature
Re: DEP14 policy for two dots
Robie forgot this bit (I think): [1] http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2016-November/000909.html Cheers, mwh On 16 November 2016 at 05:38, Robie Basak wrote: > FTR, I answered most questions about "why not dgit?" in the thread I > just moved to vcs-pkg-discuss only[1]. > > For some specific questions here: > > On Thu, Nov 10, 2016 at 12:31:31AM +, Ian Jackson wrote: > > dgit can work on Ubuntu too, in a readonly mode. (It would be nice to > > make `dgit push' work on Ubuntu but that requires a suitable git > > server, and some configration on the dgit client side.) > > A key difference with our system is that no infrastructure is required. > It's distributed (-able), with no special git remote. > > > The --skip-patches is a vital difference. > > Has the decision to use --skip-patches been definitively taken ? > > For now, to fulfill our use case, yes. In the general case, no, not at > all. Probably the best place to enter into this would be in a reply to > my fuller explanation of the reasons in [1]. > > > I would like to beg you to reconsider this, in the strongest possible > > terms. --skip-patches generates a patches-unapplied tree. > > > > A patches-unapplied tree: > > Sorry, I missed reference to this list when I wrote [1]. I'll study > these and consider how they related to my reasons later. > > > If you are making patches-unapplied trees I think you cannot possibly > > be representing the quilt patch stack of a `3.0 (quilt)' source > > package as a series of git commits. > > Correct. This has not been our goal. > > > Representing a `3.0 (quilt)' package that way is desirable, as it > > means that `git blame' and `git log' can be used to see which patches > > do what. > > In contrast, in our Ubuntu development workflow, what you mention is not > a requirement, but what is a requirement is to use "git blame" and "git > log" to see when the quilt patches applied were altered. We don't want > to drill down as far as you are suggesting; instead, we want the > information at one level removed. > > Robie >
Re: OpenSSL 1.1.0 / transition process
On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote: > Would the OpenSSL maintainers and/or release managers consider making a > wiki page about the transition with the most common questions about it, > similar to the upstream wiki but with a Debian focus? I started one at https://wiki.debian.org/OpenSSL-1.1 > The questions which come to my mind (and may already be answered): > > - will it definitely go ahead for stretch? > > - will the stretch freeze and release dates be delayed to allow people > to catch up? > > - is it expected that package maintainers spend time patching for this, > or we can wait for upstreams to support it? I can't answer those. I just copied them into the Wiki hoping someone will. > - given the huge number of packages listed on the transition page, I > couldn't help feeling that it would be useful to be able to get some > reports about how many packages have now had a bug forwarded upstream, > how many upstreams have released a newer version with the fix, how many > upstreams have a fix that is not released, etc I added to the wiki a few links: - my ben page. Similar to release team's page but it shows which package moved to 1.0 and which more towards 1.1. (updated ~17.15 UTC). - BTS user tags bugs. All bugs reported by Kurt and myself were user tagged. > Regards, > > Daniel Sebastian
Re: OpenSSL 1.1.0
On 2016-11-15 00:16:14 [+0200], Adrian Bunk wrote: > And since 80% of all OpenSSL-using packages in unstable are still > using libssl1.0.2 (binNMUs have not yet happened), all runtime > issues observed so far are only the tip of the iceberg. > Bugs like "With Kurt's patch, apache2 crashes on startup with an invalid > free." > or #843988 will be a common sight on the list of RC bugs for several > months in any scenario with OpenSSL 1.1 as default. Are you afraid of bugs or that nobody will look after them? Can't speak for apache but #843988 got patched and so did #843532. Sebastian
Re: OpenSSL 1.1.0 / transition process
Quoting Sebastian Andrzej Siewior (2016-11-16 00:01:06) > On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote: > > Would the OpenSSL maintainers and/or release managers consider > > making a wiki page about the transition with the most common > > questions about it, similar to the upstream wiki but with a Debian > > focus? > > I started one at > https://wiki.debian.org/OpenSSL-1.1 Great! > > The questions which come to my mind (and may already be answered): > > > > - will it definitely go ahead for stretch? > > > > - will the stretch freeze and release dates be delayed to allow > > people to catch up? > > > > - is it expected that package maintainers spend time patching for > > this, or we can wait for upstreams to support it? [...] > - BTS user tags bugs. All bugs reported by Kurt and myself were user > tagged. - will those user-tagged bugs properly track all related issues too? As an example, Bug#828590 for uwsgi is currently being addressed. When I can hopefully upload that package tomorrow, the package evidently no longer fails to build from source and the FTBFS bug can therefore be closed. But at the same time other bugs - less severe, but directly caused by the conflicting libssl libraries - will emerge¹. I can try to treat such collateral issues as related - e.g. by cloning and adapting, and/or by keeping open the original bug and renaming it, and maybe by user-tagging (if someone documents what tagging is suitable - I sure don't want to make things worse by sloppy bug tagging). But it seems to me that there is a real risk that some of the bugs tracked in above wiki page may miss out on some similar collateral problems in other packages. - Jonas ¹ uwsgi build-depends not only on libssl-dev, but also libapache-dev, php-dev and libcurl4-openssl-dev now linking against conflicting libssl*-dev packages. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#844469: ITP: golang-github-jessevdk-go-flags -- go command line option parser
Package: wnpp Severity: wishlist Owner: Tim Potter X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-github-jessevdk-go-flags Version : 1+git20161025.376.0648c82-1 Upstream Author : Jesse van den Kieboom * URL : https://github.com/jessevdk/go-flags * License : BSD-3-clause Programming Lang: Go Description : Go library for parsing command line arguments This library provides similar functionality to the builtin flag library of Go, but provides much more functionality and nicer formatting. The library uses structs, reflection and struct field tags to allow users to specify command line options. This results in very simple and concise specification of your application options. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#844468: ITP: golang-github-jmoiron-sqlx -- General purpose extensions to golang's database/sql
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-jmoiron-sqlx Version : sqlx-v1.1+git20160206.61.398dd58-1 Upstream Author : Jason Moiron * URL : https://github.com/jmoiron/sqlx * License : Expat Programming Lang: Go Description : General purpose extensions to Golang's database/sql library sqlx is a library which provides a set of extensions on Go's standard database/sql library. The sqlx versions of sql.DB, sql.TX, sql.Stmt, et al. all leave the underlying interfaces untouched, so that their interfaces are a superset on the standard ones. This makes it relatively painless to integrate existing codebases using database/sql with sqlx. Major additional concepts are: * Marshal rows into structs (with embedded struct support), maps, and slices * Named parameter support including prepared statements * Get and Select to go quickly from query to struct/slice signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#844471: ITP: pdfkit -- Python wrapper for wkhtmltopdf to convert HTML to PDF using Webkit
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: pdfkit Version : 0.5.0 Upstream Author : Golovanov Stanislav * URL : https://github.com/JazzCore/python-pdfkit * License : MIT/Expat Programming Lang: Python Description : Python wrapper for wkhtmltopdf to convert HTML to PDF using Webkit Python 2 and 3 wrapper for wkhtmltopdf utility to convert HTML to PDF using Webkit. . Wkhtmltopdf conversion and all wkhtmltopdf options are available in Python from this module I intend to maintain this within the Debian Python Modules Team.
Bug#844472: ITP: golang-github-kisom-goutils -- Various TLS certificate and other utility libraries for Golang
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-kisom-goutils Version : 0.0~git20161101.0.858c9cb-1 Upstream Author : Kyle Isom * URL : https://github.com/kisom/goutils * License : Expat Programming Lang: Go Description : Various TLS certificate tools and other utility libraries for Golang This package contains a collection of utility libraries for Golang, as well as an assortment of tools mainly for displaying information about TLS certificates and keys. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#844474: Subject: ITP: golang-github-geertjohan-go.rice -- Go package for embedding web resources into Go executables
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-geertjohan-go.rice Version : 0.0~git20160123.0.0f3f5fd-1 Upstream Author : Geert-Johan Riemer * URL : https://github.com/GeertJohan/go.rice * License : BSD-2-clause Programming Lang: Go Description : Go package for embedding web resources into Go executables go.rice is a Golang package that makes working with resources such as html, js, css, images and templates very easy. During development go.rice will load required files directly from disk. Upon deployment it is easy to add all resource files to a executable using the rice tool, without changing the source code for your package. Several methods are provided for adding resources to your binary by go.rice. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#844477: ITP: golang-github-cloudflare-redoctober -- Software-based two-man rule style encryption and decryption server
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-cloudflare-redoctober Version : 0.0~git20161017.0.78e9720-1 Upstream Author : Nicholas Sullivan * URL : https://github.com/cloudflare/redoctober * License : BSD-2-Clause Programming Lang: Go Description : Software-based two-man rule style encryption and decryption server Red October is a software-based two-man rule style encryption and decryption server. The two-man rule is a control mechanism designed to achieve a high level of security by requiring the presence of two authorized people at all times. In the case of Red October the two-man rule is implemented by encrypting data in such as way as to require two authorised key-holds to decrypt it. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenSSL 1.1.0 / transition process
On 16/11/16 00:01, Sebastian Andrzej Siewior wrote: > On 2016-11-15 17:42:59 [+0100], Daniel Pocock wrote: >> Would the OpenSSL maintainers and/or release managers consider making a >> wiki page about the transition with the most common questions about it, >> similar to the upstream wiki but with a Debian focus? > > I started one at > https://wiki.debian.org/OpenSSL-1.1 > Great, thanks for doing that, I dropped in a couple of additional questions (testing upstream builds with travis-ci, testing on jessie)
