Re: Bug#387813: ITP: gpar2 -- A GUI for verifying and repairing PAR and PAR2 recovery sets
On Sat, 2006-09-16 at 21:24 +0200, Khalid El Fathi wrote: > Package: wnpp > Severity: wishlist > Owner: Khalid El Fathi <[EMAIL PROTECTED]> > > * Package name: gpar2 > Version : 0.3 > Upstream Author : John Augustine <[EMAIL PROTECTED]> > * URL : http://sourceforge.net/projects/parchive/ > * License : GPL > Description : A GUI for verifying and repairing PAR and PAR2 recovery > sets > > A simple, easy to use graphical interface for verification and repairation of > PAR v1.0 and PAR v2.0(PAR2) recovery sets. PAR1 support is currently minimal, > as it is deprecated this most likely will not change, so do not expect the > headers, progress, output, and status to update when performing actions on > these. You can add more (sentense or two) about what is PAR recovery set and... > GPar2 is based on GTKMM, a wrapper for GTK+, and requires the > standard par2 library, libpar2, to run. ...strip this sentense, you should describe functionality and not programming language/libraries used to create package. Anybody can just look at Depends: to see what libraries are used. Ondrej. -- Ondřej Surý <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388805: RFP: please package mod_auth_xradius
retitle 388805 RFP: please package mod_auth_xradius reassign 388805 wnpp severity 388805 wishlist thank you You have filled bug at wrong package. Apache 2.X doesn't contain module for radius auth. However I was able to find mod_auth_xradius, so I am changing your bug to RFP (Request For Package) and reassigning it to our WNPP database. mod_auth_xradius provides high performance authentication against RFC 2865 RADIUS Servers. Features *Supports popular RADIUS Servers including OpenRADIUS, FreeRADIUS and commercial servers. *Distributed Authentication Cache using apr_memcache. *Local Authentication Cache using DBM. *Uses standard HTTP Basic Authentication, unlike mod_auth_radius which uses cookies for sessions. Kind regards, -- Ondřej Surý <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
exec-shield (Was: stack protection)
What about exec-shield by Ingo Molnar? http://people.redhat.com/mingo/exec-shield/ it seems it is less intrusive then other kernel patches and can be enabled/disabled at run-time Stripped from annoucement: The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary. [...] There is a new boot-time kernel command line option called exec-shield=, which has 4 values. Each value represents a different level of security: exec-shield=0- always-disabled exec-shield=1- default disabled, except binaries that enable it exec-shield=2- default enabled, except binaries that disable it exec-shield=3- always-enabled the current patch defaults to 'exec-shield=2'. The security level can also be changed runtime, by writing the level into /proc: echo 0 > /proc/sys/kernel/exec-shield end; Maybe Debian could default to exec-shield=1 ? O. On Thu, 2003-08-21 at 04:57, Russell Coker wrote: > Who is interested in stack protection? > > I think it would be good to have some experiments of stack protected packages > for Debian. Probably the best way to do this would be to start with > ssh-stack and sysklogd-stack being uploaded to experimental. I don't have > time to do this, but I would like to help test it. > > Also is there any interest in uploading a kernel-image package with the grsec > PaX support built in? -- OndÅej Surà <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Bits from the release team and request for discussion
Hi, > The following goals for Squeeze have been identified up to now: > * multiarch > * boot performance > * high quality packages (piuparts clean and other QA subgoals) > * prepare for the new package formats > * remove obsolete libraries > * add kfreebsd-amd64 and kfreebsd-i386 > * full IPv6 support > * large file support with root being signed[1] really soon (TM), could we add DNSSEC support to this list? Since I have recently switched position in my company (which took a lot of time), it looks like I will have now plenty of time for DNSSEC (since I can put DNSSEC in Debian to my top priorities). Ondrej 1. as in DNSSEC signed -- Ondřej Surý http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542654: ITP: libnet-dns-sec-maint-zone -- DNSSEC signing application
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: libnet-dns-sec-maint-zone Version : 0.012 Upstream Author : Olaf M. Kolkman * URL : http://www.ripe.net/disi/dnssec_maint_tool/ * License : BSD Programming Lang: Perl Description : DNSSEC signing application The this program suite is designed to ease DNSSEC key management. The suite contains, besides a number of libraries, the following programs: . dnssigner - A signer that uses the keydatabase to sign zones. . The Net::DNS::SEC::Maint::Zone object essentially contains one main attribute, a textual representation of a zone. . The class can be used to pass a (signed) zone back and forth from a client to a (signing) server. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542667: ITP: opendnssec -- complete DNSSEC zone signing system
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: opendnssec Version : 1.0a2 Upstream Author : Roy Arends, Rickard Bondesson, Alex Dalitz, John A. Dickinson, Jelte Jansen, Sion Lloyd, Matthijs Mekking, Stephen Morris, Jakob Schlyter, Patrik Wallström * URL : http://www.opendnssec.org/ * License : BSD Programming Lang: C, Ruby Description : complete DNSSEC zone signing system OpenDNSSEC takes in unsigned zones, adds the signatures and other records for DNSSEC and passes it on to the authoritative name servers for that zone. . DNS is complicated, and so is digital signing; their combination in DNSSEC is of course complex as well. The idea of OpenDNSSEC is to handle such difficulties, to relieve the administrator of them after a one-time effort for setting it up. . The storage of keys is done through a PKCS #11 standard interface. To deploy OpenDNSSEC, an implementation of this interface is needed, for example a software library, an HSM or perhaps a simpler token. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543320: ITP: dnsruby -- a DNS client library
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: dnsruby Version : 1.35 Upstream Author : Alex D. * URL : http://rubyforge.org/projects/dnsruby/ * License : Apache Software License Programming Lang: Ruby Description : a DNS client library Dnsruby is a pure Ruby DNS client library which implements a stub resolver. It aims to comply with all DNS RFCs, including DNSSEC NSEC3 support. . Dnsruby presents a new API for DNS. It is based on Ruby's core resolv.rb Resolv API, but has been much extended to provide a complete DNS implementation. . Dnsruby runs a single I/O thread to handle all concurrent queries. It is therefore suitable for high volume DNS applications. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545791: ITP: ncap -- Network Capture Library and Tools
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: ncap Version : 1.8.1 Upstream Author : Internet Systems Consortium * URL : https://www.dns-oarc.net/tools/ncap * License : BSD Programming Lang: C, Python Description : Network Capture Library and Tools ncap is a network capture utility like libpcap (on which it is based) and tcpdump. It produces binary data in ncap(3) format, either on standard output (by default) or in successive dump files. This utility is similar to tcpdump(1), but performs IP reassembly and generates framing-independent portable output. ncap is expected to be used for gathering continuous research or audit traces. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (900, 'jaunty-updates'), (900, 'jaunty-security'), (900, 'jaunty-backports'), (900, 'jaunty'), (500, 'jaunty-proposed') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545795: ITP: libbind -- standard resolver library
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: libbind Version : 6.0 Upstream Author : Internet Systems Consortium * URL : https://www.isc.org/software/libbind * License : BSD Programming Lang: C++ Description : the standard resolver library ISC's libbind provides the standard resolver library, along with header files and documentation, for communicating with domain name servers, retrieving network host entries from /etc/hosts or via DNS, converting CIDR network addresses, performing Hesiod information lookups, retrieving network entries from /etc/networks, implementing TSIG transaction/request security of DNS messages, performing name-to-address and address-to-name translations, and utilizing /etc/resolv.conf for resolver configuration. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (900, 'jaunty-updates'), (900, 'jaunty-security'), (900, 'jaunty-backports'), (900, 'jaunty'), (500, 'jaunty-proposed') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545795: ITP: libbind -- standard resolver library
Ah thanks, missed that. Ondrej > This seems to be already packaged: > > <http://packages.debian.org/source/sid/libbind> > > And there's also the one coming from the bind9 source packages. It's not - libbind9 is something else. Ondrej -- Ondřej Surý http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian qualified as a OMG operating system
Emanuele Rocca píše v Čt 15. 03. 2007 v 10:33 +0100: > Hi guys, > > quoting http://wiki.debian.org/DebianSystem#systemadministration > > "Debian has been qualified as a OMG operating system for administrators, > primarily because of its ease of use, security and straight-forward > common sense usage." > > What is a "OMG operating system"? > > In my head OMG could mean: > > 1) Object Management Group > 2) Oh My God That would be rather Oh My Goddess :-) http://en.wikipedia.org/wiki/Oh_My_Goddess! but in this case it;s most propably Object Management Group. http://www.omg.org/ Ondrej -- Ondřej Surý <[EMAIL PROTECTED]> *** http://blog.rfc1925.org/ Kulturní občasník *** http://www.obcasnik.cz/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492895: ITP: dnssec-tools -- DNSSEC tools
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" <[EMAIL PROTECTED]> * Package name: dnssec-tools Version : 1.4.1 Upstream Author : SPARTA, Inc. * URL : http://www.dnssec-tools.org/ * License : BSD Programming Lang: Perl Description : DNSSEC tools, applications and wrappers The goal of the DNSSEC-Tools project is to create a set of tools, patches, applications, wrappers, extensions, and plugins that will help ease the deployment of DNSSEC-related technologies. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-20-generic (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493118: ITP: libnet-dns-sec-perl -- DNSSEC extensions to Net::DNS
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" <[EMAIL PROTECTED]> * Package name: libnet-dns-sec-perl Version : 0.14 Upstream Author : Olaf M. Kolkman <[EMAIL PROTECTED]> * URL : http://www.net-dns.org/ * License : custom Programming Lang: Perl Description : DNSSEC extensions to Net::DNS The Net::DSN::SEC suite provides the resource records that are needed for DNSSEC (RFC 4033, 4034 and 4035). . It also provides support for SIG0. That later is useful for dynamic updates using key-pairs. . RSA and DSA crypto routines are supported. COPYRIGHT: Copyright Notice and Disclaimer Copyright (c) 2001-2005 RIPE NCC. Author Olaf M. Kolkman <[EMAIL PROTECTED]> All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Based on, and contains, code by Copyright (c) 1997-2001 Michael Fuhr. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-20-generic (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500144: ITP: libnet-dns-zone-parser-perl -- RFC compliant zone file parser
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" <[EMAIL PROTECTED]> * Package name: libnet-dns-zone-parser-perl Version : 0.01.99 Upstream Author : Olaf M. Kolkman <[EMAIL PROTECTED]> * URL : http://www.net-dns.org/ * License : BSD Programming Lang: Perl Description : RFC compliant zone file (pre)parser The Net::DNS::Zone::Parser should be considered a preprocessor that "normalizes" a zonefile. . It will read a zonefile in a format conforming to the relevant RFCs with the addition of BIND's GENERATE directive from disk and will write fully specified resource records (RRs) to a filehandle. Whereby: All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The $GENERATE primitive parser is based on code in Net::DNS::ZoneFile, which has it's own copyright: Copyright (c) 1997-2002 Michael Fuhr. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Note regarding the copyright: The copyright of the upstream package refers to the Perl license. That is: Copyright 1989-2001, Larry Wall All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of either: a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or b) the "Artistic License" which comes with Perl. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL' and the Artistic Licence in /usr/share/common-licenses/Artistic'. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-21-generic (SMP w/2 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [php-maint] Bug#341420: marked as done (code in exts/dbase is not DFSG-free)
2008/11/30 Holger Levsen <[EMAIL PROTECTED]>: > Hi, > > On Sunday 30 November 2008 00:56, Raphael Geissert wrote: >> > Closes: 341420 >> Do you mind at least contacting the maintainers? >> I find your upload very impolite. > > Huh? We are in a permanent bugsquashing party, cause we want to release lenny. So what? One email with "I am going to upload PHP5 to resolve #341420" would really delay release. I don't find it impolite, I find it very rude. > This is a RC bugs since three weeks, so I rather think the php-maintainers > have been unpolite leaving it open so long... Sorry, but this is really bad approach - attacking php maintainers when somebody else made mistake of not communicating that he is going to upload. This is basic courtesy between DDs (at least it was in the old days). We are all only people with real lives and sometimes the time is lacking, or we forgot about bugs or whatever - but nothing of it could be excuse for doing NMU without prior notice - sending email is not that hard compared to preparing proper NMU. Ondrej -- Ondřej Surý <[EMAIL PROTECTED]>
Re: Bug#451799: new evince cannot display Japanese characters correctly
> However I don't think there is anything copyrightable in these files; > they only contain series of numbers that describe the mappings. Do you > people think it could be suitable for main? > (Please follow-up on -legal only for licensing discussions.) > > Ondrej, are you willing - if the legal problems are settled out - to > package it? Otherwise I guess me or any of the co-maintainers could do > it, the packaging is absolutely trivial. It's already packaged in pkg-freedesktop SVN, but it was rejected by ftp-masters due licensing problems. Ondrej. -- Ondřej Surý <[EMAIL PROTECTED]> *** http://blog.rfc1925.org/ Kulturní občasník *** http://www.obcasnik.cz/ Nehoupat, prosím *** http://nehoupat.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#566155: ITP: softhsm -- a cryptographic store accessible through a PKCS #11
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: softhsm Version : 1.1.2 Upstream Author : Rickard Bellgrim, .SE (The Internet Infrastructure Foundation) * URL : http://trac.opendnssec.org/wiki/SoftHS * License : BSD Programming Lang: C Description : a cryptographic store accessible through a PKCS #11 OpenDNSSEC handles and stores its cryptographic keys via the PKCS#11 interface. This interface specifies how to communicate with cryptographic devices such as HSM:s (Hardware Security Modules) and smart cards. The purpose of these devices is, among others, to generate cryptographic keys and sign information without revealing private-key material to the outside world. They are often designed to perform well on these specific tasks compared to ordinary processes in a normal computer. . A potential problem with the use of the PKCS#11 interface is that it might limit the wide spread use of OpenDNSSEC, since a potential user might not be willing to invest in a new hardware device. To counter this effect, OpenDNSSEC is providing a software implementation of a generic cryptographic device with a PKCS#11 interface, the SoftHSM. SoftHSM is designed to meet the requirements of OpenDNSSEC, but can also work together with other cryptographic products because of the PKCS#11 interface. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktYhbgACgkQ9OZqfMIN8nNszgCfSOkrj3p6EicKIRGCLiNILCbm EVcAnRcrnnf9DAs0iTq2nRcKVkzKiII4 =a2SG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566980: ITP: opendnssec-auditor -- tool to audit DNS signed zones according to local policy
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: opendnssec-auditor Version : 1.0.0rc3 Upstream Author : Alex Dalitz * URL : http://www.opendnssec.org/ * License : BSD Programming Lang: Ruby Description : tool to audit DNS signed zones according to local policy OpenDNSSEC is a complete DNSSEC zone signing system which is very easy to use with stability and security in mind. There are a lot of details in signing zone files with DNSSEC and OpenDNSSEC covers most of it. . This package contains OpenDNSSEC Auditor, which is a tool to check whether DNSSEC signed zone complies to a local policy. It is issued automatically (unless disabled) after each resigning of a zone and will stop the signed zone file from being distributed if any error is found. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktewBoACgkQ9OZqfMIN8nM6kACfS2I688iFb+M26Tu3yYJjrz+z 2QEAnim2rJjyFiOQcRIJYg8AyxuDTMxZ =T54p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567008: ITP: opendnssec-conf -- common configuration files for OpenDNSSEC suite
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: opendnssec-conf Version : 1.0.0~rc3 Upstream Author : Jakob Schlyter * URL : http://www.opendnssec.org/ * License : BSD Programming Lang: XML Description : common configuration files for OpenDNSSEC suite OpenDNSSEC is a complete DNSSEC zone signing system which is very easy to use with stability and security in mind. There are a lot of details in signing zone files with DNSSEC and OpenDNSSEC covers most of it. . This package contains common configuration files. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktfECUACgkQ9OZqfMIN8nMSXQCfRmpiMm+4SynXICF6gtT4x3UT t8kAn1M17iJOJC59/SOB2J+8tdlya1pr =Cr6K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568102: ITP: libhsm -- library for interfacing PKCS#11 Hardware Security Modules
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libhsm Version : 1.0.0~rc3 Upstream Author : Alex Dalitz, Jakob Schlyter, Rickard Bellgrim, Jelte Jansen, Sion Lloyd * URL : http://www.opendnssec.org/ * License : BSD Programming Lang: C Description : library for interfacing PKCS#11 Hardware Security Modules OpenDNSSEC is a complete DNSSEC zone signing system which is very easy to use with stability and security in mind. There are a lot of details in signing zone files with DNSSEC and OpenDNSSEC covers most of it. . Support library for interfacing PKCS#11 compatible Hardware Security Modules (HSM). This library allows programs to use cryptografic secure storages for keying material such as softhsm (HSM implemented in software), SCA6000, Aladdin eToken, OpenSC, nCipher or AEP Keyper. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAktoJPYACgkQ9OZqfMIN8nN/DACgiho8KVzx4DCMNDtvD48NLuti R1cAn0/b64qrAwj5wqsKQsKshHgEhhDQ =33cy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575349: ITP: opendnssec-signer -- tools to periodicaly sign DNSSEC zone files
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: opendnssec-signer Version : 1.0.0 Upstream Author : Alex Dalitz, Jakob Schlyter, Rickard Bellgrim, Jelte Jansen, Sion Lloyd * URL : http://www.opendnssec.org/ * License : BSD Programming Lang: C, Python Description : tools to periodicaly sign DNSSEC zone files Package: opendnssec-signer Description: daemon to sign DNS zone files periodically OpenDNSSEC is a complete DNSSEC zone signing system which is very easy to use with stability and security in mind. There are a lot of details in signing zone files with DNSSEC and OpenDNSSEC covers most of it. . This package contains OpenDNSSEC Signer Engine. The task of the signer engine is to schedule signing operation on DNS zones. Taking input from the KASP, it will automatically sign zones and keep their signatures up-to-date. Package: opendnssec-signer-tools Description: set of tools used by OpenDNSSEC to sign zone files OpenDNSSEC is a complete DNSSEC zone signing system which is very easy to use with stability and security in mind. There are a lot of details in signing zone files with DNSSEC and OpenDNSSEC covers most of it. . This package contains OpenDNSSEC Signer Engine Tools. The task of the signer engine is to schedule signing operation on DNS zones. Taking input from the KASP, it will automatically sign zones and keep their signatures up-to-date. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100325045203.14218.35428.report...@howl
Re: [php-maint] ITP: php-recaptcha -- PHP interface to recaptcha.net
Dear all, could you take this out of pkg-php-maint? Debian-legal would ve more appropriate list to discuss this. Ondrej Sury On 20.6.2010, at 18:22, Thomas Goirand wrote: Tollef Fog Heen wrote: | Some made the comparison (like you just did) with IM clients, specific | browsers (like youtube clients and others), but I don't believe this | applies here. To my opinion, I believe this is a remotely executed | procedure, stored on a non-free server that we wont ever control, which | makes php-recaptcha a good candidate for contrib. This is a lot more | complex debate than what you pretend. I don't see how that is fundamentally different from, say, youtube- dl. Server-to-server connectivity isn't part of the software functionality, removing it would enhance the software, and that is the fundamental difference to me. More in details if anyone didn't get it in a short version: remove any kind of connectivity to the youtube servers, and youtube-dl has no use, you can uninstall it from your system. Do the same with something that does a captcha, then it's great if it continues to work without connectivity. In fact, for a captcha software, it's *more convenient* if it doesn't connect to a specific privately owned captcha server at all, so that way you can run it in a LAN / DMZ. The connection to a server that holds a part of the code that you will never have access to, is only removing some freedom, it's not adding any functionality. | We are talking about a remote procedure on a software, that has no | valid reason to be used as a service, and not embedded on the server | that you use. If you believe that there's a valid reason, I welcome | you to express yourself about it. The valid reason is making those text where the captchas come from be more accessible. I'm not 100% sure of what you are saying here, but I'll try to answer anyway (please be indulgent if I didn't understand you correctly). So here, you are discussing about the quality of the captchas, right? Not about my argumentation about recaptcha being a remote procedures / function / method (take your pick) that should, to me, live on your local server? If that is the case, then aren't you a bit off-topic, or am I missing something important? If your point is about the text that Google is digitizing thanks to recaptcha, that's off-topic IMHO. If it wasn't off-topic, then I'd say it's adding some evil, as Google has been quite bad with many book editors and copyright infringement (which I already wrote btw). | If Debian is not the entity to refuse/complain about it, then who will? | Do we really care about software freeness? I hope we (as an entity) | still do, and I *know* many of us still do. Part of software freedom is the no discrimination against fields of endeavour bit. Which is exactly why this was a "P.S" and not in the body of my message. This is a side note only, and should be considered as such, eg: no implication on the rest of my freeness reasoning, this was just a reminder for people not knowing who we are talking about here. This is also a hidden message saying that rather than spending time packaging and supporting Google tools they use to own us all (like php- recaptcha), we'd better focus on 100% free existing tools and enhance them (like php-text-captcha) so they become even better than the non-free counterpart. Neil Williams wrote: IMHO if this package is to enter Debian at all, it should be in contrib as it relies on a non-free component to operate (so non-free that the component cannot even be packaged for Debian). This is exactly what I believe, and what I wrote as being my 2nd thought: to me, it should go to contrib, and not to non-free, as it depends on a remote execution by a library we don't even have a binary for. Neil Williams wrote: Remote procedures alone are not sufficient reason to consider a package using the procedure as non-free - e.g. blog clients use a variety of blog engines, some of which are non-free. I want to insist here: the captcha generation is a remote procedure / method / function, absolutely NOT a a service like youtube or instant messaging, or even (micro-) blogging. Not understanding this point is not understanding why I am arguing against php-recaptcha to enter Debian main. Discussing on another point is, IMHO, a bit off-topic (which I don't mind so much... :) ). Blog clients rely on remotely executed procedures. All blog engines are *stored* on a non-free server because servers themselves (as machines) are always non-free if they hope to be secure. ;-) I think what you meant is connecting to a non-free *service* and there are a lot of those which do not preclude packages using them being in main. No, it's not like a blog client. In fact, I'd be happy if everyone could understand that there's no client/server thing here. Google is only giving you access to a function. That function could run on your local server, totally disco
RFH: bug squashing for php5
Hi, we currently lack hands for testing and bug squashing in php5. I have just uploaded php5 5.3.3-2 to unstable and as soon as it get built it would be great if we had more hands to go through all the bugs in the src=php5 and test if they are still present in 5.3.3 version. And if they are not, then closing the bug with correct version and at least short explanation that the bug was tested and is not present in latest release. (You know the usual drill...) Ondrej -- Ondřej Surý
wnpp: ITP: gq - gtk ldap client
Package: wnpp Version: N/A Severity: wishlist GQ is a GTK-based LDAP client. Features include: - browse and search modes - LDAPv3 schema browser - template editor - edit and delete entries - add entries with templates - export subtree or whole server to LDIF file - use any number of servers - search based on single argument or LDAP filter - TLS support for LDAPv3 Licence is GPLv2, homesite is http://biot.com/gq/ -- System Information Debian Release: testing/unstable Kernel Version: Linux druid 2.4.3 #1 Mon Apr 2 13:28:28 CEST 2001 i686 unknown -- Ondřej Surý <[EMAIL PROTECTED]> Globe Internet s.r.o. http://globe.cz/ Tel: +420235365000 Fax: +420235365009 Pláničkova 1, 162 00 Praha 6 Mob: +420605204544 ICQ: 24944126 Mapa: http://globe.namape.cz/ GPG fingerprint: CC91 8F02 8CDE 911A 933F AE52 F4E6 6A7C C20D F273
Re: wnpp: ITP: gq - gtk ldap client
> What's wrong with the current gq package? Sorry, I hadn't noticed... I will close that bug. I appologies. -- Ondřej Surý <[EMAIL PROTECTED]> Globe Internet s.r.o. http://globe.cz/ Tel: +420235365000 Fax: +420235365009 Pláničkova 1, 162 00 Praha 6 Mob: +420605204544 ICQ: 24944126 Mapa: http://globe.namape.cz/ GPG fingerprint: CC91 8F02 8CDE 911A 933F AE52 F4E6 6A7C C20D F273
Bug#516991: ITP: dnssec-conf -- DNSSEC and DLV configuration tool
X-Debbugs-Cc: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: dnssec-conf Version : 1.15 Upstream Author : Paul Wouters * URL : http://www.xelerance.com/software/dnssec-conf/ * License : GPLv2+ Programming Lang: Python Description : DNSSEC and DLV configuration tool DNSSEC configuration and priming tool. Keys are required until the root is signed, as well as for local unpublished DNSSEC keys to be preloaded into the recursive nameserver. These DNSSEC configuration files can be directly included in the bind or unbound nameserver configuration files. dnssec-conf includes a commandline configuration client for Bind and Unbound, known DNSSEC keys, URL's to official publication pages of keys, and harvested keys, as well a script to harvest DNSKEY's from DNS. P.S.: My reportbug is broken and I can't find my previous ITPs in wnpp package. I hope I'm not sending this for the third time. -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please test libnet-dns-perl 0.77 in Debian experimental
Hi, I have updated Net::DNS in experimental to version 0.77. There were some significant changes in the upstream version 0.69/0.70, so I would appreciate if you can test your perl packages if they still work with libnet-dns-perl 0.77. I know that at least fpdns[1] is broken, but I would expect that more packages will be broken as well (especially those using private APIs). More information: http://www.net-dns.org/blog/2012/12/05/netdns-0-69-released/ http://www.net-dns.org/blog/2012/12/16/netdns-version-0-71-released/ and the rest of the blog. Since we don't have SOVERSION in perl libraries I will do my best to add correct "Breaks:" in the package, so either write me directly or create bugreport on libnet-dns-perl. Thanks, Ondrej Affected packages and developers: -- cut here -- Alexander Wirt libmail-verify-perl Andrew Pollock sieve-connect Angel Abad libgravatar-url-perl (U) libnet-sip-perl (U) Anibal Monsalve Salazar cluster-agents (U) Ansgar Burchardt libnet-dns-async-perl (U) Ansgar Burchardt libgravatar-url-perl (U) libnet-sip-perl (U) Antonio Radici libpoe-component-client-dns-perl (U) postgrey Chris Butler libemail-valid-perl (U) Christine Spang libnet-bonjour-perl (U) Damyan Ivanov libnet-sip-perl (U) Daniel Lintott libnet-sip-perl (U) Debian dsc Maintainer Team dsc-statistics Debian Edu Packaging Team slbackup Debian HA Maintainers cluster-agents Debian Perl Group all-knowing-dns libemail-valid-perl libgravatar-url-perl libmail-checkuser-perl libnet-bonjour-perl libnet-dns-async-perl libnet-dns-resolver-programmable-perl libnet-nslookup-perl libnet-rblclient-perl libnet-sip-perl libnet-smtp-server-perl libpoe-component-client-dns-perl mail-spf-perl Deepak Tripathi libnet-smtp-server-perl (U) Devin Carraway qpsmtpd Ernesto Hernández-Novich (USB) webgui Fabrizio Regalli libmail-checkuser-perl (U) Florian Hinzmann dnswalk Florian Schlichting libmail-checkuser-perl (U) Florian Schlichting libpoe-component-client-dns-perl (U) Frederic Peters jdresolve Frederik Schüler cluster-agents (U) Giuseppe Iuculano razor gregor herrmann libemail-valid-perl (U) libnet-dns-resolver-programmable-perl (U) libnet-sip-perl (U) libnet-smtp-server-perl (U) libpoe-component-client-dns-perl (U) mail-spf-perl (U) gregor herrmann libnet-rblclient-perl (U) Hilko Bengen liblwpx-paranoidagent-perl Jan Wagner libnet-dns-async-perl (U) postfwd Jesus Climent spamassassin (U) Jon Daley postgrey (U) Jonathan Yu libnet-sip-perl (U) libpoe-component-client-dns-perl (U) Jose Luis Rivas libnet-sip-perl (U) libpoe-component-client-dns-perl (U) Jotam Jr. Trejo libnet-sip-perl (U) Julián Moreno Patiño amispammer Krzysztof Krzyzaniak (eloy) libemail-valid-perl (U) Magnus Holmgren libmail-dkim-perl Marc Haber dsc-statistics (U) Martin Loschwitz cluster-agents (U) Martin Zobel-Helas libmail-checkuser-perl (U) Martín Ferrari libnet-sip-perl (U) libpoe-component-client-dns-perl (U) Michael Stapelberg all-knowing-dns all-knowing-dns (U) Mike Gabriel slbackup (U) Morten Werner Forsbring slbackup slbackup (U) Noah Meyerhans spamassassin Ondřej Surý dnssec-tools libnet-dns-sec-perl Rene Mayorga libnet-rblclient-perl (U) Rene Mayorga libnet-sip-perl (U) libpoe-component-client-dns-perl (U) Ron Lee libemail-valid-perl (U) Ryan Niebur libemail-valid-perl (U) libgravatar-url-perl (U) Sam Hartman barnowl Scott Kitterman mail-spf-perl (U) Sebastian Laubscher dsc-statistics (U) Sebastien Delafond libnet-socks-perl Simon Horman cluster-agents (U) Simon Kainz duck TANIGUCHI Takaki libnet-nslookup-perl (U) Thorsten Alteholz net-dns-fingerprint Werner Detter policyd-weight Xavier Guimard libnet-nslookup-perl (U) -- cut here -- 1. The version from github.com/jschlyter/fpdns works though. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403015515.4761.129758829.2ca0f...@webmail.messagingengine.com
New project goal: Get rid of Berkeley DB (post jessie)
lien Viard de Galbert webalizer Junichi Uekawa jack-audio-connection-kit (U) Kamal Mostafa trustedqsl (U) xastir (U) Klaus Reimer webdruid Krzysztof Klimonda 389-ds-base (U) LaMont Jones hpsockd postfix Laurent Bigonville evolution-data-server (U) Lior Kaplan php5 (U) Loic Minier evolution-data-server (U) rpm (U) Lucas Nussbaum ruby-bdb (U) Luigi Gangitano squid squid3 Magnus Holmgren prayer Marc Haber exim4 (U) Marco d'Itri inn2 libberkeleydb-perl vacation Margarita Manterola evolution-data-server (U) Mark Brown xemacs21 Mark Hymers gridengine (U) Marvin Stark syrep Mathieu Parent c-icap (U) c-icap-modules (U) Matthias Julius dnshistory Matthias Klose python-bsddb3 python2.7 python3.3 python3.4 Matthijs Möhlmann openldap (U) Mattias Ellert canl-c++ nordugrid-arc Micah Anderson bitcoin (U) Michael Banck gridengine (U) Michael Meskes citadel (U) Michael Schutte ruby-bdb (U) Michael Tokarev iproute2 (U) postfix (U) Michael Vogt apt (U) Michal Čihař rpm Mike Markley opendkim Nick Rusnov nmh nmh (U) Nico Golde moc (U) Nicolas Boullis isync Nicolas Duboc spamprobe NIIBE Yutaka chise-base Nikita V. Youshchenko libetpan libetpan (U) Niko Tyni perl Nobuhiro Iwamatsu cairo-dock-plug-ins (U) Noèl Köthe drac Noël Köthe drac Ondřej Surý cyrus-imapd-2.4 (U) cyrus-sasl2 (U) db-defaults (U) php5 (U) Otavio Salvador apt (U) Oystein Gisnas evolution-data-server (U) Patrick Matthäi animals (U) Patrick Ouellette trustedqsl (U) Paul Mangan claws-mail (U) Paul Martin radiusd-livingston Pedro Fragoso evolution-data-server (U) Pedro Ribeiro poedit Peter Samuelson apr-util (U) subversion Peter Van Eynde clisp (U) Petr Čech pavuk Philipp Schafft animals Rafael Cunha de Almeida tcpstat Reinhard Tartler jack-audio-connection-kit (U) Ricardo Mones claws-mail libetpan Riccardo Setti evolution-data-server (U) Richard Atterer jigdo Robert Millan freebsd-buildutils (U) Roberto C. Sanchez cyrus-sasl2 (U) Roland Bauerschmidt openldap (U) Ross Burton onak (U) Russ Allbery openldap (U) Ryan Kavanagh opensmtpd Sam Hocevar (Debian packages) guile-db Scott Howard bitcoin (U) Scott Kitterman opendkim (U) Sean Finney php5 (U) Serafeim Zanikolas bogofilter Simon Horman perdition Sjoerd Simons evolution-data-server (U) Stefan Fritsch apr-util (U) Stephen Frost openldap (U) Steve Langasek openldap (U) Sven Mueller cyrus-imapd-2.4 (U) Tatsuya Kinoshita skksearch skktools Theodore Y. Ts'o isync (U) Thijs Kinkhorst php5 (U) Thomas Bushnell, BSG mmorph Thomas Pierson libqxt Tim Weippert c-icap c-icap-modules Timo Aaltonen 389-ds-base (U) openldap (U) Torsten Landschoff openldap (U) Troy Heber subversion (U) Tzafrir Cohen kamailio (U) Ulises Vitulli mailavenger Victor Seva kamailio (U) Wilfried Goesgens citadel (U) Willem van den Akker jabberd2 (U) William Dauchy php5 (U) William Vera dsniff Youhei SASAKI cairo-dock-plug-ins (U) YunQiang Su libpinyin (U) Yves-Alexis Perez evolution-data-server (U) Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403170716.8284.130519093.3334e...@webmail.messagingengine.com
Re: New project goal: Get rid of Berkeley DB (post jessie)
On Thu, Jun 19, 2014, at 12:33, Svante Signell wrote: > On Thu, 2014-06-19 at 11:38 +0200, Ondřej Surý wrote: > > Hi, > > > > > > > > my view is that Berkeley DB is dead since Oracle relicenced it to AGPL3; > > What is wrong with that license, and what was it before? I am quite sure you are capable of Google and Wikipedia, but anyway here you go: + responses in d-d and d-legal... and here's the summary by LWN: https://lwn.net/Articles/557820/ O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403174552.22969.130539797.7972d...@webmail.messagingengine.com
Re: New project goal: Get rid of Berkeley DB (post jessie)
On Thu, Jun 19, 2014, at 17:12, Andreas Metzler wrote: > Ondřej Surý wrote: > > > > > my view is that Berkeley DB is dead since Oracle relicenced it to AGPL3; > [...] > > P.S.: I will do that for Cyrus SASL and Cyrus IMAP in any case, but > > it would be nicer if we had this as a release goal. > [...] > > Hell, > Do you already know yet what you are going to use there as replacement? LMDB - I already have working patch for Cyrus SASL, the API is modeled closely after BDB, so the porting shouldn't be hard and Howard is extremely helpful and pleasant to deal with in my experience. I just need to write some tools to dump & import the data from existing databases. (python-berkeleydb & py-lmdb will come to rescue I guess). O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403191112.26240.130637553.48597...@webmail.messagingengine.com
Re: New project goal: Get rid of Berkeley DB (post jessie)
Hi Russ, On Thu, Jun 19, 2014, at 16:10, Russ Allbery wrote: > Ondřej Surý writes: > > > > > > my view is that Berkeley DB is dead since Oracle relicenced it to AGPL3; > > I also think there are better alternatives for key-value storage > > databases like LMDB (http://symas.com/mdb/) (or possibly others like > > LevelDB, Tokyo/Kyoto, etc. we don't have to settle on one common > > solution). > > > So I think that we can probably get rid of the Berkeley DB at the places > > where it's used like a simple key-value database. > > > It would require some amount of cooperation with upstream and some work > > within the packaging (converting the database at the upgrade time). > > We would need to continue to support it in Debian for reading existing > Berkeley DB key/value pair databases via such things as Perl's DB_File. > I know I'm not the only one who has tons of key/value pair Berkeley DB > files scattered around from inumerable pieces of local code or packages > like krb5-strength. Yes, and I will support db5.3 as far as I can. On the other hand it won't hurt to not grow the number of new Berkeley DB files in the world if there's better and free/libre replacement, right? > That said, I don't think the Berkeley DB key/value pair on-disk data > structure could be all that complex, the algorithms around such a thing > are very well-understood, and I don't think the implementation has > changed > in years and is therefore unambiguously under a good license. Maybe > someone could fork just this portion of Berkeley DB without all the > complex transaction stuff and take over upstream maintenance of just > that? Or we can just keep db5.3 forever and wait what will BSD folks do. Maybe we will end up with LibreDB (*cough*)... Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403191254.26974.130638553.2782b...@webmail.messagingengine.com
Re: New project goal: Get rid of Berkeley DB (post jessie)
On Thu, Jun 19, 2014, at 18:08, Colin Watson wrote: > On Thu, Jun 19, 2014 at 07:10:46AM -0700, Russ Allbery wrote: > > We would need to continue to support it in Debian for reading existing > > Berkeley DB key/value pair databases via such things as Perl's DB_File. > > I know I'm not the only one who has tons of key/value pair Berkeley DB > > files scattered around from inumerable pieces of local code or packages > > like krb5-strength. > > > > That said, I don't think the Berkeley DB key/value pair on-disk data > > structure could be all that complex, the algorithms around such a thing > > are very well-understood, and I don't think the implementation has changed > > in years and is therefore unambiguously under a good license. Maybe > > someone could fork just this portion of Berkeley DB without all the > > complex transaction stuff and take over upstream maintenance of just that? > > Right. I think for many of the affected packages, given some upstream > cooperation, it would be quite easy to convert them over to maybe > something as simple as gdbm; I did that many years ago for man-db after > getting fed up with on-disk format changes and other complexity-induced > bugs, and have not been at all sad that I did so (this was well before > the licence change, which I have not thought very deeply about). True, but gdbm is GPL and LGPL and that's a problem for many non-GPL applications using Berkeley DB now. qdbm with LGPL might be a better match, but I think that LMDB API was designed for easy porting from Berkeley DB, so it's my favourite candidate. > But I'm not sure that it would be helpful to be aggressive about > removing Berkeley DB entirely; in the medium term I think the best we > could hope for would be to reduce the extent to which it is entrenched. My vision of "aggressive" in context of Debian release goals is something like 10 years :). And we should coordinate the transition with upstream and probably also other distributions. Berkeley DB 6 is also no-flyer for RH, so the move to something else might work across all distros. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403203281.25838.130711385.33b4c...@webmail.messagingengine.com
Re: New project goal: Get rid of Berkeley DB (post jessie)
Please let's not have this discussion again. There are more problems with Berkeley DB than just relicensing. On Fri, Jun 20, 2014, at 09:47, Thomas Goirand wrote: > Respectfully, this is only your own opinion. Maybe I'm wrong, but I > myself fail to see why the AGPLv3 is a problem. And I don't understand > why you wrote that "the AGPLv3 is not very friendly to downstream > projects". IMO it is only unfriendly with proprietary SaaS, which isn't > the concern of Debian, right? Clicking few times on [Thread Next] would really help you and me: https://lists.debian.org/debian-legal/2013/07/msg00020.html Incompatible BDB rdepends: 389-ds-base: GPLv2-only apr-util: Apache 2.0 boxbackup: 4-clause BSD canl-c++: Apache 2.0 clisp: GPLv2-only cyrus-imapd-2.4: 4-clause BSD cyrus-sasl2: 4-clause BSD dovecot (parts): 4-clause BSD evolution-exchange: GPLv2-only exim: sasl parts are 4-clause BSD[1] gqcov: GPLv2-only gridengine: tcsh parts under 4-clause BSD, rest is SISSL[2] hpsockd: GPLv2-only iproute2: GPLv2-only jabberd2: GPLv2-only jigdo: GPLv2-only kamailio: OpenSSL parts with advertising clause ldiskfsprogs: GPLv2-only libqxt: contains file with LGPL2.1-only lucene2: Apache 2.0 moc: GPLv2-only netatalk: GPLv2-only file[3] nordugrid-arc: Apache 2.0 nvi: 4-clause BSD pavuk: advertising clause php5: PHP License 3.01[4] postfix: IBM PUBLIC LICENSE 1.0[5] prayer: cyrus-imap parts under 4-clause BSD radiusd-livingston: 4-clause BSD redland: Apache 2.0 reprepro: GPLv2-only rpm: lib/merge.c is 4-clause BSD[1] spamprobe: QPL[6] squidguard: GPLv2-only subversion: Apache 2.0 wvstreams: LGPLv2.1-only zeroc-ice: GPLv2-only 1. BTW this links 4-clause BSD with GPL code within the same source 2. SISSL is not GPL compatible according to Wikipedia 3. And a couple of files under UNKNOWN license :) 4. AFAIK GPL-incompatible 5. http://www.gnu.org/licenses/license-list.html#IBMPL 6. http://www.gnu.org/licenses/license-list.html#QPL 7. However this case might be the borderline case as outlined here: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403258230.18463.130930537.3a9fe...@webmail.messagingengine.com
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dnssec-root-key Version : 20100715 Upstream Author : ICANN/IANA * URL : http://data.iana.org/root-anchors/ * License : Public Data (same as with root.zone) Programming Lang: None Description : This package contains DNSSEC root key This package contains DNSSEC root key in all available formats that all packages doing DNSSEC validation can use as a common data source. . unbound-anchor is used to keep the root.key up-to-date via RFC5011 mechanism. - -- PERSONAL NOTE: I now maintain at least two packages that need DNSSEC root.key (hash-slinger and getdns[1]). There are at least bind9, unbound and dnsmasq that can use this as well. 1. Waiting for next upstream release with proper libtool flags. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTq8iuAAoJEAyZtw70/LsHnXAQALn7VdqAb19f8lfon4xErVTl X51iFSNoqIFJQgl1y80sFsStVbPgwGgqPmRnrviVmjXvYphJs6YpZkIZCG1EMbz6 ICUHdVrH9//hbjHkY265W2SOECo2uRXPYZ6EgHl0keKJbZPodnlxrxlhPeQ9y68Q srh7/glB/BMxU1k6VJwut50w00Cr9vmYX4mtG0I8GNBmWhQU0GXS/4qdNWMnIqaL qGaDN2sheFHsaEqL0pZquK4U7tL0Ah0J/6VUHiPbnqI49olii7N3IXtH7i9KM3V1 2JFPTN2S0I8qGh/e4kbZzko2zULbwKwFYRP9hymU/CQ1WMnYpmonN+iHgVL0K2rO 6qF4OQKS/Fw/mttym5fir3aBL+mKhbuVtVnH3WsC6Lra3hyB1sPTFAZZyfgTLe7v N1shbIznaUtDXQ/rey/n9ljC3HJa6hUQ9s1ae7SmkmVj9cbbuMZNFEkCUgco6VXM O1D5q5oJ/F0xsWLutJ0BirkGqKHqiL7/6sofWRyysNrRdqM63p7XNCeOy8o06YUH P/FkaL/Uk1sTabL07pFjknYmRORWdhglNaUD1Xy9r8LlHpDyk/qf8vkBzN0Y4dHH XgLKm6UDMm5tjhlIyjArIVT4Q22i+ZVsvkPCsEXrglimrrMQxDTI6Gi8q6FbfuD8 iczDv8qKX0dehB2IoRBe =afU7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626071603.2788.54208.report...@howl.nic.cz
Sources licensed under PHP License and not being PHP are not distributable
Hi everyone, I should have done this earlier before cloning the bugs, so here's some more background on the bugs filled. I did have a quite long and extensive chat with FTP Masters and our conclusion was that PHP License (any version) is suitable only for software that comes directly from "PHP Group", that basically means only PHP (src:php5) itself. We have several options to do here: 1. Ask upstream to re-license the software to different free license - BSD or MIT/Expat is the closest one. 2. Show that the software in question does come from "PHP Group", f.e. software based on src:php5 sources. Most notable example is src:php-json which is copy of ext/json/ adapted to libjson-c-dev instead of the included JSON-IS-EVIL library. 3. We remove the source packages from Debian. One more note: PHP is *not* compatible with GPL[1]. If you have sources that combine PHP-licensed source with GPL-licenced source the result is not distributable. That includes linking GPL library to PHP licenced source (e.g. libreadline as most notable example of GPL library). While doing the copyright research I have found two such examples and Ansgar was that kind that he filled: #752625 and #752627 Full list of bugs filled under this: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ondrej%40debian.org&tag=php-license-3.01 If you feel to dispute this please take your *well-formed* and *well-thought* arguments to debian-legal. Ondrej [1] <https://www.gnu.org/licenses/license-list.html#PHP-3.01> -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403780412.23608.134754697.0362d...@webmail.messagingengine.com
Re: Sources licensed under PHP License and not being PHP are not distributable
On Thu, Jun 26, 2014, at 13:09, Dimitri John Ledkov wrote: > On 26 June 2014 12:00, Ondřej Surý wrote: > > > > Hi everyone, > > > > I should have done this earlier before cloning the bugs, so here's > > some more background on the bugs filled. > > > > I did have a quite long and extensive chat with FTP Masters > > and our conclusion was that PHP License (any version) is > > suitable only for software that comes directly from "PHP Group", > > that basically means only PHP (src:php5) itself. > > > > Can ftp-masters or you summarise the logic argumentation behind the > above conclusion? https://ftp-master.debian.org/REJECT-FAQ.html You have a PHP add-on package (any php script/"app"/thing, not PHP itself) and it's licensed only under the standard PHP license. That license, up to the 3.x which is actually out, is not really usable for anything else than PHP itself. I've mailed our -legal list about that and got only one response, which basically supported my view on this. Basically this license talks only about PHP, the PHP Group, and includes Zend Engine, so its not applicable to anything else. And even worse, older versions include the nice ad-clause. One good solution here is to suggest a license change to your upstream, as they clearly wanted a free one. LGPL or BSD seems to be what they want. And https://lists.debian.org/debian-legal/2005/08/msg00128.html I tried to raise the same argument again: https://lists.debian.org/debian-legal/2014/06/msg0.html > > We have several options to do here: > > > > 1. Ask upstream to re-license the software to different free license > > - BSD or MIT/Expat is the closest one. > > > > 2. Show that the software in question does come from "PHP Group", > > f.e. software based on src:php5 sources. Most notable example is > > src:php-json which is copy of ext/json/ adapted to libjson-c-dev > > instead of the included JSON-IS-EVIL library. > > > > 3. We remove the source packages from Debian. > > > > One more note: PHP is *not* compatible with GPL[1]. If you have > > sources that combine PHP-licensed source with GPL-licenced > > source the result is not distributable. That includes linking GPL > > library to PHP licenced source (e.g. libreadline as most notable > > example of GPL library). > > > > While doing the copyright research I have found two such examples > > and Ansgar was that kind that he filled: #752625 and #752627 > > > > Full list of bugs filled under this: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ondrej%40debian.org&tag=php-license-3.01 > > > > If you feel to dispute this please take your *well-formed* and > > *well-thought* > > arguments to debian-legal. > > > > Why debian-legal, and not here / with you & ftp-masters ? The initial conclusion came from debian-legal, and I think it's futile to discuss that with ftp-masters when I already done that. And as you can see in the initial conversation in the bug report I was against the removal, but in the end they have convinced me that licensing anything not-being-PHP under PHP License is just no-goer. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403782870.32126.134768701.169c5...@webmail.messagingengine.com
Re: Sources licensed under PHP License and not being PHP are not distributable
On Thu, Jun 26, 2014, at 13:36, Faidon Liambotis wrote: > On 06/26/14 14:00, Ondřej Surý wrote: > > I should have done this earlier before cloning the bugs, so here's > > some more background on the bugs filled. > > > > I did have a quite long and extensive chat with FTP Masters > > and our conclusion was that PHP License (any version) is > > suitable only for software that comes directly from "PHP Group", > > that basically means only PHP (src:php5) itself. > > Could you elaborate on the reasoning of that? Neither your email to > -devel nor the one to -legal[1] explains why you think so and whatever > it is, I think it's far from obvious. I think an outcome that results in > a mass (RC) bug filing needs to be better documented than that -- and > btw, you're supposed to mail debian-devel *before* you do so, not after; > cf. developer's reference 7.1.1. Don't shoot the messenger, I just did the dirty work. I have discussed this with ftp-masters and release team before filling the bugs, arguing heavily in disagreement with ftp-master's REJECT FAQ - the PHP License REJECT is there since 2005. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403783628.3039.134777537.5ee02...@webmail.messagingengine.com
Re: Bug#752614: Sources licensed under PHP License and not being PHP are not distributable
On Thu, Jun 26, 2014, at 13:56, Ondřej Surý wrote: > On Thu, Jun 26, 2014, at 13:52, Mike Gabriel wrote: > > Hi Ondřej, > > > > On Do 26 Jun 2014 13:00:12 CEST, Ondřej Surý wrote: > > > > > I did have a quite long and extensive chat with FTP Masters > > > and our conclusion was that PHP License (any version) is > > > suitable only for software that comes directly from "PHP Group", > > > that basically means only PHP (src:php5) itself. > > > > Can you provide some evidence why you think this applies to smarty3? > > > > Smarty3 is licensed under LGPL-2.1+ so I am hesitant to belief that > > this bug actually affects Smarty3. > > Files: development/lexer/LexerGenerator/Lexer.php > Copyright: > 2006, Gregory Beaver > License: PHP License 3.01, http://www.php.net/license/3_01.txt > This source file is subject to version 3.01 of the PHP license > that is available through the world-wide-web at the following URI: > http://www.php.net/license/3_01.txt. If you did not receive a copy of > the PHP License and are unable to obtain it through the web, please > send a note to lice...@php.net so we can mail you a copy immediately. > > Files: development/lexer/Exception.php > Copyright: > 2006, Gregory Beaver > License: PHP License 3.0, http://www.php.net/license/3_0.txt > This source file is subject to version 3.0 of the PHP license > that is available through the world-wide-web at the following URI: > http://www.php.net/license/3_0.txt. If you did not receive a copy of > the PHP License and are unable to obtain it through the web, please > send a note to lice...@php.net so we can mail you a copy immediately. > > And two more undocumented: ./development/lexer/ParserGenerator/State.php: * @license http://www.php.net/license/3_01.txt PHP License 3.01 ./development/lexer/ParserGenerator/Parser.php: * @license http://www.php.net/license/3_01.txt PHP License 3.01 Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403783794.3718.134779033.23005...@webmail.messagingengine.com
Re: Bug#752614: Sources licensed under PHP License and not being PHP are not distributable
On Thu, Jun 26, 2014, at 13:52, Mike Gabriel wrote: > Hi Ondřej, > > On Do 26 Jun 2014 13:00:12 CEST, Ondřej Surý wrote: > > > I did have a quite long and extensive chat with FTP Masters > > and our conclusion was that PHP License (any version) is > > suitable only for software that comes directly from "PHP Group", > > that basically means only PHP (src:php5) itself. > > Can you provide some evidence why you think this applies to smarty3? > > Smarty3 is licensed under LGPL-2.1+ so I am hesitant to belief that > this bug actually affects Smarty3. Files: development/lexer/LexerGenerator/Lexer.php Copyright: 2006, Gregory Beaver License: PHP License 3.01, http://www.php.net/license/3_01.txt This source file is subject to version 3.01 of the PHP license that is available through the world-wide-web at the following URI: http://www.php.net/license/3_01.txt. If you did not receive a copy of the PHP License and are unable to obtain it through the web, please send a note to lice...@php.net so we can mail you a copy immediately. Files: development/lexer/Exception.php Copyright: 2006, Gregory Beaver License: PHP License 3.0, http://www.php.net/license/3_0.txt This source file is subject to version 3.0 of the PHP license that is available through the world-wide-web at the following URI: http://www.php.net/license/3_0.txt. If you did not receive a copy of the PHP License and are unable to obtain it through the web, please send a note to lice...@php.net so we can mail you a copy immediately. And two more undocumented: -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403783770.3678.134778889.53139...@webmail.messagingengine.com
Re: Sources licensed under PHP License and not being PHP are not distributable
Hi Charles, On Thu, Jun 26, 2014, at 14:27, Charles Plessy wrote: > If your disagreement with the FTP team is unresolvable, and if you have > time, maybe you can try to open a ticket for a resolution by the Technical > Comittee ? I don't think that falls under tech-ctte jurisdiction under Chapter 8.1 of Debian Constitution. Ccing Debian Secretary... I guess such overruling would need a GR. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403785947.11658.134791917.1d35c...@webmail.messagingengine.com
Re: how do I treat an un-owned leftover directory?
If you do create those directories in {pre,post}inst, you should
check if they are empty in {pre,post}rm and remove them
after unlinking the stuff you have linked in.
e.g. just cleanup after your package on purge
Ondrej
On Thu, Jun 26, 2014, at 14:45, Dennis van Dok wrote:
> Hi,
>
> my packages igtf-policy-bundle has piuparts errors[1].
>
> I'm symlinking files to /etc/grid-security/certificates/ on
> installation, and everything but the directories themselves are removed
> on package removal.
>
> I guess I could remove these directories if they are completely empty
> after package removal, but I don't really own the directories. The use
> of these directories is an established convention with grid computing
> software.
>
> I would appreciate your advice!
>
> Best,
>
> Dennis van Dok
>
>
> 1. https://piuparts.debian.org/sid/source/i/igtf-policy-bundle.html
>
>
> --
> D.H. van Dok :: System administrator :: www.nikhef.nl/grid ::
> Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/53ac15e1.4090...@nikhef.nl
>
--
Ondřej Surý
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1403788667.22785.134811305.2840a...@webmail.messagingengine.com
Re: Sources licensed under PHP License and not being PHP are not distributable
Steve, I did hand checked all copyright files in question and while php-imlib might have slipped me, I am quite sure that your claim about "lot of these" is false, since php-imlib is not the only package under dual licensing I have seen. I do apologize for filling bug against php-imlib though. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server > On 26. 6. 2014, at 19:29, Steve Langasek wrote: > >> On Thu, Jun 26, 2014 at 02:36:18PM +0300, Faidon Liambotis wrote: >>> On 06/26/14 14:00, Ondřej Surý wrote: >>> I should have done this earlier before cloning the bugs, so here's >>> some more background on the bugs filled. > >>> I did have a quite long and extensive chat with FTP Masters >>> and our conclusion was that PHP License (any version) is >>> suitable only for software that comes directly from "PHP Group", >>> that basically means only PHP (src:php5) itself. > >> Could you elaborate on the reasoning of that? Neither your email to -devel >> nor the one to -legal[1] explains why you think so and whatever it is, I >> think it's far from obvious. I think an outcome that results in a mass (RC) >> bug filing needs to be better documented than that -- and btw, you're >> supposed to mail debian-devel *before* you do so, not after; cf. developer's >> reference 7.1.1. > >> Besides the importance of the bug filing itself and removing half of PHP >> from Debian (including packages such as php-memcached!), I have another >> point to make: as you're well aware, we're in the progress of packaging >> Facebook's HHVM, which is a new runtime engine for PHP that is gaining some >> popularity[2]. > > Furthermore, there are bugs in the actual MBF that's been filed here. Bug > #752639 was filed against php-imlib, which gives the PHP license as one of > *two* options under which the work can be distributed - LGPL is the other, > and is in practice the one that's in effect for Debian. > > So I think we need a review here of the MBF methodology, because the > problems with the PHP License were already identified and worked through in > the archive a decade ago - so a lot of these bugs are probably false > positives. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org
Re: Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Hi Robert,
On Fri, Jun 27, 2014, at 00:32, Robert Edmonds wrote:
> Ondřej Surý wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Ondřej Surý"
> >
> > * Package name: dnssec-root-key
>
> Hm, I would maybe call this dnssec-root-anchors. Technically there
> should be very few copies of the root key :-)
I ended up with dns-root-data, and also included root.zone and
root.hints.
The git repo resides at github.com at the moment as I feel it's not
appropriate for collab-maint:
https://github.com/oerdnj/dns-root-data
> Similarly, s/key/trust anchors/g in the descriptions?
Yep, already fixed that:
Package: dns-root-data
Architecture: all
Depends: ${misc:Depends}
Description: DNS root data including root zone and DNSSEC key
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
.
* Root Hints and Zone Files (root.hints, root.zone)
* Root Trust Anchors (root.key, root.ds)
> > Version : 20100715
> > Upstream Author : ICANN/IANA
> > * URL : http://data.iana.org/root-anchors/
>
> > * License : Public Data (same as with root.zone)
>
> It might be nice to include a copy of this document in /usr/share/doc:
True, fixed in git.
> http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
>
> Since it looks like this is the only place where a schema is defined for
> the root-anchors.xml file.
>
> But I guess we would need a better (non-)license than this:
>
>Copyright (c) 2010 Internet Corporation For Assigned Names and
>Numbers.
We do, I spoken with Kim Davies and the IANA published data is basically
public domain.
> > Programming Lang: None
> > Description : This package contains DNSSEC root key
> >
> > This package contains DNSSEC root key in all available
> > formats that all packages doing DNSSEC validation can
> > use as a common data source.
> > .
> > unbound-anchor is used to keep the root.key up-to-date
> > via RFC5011 mechanism.
I have removed the unbound-anchor runtime dependency in the end. Somehow
I feel it would be better to update this package via s-p-u mechanism.
> > PERSONAL NOTE: I now maintain at least two packages that
> > need DNSSEC root.key (hash-slinger and getdns[1]). There
> > are at least bind9, unbound and dnsmasq that can use this
> > as well.
> >
> >
> > 1. Waiting for next upstream release with proper libtool
> > flags.
>
> So, I wonder if this package should be responsible for providing the
> root-anchors.xml file, and the bind9/unbound/dnsmasq/etc. packages
> should be responsible for converting that from XML to whatever format
> they use (and unfortunately it appears every different program uses a
> different trust anchor format).
I provide root.key and root.ds in /etc/dns/. It's probably not a bad
idea to also provide root-anchors.xml in /usr/share/dns-root-data/
As a side note - do you think that /etc/dns/ is OK, or we should use
/usr/share/dns-root-data/ (or /usr/share/dns/)?
> Or by "all available formats" do you mean that this source package
> should take the root-anchors.xml file and generate several common
> formats (at package build time?) and provide them in /usr/share
> alongside the original root-anchors files from iana.org, so that DNSSEC
> software packages don't need an XML dependency? (Though, bind9 and
> unbound-anchor already pull in XML parsing libraries, but e.g. dnsmasq
> currently does not.)
My thought is to provide just root.key and root.ds and adjust if the
users of the package needs more.
> Should we patch unbound-anchor so that its fallback mode (where it tries
> to fetch files from https://data.iana.org/root-anchors/) can be made to
> check file:///usr/share/dnssec-root-anchors/ first? (And if so, it'd be
> nice to upstream that.)
Yes, I was surprised that upstream unbound-anchor cannot be used
in offline mode.
> Should we do anything about the built-in static content in
> unbound-anchor that would be duplicative of the content in this package?
> I'm talking about this:
>
>
> http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l207
>
> And this:
>
>
> http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l237
That's probably up to you. It seems to be a good idea to look for the
dns-root-data contents first before falling back to the compiled in
defaults.
> And, finally, is it known that the root DNSSEC key
Re: Sources licensed under PHP License and not being PHP are not distributable
On Tue, Jul 1, 2014, at 10:17, Matthias Urlichs wrote: > (C) Bite the bullet and admit that when everybody else calls a color > "light blue" which we consider to be "cyan", we might as well docuent > that fact instead of trying to convince everybody else that they're > wrong, even if they are, from our PoV. After all, the color stays the > same, no matter what people call it. > > By the same token, this license is valid by force of everybody under > the sun considering it to be valid (taking intent and all that into > account). The chance of an author of / contributor to one of these > packages (nobody else has any legal standing to do so) suing us for > distributing this code is … well … I suspect that if you want to get > a lawyer to laugh, you might as well ask them. > > So. Bottom line: Can we agree to compromise on some modification of > (C) informally, or is a GR required? JFTR the http://www.php.net/software page claims that software distributed from php.net, pecl.php.net and pear.php.net distributes software under PHP License[1]. This was also claimed in some private emails between me and PHP folks[2]. My conclusion is that the PHP folks do agree that the PHP License cannot be used for software outside *.php.net, but it's perfectly OK for stuff distributed from *.php.net. If there's no wild disagreement from FTP Masters on this in couple of days I will just start closing bugs on packages distributed from *.php.net. 1,2: smarty3 should be okay as well, it's just not yet documented there. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404212304.28574.136477009.4c349...@webmail.messagingengine.com
Re: MATE 1.8 has now fully arrived in Debian
On Tue, Jul 1, 2014, at 08:15, Stefano Rivera wrote: > Hi Matthias (2014.06.26_08:38:09_+0200) > > Of these, roughly 20% have switched to systemd. And they apparently did not > > and do not have any problem with it, otherwise we'd hear about it. Here and > > other places. Quite loudly. > > Not necessarily. > > My laptop won't boot with systemd, although other machines I have will. > I haven't filed a bug, because I haven't had the time to sit down and > learn how to debug systemd booting, and I wouldn't want to file an bug > until I know what's going on... Still - this is just anecdotic evidence that doesn't deviate from normal modus operandi of Debian packaging (e.g. most software has bugs). I think that what Matthias wanted to say is there is no massive breakage among users who has switched to systemd (and not that systemd is 100% bug free). O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404212503.29526.136479005.56414...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
On Tue, Jul 1, 2014, at 17:20, Thomas Weber wrote: > On Tue, Jul 01, 2014 at 04:38:16PM +0200, Thijs Kinkhorst wrote: > > The responses from the systemd maintainers are indeed on the terse side, > > but I can imagine that your style of bug reporting does not invite our > > volunteers to spend more time on it. > > This is not a question of spending time. An upgrade broke functionality > and purging systemd fixed this issue. That does not mean that it is a > bug in systemd, but it surely is a bug somewhere, be it the dependencies > (if systemd-shim is needed, why was it not installed during the upgrade?) > or the code of some other package. > Now, time is limited, but "I don't have time right now" is certainly not > a reason to close a bug within three hours. > > Or, taking a different perspective: now that the issue is known, what is > done to prevent another user from hitting the very same issue in the > future? By reporting appropriate bug? If the power button ceased to work there should be a bug report about power button not working and not about preventing systemd to be installed. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404231839.20584.136601777.3c78a...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
On Tue, Jul 1, 2014, at 18:03, Jakub Wilk wrote: > * Juliusz Chroboczek , 2014-07-01, 15:25: > >I filed bug 753357 > > Why is this bug marked as fixed in systemd/204-9? I suggest to reassign this bug to acpi-support-base and stop this yet-another-senseless-flamewar-about-systemd in the beginning pretty please. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404232118.21941.136603961.75c50...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
On Tue, Jul 1, 2014, at 18:09, Marco d'Itri wrote: > On Jul 01, Carlos Alberto Lopez Perez wrote: > > > I think that a critical debconf warning should be in place to avoid > > replacing the init system of users without prior explicit consent. > I think that this would be an annoying waste of time for most users, > since only a few people care so much about not being tainted by systemd. Yes and we *have* release notes for this kind of information. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404233608.29272.136613049.4b0b3...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
Miroslaw, unless you offer to ack as a front desk for bugs in systemd, then please go with your judgments elsewhere. Your judgmental comments are neither helpful nor welcome here. Thanks, Ondrej On Tue, Jul 1, 2014, at 18:17, Mirosław Baran wrote: > Michael Biebl made an argument from authority: > > > Am 01.07.2014 17:35, schrieb Juliusz Chroboczek: > > >> I am not a Debian Developer. I am not bound by the Social Contract. > > > I may remind you about [1] then. If you feel like you need to rant or > > vent, please do it someplace else or expect a terse answer like the one > > you got. > > Your answer wasn't *just* terse. Your answer was downright rude. > > Kind regards, > – Miroslaw Baran > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/d834210ada34efc7aeca83a89e022...@hell.pl > -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404238532.4097.136641601.2e1a4...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
Michael, On Tue, Jul 1, 2014, at 18:51, Michael Biebl wrote: > > Install systemd-sysv for systemd-shim. > > The libpam-systemd package in 204-9 ensures that either of the two is > > installed. > > The behaviour of acpi-support-base is correct, there shouldn't be any > bug filed against it. please don't get me wrong, this is not an attack on systemd. There has to be a bug somewhere, if the power button can stop working in partial upgrades. Maybe the dependencies need to be tighten or conflict added or it just needs d/NEWS with explanation? Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404238681.4912.136642081.371fc...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
On Tue, Jul 1, 2014, at 20:18, Ondřej Surý wrote: > Michael, > > On Tue, Jul 1, 2014, at 18:51, Michael Biebl wrote: > > > Install systemd-sysv for systemd-shim. > > > The libpam-systemd package in 204-9 ensures that either of the two is > > > installed. > > > > The behaviour of acpi-support-base is correct, there shouldn't be any > > bug filed against it. > > please don't get me wrong, this is not an attack on systemd. > > There has to be a bug somewhere, if the power button can stop working > in partial upgrades. Maybe the dependencies need to be tighten or > conflict added or it just needs d/NEWS with explanation? Ah, Steve has just posted an excellent explanation of the situation... O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404238880.5705.136643637.3e81f...@webmail.messagingengine.com
Re: How to avoid stealth installation of systemd?
On Wed, Jul 2, 2014, at 09:37, Thomas Goirand wrote: > On 07/02/2014 12:09 AM, Marco d'Itri wrote: > > On Jul 01, Carlos Alberto Lopez Perez wrote: > > > >> I think that a critical debconf warning should be in place to avoid > >> replacing the init system of users without prior explicit consent. > > I think that this would be an annoying waste of time for most users, > > since only a few people care so much about not being tainted by systemd. > > I don't agree. Many people in this list voiced concerns about systemd, > and don't want it installed on their systems. Not many - just few and repetetively :(. There are also many people who either don't care or just agree. You don't expect to have the '+1' war to happen here, right? > IMO, enough so that it'd be worth a quick warning. Yes, we have a release notes for that. I guess you would be welcome to help draft a text that needs to be put there instead of flaming here. > Please don't take the average grand-mother who > just had her first computer 3 days ago as an excuse to say newbies don't > need to know. This does *not* work, and we don't do Debian only for > those. There's also experts that are running Debian, and it'd be nice to > tell them. *I* for example, would be happy to be warned about such a > change, and wouldn't consider it a waste of time. Yes, we have a release notes for that. Thomas, just stop with this FUD. Your constant flaming is not helping neither you, your cause nor Debian, and it's becoming tiresome. You will not achieve anything more than a place in personal blacklists, and that would be a shame, because your "non-systemd" contributions are valuable. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404288449.15504.136854561.35cb4...@webmail.messagingengine.com
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Thu, Jul 3, 2014, at 16:59, Thorsten Glaser wrote: > Besides, it’s not that the TC made a decision. Rather, the TC was > split, and the chairman threw in his weight. This is absolutely not > what I’d call a project(!) decision. No! The TC has made the decision with full adherence to Debian Constitution. If you disagree, perhaps you should go re-read the Constitution, and if you disagree with our Constitution then perhaps it's time for you to step down as a Debian Developer, since you are bound by the Constitution and Social Contract and you are doing hard to the project by making claims like this one. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404466044.32693.138025825.706c6...@webmail.messagingengine.com
Re: Bug#752075: daemontools-run: Add systemd support
Gerrit, it's up to you to lower the severity of the bug to "important" (I guess since it will break with default init system). You should have done that instead of ccing debian-devel in the current situation. Please do not abuse debian-devel to questions that could be politely and calmly discussed outside the list. Thanks, O. On Fri, Jul 4, 2014, at 11:08, Gerrit Pape wrote: > Hi, > > I looked into latest policy, but did not find anything about systemd > support. I'm surprised that this is now a release critical bug, and the > package marked for removal. What's the justification? > > This package hooks into /etc/inittab, does systemd not automatically > manage services from inittab? Isn't it systemd having release critical > bug then? > > Regards, Gerrit > > > On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote: > > Package: daemontools-run > > Version: 1:0.76-3 > > Severity: grave > > Justification: renders package unusable > > > > Hi, > > Debian decided to use systemd. > > > > I'm using a local dnscache (djbdns) for recursive dns lookups, but this > > service isn't started automatically. I assume that it's because > > daemontools-run only supports sysvinit's inittab. > > > > Please add systemd support, > > Cheers! > > > > > > -- System Information: > > Debian Release: jessie/sid > > APT prefers unstable > > APT policy: (600, 'unstable') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > > > Versions of packages daemontools-run depends on: > > ii daemontools 1:0.76-3 > > > > daemontools-run recommends no packages. > > > > daemontools-run suggests no packages. > > > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/20140704090821.13265.qm...@79b6c771442573.315fe32.mid.smarden.org > -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404468401.9917.138036781.4169e...@webmail.messagingengine.com
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Fri, Jul 4, 2014, at 16:42, Adam Borowski wrote: > On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote: > > So, let me get this straight: > > > > You're saying that if, having decided to postpone rebooting after an > > upgrade where any reasonable person would expect to reboot > > This is Debian, not Windows or Red Hat, forced reboots are not > acceptable. Yes, this is Debian and not a magic world. > There was enough trouble when udev needed an in-lockstep upgrade with the > kernel a few releases back. If systemd components are going to need such > forced reboots on a repeated basis, I don't like where this is going. Nobody said that. But I am sure you can understand that some changes might require a reboot to have all functionality. I think it's unreasonable to require that all components must work in every combination of partial upgrade. And still this is unstable/testing and some inconveniences are allowed, we just must be sure that the stable release upgrade process is smooth. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404486367.14427.138117277.67a2e...@webmail.messagingengine.com
Re: possible MBF: automatically detecting unused build dependencies
s, the generated results > are > very relevant for making solving the bootstrap problem easier. > > You can find the results per source package in the attachment together > with the > dd-list output. The file drop-from-bd.txt lists the build dependencies > that can > be dropped from Build-Depends while move-to-bdi lists the build > dependencies > that can be moved from Build-Depends to Build-Depends-Indep. > > Can you spot obvious mistakes in the results or in the procedure used to > generate them? > > cheers, josch > > [1] #749616 #749972 #751702 #751897 #752938 > [2] https://github.com/josch/findunusedbd > Email had 3 attachments: > + dd-list.txt > 22k (text/plain) > + drop-from-bd.txt > 22k (text/plain) > + move-to-bdi.txt > 1k (text/plain) -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404735376.10703.138839897.49d9f...@webmail.messagingengine.com
Re: libjpeg-turbo transition
Hi Mike, On Wed, Jul 9, 2014, at 19:57, Mike Gabriel wrote: > Hi Niels, > > On Mi 09 Jul 2014 19:44:39 CEST, Niels Thykier wrote: > > > Hi Mike, > > > > Thank you for your efforts. > > > > If you plan on doing this transition for Jessie, please do keep the "5th > > of September" deadline in mind[1]. > > Ack. > > > Please also consider filing a > > transition bug to help us (the release team) get an overview of the > > affected packages at your earliest convenience. > > If someone else could take this over before August, that will be much > appreciated. I won't be able to make it before then... I can take care of those things about the releases. I can also help with the packages, merging the work already done in Ubuntu into git, etc. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404982010.12364.140069145.6a93f...@webmail.messagingengine.com
Re: Solutions for the Apache upgrade hell
Hi Arno, On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote: > Hello, > > we've got a problem with Apache that causes problems during upgrades > (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4 > changed ABIs, so that we need to ensure that dpkg properly removes > packages linking against the obsolete ABIs at upgrade time. This is the > first time this happened since Debian Etch, so this brings a problem to > the spotlight, that hasn't been one for a long time. > > To summarize the bug reports: The problem is, that Apache package > maintainers at that time decided, that third party modules shall depend > on apache2.2-common, by guaranteeing ABIs remain stable as long as the > package name does not change. This is, so far policy compliant. However, > by now ABIs did change and we were forced to rename the package (we did > so, by providing a virtual API package third parties must depend on. At > time of writing this is apache2-api-20120211). Unfortunately, > apache2.2-common also contains conffiles and configuration file handling > in postinst/postrm ... > > I spent a lot of time to properly transition to a new state with > conffiles/configuration separated from ABI handling, and this works well > enough for regular updates by now. > > Unfortunately it turns out, that /a lot/ of people use "aptitude > --purge-unused safe-upgrade", or the apt equivalent "apt-get > dist-upgrade --purge" which causes dpkg to purge the user's > configuration, in particular enabled modules, during the upgrade because > apache2.2-common disappears in that step. Those people end up with > effects as described in the bugs outlined above, for example with > incomplete installations because our maintainer scripts had no chance to > properly detect the state of the /etc/apache2 directory before the > upgrade. > > This gives us three possibilities which all have unwanted side effects > (unless you come up with an idea that all of us makes happy). I'm > writing to this list in hope that someone has a very smart idea to make > everyone happy, or express your support for either alternative to give > us some insights what people think would be the best alternative. > > * Add a apache2.2-commmon transitional package. This gives us a chance > to inspect /etc/apache2 in spite of --purge-unused and properly > transition to Apache 2.4. HOWEVER, this has the nasty side effect that > modules ABIs are considered compatible as far as dpkg is concerned. > Therefore, old module packages aren't forced to be removed and this > breaks at runtime when people try to start their upgraded web server > with incompatible modules. As a workaround we could add a versioned > "Breaks" for all modules in Wheezy (~ 75) in the apache2.2-common > transitional package, and in addition for packages that existed in > Squeeze or Etch only (no, really). That said, this still won't help for > third party modules outside Debian which people might use (and to my > best knowledge, they do a lot) and it's generally problematic in view of > the policy with respect to library packaging (even though we're not a > library strictly speaking) This + BIG FAT WARNING in release notes seems to be the best option to me. People's configuration will probably break anyway due custom configuration files, etc. or manually compiled modules[1][2]. Also if people have custom modules that will get removed in the upgrade, they wouldn't want to start the apache without those modules anyway - this could have all kind of security implications - exposing the raw source files of interpreted languages, etc. 1. As an option you can walk through all enabled modules in apache2.4 postinst and detect incompatible ABI in /usr/lib/apache2/modules/*.so files. 2. As a thought did you think about moving the modules under /usr/lib/apache2/20120211/ (e.g. similar to what PHP has). You still have time for that and it would make the transition easier in the future (also with third party modules). Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405325501.4775.141318941.5caff...@webmail.messagingengine.com
Re: Let's shrink Packages.xz
Hi Jakub, On Mon, Jul 14, 2014, at 18:25, Jakub Wilk wrote: > Food for thought: > Which fields take up most space in Packages.xz[0]? I am still lost - what problem are we trying to solve here? Could we at least define it to see if the problem exists? Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405526596.17312.142348849.27365...@webmail.messagingengine.com
Re: libjpeg-turbo transition
Hi Mike On Fri, Jul 11, 2014, at 09:33, Mike Gabriel wrote: > >> > Please also consider filing a > >> > transition bug to help us (the release team) get an overview of the > >> > affected packages at your earliest convenience. > >> > >> If someone else could take this over before August, that will be much > >> appreciated. I won't be able to make it before then... > > > > I can take care of those things about the releases. I can also help with > > the packages, merging the work already done in Ubuntu into git, etc. > > Great! Go ahead then. I will join in again when I am back from VAC > (2nd Aug 2014). Done. Feel free to discuss the transition plan in #754988. I will be working on updated libjpeg-turbo packages next week. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405526729.17627.142349685.20a74...@webmail.messagingengine.com
Re: Let's shrink Packages.xz
On Wed, Jul 16, 2014, at 19:28, Russ Allbery wrote: > Ondřej Surý writes: > > On Mon, Jul 14, 2014, at 18:25, Jakub Wilk wrote: > > >> Food for thought: > >> Which fields take up most space in Packages.xz[0]? > > > I am still lost - what problem are we trying to solve here? > > Could we at least define it to see if the problem exists? > > I'm fairly sure Jakub's message was in response to the recent discussion > about small Node.js packages and the frequent complaints that we should > not introduce small packages into the archive because it bloats our > metadata. > > Reducing the size of Packages.xz by 11% or 22% would leave room for quite > a lot of small packages while not making the problem any worse than it is > today. Ok, that makes much more sense now. Still is the main problem the download size or the size on the disk (I can guess that it can be a problem on embedded archs). Or both? Dropping md5+sha1 or even introducing sha-224 instead of sha-256 would help in this case. Having the fallback mechanism leaves open door for stripping+downgrade attacks anyway. Switching to an optimized binary format isn't an option? But I guess it won't be probably that much better than a good compression algorithm. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405536029.10176.142404101.152ab...@webmail.messagingengine.com
Unsafe --purge-unused at dist-upgrade (Was: Solutions for the Apache upgrade hell)
Could we please decouple the --purge-unused thread with the "Solutions for the Apache upgrade hell" thread? It's getting confusing and I am only interested about Apache2 and not about aptitude. Thanks, O. On Thu, Jul 17, 2014, at 23:32, Andrei POPESCU wrote: > On Jo, 17 iul 14, 03:17:35, Vincent Lefevre wrote: > > On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote: > > > On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: > > > > I do that too. I haven't seen any official documentation saying that > > > > this is a bad thing to do. > > > > > > aptitude actively warns against it as highlighted in this thread. > > > > Wrong! I purge removed packages almost all the time with aptitude, > > and I've never seen any warning! > > From aptitude(8) > >--purge-unused >If Aptitude::Delete-Unused is set to “true” (its default), then >in addition to removing each package that is no longer required a >by any installed package, aptitude will also purge them, removing >their configuration files and perhaps other important data. For >more information about which packages are considered to be >“unused”, see the section “Managing Automatically Installed >Packages” in the aptitude reference manual. THIS OPTION CAN >CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE >DOING! > >This corresponds to the configuration option >Aptitude::Purge-Unused. > > > Yes, this is probably not what you understood as "actively", but this > thread is also not about running 'aptitude purge', but 'full-upgrade', > and if you change the default... -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405634901.20492.142887693.68bb6...@webmail.messagingengine.com
Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote: > Additionally, since debian.org uses DNSSEC, if you can somehow MITM > people.debian.org then due to DANE you can MITM it for HTTP as well as > HTTPS, so forcing HTTPS really doesn't gain you much. But that implies that the attacker has access to private keys, and in this case you are so screwed. The possibility of stolen private keys should not be argument for not implementing security. > > There are lots of attack vectors. It's not a response to a single > > attack being exploited in the wild. > > So name one? Pervasive monitoring. Really we should introduce encryption *everywhere*. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405841035.16130.143560421.61491...@webmail.messagingengine.com
Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Sun, Jul 20, 2014, at 12:06, Tim Retout wrote: > On 20 July 2014 10:07, Wouter Verhelst wrote: > > With the state of the CA cartel these days, I have little > > trust in the strength of HTTPS as a verification mechanism, and so I > > wouldn't trust a file to be correct even if it came through an HTTPS > > connection that validates. Instead, I would only trust such a file if it > > came with a GPG signature from a key that is in the Debian keyring. > > Good, because that's not what HTTPS does for you. It makes it more > difficult to watch exactly what you're accessing. > > Suppose for example I uploaded a preseed file to people.debian.org > that created a Tor relay, and a suitably large government agency > wanted to see all the IP addresses installing it. With HTTP, they > just break into the internet backbone at an appropriate point, and log > every request for that file in a *completely undetectable manner*. > With HTTPS, they either need to break into the machine running > people.debian.org, or start presenting a different SSL certificate - > both things which can potentially be detected. > > Another situation is if a dissident accesses people.debian.org via > Tor. With HTTP, the operator of the exit node they are using could > MITM the request and tamper with the file - no state intervention > required. If it's a web page, they could potentially attempt to > exploit the browser. [...] This is excellent summary, thank you Tim. We should not forget that the metadata are interesting too (and thus we also need dns privacy, we don't have right now). Also one of the reasons to encrypt everywhere is that it makes much harder to decrypt everything. The more encrypted "noise" we have in the background the better. P.S.: And I am not known for my love for CAs :)... Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405869571.23682.143634353.4b92d...@webmail.messagingengine.com
Re: How to build-depend on a C++11-capable compiler?
On Mon, Jul 21, 2014, at 12:48, Thibaut Paumard wrote: > Hi, > > The new release of my package Gyoto should be built preferably with a > C++11-capable compiler. It can be built with a reduced feature-set > without, though. > > Is there a clever way to ensure that the default compiler is > C++11-capable, if available in the archive, or should I simply > Build-Depend on g++ (>=4:4.7)? (The goal behind this question is to make > life easier for backporters and persons trying alternate toolchains). Stable has g++-4.7 as default on amd64, i386, kfreebsd-amd64, kfreebsd-i386, so I would say - make a note to README.source and leave that up-to-backporters. clang and default gcc in jessie+ is C++11, so I would suggest to not complicate it. If you really insist you would have to: - depend on g++-4.7 | g++ (>= 4:4.7) - detect default CC in d/rules and pass correct CXX=g++-4.7 And that would only lead to non-deterministic builds confusing people who mangle CC/CXX (for good reasons). I would suggest modifying configure check that would fail to compile if the compiler is not C++11 instead of compiling with reduced feature set. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405940295.3445.143889165.713ab...@webmail.messagingengine.com
Re: myth(?): places in the world where https is illegal? Re: people.debian.org will move from ravel to paradis and become HTTPS only
On Mon, Jul 21, 2014, at 13:12, Holger Levsen wrote: > Hi Iain, > > On Sonntag, 20. Juli 2014, Iain R. Learmonth wrote: > > The main one is that there are places in the world you just can't use HTTPS > > for legal reasons [...] > > I'm curious, can you name one? http://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography And http://www.cryptolaw.org/cls2.htm The usual suspects: Belarus, Iran, Saudi Arabia (and I guess North Korea, but the use of crypto is probably OK if you are allowed to use a computer and connect to outside of the world anyway...) But again this should not be a reason to not deploy encryption everywhere. The current problem with HTTPS is that it bundles encryption with authenticity. This needs to be unbundled[1]. My opinion is that even a transparent opportunistic encryption (f.e. like DANE implementation in postfix) would improve the overall state of security. 1. I must admit that I haven't been able to monitor httpbis progress on this topic. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405949524.7249.143937105.648e1...@webmail.messagingengine.com
RFH Packaging DNSSEC/TLSA Validator (Was: people.debian.org will move from ravel to paradis and become HTTPS only)
Hi, On Sun, Jul 20, 2014, at 08:47, Tollef Fog Heen wrote: > Not many HTTP clients support DANE, unfortunately, and MITM-ing > DNSSEC-secured domains is a bit more effort than just MITM-ing a > plaintext HTTP connection. my team has just produced js-types version of DNSSEC/TLSA Validator so it won't break with recent Mozilla changes. (Should be published soon at www.dnssec-validator.cz - I have a RC binary if you are interested.) Would there be somebody willing to help me with packaging? I have never packaged xul plugin, so it probably would be faster if there's somebody with *free time* (that I also lack) and skill. We have also got rid of FireBreath framework and other stuff, so the packaging should be much easier now. I will stay on packaging team, I just need a kick-off (or a least a tip for good existing package I can canibalize...) Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405956064.22784.143988757.47da5...@webmail.messagingengine.com
Re: libjpeg-turbo transition
On Wed, Jul 16, 2014, at 18:05, Ondřej Surý wrote: > Hi Mike > > On Fri, Jul 11, 2014, at 09:33, Mike Gabriel wrote: > > >> > Please also consider filing a > > >> > transition bug to help us (the release team) get an overview of the > > >> > affected packages at your earliest convenience. > > >> > > >> If someone else could take this over before August, that will be much > > >> appreciated. I won't be able to make it before then... > > > > > > I can take care of those things about the releases. I can also help with > > > the packages, merging the work already done in Ubuntu into git, etc. > > > > Great! Go ahead then. I will join in again when I am back from VAC > > (2nd Aug 2014). > > Done. > > Feel free to discuss the transition plan in #754988. > > I will be working on updated libjpeg-turbo packages next week. Done, the result has been uploaded to experimental. The git repository should be up-to-date, so you can build your own packages until the updated packages is processed from NEW. Also dropping 717076 (Bcced this time) and adding 754988 to the Cc list, so we can discuss the transition at the right place. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405960267.10521.144018049.226a9...@webmail.messagingengine.com
Re: RFH Packaging DNSSEC/TLSA Validator
Preliminary packaging (aka it compiles and works) can be found: https://github.com/oerdnj/dnssec-validator and packages for wheezy and jessie/amd64 can http://people.debian.org/~ondrej/dnssec-validator/ # no repo, just bare dir I just found the upstream misses OpenSSL exception[1], so I will have to sort it out together with next stable upstream release. 1. Do we already have some nice *SSL boilerplate exception that would allow OpenSSL derivative libraries as well? O. On Mon, Jul 21, 2014, at 18:41, David Prévot wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Control: unblock -1 by 675923 > Control: noowner 675923 > Control: retitle 675923 RFP: firebreath -- cross-platform browser plugin > framework > > Hi Ondřej, > > Le 21/07/2014 11:21, Ondřej Surý a écrit : > > my team has just produced js-types version of DNSSEC/TLSA Validator > > so it won't break with recent Mozilla changes. > […] > > We have also got rid of FireBreath framework and other stuff, so > > the packaging should be much easier now. > > Great, that should make #672845 finally fixable (assuming we’re talking > about the same thing). > > > Would there be somebody willing to help me with packaging? > […] > > I will stay on packaging team, I just need a kick-off (or a least a tip > > for good existing package I can canibalize...) > > Sure, pick (almost) any package handled by the Debian Mozilla Extension > Maintainers (CCed), feel free to join us on the list or IRC. Please > maintain it inside the team if you want to take the lead on it (and > feel free to take the ownership of #672845 then). > > Regards > > David > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBCAAGBQJTzULIAAoJEAWMHPlE9r08d8kH/0iNgXNi6wjM4lcpWVego9OE > KdLlMLM3Ayu1KsKxHGGiP6F7G7zoT02Y45vy4Q42QBKb78V1ZsqsGmsVlkI+Ud5t > oejzt6EbVjXxhIHLVXGgODcLh+FIwGdfiaHsYqR4GepS6pl89rvOnqBnZfxVT3Qn > C47CPIphmKCP6/jst+E6UfZPkrvK9SXoT2L3JmqFhRe2/ukzYoc3NzoTrLewZWcQ > S5sVY91HpEVI6aSp9RUpTo5w7yeE06W9SuFT2mTZ0G9PnUAKX46D49h6GtkXfPZi > O+Dz7vPxBcyoRXqQm5nn86tbTdBVPjknpw3uIuXEUQmyoUEQhu/9jBJRrPx3cGU= > =ObyE > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/53cd42cf.7060...@debian.org > -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405989723.6701.144176417.7323c...@webmail.messagingengine.com
Re: Introducing vcswatch
On Sat, Jul 5, 2014, at 08:19, Andreas Tille wrote: > Hi Christoph, > > On Fri, Jul 04, 2014 at 11:04:33PM +0200, Christoph Berg wrote: > > > > https://qa.debian.org/cgi-bin/vcswatch > > Cool! I wonder whether you could add a field where you can seek for > package maintainer address (since if I can only seek for a package it > does not make much of a difference to look into the repository itself.) +1 but do that for Uploaders as well... Or integrate vcswatch into http://qa.debian.org/developer.php?login= Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1406793456.1808893.147593050.37846...@webmail.messagingengine.com
Re: First steps towards source-only uploads
On Fri, Aug 1, 2014, at 09:54, Michael Tokarev wrote: > 01.08.2014 11:37, Ansgar Burchardt wrote: > > Hi, > > > > as a first step towards source-only uploads, the archive will now accept > > source-only uploads provided the following conditions are met: > > > > * The source package is not NEW and does not build NEW binaries. > > * Architecture-independent (arch:all) packages must be included in > >uploads. > > Is there an easy way to produce such uploads? Build binary packages as usual, but sed-out _(amd64|i386).deb from resulting .changes before signing it. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1406880972.2158370.147993346.05a1a...@webmail.messagingengine.com
Re: [CTTE #717076] Default libjpeg implementation in Debian
Hey all, tech-ctte bug was opened last July 2013. Bill you had a year to provide an evidence or arguments why we should not switch away from jpeg8. You have refused to take part in the discussion, and yet now after the decision has been made, you come with backhand arguments with no references... To remind you what you said at that time: On Wed, 24 Jul 2013, Bill Allombert wrote: > I am not going to answer such drivel. You will have to contend with what I > sent to debian-devel. Show a bit of respect. On Sat, Aug 9, 2014, at 15:03, Henrique de Moraes Holschuh wrote: > On Sat, 09 Aug 2014, Bill Allombert wrote: > > > 3. libjpeg8 adds new features to the JPEG image format. These have > > > however been rejected from the ISO standard, and their > > > contributions to image quality and compression appear to be widely > > > disputed. > > > > This is not really relevant. What is relevant, however, is that nobody is > > disputing that libjpeg8 produce higher quality images than libjpeg62 when > > decompressing standard JPEG images. > > If this is true, it is a concern: at least the bitmap editors and image > processing utilities (gimp, imagemagick, etc) would regress on output > quality. > > Are there any examples of this output difference? And I do mean between > IJG libjpeg and libjpeg-turbo, not IJG libjpeg62 and IJG libjpeg8/9. Yes, citation needed. Otherwise those are just empty claims. > > Beside it has been reported that libjpeg-turbo do not play well with > > valgrind. Again, ctation needed. > This could also be a serious problem. Any lib that impairs the use of > valgrind-style tools is going to be trouble as they interfere with > valgrind runs on the applications/libraries linked to them. Searching for "libjpeg-turbo valgrind" shows: https://bugzilla.redhat.com/show_bug.cgi?id=730364 and referenced: fixed-closed upstream http://sourceforge.net/p/libjpeg-turbo/bugs/33/ Also I found several reports where users are able to run valgrind just fine. > Should the two points above be pressing concerns that cannot be easily > addressed by changes in libjpeg-turbo in a short timeframe, could we keep > both libraries in light of this new information? Release team has already expresses that they do not wish to have two libjpeg libraries in stable release. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1407745746.1370837.151317905.03aae...@webmail.messagingengine.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Mon, Aug 11, 2014, at 12:23, Anthony F McInerney wrote: Can we now move on to choosing a DE? Nope, we still don't have enough anecdotic evidence and trolling yet[1]... O. 1. Not target at you, just general observation of d-d... -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: First steps towards source-only uploads
On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote: > And any package that cannot build arch:all on a released arch for which > it produces binary packages potentially has a FTBFS bug, anyway, which > can be reported by any interested parties. Exceptions would be arches > that are too resource-constrained to build it in the first place. I have encountered a situation where the FTBFS bug was caused by segfault in other package. This has forced me to split opendnssec-doc to arch:all package (which was good thing anyway), so there are cases where you want to build the arch:all on most stable and fastest arch. Could we just pick amd64 and be done? :) Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408111452.213427.153089893.5c8a7...@webmail.messagingengine.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote: > On 08/15/2014 11:53 PM, The Wanderer wrote: > > It's also something the Linux kernel is still doing, with apparent > > success. > > Yes, the Linux kernel is a successful project. Does this mean using a > list for reviewing patches is a good thing? No! The workflow with a list > is simply horrible. Using git-review and gerrit is so much better. JFTR we have dropped gerrit in favour of gitlab (or github or bitbucket) pull requests since gerrit was too cumbersome to use. So, no, gerrit is no miraculous cure-all. However I think that establishing a procedure that every patch has to be submitted as a pull request and this pull request needs to be acked by other developer is a good practice that can be adapted to any project (the only exception being one-man shows). Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408437453.1734025.154279197.7c841...@webmail.messagingengine.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote: > The problem, however, is that taking security seriously, while possibly > necessary, is not sufficient. I'm glad that FFmpeg takes security > seriously, but what FFmpeg needs is to *have fewer security bugs*. JFTR the Coverity Scan results for ffmpeg looks promising: https://scan.coverity.com/projects/54 I am not saying that we should base our decisions on Coverity Scan[1] results, but this is one more metric that could help to weight the decision to one or other direction. (Also this is not an advice what should ffmpeg do...) >From the security viewpoint, I would be also interested if ffmpeg has tests and what is current code coverage. That could help avoiding regressions when doing security updates. 1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck (and other metrics like Cyclomatic complexity) Cheers, Ondrej P.S.: libav doesn't seem to be using Coverity Scan actively: https://scan.coverity.com/projects/106 (last scan was 4 months ago) -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408438231.1736622.154282345.60f00...@webmail.messagingengine.com
Re: Reintroducing FFmpeg to Debian
Norbert, On Wed, Aug 20, 2014, at 11:43, Norbert Preining wrote: [...] > The base line of this discussion for me is: [...] > * from my point of view, it would be best to throw out Av immediately > and switch to ffmpeg before release. It would be great if you didn't send your personal judgements to the list. We have seen too much of that in past days, we don't need to add more. And the most important thing - we don't do decisions based on who is who[1] and how do they behave to each other, but based on technical merits. And while I agree that we should switch to ffmpeg for jessie, it's based solely on the QA, code features and level of usage of ffmpeg library users that move my opinion towards the ffmpeg side. 1. With the exception of clearly hostile upstream which is not the case here. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408528712.2111226.154729989.2772d...@webmail.messagingengine.com
Re: Reverting to GNOME for jessie's default desktop
Hey, On Thu, Aug 21, 2014, at 17:56, Paul van der Vlis wrote: > Hello, > For some hardware there are no 3D drivers. E.g. in server-boards there > are most of the time very poor GPU's. I don't use a graphical > environment on servers myself most of the time, but I think many people > do. We don't have to target those (or any other weird setup) anyway with *default* desktop environment. If anyone run graphical environment on servers I am quite confident they can install non-default DE on the machine. Please, let's drop the mindset where default DE has to fit all. That's not going to happen anyway. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408954684.4046835.156367981.2a372...@webmail.messagingengine.com
Re: internationalized domain name (IDN) in Debian
Hi Noël, could you please disable Greylisting on the echo@köthe.de email? It makes the testing more difficult than it needs to be. Cheers, Ondrej On Sun, Aug 24, 2014, at 19:55, Noël Köthe wrote: > Hello, > > I'm collecting the status of IDN in Debian on > https://wiki.debian.org/IDN > > Summary: webbrowser support it in general but email clients still lack > the support of it. > > If you could test your not listed client(s) with an IDN domain would > help. > > Thank you. > > > -- > Noël Köthe > Debian GNU/Linux, www.debian.org > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408978503.4138720.156487781.4314e...@webmail.messagingengine.com
Re: First steps towards source-only uploads
On Wed, Aug 13, 2014, at 14:02, Guillem Jover wrote: > Hi! > > On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote: > > #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs > > This is now available in dpkg 1.17.11, and as mentioned on the bug > report, you can use it in at least these ways: > > # Source and arch-indep only build, will fail if the package does > # not produce any arch-indep binary, in which case you'd use -S. > $ dpkg-buildpackage -g > > or > > # Full build, but filter the generated .changes file to only inlcude > # source and possibly arch-indep binaries, will not fail if the > # latter are missing. > $ dpkg-buildpackage --changes-option=-g Any success of passing this to git-pbuilder? I had to modify pdebuild to not pass $DEBBUILDOPTS to dpkg-buildpackage invocation and only pass those options to the build inside of pbuilder. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409041723.583972.156795125.3f34c...@webmail.messagingengine.com
logcheck rules for systemd
Hey all, I have started to collect logcheck/ignore.d.server/systemd rules for systemd: https://wiki.debian.org/systemd/logcheck I think it might be a good idea to fine tune the rules before submitting them for inclusion into logcheck default ruleset... O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409225828.1356518.157744133.5c919...@webmail.messagingengine.com
Re: logcheck rules for systemd
On Thu, Aug 28, 2014, at 13:52, Chris Boot wrote: > On 28/08/14 12:37, Ondřej Surý wrote: > > Hey all, > > > > I have started to collect logcheck/ignore.d.server/systemd rules for > > systemd: > > > > https://wiki.debian.org/systemd/logcheck > > > > I think it might be a good idea to fine tune the rules before submitting > > them > > for inclusion into logcheck default ruleset... > > Hi Ondřej, > > You may find it easier to bundle the logcheck rules with systemd itself > rather than as part of logcheck-database. I don't care - that's up to the respective maintainers to decide. But generally I concur with Michael - the systemd is a default init and we probably don't want to ship the logcheck file from withing default init package, so logcheck-database might be a better place. I will be happy with collaboratively updated wiki page for the moment. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409229013.1369405.157762653.1513a...@webmail.messagingengine.com
Re: Base binary packages using xz instead of gzip
On Tue, Sep 2, 2014, at 10:24, Marco d'Itri wrote: > I know, but if systems on which xz-utils is not easily available really > exist then the interested parties could replace it with xzdec which is > small and statically linked. Is there such system or are we having an academic debate again? Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409650489.3678407.162594529.173b5...@webmail.messagingengine.com
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On Thu, Sep 4, 2014, at 10:58, Ansgar Burchardt wrote: > What about a lintian warning (error, whatever) instead? I support that... lintian warning for non-default compression lintian (auto-reject) error for > 7 O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409823651.238275.163523005.60fa0...@webmail.messagingengine.com
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Tue, Sep 9, 2014, at 09:11, Samuel Thibault wrote: > > You cannot have an MTA without configuring it, and nobody even tried to > > implement auto-migration of the old default mailer's configuration to the > > new one. Also, we didn't switch to a different default mailer because the > > new one offered a heap of features and infrastructure which the other > > lacked. None of this applies to systemd. > > This does apply to systemd too. > > When I got "upgraded" to systemd on july, my system was completely > misbehaving for several reasons related to my configuration: > > - I had an ISO mount in my fstab, whose file didn't exist any more, > sysvinit never complained about it, systemd just stopped at boot. > - I had several bind mounts, forming loops, which has never been a > problem for sysvinit, but it made systemd take ages to boot & shutdown > because it'd crazily bring thousands of lines in /proc/mounts, details > in #755674. > - I had tweaks in /etc/inittab to get the gettys earlier than > daemon starts, in case those get stuck etc., this does not work any > more with systemd. > - I had tweaks in /etc/inittab to have more gettys on the text console, > this does not work with systemd any more. > - I had tweaks in /etc/inittab to shutdown instead of reboot when I > press ctrl-alt-backspace, this does not work with systemd any more. And you are saying that you can do all those tweaks, but you cannot pin systemd-sysv to not install? Let's just document the way how to prevent systemd-sysv to install in release notes and switch the default init to systemd as Debian maintainers who would like to keep their sanity would do. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410256058.2294779.165322957.7f81e...@webmail.messagingengine.com
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Tue, Sep 9, 2014, at 11:54, Samuel Thibault wrote: > Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit : > > And you are saying that you can do all those tweaks, but you cannot > > pin systemd-sysv to not install? > > No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I > would have gotten all these changes all of a sudden without asking for > them. That can be pretty bad for the serial console access. Also broken libdb upgrade in hamm (I think) broke my system beyond repair... It's testing (and unstable), it's expected to have some undocumented breakages. That's the sole reason to have the testing and unstable in first place. To find the problems, fix them and if that's not possible (for various reasons[*]) then we should document that in the release notes. > And I'm saying that I don't think this is an isolated case, And I'm saying that all we have is anecdotal evidence and we all know what we step into when we run our systems on jessie or sid. So please fill a bug for every breakage you will encounter, so it can be either fixed or documented. > I believe most our users prefer to stay with sysvinit when upgrading from > wheezy And I believe that most our users don't care. But I as a maintainer and operator of several daemons I really do care to have as most unified environment for debugging the problems. Ondrej * - f.e. I am quite sure I broke some php5-cgi deployments by enforcing the more strict security... -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410261048.2317496.165348985.0bb28...@webmail.messagingengine.com
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Tue, Sep 9, 2014, at 15:14, Mathieu Parent wrote: > 4) Upgrade to systemd silently without asking the user AND add a grub > entry to use old init I like this approach very much since it's least intrusive to the upgrade process, but provides a emergency fallback in default installation. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410272574.2370157.165422265.73c93...@webmail.messagingengine.com
Re: Seeking help with OpenVPN scripts and systemd
Alberto, I think you might be too deep in sysvinit paradigms how we did (hack) things before. I personally think that mapping the functionality 1:1 is a wrong approach because you will end up in some impossible scenario in the end anyway. I think the better way how to convert openvpn to systemd would be: to convert all AUTOSTART= VPNs to openvpn@ enabled instances and all other to disabled openvpn@ instances at upgrade time. I guess there might be a need to some more subtle tweaking, but I think you can autoconvert most of the old configuration this way. So I would suggest to write down all current use cases and write down a solution for sysvinit and systemd for each of the use cases. The mapping "problem" -> "solution" could be more helpful than "current solution" -> "new solution". I don't think it's needed to support "I drop new configuration" and it get's picked automatically, but if you think it's needed, I think you can prepare openvpn.script that would: a) make a note which openvpn@ instances are autoconfigured (probably by having openvpn-auto@.service) b) walk through all AUTOSTART configurations and instantiate openvpn-auto@.service for each new configuration (not already managed by openvpn@.service c) when configuration disappears remove the auto-enabled openvpn-auto@.service In that way you will have: openvpn@.service # manually managed openvpn-auto@.service # automanaged openvpn.service # service script to manage opevpn-auto@.service(s) How does that sounds? Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410350460.596384.165821573.37360...@webmail.messagingengine.com
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, Sep 10, 2014, at 04:12, Ben Hutchings wrote: > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > ]] Carlos Alberto Lopez Perez > > > > > > > But if you don't (Is not uncommon to have servers on remote locations > > > > that are only accessible via ssh) and the machine don't boots properly > > > > you can find yourself in trouble. > > > > > > Then surely you test the upgrade before making it live, using kvm > > > -snapshot or similar functionality? > > > > This is simply not possible in physical live, productions servers on remote > > CPDs. > > In that case you test on your staging server first... Or at least be present at the facility when you do release to release+1 upgrade[+]. I have done really weird stuff with my non-production systems (like cross-upgrading from Ubuntu devel to Debian stable), but for production system you can broke your system even on kernel upgrades[*], so nothing here is init system specific. * - we had to carry a custom kernel at the time when Ubuntu backported only a part of a patch and that broke a hw raid disk enumeration... + - And if you really can't be there or have a KVM or serial console, you can always tweak the system to your likings before you do the reboot. People, this is nothing new, please don't try to pretend it is just because it's a init system. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410354585.617786.165847321.72a52...@webmail.messagingengine.com
MBF: libjpeg-turbo transition started (if you depend on libjpeg8-dev please read)
Hi, I will be filling bug reports on packages explicitly depending on libjpeg8-dev. The text of bug report can be found here: https://wiki.debian.org/LJTTransition I have already rebuild several packages and it mostly looks OK, the results of the rebuild can be found at the same place in the wiki. Affected maintainers: Agustin Henze crrcsim Alastair McKinstry libterralib (U) ncl Alessandro Ghedini mpv (U) Alessio Treglia harvid (U) Andreas Metzler sdop Andreas Rönnquist allegro5 (U) Andy Hawkins flactag (U) Axel Beckert dillo Bas Couwenberg libgaiagraphics (U) Bernd Zeimetz rawstudio (U) Bertrand Marc libextractor Bruno "Fuddl" Kleinert ioquake3 (U) Damien Raude-Morvan openjdk-6 (U) openjdk-7 (U) openjdk-8 (U) Daniel Pocock flactag Daniel Walrond wv Darren Salt xine-ui David Paleino libgaiagraphics (U) Debian Erlang Packagers wings3d Debian FlightGear Crew flightgear simgear Debian Games Team allegro5 aseprite freeorion ioquake3 Debian GIS Project libgaiagraphics Debian GIS Team libterralib Debian Krap Maintainers libindi Debian Multimedia Maintainers harvid libquicktime mpv Debian Perl Group libalien-sdl-perl Debian PhotoTools Maintainers rawstudio Debian Science Maintainers openctm Debian Shotwell Maintainers libraw Debian Squeak Team squeak-vm Dmitry Smirnov abiword Dmitry Smirnov wv (U) Dominique Dumont libalien-sdl-perl (U) Eugene V. Lyubimkin fbreader Georges Khaznadar gtkextra Giovanni Mascellani mandelbulber Guenter Geiger (Debian/GNU) gem (U) Hubert Chathi ufraw IOhannes m zmölnig gem (U) Jari Aalto jpegjudge Jonas Smedegaard squeak-vm (U) José L. Redrejo Rodríguez squeak-vm (U) Lennart Weller nvidia-texture-tools Loic Minier libquicktime (U) Markus Koschany freeorion (U) Markus Wanner flightgear (U) simgear (U) Matteo F. Vescovi libraw (U) Matthias Klose pillow Matthias Klose openjdk-6 (U) openjdk-7 (U) openjdk-8 (U) Maximiliano Curia libindi (U) OpenJDK Team openjdk-6 openjdk-7 openjdk-8 Ove Kaaven flightgear (U) simgear (U) Paul Brossier gem Petter Reinholdtsen libterralib (U) Pino Toscano libindi (U) Reinhard Tartler libquicktime (U) mpv (U) Robin Gareus harvid (U) Roland Stigge jasper Sergei Golovan wings3d (U) Simon McVittie ioquake3 (U) Teemu Ikonen openctm (U) Tobias Hansen allegro5 (U) aseprite (U) Torsten Werner openjdk-6 (U) Євгеній Мещеряков swi-prolog Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411997061.2736076.172953677.7ac72...@webmail.messagingengine.com
Re: Your behaviour on Debian lists
On Tue, Oct 7, 2014, at 18:00, Cyril Brulebois wrote: > Thorsten Glaser (2014-10-07): > > Yeah, but Md is an arsehole anyway and requires printf to be > > a /bin/sh builtin instead of just adding /usr/bin to $PATH, > > especially now that the initrd mounts /usr already anyway, > > and CTTE decided to rather offend me than Md because he is > > maintainer of the more important packages, or those where > > it’s hard to find someone else for. > > I can't believe I'm reading this. > > Such a toxic behaviour is very much not welcome on Debian lists, or > anywhere within the Debian project. > > Please apologize and never do that again. > > But since that isn't the first time (see May 2014), and since you don't > seem to care about your fellow developers, it might be worth considering > leaving the project entirely. As I have witnessed several such behaviour myself on the debian lists, and tg is only person I do have in my killfile, I am strongly seconding this. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412702339.4184912.176218889.3758c...@webmail.messagingengine.com
Re: Remember when men were men and wrote their own init scripts? =)
On Mon, Oct 20, 2014, at 19:34, Martinx - ジェームズ wrote: > I really do NOT want to start a flame war, I know that you guys are tired about this "init" subject appearing over and over... No, you wanted to add more oil on existing flamewars and you know it. If you don't want to start the flamewars, you should refrain sending such emails, please. > But, my turn...:-P No, please don't. It's neither useful, productive nor funny. Cheers, Ondrej
Re: Remember when men were men and wrote their own init scripts? =)
If you have the unresistible urge to act, then go fix a bug. Or help with triaging the bugs - finding reproducible test case also helps. Turn that urge into something productive. Flaming in the mailing list isn't helpful, it's exactly the oposite. Cheers, Ondrej On Mon, Oct 20, 2014, at 21:00, Martinx - ジェームズ wrote: But I need to act (at least, say something) to preserve our distro and I cannot remain in silence. Sorry... This isn't intended to be fun. Cheers! Thiago On 20 October 2014 16:57, Ondřej Surý <[1]ond...@sury.org> wrote: On Mon, Oct 20, 2014, at 19:34, Martinx - ジェームズ wrote: > I really do NOT want to start a flame war, I know that you guys are tired about this "init" subject appearing over and over... No, you wanted to add more oil on existing flamewars and you know it. If you don't want to start the flamewars, you should refrain sending such emails, please. > But, my turn...:-P No, please don't. It's neither useful, productive nor funny. Cheers, Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server References 1. mailto:ond...@sury.org
Re: GPL-3 & openssl: provide a -nossl variant for a library
Why just not add a license exception as many other GPL projects do? Something like (copied from our Knot DNS d/copyright): In addition, as a special exception, the author of this program gives permission to link the code of its release with the OpenSSL project's "OpenSSL" library (or with modified versions of it that use the same license as the "OpenSSL" library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than "OpenSSL". If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. O. On Tue, Oct 21, 2014, at 15:58, Michael Fladischer wrote: > Hi, > > I'm the maintainer for src:librabbitmq and the binary package > librabbitmq1 is linked against libssl1.0.0 (OpenSSL). > > Now I was approached by Julien Kerihuel from the OpenChange project, who > release their software under the terms of GPL-3, asking if I could > provide an alternative to the OpenSSL-linked library so they can use it > without causing a license conflict. > > Sadly librabbitmq only supports OpenSSL, there is rudimentary support > for GnuTLS but it seems to be severely broken at the moment. > > Considering this, is it a good idea to provide a librabbitmq1-nossl > binary package that was built without OpenSSL while still having > librabbitmq1 with OpenSSL-support? > > I could not find another package that does this, so I assume that a > similar situation did not yet occur (unlikely) or that there where > arguments against providing such a package variant. > > Cheers, > -- > Michael Fladischer > Fladi.at > > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413902487.597746.181561769.5fe55...@webmail.messagingengine.com
Re: piece of mind
On Tue, Oct 21, 2014, at 16:13, Norbert Preining wrote: > On Tue, 21 Oct 2014, Josselin Mouette wrote: > > not possible to split the system cgroups arbitrator from the process > > which starts services and sessions in cgroups. It is not possible to > > ensure the relation of a log to a service if you do not have awareness > > of how the service was launched. Et caetera. > > And surely that didn't work the last 20 years ... > > Only because the "Wanderer" is a troll, doesn't mean that everything > he says is wrong. Norbert, could you please stop your aggressive behaviour against other people on this list? Sadly, you are not very funny with these remarks. Thanks, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413902683.598952.181564081.0ddf4...@webmail.messagingengine.com
Bug#767890: ITP: python-getdns -- modern asynchronous DNS API (python bindings)
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-getdns Version : 0.2.0 Upstream Author : Verisign & NlNetLabs * URL : http://getdnsapi.org/ * License : BSD-3-clause Programming Lang: Python Description : modern asynchronous DNS API (python bindings) getdns is a modern asynchronous DNS API. It implements DNS entry points from a design developed and vetted by application developers, in an API specification edited by Paul Hoffman. With the development of this API, we intend to offer application developers a modernized and flexible way to access DNS security (DNSSEC) and other powerful new DNS features; a particular hope is to inspire application developers towards innovative security solutions in their applications. . This package contains pythong bindings for the library. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUV1CNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHcvcP/2ecDe7EJs/pUxGZIJp1aIn/ tzUfOZsxbaCueBi0LlDXwb00fm1FbR4eWlMupE+GIr+amp5EDZ3dpq3rH5WT0kDv 19kuUHliSTv8DV3EbzpYKvqzvyN0Ka8b4o3C9B8N97ETjmPXUZJGlfChmbUgAnY6 ZsnpxHydhV3LbcTNymSPckYGEOvEotQtzjHXcBQM7VG3NPrOkl5vY/Mxvr51T9ff uExF6EztwgWlW25MfC9Ux+WdqT9KzqYh1zXlz+6CrCZbb0J6gCxjAW58JyDbGm39 T/bviEw+8HE3btT+EOXOMP+j5lpueQNafo4VpNK0cNjFPImP6NH1CK70s+klxH7j aJxS+nJf4xuZQnbZ9k46UXyQvNcS18DItxsrkJ0izrqtF3F/X1qdZV8SBnb/w7Em GKtcSCb0O2vJoCsCFhsLVzlMP5KgkwKCSqU0yOOigjTiPrVV6QqTiU4B75aSCvOM GBMlc0DkQ5IHBea2cyN4O66fe7zDYnOcwF29ZnKLDaZ3LiXxRVWm6PrVQzE30l6l oYzxgwmMJUsG+bu2KxpGtygtERrIe8Xmkw6yhVqpOnZeYc+bMi61P0lKkeVGn2NO FmVGJSPBZu6y/ndX6nF9b/Q2q8J3OH2tnIQcs/iShqMABAGEH/Ukf5VqI7ghdX88 qsXS9Jg0q7qpfatBiwu/ =SyPq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141103095317.7374.22940.report...@lettie.nic.cz
dpkg-maintscript-helper symlink_to_dir and dir_to_symlink without Pre-Depends:
Hi, I think it would be worth doing a jessie-wide test on packages using dpkg-maintscript-helper without Pre-Depends. There was a lot of late fixes[0] for any->all dh_linkdocs. As this breaks upgrades it needs to be mass bug filled and fixed before release. Not sure how to proceed[1] from there hence this mail. 0. I was involved in some unfortunately and I confess for probably creating few of those bugs. 1. lintian error and lintian rerun on jessie? Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415121568.2946330.186988365.5c12e...@webmail.messagingengine.com
Re: dpkg-maintscript-helper symlink_to_dir and dir_to_symlink without Pre-Depends:
On Tue, Nov 4, 2014, at 18:23, Holger Levsen wrote: > Hi Ondřej, > > On Dienstag, 4. November 2014, Ondřej Surý wrote: > > I think it would be worth doing a jessie-wide test on packages using > > dpkg-maintscript-helper without Pre-Depends. There was a lot of late > > fixes[0] for any->all dh_linkdocs. As this breaks upgrades it needs to > > be mass bug filled and fixed before release. > > https://piuparts.debian.org/wheezy2jessie/ tests upgrades for all > packages, is > there any string I can grep for in the logs? I think this: dpkg-maintscript-helper: error: command symlink_to_dir is unknown Hint: upgrading dpkg to a newer version might help. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415121962.2947615.186993537.43ead...@webmail.messagingengine.com
Re: dpkg-maintscript-helper symlink_to_dir and dir_to_symlink without Pre-Depends:
On Tue, Nov 4, 2014, at 18:36, Jonas Smedegaard wrote:
> Quoting Holger Levsen (2014-11-04 18:23:11)
> > On Dienstag, 4. November 2014, Ondřej Surý wrote:
> >> I think it would be worth doing a jessie-wide test on packages using
> >> dpkg-maintscript-helper without Pre-Depends. There was a lot of late
> >> fixes[0] for any->all dh_linkdocs. As this breaks upgrades it needs
> >> to be mass bug filled and fixed before release.
> >
> > https://piuparts.debian.org/wheezy2jessie/ tests upgrades for all
> > packages, is there any string I can grep for in the logs?
>
> If possible "shuffle" the order of packages getting upgraded.
>
> Or specifically for this one: Hold back upgrade of dpkg to reveal all
> those packages needing the Jessie version but not stating it explicitly.
I think this is too much work for little gain.
Walking through the packages and greping them for
"(symlink|dir)_to_(dir|symlink)" in {pre,post}{inst,rm} + greping
"Pre-Depends: dpkg (>= 1.17.5)" in d/control is less work.
O.
--
Ondřej Surý
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1415123332.2952423.187002313.0f628...@webmail.messagingengine.com
Re: Pre-Depends: init-system-helpers
On Tue, Nov 18, 2014, at 10:25, Simon McVittie wrote: > We already have a way to disable services, which knows about sysvinit, > systemd and Upstart despite its unfortunate name (update-rc.d). Perhaps we could provide an alternative name to this: f.e. init-maintscript-helper would reflect the intended usage from maintainer scripts? (As we have dpkg-m-h, php5-m-h, apache2-m-h...). And slowly migrate the scripts to use new name, e.g. lintian warning for jessie+1. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416325649.3652366.192466549.6fbe6...@webmail.messagingengine.com
