Paging Daniel Schepler
I'm trying to get in touch with Daniel Schepler, who seems to pop in here from time to time. Does anyone know how best to contact him? I'm trying to get some software license issues worked out. -- David Griffith d...@661.org
Bug#951816: ITP: golang-github-jcmturner-gofork -- forked and modified go standard libary packages to work around issues
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-github-jcmturner-gofork Version : 1.0.0-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/gofork * License : BSD-3-clause Programming Lang: Go Description : forked and modified go standard libary packages to work around issues This repository contains modified Go standard library packages for use as work arounds until issues are addressed in the official distribution. Dependency of new version of git-lfs
Bug#951817: ITP: golang-gopkg-jcmturner-aescts.v1 -- AES CBC Ciphertext Stealing mode for Go
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gopkg-jcmturner-aescts.v1 Version : 1.0.1-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/aescts * License : Apache-2.0 Programming Lang: Go Description : AES CBC Ciphertext Stealing mode for Go Golang library to encrypt and decrypt data using AES CBC Ciphertext stealing mode. Dependency of new version of git-lfs
Bug#951815: ITP: golang-github-dpotapov-go-spnego -- Wraps gokrb5 and sspi libraries to provide cross-platform way to make HTTP calls with Kerberos authentication
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-github-dpotapov-go-spnego Version : 0.0~git20190506.c2c6091-1 Upstream Author : Daniel Potapov * URL : https://github.com/dpotapov/go-spnego * License : Expat Programming Lang: Go Description : Wraps gokrb5 and sspi libraries to provide cross-platform way to make HTTP calls with Kerberos authentication go-spnego The package extends Go's HTTP Transport allowing Kerberos authentication through Negotiate mechanism (see RFC4559 (https://tools.ietf.org/html/rfc4559)). . Internally it is implemented by wrapping 2 libraries: gokrb5 (https://github.com/jcmturner/gokrb5) on Linux and sspi (https://github.com/alexbrainman/sspi) on Windows. . There is no pre-authenticaion yet, so the library assumes you have Kerberos ticket obtained. . Linux implementation requires MIT or Heimdal Kerberos to be present. Windows implementation utilizes credentials of currently logged in user. . Currently it allows only to make HTTP calls, no server side support yet. Dependency of new version of git-lfs
Bug#951813: ITP: golang-gopkg-jcmturner-gokrb5.v5 -- Pure Go Kerberos library for clients and services
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gopkg-jcmturner-gokrb5.v5 Version : 5.3.0-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/gokrb5 * License : Apache-2.0 Programming Lang: Go Description : Pure Go Kerberos library for clients and services Features - Pure Go - no dependency on external libraries - No platform specific code - Server Side - HTTP handler wrapper implements SPNEGO Kerberos authentication - HTTP handler wrapper decodes Microsoft AD PAC authorization data - Client Side - Client that can authenticate to an SPNEGO Kerberos authenticated web service - Ability to change client's password - General - Kerberos libraries for custom integration - Parsing Keytab files - Parsing krb5.conf files - Parsing client credentials cache files such as /tmp/krb5cc_$(id -u $(whoami)) Dependency of new version of git-lfs
Bug#951811: ITP: golang-gopkg-jcmturner-dnsutils.v1 -- Golang library of DNS utilities
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gopkg-jcmturner-dnsutils.v1 Version : 1.0.1-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/dnsutils * License : Apache-2.0 Programming Lang: Go Description : Golang library of DNS utilities A golang library of DNS utilities, mostly for the purposes of reading SRV records Dependency of new version of git-lfs
Bug#951814: ITP: golang-gopkg-jcmturner-goidentity.v2 -- A golang library for managing identities
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gopkg-jcmturner-goidentity.v2 Version : 2.0.0-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/goidentity * License : Apache-2.0 Programming Lang: Go Description : A golang library for managing identities Standard interface for holding authenticated identities and their attributes. Dependency of new version of git-lfs
Bug#951812: ITP: golang-gopkg-jcmturner-rpc.v0 -- Remote Procedure Call libraries
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-gopkg-jcmturner-rpc.v0 Version : 0.0.2-1 Upstream Author : Jonathan Turner * URL : https://github.com/jcmturner/rpc * License : Apache-2.0 Programming Lang: Go Description : Remote Procedure Call libraries A partial implementation that mainly focuses on unmarshaling NDR encoded byte streams into Go structures. Dependency of new version of git-lfs
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On 2/21/20 2:00 AM, Wouter Verhelst wrote: Even so, if we want to do so, this can be done correctly by a preinst script in new libc, by way of a script that does the following: cp -a /lib/ /usr/lib/ ln -sf /lib/ /usr/lib/ The first of the above two creates the new file; the second replaces the old file, atomically, by a symlink. Errr, pretty sure you meant to have the ln arguments in the opposite order. The link name is the second argument to ln. Besides that, you need a sync after the cp. Otherwise (in the event of an ill-timed crash) the data may not be written out, and you might wind up with /usr/lib/ being, e.g., a zero-byte file (with /lib/ a symlink to it). Possibly you even end up with /usr/lib/ missing, and /lib/name> a dangling link. (It appears ln does not do a sync of any sort between the symlinkat and rename syscalls, no idea if that is also a bug.)
Bug#951788: ITP: azure-devops-cli-extension -- Azure DevOps Extension for Azure CLI
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-devel@lists.debian.org Control: block -1 by 930413 * Package name: azure-devops-cli-extension Version : 0.17.0 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-devops-cli-extension * License : MIT * Programming Lang: Python * Description : Azure DevOps Extension for Azure CLI The Azure DevOps Extension for Azure CLI adds Pipelines, Boards, Repos, Artifacts and DevOps commands to the Azure CLI 2.0. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
Em 21/02/2020 11:15, Jeremy Stanley escreveu: Further, political exclusivity can be misleading. I work with a nonprofit which puts on some fairly large conferences every year. In recent years we've seen increasing pressure from our attendees to stop considering locations within the USA due to concerns over inability to qualify for entry visas (coupled with no-fly lists and the risk of being turned around at their port of entry), but each time we've held an event in Canada we see a significantly higher proportion of our global attendees who are unable to obtain a visa and/or enter. As it turns out, Canada is actually more picky about who it will let visit than the USA is, it's just not as well-known for that. I saw this in 2017, my visa was denied with two other brazilians. -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
On 2020-02-21 09:11:56 +0100 (+0100), Giovanni Mascellani wrote: [...] > So I believe the best the DebConf organization can do is to try to > rotate the excluded categories as much as possible (depending also on > the available bids). This will never be fair, there always will be > people who are more excluded than others, because this is the reality: > there are people who are more privileged than others (disclaimer: I am > aware I am in the privileged category by basically all point of view; I > am happy of that, but I know it is just luck). DebConf cannot > unfortunately fix this, the best it can do is to mitigate it as I said. [...] Further, political exclusivity can be misleading. I work with a nonprofit which puts on some fairly large conferences every year. In recent years we've seen increasing pressure from our attendees to stop considering locations within the USA due to concerns over inability to qualify for entry visas (coupled with no-fly lists and the risk of being turned around at their port of entry), but each time we've held an event in Canada we see a significantly higher proportion of our global attendees who are unable to obtain a visa and/or enter. As it turns out, Canada is actually more picky about who it will let visit than the USA is, it's just not as well-known for that. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
Hi, Il 20/02/20 10:29, Zlatan Todoric ha scritto: > So, could we avoid in future places that are politically very sensitive? > No country is perfect but some are really not needed to go through when > we have more "calm" choices. I don't think this criterion is too important when evaluation a DebConf bid. Of course you don't want to go to areas with military activity or other risks for the physical security of DebConf attendees, and of course you want to exclude the least possible number of people. But always disqualifying location bids on the ground that it would be exclusive because of reasons not in control of the DebConf organizers would be exclusive as well, I think. It would essentially give a privilege to those countries and people who, by historical legacy, do not find themselves implied in territorial disputes. So I believe the best the DebConf organization can do is to try to rotate the excluded categories as much as possible (depending also on the available bids). This will never be fair, there always will be people who are more excluded than others, because this is the reality: there are people who are more privileged than others (disclaimer: I am aware I am in the privileged category by basically all point of view; I am happy of that, but I know it is just luck). DebConf cannot unfortunately fix this, the best it can do is to mitigate it as I said. Again, I know I am on the winning side here: the time there will be a bid in a place where white male heterosexuals western Europeans are not welcome, I'll be glad to support it. Also, I believe that the concept of "calm" choices is very subjective. To me Kosovo is as much "calm" as India. I think that the average Pakistani would consider Kosovo much "calmer" than India. The word "calm" sounds objective, but our usage of it (and of similar words) is often very subjective. It is hard, but I believe we should try to avoid this mistake, and use subjective expressions when other people could conceivably have different opinions. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Wouter Verhelst writes: > On Wed, Feb 19, 2020 at 06:26:32AM +0100, Marco d'Itri wrote: >> On Feb 19, Guillem Jover wrote: >> > For any pathname that has been hardcoded a symlink can be used for >> > backwards compat, nothing unlike /bin or /sbin here. This looks just >> > like a normal bug from a botched transition, nothing special. >> Creating symlinks in /bin and /sbin DOES NOT result in a merged-/usr >> system, because the content of /usr would not be decoupled anymore from >> the content of /. > > No, but it allows us to *transition* from the current situation to a > merged-/usr situation, *without* breaking the package manager's > expectations. openSuSE tried to transition to merged-/usr that way seven years ago[1]. I booted a recent live system and noted that they are still stuck in the transitional state. I would not recommend following that example. [1]: https://en.opensuse.org/openSUSE:Usr_merge >> A merged-/usr system must have /bin /sbin /lib* symlinks to /usr. > > We can have a policy that by release X, any package installing anything > in /bin /sbin or /lib that is not a compat symlink is RC buggy. > > Once we've reached that point, we can drop the directories and convert > them to symlinks. At that point, dpkg can also ignore any request to > create the compat symlinks, and later on we can make it an RC bug to > create compat symlinks if we wish to no longer support non-merged-/usr. > > Yes, this approach takes more time, but it is an equally valid way to > move from unmerged /usr to merged-/usr, and is the approach that people > are advocating. It's not "the" approach that people are advocating; that would apply that there was consensus that the (singular) approach is the right way. I would recommend *not* following it given it wasn't successful for other distributions. The largest blocker for doing anything is that Debian hasn't agreed on making merged-/usr mandatory anyway. Ansgar
