Re: bind9 shipping outdated root hint file (etc.)
Robert Edmonds: The only package in the archive that I know of that has a seriously deficient set of root hints is djbdns; it has 11/13 of the current set of IPv4 root server addresses, and 0/13 IPv6 root server addresses. (However, I don't believe the 'djbdns' binary package ships with the IPv6 patch applied.) What you know is somewhat wrong. dnscache does not use a "hints" mechanism. It uses a list of the actual servers. People patched this list *years ago*. P. J. Pandit, publisher of ndjbdns for Fedora, updated xyr published copy of the list in 2013. I had an updated list in the very first published version of djbwares. * http://jdebp.eu./Softwares/djbwares/ I later fixed ip6.arpa and removed the egregiously outdated RBL list, too. * https://lists.debian.org/debian-user/2017/03/msg01307.html But that is as nothing. I *first* patched this list almost *a decade and a half ago*. * http://jdebp.eu./FGA/djbdns-problems.html#wrong-icann-root Debian's list in its djbdns package is actually a private Debian one that is substituted by Debian in place of the one from the djbdns itself, named debian/dnsroots.global . Debian needs to catch up.
Bug#872622: ITP: bandage -- Bioinformatics Application for Navigating De novo Assembly Graphs Easily
Package: wnpp Severity: wishlist Owner: Debian Med * Package name: bandage Version : 0.8.1 Upstream Author : Ryan R. Wick * URL : https://github.com/rrwick/Bandage/ * License : GPL3 Programming Lang: C++ Description : Bioinformatics Application for Navigating De novo Assembly Graphs Easily Bandage is a GUI program that allows users to interact with the assembly graphs made by de novo assemblers such as Velvet, SPAdes, MEGAHIT and others. De novo assembly graphs contain not only assembled contigs but also the connections between those contigs, which were previously not easily accessible. Bandage visualises assembly graphs, with connections, using graph layout algorithms. Nodes in the drawn graph, which represent contigs, can be automatically labelled with their ID, length or depth. Users can interact with the graph by moving, labelling and colouring nodes. Sequence information can also be extracted directly from the graph viewer. By displaying connections between contigs, Bandage opens up new possibilities for analysing and improving de novo assemblies that are not possible by looking at contigs alone. More information and download links are on the Bandage website: rrwick.github.io/Bandage The package is relevant to the field of genome assembly and will be maintained by the Debian Med team.
Package Managers All the Way Down
Howdy all, I am catching up with the Linux.conf.au 2017 presentations, and have just watched “Package Managers All the Way Down” by Kristoffer Grönlund https://archive.org/details/lca2017-Package_Managers_all_the_way_down>, also discussed at LWN https://lwn.net/Articles/712318/>. The problems Kristoffer covered are ones that affect the Debian Project a lot, and his call for solutions is interesting. Are there any DebConf 2017 presentations or working groups that are tackling this? -- \“I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _o__) | Ben Finney
Re: OpenSSL disables TLS 1.0 and 1.1
Hi, On Sat, 12 Aug 2017 14:16:25 +0200 Tollef Fog Heen wrote: > While I think we might want to ship buster with TLS 1.0 available, I > think running with it disabled for parts of the development cycle is > very useful, since it exposes bugs we have in packages that will use > that version out of the box (isync being referred to elsethread). > Finding and fixing those bugs is good. Seconded in Tollef's opinion. - This affects *only* testing and unstable, not stable release (yet). So, most of users are not influenced. - We *can* revert it before Buster release if it would be too much wrong impact for us. - This is done in early timing for Buster Cycle. We have enough time to see what is going on. So, please file bugs with real world precise examples against affected packages, and let's fix it first. And, if it will not be reverted, maybe we can provide alternatives such as openssh-client-ssh1 does. > Package: openssh-client-ssh1 > (snip) > Description: secure shell (SSH) client for legacy SSH1 protocol > (snip) > This package provides the ssh1 and scp1 clients and the ssh-keygen1 > utility, all built with support for the legacy SSH1 protocol. This > protocol is obsolete and should not normally be used, but in some cases > there may be no alternative way to connect to outdated servers. > . > In some countries it may be illegal to use any encryption at all > without a special permit. > ... -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Bug#872638: ITP: node-buble -- A fast ES2015 compiler for Node.js
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-buble Version : 0.15.2 Upstream Author : Rich Harris * URL : https://gitlab.com/Rich-Harris/buble#README * License : Expat Programming Lang: JavaScript Description : A fast ES2015 compiler for Node.js Bublé is a blazing-fast ES2015 compiler : it will turn that code into Javascript that can run in today's environments. Notice that not all of ES6 are supported, either because they give size or performance issues or because they can't be transpiled to ES5. . Node.js is an event-based server-side JavaScript engine. This package is a dependency of rollup-plugin-buble, which is a dependency of rollup, which I desperately need to update quite a few of my packages. Cheers, Snark on #debian-js
Re: Whether remotely running software is considered "software" for Debian.
On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote: > Consider the following: unrar-nonfree contains some software which is non-free > and can therefore not be in main. The reason we don't put it in main is that > we want users who care about freedom to not even see this software. Agreed? Ex falso quodlibet? Archive areas serve a purpose of grouping and indeed everything that is not main is not part of the distribution. But I don't think the purpose of the separate areas is to hide anything. > Now what would be the result of moving this non-free part to a network server? > In terms of freedom there are no benefits to this. The user is still using > the > non-free software, but now they can also be tracked by the server admin, and > they can't use a debugger to hack it, should they want to. So it is 100% bad > for them. > > However, according to your logic, because it is no longer running on your own > cpu, this change would allow unrar-nonfree to go into main. You do agree that > this is not a sensible result of making software worse, right? I think such a package would fail other sanity checks (the existence of a free implementation of the algorithm being one of them - there's no right to be included in the distribution). In my view a more interesting thought example would be DRM: What about an DFSG-compliant module that communicates with a remote license server returning encryption keys. There's not an inherent need for a DRM module to be Closed Source, given that the Linux platform does not offer any security guarantees against Reverse Engineering and leaking the key material anyway. Would that be acceptable for main? Would the existence of a free server implementation change the opinion, even though it likely would not help the media files you intend to view? At the same time: As long as programs are talking to an API - even if RE'ed - and doing so lets users accomplish their tasks at hand and the programs in question are completely DFSG-compliant, I think we should carry them in main if they provide a benefit. We have lots of historic precedent in this area. What are we going to do otherwise? Proof for every program that there's a way to use them either entirely disconnected or against a free server/device? What about proprietary hardware connected over, say, USB? Would we remove the corresponding drivers from the kernel? Where would we stop on this slippery slope? >> The language in Policy §2.2 does not relate to any program's purpose at >> all. > What do you think the purpose of policy is, if not to ensure that our software > gives freedom to our users? The agreed-upon baseline is the DFSG which does not offer this premise you interpret as a guarantee, though. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#872656: ITP: node-unicode-canonical-property-names-ecmascript --
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-unicode-canonical-property-names-ecmascript Version : 1.0.2 Upstream Author : Mathias Bynens (https://mathiasbynens.be/) * URL : https://github.com/mathiasbynens/unicode-canonical-property-names-ecmascript * License : Expat Programming Lang: JavaScript Description : Unicode property names supported in ES RegExp in Node.js This module provides the set of canonical Unicode property names supported in ECMAScript RegExp property escapes. . Node.js is an event-based server-side JavaScript engine. It is a depends of a depends of a depends ... of a depends of rollup, which is my target because I need it to maintain properly a few of my existing packages. Cheers, Snark on #debian-js
Bug#872655: ITP: node-unicode-canonical-property-names-ecmascript --
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-unicode-canonical-property-names-ecmascript Version : 1.0.2 Upstream Author : Mathias Bynens (https://mathiasbynens.be/) * URL : https://github.com/mathiasbynens/unicode-canonical-property-names-ecmascript * License : Expat Programming Lang: JavaScript Description : Unicode property names supported in ES RegExp in Node.js This module provides the set of canonical Unicode property names supported in ECMAScript RegExp property escapes. . Node.js is an event-based server-side JavaScript engine. It is a depends of a depends of a depends ... of a depends of rollup, which is my target because I need it to maintain properly a few of my existing packages. Cheers, Snark on #debian-js
Bug#872659: ITP: node-unicode-property-aliases-ecmascript -- Unicode property aliases mapping for property names in Node.js
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-unicode-property-aliases-ecmascript Version : 1.0.3 Upstream Author : Mathias Bynens (https://mathiasbynens.be/) * URL : https://github.com/mathiasbynens/unicode-property-aliases-ecmascript * License : Expat Programming Lang: JavaScript Description : Unicode property aliases mapping for property names in Node.js This modules provides unicode property alias mappings in JavaScript format for property names that are supported in ECMAScript RegExp property escapes. . Node.js is an event-based server-side JavaScript engine. It is a depend of ... of a depend of rollup, which I need to properly maintain a few of my existing packages. Snark on #debian-js
Summary of the Debian web team BoF at DC17
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the web team BoF session in Montréal. Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] We had a conversation about some of the issues facing the web team. Initial Agenda -- 1. Design work 2. Migration from CVS 3. Content Design Work --- People continue to appear on debian-...@lists.debian.org either complaining or offering re-designs. There are thousands of pages, it's not just a case of fixing the front page or simply tweaking CSS. If we're going to make changes, we need continued maintenance, not just short-term contributors. We have multiple people working on design already, but we're not following through and making many changes. Why? How can we make a difference? We should be looking at mockups for designs - it's difficult to evaluate things without that. CVS continues to be a barrier (more later). It's very difficult to do "radical" things, and this will put people off. webwml may also be putting people off. If we look into new designs / VCS / backends, it's *imperative* that we don't lose our translations too - they're critically important. We should also discuss what part of our website is targeted for which kind of visitors? Migration from CVS -- CVS is extremely difficult to do radical things (like renaming or deleting files!) There are differing opinions about how painful CVS is, but maybe some people are just too used to it and its limitations? Steve used to be a CVS expert, but recently just working on making modifications to a small section of the website was effectively stalled due to the pain of using CVS. We believe it may be dissuading others from helping, and we should do something about that. We know that some people are already running their own CVS<->git conversions and/or gateways right now. Osamu Aoki has scripts to help with this. Migrating from CVS to git is not a small task. The models are very different. Conversion to git does make for a very large repository, so even small changes need a full clone. Maybe we can use a git web services (github/gitlab/similar) to help with this and make it easier for people to make small changes. We don't want to put off potential contributors... ACTION: Steve is volunteering his own time to make a cvs->git migration happen this year. He'll need some help to understand more of the website setup, workflow etc. to make that happen. Does history matter? Is leaving history in CVS acceptable? Other options? After some discussion, it became clear that history preservation has been very useful at times. We came to a clear general consensus: keeping history is important and we should do that. Moving to git is, if anything, going to make using history even easier and therefore more likely. Archaeology in the website history is more common than most people realise! There will be more discussion needed around this area in the future, so we'll get periodic meetings to manage this process. We're not trying to do the whole thing in one big chunk. Expect to do multiple conversions as a learning process, with progress visible in the coming months. Help welcome, but it's also understood that we're struggling for person power to make this change and that's why we've not done this yet... We're also going to be asking for help from non-coding people during the migration process, to help with verifying things as we go. Workflows - How do people currently work on the website source? * For some people, check out pages, edit, build locally, commit * For other (larjona!), checkout, edit, commit, wait to see if it broke things * Translators: very different workflow that depends on how CVS works (commits are always incremental). There are scripts to help with this work, e.g. to mark if translated pages are out of date. This does not appear to be well documented anywhere, and this is a problem. We'll need to provide new docs for a new workflow, of course. There are pages describing how to work on the website, but lots of people are not finding them / reading them. That's not helping. Iain Learmonth apparently already started working on VCS-agnostic interfaces for the website scripts some time ago. Hopefully that should help us! Build process - The current process for building the website is very slow. What can we do to change that? It's been painful to do changes quickly, e.g. for changing version and announcing things on release days. There's an "update-parts" script on the main web server which can help with this. This has been improved lately: * not always pushing to mirrors straight away * not descending subdirectories * able to change just the top page "make" is slow for huge trees of subdirectories, and "cvs u
Bug#872693: ITP: node-unicode-tr51 -- Emoji data for Node.js
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-unicode-tr51 Version : 9.0.0 Upstream Author : Mathias Bynens (https://mathiasbynens.be/) * URL : https://mths.be/unicode-tr51 * License : Expat Programming Lang: JavaScript Description : Emoji data for Node.js This module provides the emoji data extracted from Unicode Technical Report #51. . Node.js is an event-based server-side JavaScript engine. Snark on #debian-js
