Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi Alex, As I wrote earlier, we're open to making certain features available upon request. In the specific case of the feature that was discussed - could you please elaborate what is missing and what functionality is available on the Enterprise edition that you'd like to be made public? We want to better understand the use-case and the requirements to respond to this request. Thanks, Eliran On Wed, Jun 22, 2016 at 9:53 AM Alexander Wirt wrote: > On Wed, 22 Jun 2016, Pirate Praveen wrote: > > > [adding gitlab folks in cc] > > > > On Saturday 11 June 2016 02:16 PM, Alexander Wirt wrote: > > > On Sat, 11 Jun 2016, Ole Streicher wrote: > > > > > >> Pirate Praveen writes: > > Debian needs feature X but it is already in the e.nterprise > version. We make > > a patch and for commercial reasons it never gets merged (they > already sell it > > in the enterprise version). Which means we will have to fork the > software and > > keep those patches forever. Been there done that. For me, that isn't > > acceptable. > > I don't want another Nagios. > > >>> > > >>> I agree this is a legitimate concern. I have asked Gitlab Inc for > their > > >>> policy on merge requests to Gitlab CE for features already in Gitlab > EE. > > >>> Based on their reply, we can decide how to proceed. If their reply is > > >>> positive, I will ask them to make it public, and we can go ahead > with a > > >>> debian.net instance of Gitlab. If their reply is negative, we can > drop > > >>> gitlab and consider Pagure (second best option). > > >> > > >> We do patching as part of our daily packaging already: to replace (or > > >> circumvent) non-dfsg functionality, to integrate into our environment, > > >> and everything else that upstream is not willing or able to apply > > >> himself but is good in our opinion. Depending on the package, you may > > >> find huge patches for our packages > > >> > > >> I would not see why a missing functionality of gitlab would be > different > > >> here. > > > Given my personal expericence with so called opencore software, I do. > > > > > > Alex > > > > > > > > > > Hi Alex, > > > > GitLab folks have indicated their interest to consider solving access > > problems for debian (possibly releasing relevant code as Free Software > > if we are serious about using gitlab). They would like to have a call > > with relevant admins (since you being git.debian.org maintainer, your > > presence would be essential, if we were to do such a call). Would you be > > open to such a call? > I really prefer async communication like mail. > > Alex > > -- Best, Eliran
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: > As I wrote earlier, we're open to making certain features available upon > request. In the specific case of the feature that was discussed - could you > please elaborate what is missing and what functionality is available on the > Enterprise edition that you'd like to be made public? We want to better > understand the use-case and the requirements to respond to this request. I'm obviously not Alex but I also object using a software for Debian's own infrastructure which is split into a free and an enterprise version. It's not about a specific patch. Free gitlab and we can talk again. It's not that there are no free alternatives. -- cheers, Holger signature.asc Description: Digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 22 June 2016 at 10:42, Holger Levsen wrote: > On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: >> As I wrote earlier, we're open to making certain features available upon >> request. In the specific case of the feature that was discussed - could you >> please elaborate what is missing and what functionality is available on the >> Enterprise edition that you'd like to be made public? We want to better >> understand the use-case and the requirements to respond to this request. > > I'm obviously not Alex but I also object using a software for Debian's > own infrastructure which is split into a free and an enterprise version. > > It's not about a specific patch. > > Free gitlab and we can talk again. > > It's not that there are no free alternatives. > +1 -- Arturo Borrero González
Re: Bug#827705: dependency loop between initscripts and sysvinit-utils causes dist-upgrade failure
Control: tag -1 pending Hello Michael, Michael Biebl [2016-06-20 0:59 +0200]: > The issue being that /lib/init/vars.sh has been moved from initscripts > to sysvinit-utils. > sysvinit-utils got a Breaks/Replaces: initscripts (<< 2.88dsf-59.5) for > that. > On the other hand, the initscripts has got a dependency on > sysvinit-utils (>= 2.88dsf-59.5) to ensure /lib/init/vars.sh is available. > > As mentioned, dropping the Breaks should break the loop. I can reproduce the upgrade failure in a schroot, this is indeed very similar to the util-linux vs. sysvinit upgrade problem that we had some weeks ago. Similar to what we did back then, I also see no other option than dropping the Breaks:. This will break carefully crafted downgrade scenarios, but if you do these you are already on your own anyway.. I verified that upgrading from jessie to unstable plus a local apt repo without the Breaks: works fine, so I committed this: http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=f1acba82 I'll 0-day NMU this now, as it got introduced by my previous NMU and fixes an RC bug. Thanks and sorry for the trouble, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Building Mobile and Web Application !!
Hi, Trust you are doing well! I have been surfed through your site (www.lists.debian.org) and I am contacting you in reference to a possible Business Enquiry. We are mobile apps company and we have experts in App Development and Testing services. We have extensive experience in building mobile and web applications in various technologies such as PHP, Mobile application development on various platforms including Android and iOS. Our expertise is in following areas: . Android Apps . IOS Apps . Web Apps If you are interested, please share your proper requirement so we can send you best proposal accordingly. Please share you Skype ID or other contact details for quick conversation. Thanks & Regards, Arpita Services: - SEO, SMO, PPC, Website Designing, Website Development, Website Redesigning, Content Management System, E-Commerce Solution etc.
Re: opinions of snappy packages
On Sun, Jun 19, 2016 at 03:44:54PM -0700, Steve Langasek wrote: > snapd is available in Debian unstable for roughly the past two weeks. Disclaimer: I've never used snap packages, and I haven't even read their documentation. https://packages.debian.org/sid/snapd indicates the package is in the Debian main archive. The rant[0] by adamw (which I'm sure isn't nice reading for the Ubuntu folk working on snaps and their tooling) indicates that the server end is not free software: Here’s another interesting thing about Snaps: the server end (the ‘app store’ bit of the equation) is closed source, 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? At least until such time as there is a server side of this that can realistically be used with snapd (without changing its source) and that is free software. [0] https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ Furhter, the snapd package description is as follows: Description: Scripts for snapd that should only run on ubuntu core systems. This package contains systemd services that need to run on ubuntu core systems. . This package should not be installed on a Desktop system. This seems to not be relevant for a package that's meant to install snap pacxkages on a Debian system. I think it should be replaced by something that is more useful to a Debian user/sysadmin. -- 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
On Jun 21 2016, Gunnar Wolf wrote: > Now, I have said this too many times, but once more: As keyring-maint, > we are not collecting samples of people showing valid-looking ID > documents to others. This is one of the issues why we don't have > long-queue key signing parties: Just checking the ID of a complete > stranger is not real identity validation. > > My personal guideline is that I will sign your key if and only if I > see your face and can think of your name, and the opposite way > around. Hmm. Can you explain that in a little more detail? As I understand, we'll have to meet a few times for beer until we remember each others name, and then we sign keys - without ever having verified if we've actually given our legal name. I'm a little confused as to what sort of malicious activity this is intended to stop/make more difficult...? 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.«
Bug#827916: ITP: libsmithwaterman -- determine similar regions between two strings or genomic sequences
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libsmithwaterman Version : 0.0+20151117 Upstream Author : Erik Garrison * URL : https://github.com/ekg/smithwaterman * License : GPL Programming Lang: C++ Description : determine similar regions between two strings or genomic sequences The Smith–Waterman algorithm performs local sequence alignment; that is, for determining similar regions between two strings or nucleotide or protein sequences. Instead of looking at the total sequence, the Smith–Waterman algorithm compares segments of all possible lengths and optimizes the similarity measure. Remark: This library is a precondition for freebayes that will be packaged by the Debian Med team at https://anonscm.debian.org/git/debian-med/libsmithwaterman.git
Re: opinions of snappy packages
Hi Lars, I agree with both your points. Please file actual bugs. -- cheers, Holger signature.asc Description: Digital signature
Re: Keysigning via Video Conferencing
On Wed, Jun 22, 2016 at 07:58:43AM -0700, Nikolaus Rath wrote: > On Jun 21 2016, Gunnar Wolf wrote: > > Now, I have said this too many times, but once more: As keyring-maint, > > we are not collecting samples of people showing valid-looking ID > > documents to others. This is one of the issues why we don't have > > long-queue key signing parties: Just checking the ID of a complete > > stranger is not real identity validation. > > > > My personal guideline is that I will sign your key if and only if I > > see your face and can think of your name, and the opposite way > > around. > > Hmm. Can you explain that in a little more detail? > > As I understand, we'll have to meet a few times for beer until we > remember each others name, and then we sign keys - without ever having > verified if we've actually given our legal name. To some of us, it doesn't matter what your legal name is or if you have papers to show that your government and you agree on what your name is. What matters is that you're you, and that you're the person I know from a reasonable shared history. I tend to prefer to sign keys for people I already know. "This is Richard. I know him for a long time. We've talked about things and done things together. We have a history. I know it's him. Richard is the name he always uses with people. I introduce him to other people as Richard. If he were to show me a passport that says he's actually Albert, I'd be very surprised. I might be alarmed, unless there's a reasonable explanatation." Compare that with this: "This is a person whom I have never met before, and have never heard of before. He has some kind of document that I can't reliably verify, which says his name is Richard. I've heard that forged id documents aren't that hard to get and not too expensive, but I don't know how to recognise forgeries. If I sign his key, he's only a couple of steps away from having root on millions of Debian machines, including mine. Do I trust him? I know that PGP key signing is supposed to be only about identity, but do I really trust the id documents enough to vouch for his identity, when the stakes are high? What if he's actually a secret agent from Malta, and will be infecting Debian with malware to compute the value of pi?" We can't have people computing the value of pi. They might find hidden messages from god-like aliens. As a knight who says NIH, I insist we only accept hidden messages in pi that we put there ourselves. And that we sign the messages with PGP keys in the Debian keyring. I'm not saying that requiring to see someone's government-issued ID to sign their key is actually bad, but it's also not clear to me that it should be a necessary condition for signing their key. Also, legal names are not necessary on keys that get signed. "Legal name" is a big can of really ugly worms that can hurt some people. See real name policies of Facebook and (previously) Google. A name that people know and recognise are relevant. Preferably a name that we can use to locate a pi-computing malware uploader if we need to. PS. *Obviously* a policy to only sign keys for people you already know is a stratagem to get people to talk to me at parties. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: opinions of snappy packages
(Disclosure: I work for Canonical, but not on Snappy.)
On Wed, Jun 22, 2016 at 05:27:43PM +0300, 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? At least until such time as there is a server side of this that
> can realistically be used with snapd (without changing its source) and
> that is free software.
I don't understand this. What about Twitter clients[0], YouTube
clients[1], Flickr clients[2], and probably clients for many other
non-free web services?[3]
There's a valid argument about whether Canonical has done the right
thing by developing non-free web service that Snappy relies on, but I
don't think that it is one that there is precedent to use to kick
something out of Debian ('contrib' is not Debian). If you want to set
one, then it needs to be applied fairly across all of Debian.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
[0] twittering-mode
[1] youtube-dl
[2] frogr
[3] I didn't check if these can operate on some other service, and
therefore if this argument doesn't apply to them. Use your
imagination, or your 'apt search' and find something which it does
apply to.
signature.asc
Description: PGP signature
Re: Keysigning via Video Conferencing
Jason Thomas dijo [Wed, Jun 22, 2016 at 02:38:52PM +1000]: > Hi Gunnar, > I'm basically in Sydney Australia, however finding time to meet people > is difficult these days, with work, a wife and two little kids. > I live in Penrith NSW, and work in Granville NSW. I do travel up and > down the east coast of Australia and around Sydney for work, buts its > sporadic. > If anyone living in the Sydney area wanted to meet up, I'd be all for > it. > Thanks. Answered mostly off-list, as this included some could-be private information I gathered from many public sources :) Now, for anybody needing to set up a keysigning, please do remember checking the relevant web page for your country! https://wiki.debian.org/Keysigning/Offers#AU signature.asc Description: Digital signature
Re: opinions of snappy packages
On 06/22/2016 06:51 PM, Lars Wirzenius wrote:
> On Wed, Jun 22, 2016 at 05:29:12PM +0100, Iain Lane wrote:
>> I don't understand this. What about Twitter clients[0], YouTube
>> clients[1], Flickr clients[2], and probably clients for many other
>> non-free web services?[3]
>
> If a piece of free software requires, for its essential function, some
> server-side software that's non-free, and there's no free
> alternatives, then I think that free software belongs in contrib. This
> is similar to a game that is free software requiring graphics or music
> that's non-free and has no free replacements: the game belongs in
> contrib.
>
> I agree this should be applied fairly across all of Debian.
>
> We have, for example, the translate-shell package, which seems to
> provide an interface to the Google Translate service (which is clearly
> non-free). It's in contrib.
>
> We also have get-ipleyer, which downloads some files from the BBC
> iPlayer service. It's in main. I think it should be in contrib.
>
> Possibly I am in a minority here?
>
I am maintainer of mps-youtube which is a CLI to Youtube (doing also
some things very convenient such as downloading audio/video in many
formats). If its usage of youtube would be decided to go into contrib, I
wouldn't mind it at all ("more Free" Debian sounds perfect for me) but I
want to point out (imho) some difference here: while the software I
maintain streams/downloads data the snappy thing actually downloads and
installs system software. I think there should be made a difference
between something that is a tool to get data and something that actually
changes OS itself. With mps-youtube going to contrib, all web browsers
should also go to contrib as they can access Youtube and so on.
signature.asc
Description: OpenPGP digital signature
Re: opinions of snappy packages
On Wed, Jun 22, 2016 at 05:29:12PM +0100, Iain Lane wrote: > I don't understand this. What about Twitter clients[0], YouTube > clients[1], Flickr clients[2], and probably clients for many other > non-free web services?[3] If a piece of free software requires, for its essential function, some server-side software that's non-free, and there's no free alternatives, then I think that free software belongs in contrib. This is similar to a game that is free software requiring graphics or music that's non-free and has no free replacements: the game belongs in contrib. I agree this should be applied fairly across all of Debian. We have, for example, the translate-shell package, which seems to provide an interface to the Google Translate service (which is clearly non-free). It's in contrib. We also have get-ipleyer, which downloads some files from the BBC iPlayer service. It's in main. I think it should be in contrib. Possibly I am in a minority here? -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: opinions of snappy packages
On Wed, Jun 22, 2016 at 06:58:25PM +0200, Zlatan Todoric wrote: > With mps-youtube going to contrib, all web browsers should also go > to contrib as they can access Youtube and so on. That's not my opinion. There is plenty of free software to run on the server side to serve content to web browsers, and so I argue that the main purpose os a web browser is not to access a non-free server. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: opinions of snappy packages
On Wed, Jun 22, 2016 at 07:51:47PM +0300, Lars Wirzenius wrote: > Possibly I am in a minority here? I don't know. I haven't given your question much in the way of deep thought. There's an argument that it might lead to the development of more free web services, so I can at least see why it deserves consideration. Thanks for raising it. My response was making sure that this argument wasn't an exercise in Canonical or Snappy bashing. If it applies uniformly to all software in a comparable position then that's fair enough. I suppose you could do one or more of these - File a bug on something (I suggest that you don't start with Snappy to head off reactions like mine) requesting such a move and see if ftpmaster does it, then MBF all of the rest if so. - Ask ftpmaster for a ruling. - Try to start a GR. if you want to seriously pursue the argument. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Re: opinions of snappy packages
On Wed, 22 Jun 2016 19:51:47 +0300 Lars Wirzenius wrote: > On Wed, Jun 22, 2016 at 05:29:12PM +0100, Iain Lane wrote: > > I don't understand this. What about Twitter clients[0], YouTube > > clients[1], Flickr clients[2], and probably clients for many other > > non-free web services?[3] > > If a piece of free software requires, for its essential function, some > server-side software that's non-free, and there's no free > alternatives, then I think that free software belongs in contrib. This > is similar to a game that is free software requiring graphics or music > that's non-free and has no free replacements: the game belongs in > contrib. [...] > We also have get-ipleyer, which downloads some files from the BBC > iPlayer service. It's in main. I think it should be in contrib. > > Possibly I am in a minority here? The thing with "players" / "downloaders" is that they deal with data. I mean, youtube is a proprietary service but what youtube downloaders do is basically perform some "web API" requests and stream data. May be also actually render it on the screen. What matters here is that they merely speak a set of wire protocols and understand a set of data formats. What contrasts this with, say, a free game relying on non-free resources is that those resources must be physically installed into the user's system. To rephrase, once all the components of your system are installed from "main", your system is "free as per DFSG"; once you install something from "contrib", it means you most probably have also installed something which is not free as per DFSG -- hence rendering the system not-really-free FWIW. I'd say the key word here is "installing" stuff. So I fail to see why snapd must go in contrib. It must have a big bold warning in the package's long description though.
Re: Keysigning via Video Conferencing
Nikolaus Rath dijo [Wed, Jun 22, 2016 at 07:58:43AM -0700]: > > Now, I have said this too many times, but once more: As keyring-maint, > > we are not collecting samples of people showing valid-looking ID > > documents to others. This is one of the issues why we don't have > > long-queue key signing parties: Just checking the ID of a complete > > stranger is not real identity validation. > > > > My personal guideline is that I will sign your key if and only if I > > see your face and can think of your name, and the opposite way > > around. > > Hmm. Can you explain that in a little more detail? > > As I understand, we'll have to meet a few times for beer until we > remember each others name, and then we sign keys - without ever having > verified if we've actually given our legal name. Yes, I try to keep that as a guideline. Of course, were you to come to Mexico and meet me, or where I to travel to wherever you live, if we agree to meet for a beer or so and have a couple of hours chatting about what we do and want in Debian or in life... I guess I'd have a much better recollection on your face than if we had met at a massive key-signing party. In said case, however, I would resort to verifying your identity on some official-looking papers. It is not what *I* regard as best, but it's the closest available. Living over 1000Km from the nearest DD, I know firsthand that some people can have a hard time getting signatures, and I will be flexible if needed. But those special cases will more probably "make it" to my long-term memory. > I'm a little confused as to what sort of malicious activity this is > intended to stop/make more difficult...? I want to ensure people actually are known by the identity I sign. The best way to do it is to interact in their social circle and know other people that trust this person's identity. Of course, that's often impossible. A second-best would be to meet you repeatedly throughout some time period, with you having the same identity. That's what I do most of the time: I know the names or pseudonyms of people in Debian and in my local LUGs. I will sign according to those. Government-issued IDs are, IMO, a distant third. What can a malicious user do? Say, you detect that Foob Arski is a MIA Debian Developer and his mail address bounces. I can point you to several places in my city where you can print genuine-looking fake IDs. Get a drivers license or so going by Foob's name, come to me, I'll sign your key. Do the same with one other DD. Then ask DAM to change your mail in db.debian.org, and ask keyring-maint to change your GPG key. There, you have successfully impersonated a MIA DD, and got upload, machine usage and voting rights in Debian.
Re: Keysigning via Video Conferencing
Lars Wirzenius dijo [Wed, Jun 22, 2016 at 07:32:28PM +0300]: > PS. *Obviously* a policy to only sign keys for people you already know > is a stratagem to get people to talk to me at parties. Grah, my evil plan has been foiled. I fear, I will sit lonely with no friends at DebConf :-( Please, somebody come talk to me, starting next Tuesday! \o/ signature.asc Description: Digital signature
Re: Keysigning via Video Conferencing
On Jun 22 2016, Lars Wirzenius wrote: > On Wed, Jun 22, 2016 at 07:58:43AM -0700, Nikolaus Rath wrote: >> On Jun 21 2016, Gunnar Wolf wrote: >> > Now, I have said this too many times, but once more: As keyring-maint, >> > we are not collecting samples of people showing valid-looking ID >> > documents to others. This is one of the issues why we don't have >> > long-queue key signing parties: Just checking the ID of a complete >> > stranger is not real identity validation. >> > >> > My personal guideline is that I will sign your key if and only if I >> > see your face and can think of your name, and the opposite way >> > around. >> >> Hmm. Can you explain that in a little more detail? >> >> As I understand, we'll have to meet a few times for beer until we >> remember each others name, and then we sign keys - without ever having >> verified if we've actually given our legal name. > > To some of us, it doesn't matter what your legal name is or if you > have papers to show that your government and you agree on what your > name is. What matters is that you're you, and that you're the person I > know from a reasonable shared history. > > I tend to prefer to sign keys for people I already know. "This is > Richard. I know him for a long time. We've talked about things and > done things together. We have a history. I know it's him. Richard is > the name he always uses with people. I introduce him to other people > as Richard. If he were to show me a passport that says he's actually > Albert, I'd be very surprised. I might be alarmed, unless there's a > reasonable explanatation." [...] That's all good and well, but what I'm wondering what this signing policy is intended to protect against - and by extension, if it's actually worth it. If everyone were to follow this procedure then the bar to becoming a Debian developer would be raised significantly. Establishing a history of in-person meetings requires a) the other person to be reasonably close, b) the other person to be at least somewhat on the same wavelength, c) the other person to be a Debian developer. 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.« signature.asc Description: PGP signature
Bug#827932: ITP: porg -- a source code package organizer
Package: wnpp Severity: wishlist Porg is a program to aid package management when installing packages from source code. Porg also provides options for printing package information, package files, removing packages or querying for the owner of files. More information can be found at the program's website: http://porg.sourceforge.net/ signature.asc Description: PGP signature
Bug#827934: ITP: python-fakeredis -- Fake version of a redis-py
Package: wnpp Severity: wishlist Owner: "Ondřej Nový" * Package name: python-fakeredis Version : 0.7.0 Upstream Author : James Saryerwinnie * URL : https://github.com/jamesls/fakeredis * License : BSD-3-clause Programming Lang: Python Description : Fake version of a redis-py fakeredis is a pure Python implementation of the redis-py Python client that simulates talking to a redis server. This was created for a single purpose: to write unittests. Setting up redis is not hard, but many times you want to write unittests that do not talk to an external server (such as redis). This module now allows tests to simply use this module as a reasonable substitute for redis. We are using this package in our company and we are going to maintain it in DPMT.
Bug#827937: ITP: libhat-trie -- HAT-trie, an extremely efficient (space and time) modern variant of tries
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: libhat-trie Version : 0.0~git25f9e946 Upstream Author : Daniel C. Jones * URL : https://github.com/dcjones/hat-trie * License : MIT Programming Lang: C Description : HAT-trie, an extremely efficient (space and time) modern variant of tries This is an ANSI C99 implementation of the HAT-trie data structure of Askitis and Sinha, an extremely efficient (space and time) modern variant of tries. The version implemented here maps arrays of bytes to words (i.e., unsigned longs), which can be used to store counts, pointers, etc, or not used at all if you simply want to maintain a set of unique strings. This library is packaged by the Debian Med Packaging Team as a dependency of SPAdes, to replace code currently embedded there.
Re: Keysigning via Video Conferencing
On Jun 22 2016, Gunnar Wolf wrote: > Nikolaus Rath dijo [Wed, Jun 22, 2016 at 07:58:43AM -0700]: >> > Now, I have said this too many times, but once more: As keyring-maint, >> > we are not collecting samples of people showing valid-looking ID >> > documents to others. This is one of the issues why we don't have >> > long-queue key signing parties: Just checking the ID of a complete >> > stranger is not real identity validation. >> > >> > My personal guideline is that I will sign your key if and only if I >> > see your face and can think of your name, and the opposite way >> > around. >> >> Hmm. Can you explain that in a little more detail? >> >> As I understand, we'll have to meet a few times for beer until we >> remember each others name, and then we sign keys - without ever having >> verified if we've actually given our legal name. > > Yes, I try to keep that as a guideline. Of course, were you to come to > Mexico and meet me, or where I to travel to wherever you live, if we > agree to meet for a beer or so and have a couple of hours chatting > about what we do and want in Debian or in life... I guess I'd have a > much better recollection on your face than if we had met at a massive > key-signing party. > > In said case, however, I would resort to verifying your identity on > some official-looking papers. It is not what *I* regard as best, but > it's the closest available. Living over 1000Km from the nearest DD, I > know firsthand that some people can have a hard time getting > signatures, and I will be flexible if needed. But those special cases > will more probably "make it" to my long-term memory. > >> I'm a little confused as to what sort of malicious activity this is >> intended to stop/make more difficult...? > > I want to ensure people actually are known by the identity I sign. The > best way to do it is to interact in their social circle and know other > people that trust this person's identity. Of course, that's often > impossible. > > A second-best would be to meet you repeatedly throughout some time > period, with you having the same identity. That's what I do most of > the time: I know the names or pseudonyms of people in Debian and in my > local LUGs. I will sign according to those. > > Government-issued IDs are, IMO, a distant third. > > What can a malicious user do? Say, you detect that Foob Arski is a MIA > Debian Developer and his mail address bounces. I can point you to > several places in my city where you can print genuine-looking fake > IDs. Get a drivers license or so going by Foob's name, come to me, > I'll sign your key. Do the same with one other DD. Then ask DAM to > change your mail in db.debian.org, and ask keyring-maint to change > your GPG key. There, you have successfully impersonated a MIA DD, and > got upload, machine usage and voting rights in Debian. But how is your policy preventing this? Instead of getting the fake drivers license, I'd just meet with you a couple of times, chat about my supposed Debian work, and eventually get the signature as well. 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
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. 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. -- \ “To succeed in the world it is not enough to be stupid, you | `\must also be well-mannered.” —Voltaire | _o__) | Ben Finney
Debian Testing Cannot be installed on Hyper-V 2012 R2
Package: debian-installer Version: debian-testing-i386-netinst.iso dated 2016-06-20 07:33 391Mb I'm trying to install Debian Testing under Hyper-V Windows Server 2012 R2. mem: Start-up 1024Mb Dynamic Min 512Mb Max 3584 proc: 2 vhdx: 10Gb Install it using non-GUI. Then It freezes during: Partitions formatting at 33% Creating ext4 file system for / in partition #1 of SCSI3 (0,0,0) (sda)... Note: I have installed Debian 7/Wheezy 7.11 and 8/Jessie 8.5 on Hyper-V; so far no problem on installation with the two versions...
