Bug#951304: dh-make-golang: Manage MIT (Expat) license

Package: dh-make-golang Version: 0.3.1-1 Severity: normal Hello there! I have used your tool to package some libraries, and I have noticed that the MIT license was not recognized. As you can view on the MIT wikipedia page that "MIT License" may refer to the Expat License (used for the XML parsi

Re: Y2038 - best way forward in Debian?

Steve McIntyre 于2020年2月14日周五 上午12:20写道： > > YunQiang Su wrote: > >Ansgar 于2020年2月13日周四 下午5:29写道： > >> > >> For arm* and mips*, we mostly seem to be talking about special-purpose > >> systems where just switching to a new architecture/port doesn't seem to > >> be that much as a problem as for i386

Work-needing packages report for Feb 14, 2020

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: 1240 (new: 7) Total number of packages offered up for adoption: 238 (new: 0) Total number of packages reques

Bug#951297: ITP: gofeed -- Parse RSS and Atom feeds in Go

Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: gofeed Version : 1.0.0-beta2-1 Upstream Author : * URL : https://github.com/mmcdole/gofeed * License : MIT Programming Lang: Go Description : Parse RSS and Atom feeds in Go This packa

Bug#951295: ITP: golang-github-mmcdole-goxpp -- Go XML Pull Parser

Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-mmcdole-goxpp Version : 0.0~git20181012.0068e33-1 Upstream Author : * URL : https://github.com/mmcdole/goxpp * License : MIT Programming Lang: Go Description : Go XML Pul

Re: Y2038 - best way forward in Debian?

On Thu, Feb 13, 2020 at 04:08:22PM +0100, Andrej Shadura wrote: On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote: just redefine time_t to 64bit may also cause a problem:    a bad designed and old network protocol which aims  only target 32bit system,    a binary data packet, may contain

Re: Y2038 - best way forward in Debian?

On Thu, Feb 13, 2020 at 10:29:35AM +0100, Ansgar wrote: For arm* and mips*, we mostly seem to be talking about special-purpose systems where just switching to a new architecture/port doesn't seem to be that much as a problem as for i386. I think rebuilding the world and breaking ABI might thus b

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

On 2020-02-13 09:14, Timo Weingärtner wrote: Hallo Ulrike, 12.02.20 17:46 Ulrike Uhlig: On 12.02.20 17:01, Nicolas Dandrimont wrote: > In any case, since DSA had to restart everything at UBC, the piuparts > slave got restarted as well and it's churning through the backlog. > Unfortunately it lo

Bug#951278: ITP: cargo-lock -- Self-contained Cargo.lock parser

Package: wnpp Severity: wishlist Owner: Fabian Grünbichler * Package name: cargo-lock Version : 4.0.1 Upstream Author : Tony Arcieri * URL : https://github.com/rustsec/cargo-lock * License : Apache-2.0 or MIT Programming Lang: Rust Description : Self-c

Re: Y2038 - best way forward in Debian?

On Wed, Feb 12, 2020 at 06:10:53PM +, Steve McIntyre wrote: > Russ Allbery wrote: > >If we go down this path, can we make cross-grading a supported feature for > >the next stable release? I'm sure I'm not the only one who is stuck with > >continuously-upgraded i386 hosts who has been wanting t

Re: Y2038 - best way forward in Debian?

On Thu, Feb 13, 2020 at 05:40:29PM +0800, YunQiang Su wrote: > just redefine time_t to 64bit may also cause a problem: >a bad designed and old network protocol which aims only target 32bit > system, >a binary data packet, may contain time_t: > struct { > int a; >

Re: Y2038 - best way forward in Debian?

Andrej Shadura wrote: >On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote: >> >> just redefine time_t to 64bit may also cause a problem: >>a bad designed and old network protocol which aims only target 32bit >> system, >>a binary data packet, may contain time_t: >> struct { >>

Re: Y2038 - best way forward in Debian?

YunQiang Su wrote: >Ansgar 于2020年2月13日周四 下午5:29写道： >> >> For arm* and mips*, we mostly seem to be talking about special-purpose >> systems where just switching to a new architecture/port doesn't seem to >> be that much as a problem as for i386. I think rebuilding the world and >> breaking ABI mig

Re: Y2038 - best way forward in Debian?

Florian Weimer wrote: >* Steve McIntyre: > >>>In addition if we are using a new multiarch triplet, and need to >>>rebuild the world, are going to be ABI incompatible anyway, we might >>>as well use a proper multiarch-qualified ld.so pathname that does >>>not collide with anything. >> >> Hmmm. Movin

Bug#951270: ITP: dmarcts-report-parser -- Perl based tool to parse DMARC reports

Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: dmarcts-report-parser Version : 1.0+git20190809.1.bb5dd8b6 Upstream Author : Techsneeze.com * URL : https://github.com/techsneeze/dmarcts-report-parser/ * License : GPL-3+ Programming Lang:

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

Thanks to Ulrike also from me for pointing that out, its an important topic! I think its good to see more and more software projects realizing that terminology matters and that the words we use have an impact in shaping societies. (Thanks also to nicoo for this useful tip I stumbled upon some mont

Re: Y2038 - best way forward in Debian?

* Steve McIntyre: >>In addition if we are using a new multiarch triplet, and need to >>rebuild the world, are going to be ABI incompatible anyway, we might >>as well use a proper multiarch-qualified ld.so pathname that does >>not collide with anything. > > Hmmm. Moving ld.so is *hard* - we were al

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

* Miriam Ruiz [2020-02-13 11:49:25 +0100]: > El mié., 12 feb. 2020 a las 21:07, Nicolas Dandrimont > () escribió: > > > > * Ulrike Uhlig [2020-02-12 17:46:15 +0100]: > > > I'd like to attract your attention to this very fine document: > > > > > > https://tools.ietf.org/id/draft-knodel-terminolog

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

There’s no such thing as rejected in IETF. The timestamp is artificially set to 6 months from the I-D published date. Expired draft could mean many things: - there was not enough consensus to proceed - draft editors lost interest - draft editors didn’t have time to update the draft in time - or

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

Den tors 13 feb. 2020 kl 10:49 skrev Miriam Ruiz : > El mié., 12 feb. 2020 a las 21:07, Nicolas Dandrimont > () escribió: > > > > * Ulrike Uhlig [2020-02-12 17:46:15 +0100]: > > > I'd like to attract your attention to this very fine document: > > > > > > > https://tools.ietf.org/id/draft-knodel-t

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

El mié., 12 feb. 2020 a las 21:07, Nicolas Dandrimont () escribió: > > * Ulrike Uhlig [2020-02-12 17:46:15 +0100]: > > I'd like to attract your attention to this very fine document: > > > > https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1 > > Thanks for the pointer to thi

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

>PS: I really used real scissors and real glue to cut and paste text, so >I'm having less problems with metaphors, but I think most metaphors are >just wrong (I need to learn what they do, and then maybe I learn later >what it was the origin). We are supposed to make computer easy, but we >use

Re: Y2038 - best way forward in Debian?

Ansgar 于2020年2月13日周四 下午5:29写道： > > Steve McIntyre writes: > > wzss...@gmail.com wrote: > >>Is there the option C? > >> > >>Draft: > >> 1. define time64_t > >> 2. for data_struct which act as a part of ABI, define a new data_struct64 > >> 3. for function which act as part of ABI, define a new ve

Re: Y2038 - best way forward in Debian?

Steve McIntyre writes: > wzss...@gmail.com wrote: >>Is there the option C? >> >>Draft: >> 1. define time64_t >> 2. for data_struct which act as a part of ABI, define a new data_struct64 >> 3. for function which act as part of ABI, define a new version func64. >> 4. patch all packages to use tim

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

On 13/02/2020 21:14, Timo Weingärtner wrote: I don't think giving slaves new labels helps them in any way; they will still be slaves. True, but once "freed", they could compete to be Employee of the Month. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited

Re: Y2038 - best way forward in Debian?

On Wed, Feb 12, 2020 at 11:15 PM Steve McIntyre wrote: > Simon McVittie wrote: > >On Tue, 04 Feb 2020 at 13:14:10 +, Steve McIntyre wrote: > >> Arnd scanned the library packages in the Debian archive and identified > >> that about one third of our library packages would need rebuilding > >> (a

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

On 13.02.2020 09:14, Timo Weingärtner wrote: Hallo Ulrike, Quoting from there: "Master-slave is an oppressive metaphor that will and should never become fully detached from history." I don't think giving slaves new labels helps them in any way; they will still be slaves. You missed the p

Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?

Hallo Ulrike, 12.02.20 17:46 Ulrike Uhlig: > On 12.02.20 17:01, Nicolas Dandrimont wrote: > > In any case, since DSA had to restart everything at UBC, the piuparts > > slave got restarted as well and it's churning through the backlog. > > Unfortunately it looks like restarting the slave just eats