Re: opinions of snappy packages
On Jun 22, Lars Wirzenius wrote: > Given that snapd therefore seems to be, in practice, only usable by > Canonical's server, shouldn't the package be in contrib instead of > main? No: this was discussed the first time ~15 years ago IIRC for ICQ clients, and I do not think that anything has changed since then. -- ciao, Marco signature.asc Description: PGP signature
Bug#827978: ITP: libfastahack -- library for indexing and sequence extraction from FASTA files
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libfastahack Version : 0.0+20160309 Upstream Author : Erik Garrison * URL : https://github.com/ekg/fastahack * License : GPL Programming Lang: C++ Description : library for indexing and sequence extraction from FASTA files fastahack is a small application for indexing and extracting sequences and subsequences from FASTA files. The included Fasta.cpp library provides a FASTA reader and indexer that can be embedded into applications which would benefit from directly reading subsequences from FASTA files. The library automatically handles index file generation and use. . Features: * FASTA index (.fai) generation for FASTA files * Sequence extraction * Subsequence extraction * Sequence statistics (currently only entropy is provided) . Sequence and subsequence extraction use fseek64 to provide fastest-possible extraction without RAM-intensive file loading operations. This makes fastahack a useful tool for bioinformaticists who need to quickly extract many subsequences from a reference FASTA sequence. Remark: This package is a (pre-)pre-condition for some Debian Med target software (freebayes). It will be maintained at https://anonscm.debian.org/git/debian-med/libfastahack.git
Bug#827988: ITP: apertium-eu-en -- Apertium translation data for the Basque-English pair
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: apertium-eu-en
Version : 0.3.1
Upstream Author : 2008, Prompsit Language Engineering
2005-2008, Universitat d'Alacant (Transducens group)
2005-2007, IXA research group / IXA ikerkuntza taldea
2005-2007, TALP research group, Universitat Politècnica de
Catalunya
* URL : http://www.apertium.org/
* License : GPL-2
Programming Lang:
Description : Apertium translation data for the Basque-English pair
Data package providing Apertium language resources for translating
between the Basque and English languages.
- why is this package useful/relevant? is it a dependency for
another package? do you use it? if there are other packages
providing similar functionality, how does it compare?
A: Apertium Machine Translation data package for Basque-English language pair.
- how do you plan to maintain it? inside a packaging team
(check list at https://wiki.debian.org/Teams)? are you
looking for co-maintainers? do you need a sponsor?
A: debian-science team + upstream support.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: PGP signature
Bug#827992: ITP: phipack -- PHI test and other tests of recombination
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: phipack Version : 0.0.20160614 Upstream Author : David Bryant * URL : http://www.maths.otago.ac.nz/~dbryant/software/PhiPack.tar.gz * License : LGPL Programming Lang: C Description : PHI test and other tests of recombination The PhiPack software package implements a few tests for recombination and can produce refined incompatibility matrices as well. Specifically, PHIPack implements the 'Pairwise Homoplasy Index', Maximum Chi2 and the 'Neighbour Similarity Score'. The program Phi can be run to produce a p-value of recombination within a data set and the program profile can be run to determine regions exhibiting strongest evidence mosaicism. Remark: This package is a precondition for a Debian Med package (parsnp) and will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/phipack.git
Re: Keysigning via Video Conferencing
On Jun 23 2016, Ben Finney wrote: > Nikolaus Rath writes: > >> But how is your policy preventing this? > > If you're looking for claims of “This policy will absolutely guarantee > the malicious behaviour is impossible”, of course that's not a > believable claim and I don't expect anyone to seriously propose that. So > I don't know what you're fishing for. As I said in my other email, I am wondering if the extra burden is worth the gain in security. If everyone were to follow this procedure then the bar to becoming a Debian developer would be raised significantly. It seems to me that malicious activities are made a little harder, but for a well-meaning contributor it becomes a lot harder to get signatures. > What *is* claimed, by my reading, is that there is significantly more > reason to be confident in an identity that is stable over multiple > meetings, in the same social circles, with consequential social bonds > and interactions. Indeed, but I'm wondering why no one even seemes to consider if this gain in security is worth its price. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote: > As I said in my other email, I am wondering if the extra burden is worth > the gain in security. Is there an extra burden? Seems to me that it'd happen naturally if you contribute to Debian and as part of that interact with other Debian people. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Vcs-* and shared repos
Quoting Lars Wirzenius (2016-05-26 08:08:35) > On Wed, May 25, 2016 at 10:09:47PM +0200, Stefano Zacchiroli wrote: >> By also considering the fact that the "-d DIR" solution does not >> prevent to add a "-l" in the future, I think minimality wins here >> (hence my "Yay" to your proposal in separate mail). YMMV. > > My only concern here is the introduction of yet more ad hoc, custom > syntax into Debian data files. It's already annoying to parse such > files, and every addition makes things more annoying. I dream of an > alternative universe where Debian standardised on something like YAML > or JSON for its data files. RFC822 style files weren't a bad choice, > but I find them to be insufficiently extensible without pain. > > But in this reality, we've made our choice and we'll have to stick > with it, so go for it. I just noticed that SPDX - whom we already align with for naming of license shortnames - in their specifications include VCS URL format which covers paths and tags: > To specify a sub-path to a file or directory inside a repository use > the "#" delimiter: > PackageDownloadLocation: git://git.myproject.org/MyProject#src/somefile.c > PackageDownloadLocation: > git+https://git.myproject.org/MyProject#src/Class.java > To specify branch names, a commit hash or a tag name, use the "@" > delimiter: > PackageDownloadLocation: git://git.myproject.org/MyProject.git@master > PackageDownloadLocation: git+https://git.myproject.org/MyProject.git@v1.0 > PackageDownloadLocation: > git://git.myproject.org/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709 > Sub-paths and branch names or commit hash can be combined too: > PackageDownloadLocation: > git+https://git.myproject.org/MyProject.git@master#/src/MyClass.cpp > PackageDownloadLocation: > git+https://git.myproject.org/MyProject@da39a3ee5e6b4b0d3255bfef95601890afd80709#lib/variable.rb Found in section 3.7.5 of SPDX 2.0 PDF, located at http://spdx.org/SPDX-specifications/spdx-version-2.0 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Keysigning via Video Conferencing
* Nikolaus Rath , 2016-06-23, 09:23: I am wondering if the extra burden is worth the gain in security. If everyone were to follow this procedure then the bar to becoming a Debian developer would be raised significantly. As as data point, if everybody[0]'s key signing policy had been that establishing "social bonds" was a prerequisite, I would have almost certainly never become a DD. [0] And by "everybody" I mean that one developer that happened to live in the same big city as me. -- Jakub Wilk
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 07:30:42PM +0200, Jakub Wilk wrote: > As as data point, if everybody[0]'s key signing policy had been that > establishing "social bonds" was a prerequisite, I would have almost > certainly never become a DD. I would like to add another data point as a recent DM. The union of the DDs I have worked with and the DDs that were kind enough to meet with me for key signing on their travel through my city is an empty set. I think that Gunnar’s policy is perfectly fine. At the same time I am glad that there are DDs who allow the Debian community to be an open system. I am considering to participate in a DebConf eventually (since I have read so many positive posts about the experience), but to me it is important to get work done in Debian first and see whether I am in it for the long run, before spending time and resources on travel to a potentially faraway destination. Peter signature.asc Description: PGP signature
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 02:39:52PM -0400, Peter Colberg wrote: > The union of the DDs I have worked with and the DDs that were kind > enough to meet with me for key signing on their travel through my > city is an empty set. How embarrassing: I meant the intersection, of course. Peter signature.asc Description: PGP signature
Neomutt packages available
Hi all, I am pleased to announce the availability of neomutt [0] packages for Debian. Hints for installation you'll find at [1]. I've packaged neomutt for Debian. A Debian ITP [2] is filed. The binaries are build in a sid environment. The sources are fetched from [3]. The neomutt branch is used. I'll update packages as needed. Please test the packages and let me know of any further glitches you find. If you want, you can open an issue on [3]. The Debian Bug Tracking System is not involved as the package isn't uploaded yet, but will be soon. Thanks in advance for your cooperation Elimar [0] http://www.neomutt.org/ [1] http://www.lxtec.de/debarchiv [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825821 [3] https://github.com/neomutt/neomutt -- The path to source is always uphill! -unknown-
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 9:28 AM, Lars Wirzenius wrote: > On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote: > > As I said in my other email, I am wondering if the extra burden is worth > > the gain in security. > > Is there an extra burden? Seems to me that it'd happen naturally if > you contribute to Debian and as part of that interact with other > Debian people. > I would consider this an extra burden, yes. I've been playing with Linux for over a decade, have many DD's that know me by IRC handle, email address, and nothing else; a face to face meeting has never happened organically. The one time in my life I found a DD to sign my key, I had to schedule a time where work conveniently had me within an hour drive (one way) of that person. I would, personally, consider having an established relationship with someone you can recognize the face of because of face-to-face meetings as a bonus. It would allow you to feel comfortable verifying identity over a video conference. Just a bonus, though, I wouldn't ever make that my requirement. What is it we're really trying to protect against? Signing a key doesn't mean you trust that person's work, it means you trust that person is who they say they are. We want to prevent an evil doer from getting a key into the keyring by pretending to be someone else. We have a completely different process for establishing trust of a persons work and that's all outlined in the DM/DD application process. Our face-to-face meeting and chat is a way to see if their government says they are who they claim to be. Obviously, documents can be forged. You can ask what forms of ID they'll be bringing and use the search-o-matic to figure out signs of a counterfeit, but almost nobody is going to have the equipment to fully check every type of ID. Verifying a legal identity by means that are good enough for other organizations is only the first step in our identification process. Next up, we take the piece of paper home and start our own extended verification process (typos, existing work, etc.) followed by sending that encrypted signature back to the user via email (an address you should have verified has no typos) where the user needs to decrypt with their private key. I believe there's a document out there called Trusting Trust which discusses drawing a line between what is and is not practical. We trust C developers to not create bugs that introduce authentication back-doors during future builds. Why? Because, even if we /could/ read through the C source and review everything that's changing, we're still not going to catch everything for the same reason that bugs exist in the first place. Heck, we can't keep bugs out of our applications written in C even assuming C itself is entirely bug free. The point I'm attempting to make is that it's not practical to check every anti-forgery feature of every document. It's not (always) practical to verify an identity based on a long history of in-person interactions. Meeting someone, checking the features that don't require special equipment, having a chat with them, verifying no typos exist, and looking at existing work signed by that key, and sending an encrypted signature to that address is what we have decided is practical. Is this not why we require DD signatures in the first place? We're trusting that all DD's have put in enough effort to ensure the identity of every key they've signed. Kinda like being an op in a #debian* IRC channel; you're automatically held to a higher standard when accepting the role. I feel like the established policies do a good job of meeting in the middle of the two extremes that have been discussed. We're trusting all DD's to follow the policies that have been decided on as the practical line. If a few DD's choose to adhere to a higher standard, so-be-it, but a lower standard should be avoided. I know DD's that trust something signed with my key is me. None of them will sign my key because they've never met me. It would be concerning if they were willing to because it reduces the overall integrity of the Debian project. Somewhere, I saw it mentioned that you should be able to verify based on history only and their legal name doesn't matter. I don't entirely disagree. The chances of the NSA building a super computer to contribute to Debian, become a DD, and add backdoors into unwatched packages are pretty low. However, this does create hurdles for someone that has left the project under poor circumstances to build a new identity that they use to harm the project. It's also comforting to imagine every DD/DM is real person, just like the rest of us, and is the person they claim to be. tl;dr -- +1 existing policies :)
Re: Keysigning via Video Conferencing
On Jun 23 2016, Lars Wirzenius wrote: > On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote: >> As I said in my other email, I am wondering if the extra burden is worth >> the gain in security. > > Is there an extra burden? Seems to me that it'd happen naturally if > you contribute to Debian and as part of that interact with other > Debian people. No. At least my interactions with other Debian contributors have exclusively been online - with the exception of brief meetings for key signing purposes. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Keysigning via Video Conferencing
Quoting Peter Colberg (2016-06-23 20:39:52) > On Thu, Jun 23, 2016 at 07:30:42PM +0200, Jakub Wilk wrote: >> As as data point, if everybody[0]'s key signing policy had been that >> establishing "social bonds" was a prerequisite, I would have almost >> certainly never become a DD. > > I would like to add another data point as a recent DM. The union of > the DDs I have worked with and the DDs that were kind enough to meet > with me for key signing on their travel through my city is an empty > set. I think that Gunnar’s policy is perfectly fine. At the same time > I am glad that there are DDs who allow the Debian community to be an > open system. > > I am considering to participate in a DebConf eventually (since I have > read so many positive posts about the experience), but to me it is > important to get work done in Debian first and see whether I am in it > for the long run, before spending time and resources on travel to a > potentially faraway destination. I sign keys by a similar policy as Gunnar, it seems. But I do sign also people I have not met before... The logic I use is that I should be able to re-identify later. If I meet the person later I might have forgotten their name (I easily do) but if they remind me and tie it to something we talked about or did together, I should go "Ahhh!" rather than "hmmm". It is a balancing act. Easiest is to only trust your mother and very close friends through many years, but you also want to expand the web of trust (and maybe also social circles, but that is a _different_ matter). I think what can help here is expiry time on signatures: If my gut feeling says that the person I've discussed perl with for an hour does not really etch into my brain that efficiently, and I worry if we bump into each other, say 3 years from now, then I would've forgotten who it is. What I then do is sign but with an expiry of the key of 1-2 years. Expiry on signatures is relatively new to me, however, so I welcome input on how that is sensible or not. And also on how to eventually extend the lifespan. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 12:52:35PM -0700, Nikolaus Rath wrote: > On Jun 23 2016, Lars Wirzenius wrote: > > On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote: > >> As I said in my other email, I am wondering if the extra burden is worth > >> the gain in security. > > > > Is there an extra burden? Seems to me that it'd happen naturally if > > you contribute to Debian and as part of that interact with other > > Debian people. > > No. At least my interactions with other Debian contributors have > exclusively been online - with the exception of brief meetings for key > signing purposes. Why do you bring up in-person meetings all the time? I never suggested they're necessary. But never mind. You keep doing things as you have, and I'll keep doing what I have. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: Keysigning via Video Conferencing
Quoting Michael Lustfield (2016-06-23 21:27:15) > Somewhere, I saw it mentioned that you should be able to verify based > on history only and their legal name doesn't matter. I don't entirely > disagree. The chances of the NSA building a super computer to > contribute to Debian, become a DD, and add backdoors into unwatched > packages are pretty low. However, this does create hurdles for someone > that has left the project under poor circumstances to build a new > identity that they use to harm the project. It's also comforting to > imagine every DD/DM is real person, just like the rest of us, and is > the person they claim to be. Beare not to confuse matters: PGP signing do *not* imply judgement of social intent or coding skills! PGP signing is *only* about identification. Only when reliable identification is established can we on top of that - but _separately_ from the identification, do e.g. endorsements. When I sign keys of others, I insist on spending time with them first, but only to try memorize them for a later "lineup", not to judge their skills or attitude or political agenda. I would sing the key of a complete lunatic, if only I felt confident that I could reasonably reliably identify that person again later. - Jonas P.S. Probably not a _complete_ lunatic: If I get the impression that the person is incapable of handling PGP signing properly, then I will also not sign: If e.g. they handle their secret material too sloppily then others might too easily get hold of it and impersonate as them, effectively leading me unable to re-identify later (I would fail at recognizing the impersonator!). -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Keysigning via Video Conferencing
Hello Everyone, Sorry to interject in this matter however it is beginning to become repetitive. PGP Key Signing for New Members is purely an identification process, to prove that you are who you say you are. This provides the Debian Foundation with the assurance that you can be trusted monitoring their infrastructure, uploading packages and performing other roles throughout the foundation. Therefore providing proof that you have the skills to become a Debian Developer is obsolete in this part of the process. If a Debian Developer is to sign your key, they will need to be familiar with you, have formal identification (not just photographs) and also have the ability to provide proof, if asked that you are who you claim to be. The process will not go any other way and you can't attempt to circumnavigate the inevitable fact that you cannot have your key signed online. Try to find a Debian Developer close to your location, preferably someone familiar with you and begin to converse and identify yourself. I myself are a New Member hoping to become a Debian Developer however I will follow the correct procedures to ensure I am correctly identified. This conversation should be brought to a climax at this point considering we have established that you will need to find a Debian Developer to identify yourself, as opposed to looking online for a Debian Developer who is a willing party (All of which will deny your request). Again, find a DD who is close to you and if you can't, look slightly further away. This process is well documented on the Debian Developer/New Member forums and information pages and in addition, the Front Desk will check your application and signed keys with the DD's who signed your keys to ensure the process has been completed correctly. I must apologise and this may be frustrating for you however I don't see any exceptions that can be made to aid this issue, I hope you understand. Sorry for the inconvenience this may cause, also if you believe that anything in this email is incorrect, my apologies. Thanks for reading. Have a nice day! Thanks in advance, James Gallagher
Work-needing packages report for Jun 24, 2016
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 741 (new: 3) Total number of packages offered up for adoption: 174 (new: 1) Total number of packages requested help for: 48 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: agg (#827993), orphaned today Description: AntiGrain Geometry graphical toolkit Installations reported by Popcon: 193 blockfinder (#827652), orphaned 4 days ago Description: enumerates network information for countries Installations reported by Popcon: 18 cplay (#827890), orphaned yesterday Installations reported by Popcon: 161 738 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: pyzor (#827500), offered 6 days ago Description: spam-catcher using a collaborative filtering network Installations reported by Popcon: 2199 173 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: athcool (#278442), requested 4258 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 26 awstats (#755797), requested 701 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4172 balsa (#642906), requested 1733 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 624 cardstories (#624100), requested 1886 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 5 courier (#823807), requested 45 days ago Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-imap-ssl courier-ldap courier-mlm courier-mta courier-mta-ssl courier-pcp courier-pop (7 more omitted) Installations reported by Popcon: 2258 cups (#532097), requested 2574 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (62 more omitted) Installations reported by Popcon: 169012 cyrus-sasl2 (#799864), requested 274 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (130 more omitted) Installations reported by Popcon: 190077 developers-reference (#759995), requested 663 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 19170 devscripts (#800413), requested 268 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (28 more omitted) Installations reported by Popcon: 13075 ejabberd (#767874), requested 598 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest ejabberd-mod-s2s-log (3 more omitted) Installations reported by Popcon: 759 fbcat (#565156), requested 2353 days ago Description: framebuffer grabber Installations reported by Popcon: 214 fgetty (#823266), requested 52 days ago Description: console-only getty & login (issue with nis) Installations reported by Popcon: 2113 freeipmi (#628062), requested 1855 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: conman freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted) Installations reported by Popcon: 6553 freerdp (#799759), requested 275 days ago Description: RDP client for Windows Terminal Services (X11 client) Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp
