Bug#819532: ITP: libgzstream -- provide functionality of zlib C-library in a C++ iostream
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libgzstream Version : 1.5 Upstream Author : Deepak Bandyopadhyay, Lutz Kettner * URL : http://www.cs.unc.edu/Research/compgeom/gzstream/ * License : LGPL Programming Lang: C++ Description : provide functionality of zlib C-library in a C++ iostream Gzstream is a small C++ library, basically just a wrapper, that provides the functionality of the zlib C-library in a C++ iostream. Remark: This very small lib is embedded in several packages as code copy[1]. While this package is by no means in the field of Debian Med interest I think it is a good idea to do things right and since I need it for a Debian Med package I simply maintain it for the moment here: https://anonscm.debian.org/git/debian-med/libgzstream.git ACLs are set so any DD can commit here. Moving the package to some more fitting VCS / team is fine. [1] https://lists.debian.org/debian-mentors/2016/03/msg00550.html
Re: -flto to become more of a routine - any change in opinion since 2011?
Hallo, * Konstantin Demin [Wed, Mar 30 2016, 09:14:20AM]: > 1. LTO object format is not stable and ABI-persistent: e.g., LTO > objects compiled with gcc 5.2 may not work when using gcc 5.3 > (versions are just for example). Ref: gcc doc. > 2. Slim LTO objects are usable only with GCC of same version (see > above). To provide wider support, you'll need to ship fat LTO objects. > 3. LTO is usable in most cases, but not all. AFAIK, Linux kernel won't > build with LTO. IMO it's worse. I have at least one package where LTO seems to cause valgrind errors (related to pthread) in release build (-O2) but not in debug mode without optimization. At least it compiles today with gcc-5.x without issues. With 4.x, there were either creepy linking errors or the program was not running stable (semi random crashes, probably related to the mentioned valgrind findings). Regards, Eduard.
Re: arch all package's missing dependency on i386 prevents testing migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, >> The package in question, circlator, depends on two >> architecture-dependent packages that can only build on amd64 and >> kfreebsd-amd64 currently. The package cannot migrate to testing >> because those dependencies are not available for i386 [1]. >> >> I am hoping there is a better solution to this problem than to >> work around this by changing this package's build architecture >> from "all" to "any-amd64" > > That's not a workaround, it is the correct fix for the error in > the original upload. The package cannot work on all architectures - > the fact that this is because of dependencies rather than the code > within the package is irrelevant. Unless the code in the package > can *transparently* omit the need for the dependency on > architectures where that dependency does not exist, then the > package is not arch:all. Installation alone is insufficient, the > package needs to be usable on all the architectures in the > Architecture list. Interesting, this was new to me. This would mean that, in this case, once the dependency becomes available on another architecture, the architecture list in all dependent packages would need to be updated to include that newly available architecture (given that this one dependency was the reason for the dependent package not being arch:all)? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW+4pJAAoJEKjaUsSK1PiGF9kH/0OD6ONp1ESTt/ownc1xw0nD YjfNnm/Y3SEaXrVXu8IbcqEvgd22/oNcf/c7zwYE9BG1DN3zRrSoVUKCqMQMSuEB ubwcOL0PSPt/3+d3i1vW70VK9SFPsODTgcYf/xdG0r3UqDGRHDF/8n8yIStE3fQP MBMJgJLlVQdTivAhZfMav6gxVwxicITFaTwphWzVZiEVCGsTY3o0qlJEdEoQTJ85 CdMnmFsWhxSgROcDP14MTtPOceLyPSZ0+1CH/r4+t8w+liRwUJ/nXA0FJzJ6QSW2 zVVGqsAMcorZO/Q2nOmIVQPWMhY3kjE3HrnHR/1w+VwaYurc1r1DOi6pmRBa2G0= =XfNm -END PGP SIGNATURE- -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: arch all package's missing dependency on i386 prevents testing migration
Neil Williams writes: > On Tue, 29 Mar 2016 21:25:26 -0700 > Afif Elghraoui wrote: >> The package in question, circlator, depends on two >> architecture-dependent packages that can only build on amd64 and >> kfreebsd-amd64 currently. The package cannot migrate to testing >> because those dependencies are not available for i386 [1]. >> >> I am hoping there is a better solution to this problem than to work >> around this by changing this package's build architecture from "all" >> to "any-amd64" > > That's not a workaround, it is the correct fix for the error in the > original upload. The package cannot work on all architectures - the > fact that this is because of dependencies rather than the code within > the package is irrelevant. Unless the code in the package can > *transparently* omit the need for the dependency on architectures where > that dependency does not exist, then the package is not arch:all. > Installation alone is insufficient, the package needs to be usable on > all the architectures in the Architecture list. No. It is arch:all if it contains no arch-specific binaries and doesn't require arch-specific dependencies (i.e. dependencies which should only appear on specific architectures like "foo [amd64]"). It should be fine if an arch:all package depends on binary packages that are not installable on all architectures. Otherwise a lot of arch:all packages that depend on, say, linux-specific binary packages would become arch:any which is not very useful. As far as I remember, the testing migration script checks installability of arch:all packages on amd64 and i386, and there are manual workarounds for arch:all packages that are not installable on these architectures. Cc'ed the release team to take a look too. Ansgar
Re: arch all package's missing dependency on i386 prevents testing migration
On Wed, 30 Mar 2016 10:42:53 +0200 Ansgar Burchardt wrote: > Neil Williams writes: > > On Tue, 29 Mar 2016 21:25:26 -0700 > > Afif Elghraoui wrote: > >> The package in question, circlator, depends on two > >> architecture-dependent packages that can only build on amd64 and > >> kfreebsd-amd64 currently. The package cannot migrate to testing > >> because those dependencies are not available for i386 [1]. > >> > >> I am hoping there is a better solution to this problem than to work > >> around this by changing this package's build architecture from > >> "all" to "any-amd64" > > > > That's not a workaround, it is the correct fix for the error in the > > original upload. The package cannot work on all architectures - the > > fact that this is because of dependencies rather than the code > > within the package is irrelevant. Unless the code in the package can > > *transparently* omit the need for the dependency on architectures > > where that dependency does not exist, then the package is not > > arch:all. Installation alone is insufficient, the package needs to > > be usable on all the architectures in the Architecture list. > > No. It is arch:all if it contains no arch-specific binaries and > doesn't require arch-specific dependencies (i.e. dependencies which > should only appear on specific architectures like "foo [amd64]"). True - I got mixed up with that bit. Sorry for the confusion. > It should be fine if an arch:all package depends on binary packages > that are not installable on all architectures. Otherwise a lot of > arch:all packages that depend on, say, linux-specific binary packages > would become arch:any which is not very useful. > > As far as I remember, the testing migration script checks > installability of arch:all packages on amd64 and i386, and there are > manual workarounds for arch:all packages that are not installable on > these architectures. Cc'ed the release team to take a look too. > > Ansgar > -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpr6JhMYY0d3.pgp Description: OpenPGP digital signature
Processed: Re: Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.
Processing control commands: > reassign -1 systemd Bug #819500 [general] general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text. Bug reassigned from package 'general' to 'systemd'. Ignoring request to alter found versions of bug #819500 to the same values previously set Ignoring request to alter fixed versions of bug #819500 to the same values previously set -- 819500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819500 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.
Control: reassign -1 systemd Not sure which to blame, but assign to systemd first, since it's easily got lost if keeping it unassigned.
Re: Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.
On Mar 30, Roger Shimizu wrote: > Not sure which to blame, but assign to systemd first, since it's Yes, we systemd maintainers really love this. -- ciao, Marco signature.asc Description: PGP signature
Bug#819553: ITP: r-cran-xml2 -- GNU R XML parser
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-xml2 Version : 0.1.2 Upstream Author : Hadley Wickham * URL : https://cran.r-project.org/web/packages/xml2/ * License : MIT Programming Lang: GNU R Description : GNU R XML parser This GNU R package works with XML files using a simple, consistent interface. Built on top of the 'libxml2' C library. Remark: This package is part of a pyramid of dependencies for r-cran-treescape and will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-xml2/trunk/
Re: -flto to become more of a routine - any change in opinion since 2011?
Steffen Möller writes ("-flto to become more of a routine - any change in
opinion since 2011?"):
> I admit to be a fan of link time optimisation and would like to see this
> challenge promoted towards more of a routine challenge to establish for
> our packages. I found this informative thread
>
> https://lists.debian.org/debian-devel/2011/06/msg00181.html
I have a concern not yet addressed in this thread.
Recently we have seen spectacular advances in compiler optimisation.
Spectacular in that large swathes of existing previously-working code
have been discovered, by diligent compilers, to be contrary to the
published C standard, and `optimised' into non-working machine code.
In fact, it turns out that there is practically no existing C code
which is correct according to said standards (including C compilers
themselves). (A full discussion of how this situation came to be is
probably out of scope for debian-devel, and also might involve me
becoming quite rude. So I will avoid that.)
I worry that LTO will exacerbate this problem, by extending the
categories of technical non-compliance (with rules which are very
difficult to fully comply with) which are detected by compilers and
transformed into actual non-working code.
IMO Debian should not arrange for users to be using LTO-affected
executables (in general[1]) until there have been major advances in
the manageability of the C dialect we are using.
To give an idea of what I think would be necessary, here is an
excellent posting from Pascal Cuoq, Matthew Flatt, and John Regehr:
http://blog.regehr.org/archives/1180
(I don't necessarily agree with this in every detail, but it gives a
very good idea of the breadth and depth of the changes I think are
needed.)
In general I highly reccommend Regehr's blog for this kind of topic.
Thanks,
Ian.
[1] Of course if there are specific programs that are somehow known to
be in compliance with the rules being newly enforced in LTO, then it
might be reasonable for those specific packages Debian build systems
to enable LTO.
However it seems like it will be very rarely in practice possible to
establish that a program is correct enough to safely enable LTO.
Re: Debian package on Windows
On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote: > I think your message would be better addressed to the debian-devel mailing > list, who I have copied in to this reply so that more Debian Developers are > aware of it. (There's also the Apt developer's mailing list at the > harder-to-discover de...@lists.debian.org who I have not copied in, as they > are > likely all on -devel anyway) > > Personally (although I am not an Apt developer) I think it sounds like an > interesting idea, and there is some precedent as APT was the basis of the > "Fink" package management system for Apple Mac OS X. Not re-inventing the > wheel is a very good idea, lots of package management problems have been > discovered and solved with APT already (and it's sad to see things like Ruby > gems, Go packages etc. re-discover the very same problems over and over again) Looks like Microsoft went with a Linux syscall emulation layer for the Windows kernel: http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian package on Windows
On Wed, Mar 30, 2016 at 1:52 PM, Paul Wise wrote: > On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote: > >> I think your message would be better addressed to the debian-devel mailing >> list, who I have copied in to this reply so that more Debian Developers are >> aware of it. (There's also the Apt developer's mailing list at the >> harder-to-discover de...@lists.debian.org who I have not copied in, as they >> are >> likely all on -devel anyway) >> >> Personally (although I am not an Apt developer) I think it sounds like an >> interesting idea, and there is some precedent as APT was the basis of the >> "Fink" package management system for Apple Mac OS X. Not re-inventing the >> wheel is a very good idea, lots of package management problems have been >> discovered and solved with APT already (and it's sad to see things like Ruby >> gems, Go packages etc. re-discover the very same problems over and over >> again) > > Looks like Microsoft went with a Linux syscall emulation layer for the > Windows kernel: > > http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html Maybe worth mentioning... Some Microsoft tools use NuGet (https://www.nuget.org/). Visual Studio uses it for its developer-to-developer gallery of widgets and gadgets. I don't think Microsoft will ever support a first class package manager. They are trying to achieve exclusivity and vendor lock-in through their app store, and a general package manager violates the corporate goals. Jeff
Re: Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.
On Wed, Mar 30, 2016 at 12:40:21PM +0200, Marco d'Itri wrote: > On Mar 30, Roger Shimizu wrote: > > > Not sure which to blame, but assign to systemd first, since it's > Yes, we systemd maintainers really love this. I've closed the bug by explaining the submitter that it's very likely a hardware problem (because of the random poweroff). If somebody finds a way to reproduce it, feel free to reopen. Thanks.
Bug#819580: ITP: ruby-syslog-logger -- improved Logger replacement that logs to syslog
Package: wnpp Severity: wishlist Owner: Lucas Kanashiro * Package name: ruby-syslog-logger Version : 1.6.8 Upstream Author : Eric Hodel, Chris Powell, Matthew Boeh, Ian Lesperance, Dana Danger, Brian Smith, Ashley Martens * URL : http://github.com/ngmoco/syslog_logger * License : Expat Programming Lang: Ruby Description : improved Logger replacement that logs to syslog Logger::Syslog is a Logger replacement that logs to syslog. It is almost drop-in with a few caveats. Add Logger::Syslog to your Rails production environment to aggregate logs between multiple machines. This particular Logger::Syslog improves the original by correctly mapping Rails log severities to the Syslog counterparts. It also adds the ability to select a syslog facility other than "user". I intend to maintain this package under the umbrella of Debian Ruby team. This package is a new dependency of new chef's release.
Bug#819583: ITP: ruby-proxifier -- add support for HTTP or SOCKS proxies and allow one to force TCPSocket to use proxies
Package: wnpp Severity: wishlist Owner: Lucas Kanashiro * Package name: ruby-proxifier Version : 1.0.3 Upstream Author : Samuel Kadolph * URL : https://github.com/samuelkadolph/ruby-proxifier * License : Expat Programming Lang: Ruby Description : add support for HTTP or SOCKS proxies and allow one to force TCPSocket to use proxies Proxifier enable ruby programmers to use HTTP or SOCKS proxies interchangeably when using TCPSockets. Either manually with `Proxifier::Proxy#open` or by `require "proxifier/env"`. Allows one to use ruby code that doesn't user proxies for users that have to use proxies. The pruby and pirb executables are simple wrappers for their respective ruby executables that support proxies from environment variables. I intend to maintain this package under the umbrella of Debian Ruby team. This package is a new dependency of new chef's release.
Bug#819591: ITP: golang-github-peterbourgon-diskv -- disk-backed key-value store
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Control: block 782441 by -1 Package name: golang-github-peterbourgon-diskv Version: 2.0.0 Upstream Author: Peter Bourgon License: Expat URL: https://github.com/peterbourgon/diskv Description: disk-backed key-value store Diskv (disk-vee) is a simple, persistent key-value store written in the Go language. It starts with an incredibly simple API for storing arbitrary data on a filesystem by key, and builds several layers of performance-enhancing abstraction on top. The end result is a conceptually simple, but highly performant, disk-backed storage system. signature.asc Description: This is a digitally signed message part.
Bug#819593: ITP: golang-github-hydrogen18-stoppablelistener -- stoppable TCP listener in Go
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Control: block 782441 by -1 Package name: golang-github-hydrogen18-stoppablelistener Version: 0.0~git20151210 Upstream Author: Eric Urban License: BSD-2-Clause URL: https://github.com/hydrogen18/stoppableListener Description: stoppable TCP listener in Go This library wraps an existing TCP connection object. A goroutine calling Accept() is interrupted with StoppedError whenever the listener is stopped by a call to Stop(). signature.asc Description: This is a digitally signed message part.
Re: Debian package on Windows
On 30 March 2016 at 14:52, Paul Wise wrote: > On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote: > > > I think your message would be better addressed to the debian-devel > mailing > > list, who I have copied in to this reply so that more Debian Developers > are > > aware of it. (There's also the Apt developer's mailing list at the > > harder-to-discover de...@lists.debian.org who I have not copied in, as > they are > > likely all on -devel anyway) > > > > Personally (although I am not an Apt developer) I think it sounds like an > > interesting idea, and there is some precedent as APT was the basis of the > > "Fink" package management system for Apple Mac OS X. Not re-inventing > the > > wheel is a very good idea, lots of package management problems have been > > discovered and solved with APT already (and it's sad to see things like > Ruby > > gems, Go packages etc. re-discover the very same problems over and over > again) > > Looks like Microsoft went with a Linux syscall emulation layer for the > Windows kernel: > > http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > > Something like this: http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ Sounds super cool! Finally the "year of Linux on Desktop"! lol I would like to play with this, for sure... :-D
Re: arch all package's missing dependency on i386 prevents testing migration
على الأربعاء 30 آذار 2016 01:42، كتب Ansgar Burchardt: > As far as I remember, the testing migration script checks installability > of arch:all packages on amd64 and i386, and there are manual workarounds > for arch:all packages that are not installable on these architectures. > Cc'ed the release team to take a look too. Thanks! I'd like to upload this package to jessie-backports, so I'm hoping this won't be too much of a delay because it also has to wait in backports-NEW afterwards. Many thanks and regards Afif
Re: Debian package on Windows
Quoting Paul Wise (2016-03-30 19:52:51) > Looks like Microsoft went with a Linux syscall emulation layer for the > Windows kernel: > > http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html if I understand it correctly, then this should indeed solve Eric's original message. It looks mightily impressive! When I read about this originally I didn't find a link with so many details and even screenshots - thanks for that! It seems they can even run apt (and thus dpkg) with this "reversed wine" :D Thanks! cheers, josch signature.asc Description: signature
Re: Debian package on Windows
On Thu, Mar 31, 2016 at 2:38 PM, Johannes Schauer wrote: > It looks mightily impressive! When I read about this originally I didn't find > a > link with so many details and even screenshots - thanks for that! It seems > they > can even run apt (and thus dpkg) with this "reversed wine" :D Seems like it is fairly different to Wine, more like the BSDs' Linux syscall emulation layers or qemu-user's cross-arch syscall translation. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian package on Windows
Quoting Paul Wise (2016-03-31 08:42:58) > On Thu, Mar 31, 2016 at 2:38 PM, Johannes Schauer wrote: > > It looks mightily impressive! When I read about this originally I didn't > > find a link with so many details and even screenshots - thanks for that! It > > seems they can even run apt (and thus dpkg) with this "reversed wine" :D > > Seems like it is fairly different to Wine, more like the BSDs' Linux > syscall emulation layers or qemu-user's cross-arch syscall translation. you are right. Calling it a "reversed wine" doesn't do the wine project enough justice who had to reimplement tons of windows libraries from scratch and without being able to see the source ever. This solution does not need to reimplement any library functions, as they can take everything from the unpacked Ubuntu rootfs and then "just" need to handle the Linux systemcalls correctly. cheers, josch signature.asc Description: signature
