Re: Q: How to get build depends package from debian/control
Am 12.02.2018 um 05:41 schrieb Yao Wei: > [...] I'd prefer mk-build-deps from devscripts since this > produces pseudo-package that depends on the build dependencies, and the > dependencies can be removed by removing the pseudo-package. Whoa, what a gem, I did not know existed! Just what I was looking for for years. Thanks for mentioning it! (and thanks to Vincent Fourmond and Adam D. Barratt for creating mk-build-deps). *t
Bug#890300: ITP: fonts-eurofurence -- family of geometric rounded sans serif fonts
Package: wnpp
Severity: wishlist
Owner: Adam Borowski
* Package name: fonts-eurofurence
Version : 4.0
Upstream Author : Tobias Köhler
* URL : http://eurofurence.net/eurofurence.html
* License : SIL OFL 1.1
Description : family of geometric rounded sans serif fonts
Eurofurence is a family of fonts designed 1995-2000 by Tobias Köhler,
originally for a convention these fonts are namesake of.
.
Provided variants are:
* eurofurence (regular, bold, italic, bold italic) — meant for
signs, badges or text headings.
* eurofurence classic (regular, bold, italic, bold italic, light, light
italic) — Futura-like, appropriate for body text.
* unifur (regular) — {a,de}scender-less, titles and logos only.
A monospaced variant, “monofur”, is provided as a separate package.
Re: ubuntudiff.debian.net status
Hi, On 2018-02-12 16:58, Frédéric Bonnard wrote: Hi all, since a few days, ubuntudiff is not reachable (name does not resolve). I see Mehdi administrate this domain ( https://wiki.debian.org/DebianNetDomains ). Mehdi, anyone, do you know what's going on ? Thanks for pointing this out. I think my .debian.net domains got disabled when DSA disabled my account. Unfortunately, things didn't change recently (I have a new GPG key but it is only one sig-away before asking for its inclusion in Debian's keyring). If DSA is not able to restore my .debian.net domains, I can explain to interested DDs how to restore them. I saw Mehdi got his laptop stolen, maybe that's related. I'd appreciate if could keep private information _private_. Thanks. -- Mehdi
Bug#890273: ITP: python-os-service-types -- lib for consuming OpenStack sevice-types-authority data
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-os-service-types Version : 1.1.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/os-service-types * License : Apache-2.0 Programming Lang: Python Description : lib for consuming OpenStack sevice-types-authority data This package provides a Python library for consuming OpenStack sevice-types-authority data . The OpenStack Service Types Authority contains information about official OpenStack services and their historical service-type aliases. . The data is in JSON and the latest data should always be used. This simple library exists to allow for easy consumption of the data, along with a built-in version of the data to use in case network access is for some reason not possible and local caching of the fetched data. Note: this is a new dependency for openstacksdk, itself needed by many OpenStack API clients.
Re: Repackaging upstream source with file modifications?
Dimitri John Ledkov wrote: > On 12 February 2018 at 10:28, Colin Watson wrote: [...] >> My recent attempt to upload grub2 2.02-3 was rejected due to >> https://bugs.debian.org/745409, which I admit I've been putting off >> dealing with for a while; but the relevant tag >> (license-problem-non-free-RFC) was added to the ftpmaster auto-reject > I believe this tag to be a false positive in this case. > Whilst RFC text themselves are not-free, the code components of an RFC > are free under a 3-clause BSD like license. > I only see code components in the grub2 package and no RFC text. > http://trustee.ietf.org/license-info/IETF-TLP-5.htm Section 4 License > to Code Components Hello, I do not think so. The respective code is from rfc1952 (May 1996). The code component exception applies from Nov 2008 onwards. See https://trustee.ietf.org/copyright-faq.html 5.1: Afaiui parts from older rfc are unusable. cu Andreas PS: I would love to be wrong on this. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
ubuntudiff.debian.net status
Hi all, since a few days, ubuntudiff is not reachable (name does not resolve). I see Mehdi administrate this domain ( https://wiki.debian.org/DebianNetDomains ). Mehdi, anyone, do you know what's going on ? I saw Mehdi got his laptop stolen, maybe that's related. Thanks, F. pgppAJwh7ROGJ.pgp Description: PGP signature
Bug#890259: ITP: fonts-monofur -- terminal font with rounded shapes
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: fonts-monofur Version : 1.0 Upstream Author : tobias b köhler * URL : http://eurofurence.net/monofur.html * License : SIL OFL 1.1 Description : terminal font with rounded shapes Monofur is a monospaced (terminal/programming) font derived from the eurofurence family. It comes in two styles: upright and italic; covers Latin, common Greek and Cyrillic. Relicensed via private mail: "These fonts are licensed under SIL Open Font License version 1.1. I would enjoy it if you notify me at u...@unci.de when you use them commercially or redistribute them on a server. I always like seeing or getting examples of the fonts in use."
Bug#890258: ITP: quark -- An extremely small and simple HTTP GET-only web server
Package: wnpp Severity: wishlist Owner: Paride Legovini * Package name: quark Version : soon to be tagged Upstream Author : Laslo Hunhold * URL : https://tools.suckless.org/quark/ * License : ISC Programming Lang: C Description : An extremely small and simple HTTP GET-only web server quark is an extremely small and simple HTTP GET-only web server. It only serves static pages on a single host.
Re: Repackaging upstream source with file modifications?
Wookey writes: > On 2018-02-12 14:11 +0100, Jonas Smedegaard wrote: >> The tarball should contain only upstream code. Not patched code (then >> you arguably are making a fork). > > But we are encouraged to fork vigorously and often these days > (github...I'm looking at you). So Colin can very easily make a fork > and then package that and it will still be 'upstream'. It is more work for him, but if he is willing to do: the major advantage is that this upstream may serve other distributions (like Fedora) as well, therefore enlighting more that just to Debian & derivs. Cheers Ole
Re: Repackaging upstream source with file modifications?
On 2018-02-12 14:11 +0100, Jonas Smedegaard wrote: > Quoting Colin Watson (2018-02-12 13:18:04) > > On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > > > I'd have done the same as Simon. The main advantage is that it makes > > > the tarball free software, which we generally don't get any leeway > > > about > > > > The same advantage is gained by simply patching the replacement code > > into the regenerated tarball in a single step, rather than removing in > > one step and adding in another. > > The tarball should contain only upstream code. Not patched code (then > you arguably are making a fork). But we are encouraged to fork vigorously and often these days (github...I'm looking at you). So Colin can very easily make a fork and then package that and it will still be 'upstream'. It'll make him look younger :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: FTBFS with parallel make
On Fri, 26 Jan 2018 18:21:00 + Niels Thykier wrote: > Please keep in mind that compat 9 and earlier could use --parallel (and > compat 10+ can still use --no-parallel or --max-parallel), so these > numbers are at best rough guesstimates for the number of packages with > parallel enabled/disabled. Maybe adding lintian info "using --no-parallel" is better to track. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Repackaging upstream source with file modifications?
Quoting Colin Watson (2018-02-12 13:18:04) > On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > > On 2018-02-12 11:22 +, Colin Watson wrote: > > > Huh. I hadn't thought of that option, but it seems peculiar and > > > excessively baroque (it basically splits the patch into a remove and an > > > add, making it less obviously identical to the one submitted upstream > > > and harder to keep track of in git). Is there a strong reason to take > > > that approach? > > > > I'd have done the same as Simon. The main advantage is that it makes > > the tarball free software, which we generally don't get any leeway > > about > > The same advantage is gained by simply patching the replacement code > into the regenerated tarball in a single step, rather than removing in > one step and adding in another. The tarball should contain only upstream code. Not patched code (then you arguably are making a fork). Omitting some files when redistributing an upstream project is common and well-documented - please follow that same pattern. - 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: Repackaging upstream source with file modifications?
On 12 February 2018 at 10:28, Colin Watson wrote:
> The developer's reference says [1]:
>
> A repackaged .orig.tar.{gz,bz2,xz} [...] *should not* contain any file
> that does not come from the upstream author(s), or whose contents has
> been changed by you.
>
> My recent attempt to upload grub2 2.02-3 was rejected due to
> https://bugs.debian.org/745409, which I admit I've been putting off
> dealing with for a while; but the relevant tag
> (license-problem-non-free-RFC) was added to the ftpmaster auto-reject
I believe this tag to be a false positive in this case.
Whilst RFC text themselves are not-free, the code components of an RFC
are free under a 3-clause BSD like license.
I only see code components in the grub2 package and no RFC text.
http://trustee.ietf.org/license-info/IETF-TLP-5.htm Section 4 License
to Code Components
--
Regards,
Dimitri.
Re: Repackaging upstream source with file modifications?
On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > On 2018-02-12 11:22 +, Colin Watson wrote: > > Huh. I hadn't thought of that option, but it seems peculiar and > > excessively baroque (it basically splits the patch into a remove and an > > add, making it less obviously identical to the one submitted upstream > > and harder to keep track of in git). Is there a strong reason to take > > that approach? > > I'd have done the same as Simon. The main advantage is that it makes > the tarball free software, which we generally don't get any leeway > about The same advantage is gained by simply patching the replacement code into the regenerated tarball in a single step, rather than removing in one step and adding in another. -- Colin Watson [cjwat...@debian.org]
Re: Repackaging upstream source with file modifications?
On 2018-02-12 11:22 +, Colin Watson wrote: > On Mon, Feb 12, 2018 at 10:42:16AM +, Simon McVittie wrote: > > On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > > > Fortunately, libgcrypt upstream implemented unencumbered replacement > > > CRC code a while back, and over the weekend I worked on backporting > > > this to the version of libgcrypt imported into GRUB > > > > I believe the canonical way to do this is to delete the problematic file > > from the orig tarball, and patch in the reimplementation as part of the > > Debian part of the source package. This will mean your orig tarball is > > incomplete/not compilable, but that isn't something Debian really aims > > to solve. > > Huh. I hadn't thought of that option, but it seems peculiar and > excessively baroque (it basically splits the patch into a remove and an > add, making it less obviously identical to the one submitted upstream > and harder to keep track of in git). Is there a strong reason to take > that approach? I'd have done the same as Simon. The main advantage is that it makes the tarball free software, which we generally don't get any leeway about (although in this case I presume we have in fact been shipping a bit of non-free code for years? so continuing to do so is not making things worse). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Repackaging upstream source with file modifications?
On Mon, Feb 12, 2018 at 10:42:16AM +, Simon McVittie wrote: > On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > > I also cannot simply remove the relevant file in this case (a CRC > > implementation), as doing that would break too many existing parts > > of GRUB. > > > > Fortunately, libgcrypt upstream implemented unencumbered replacement > > CRC code a while back, and over the weekend I worked on backporting > > this to the version of libgcrypt imported into GRUB > > I believe the canonical way to do this is to delete the problematic file > from the orig tarball, and patch in the reimplementation as part of the > Debian part of the source package. This will mean your orig tarball is > incomplete/not compilable, but that isn't something Debian really aims > to solve. Huh. I hadn't thought of that option, but it seems peculiar and excessively baroque (it basically splits the patch into a remove and an add, making it less obviously identical to the one submitted upstream and harder to keep track of in git). Is there a strong reason to take that approach? -- Colin Watson [cjwat...@debian.org]
Re: Repackaging upstream source with file modifications?
On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > I also cannot simply > remove the relevant file in this case (a CRC implementation), as doing > that would break too many existing parts of GRUB. > > Fortunately, libgcrypt upstream implemented unencumbered replacement CRC > code a while back, and over the weekend I worked on backporting this to > the version of libgcrypt imported into GRUB I believe the canonical way to do this is to delete the problematic file from the orig tarball, and patch in the reimplementation as part of the Debian part of the source package. This will mean your orig tarball is incomplete/not compilable, but that isn't something Debian really aims to solve. smcv
Repackaging upstream source with file modifications?
The developer's reference says [1]:
A repackaged .orig.tar.{gz,bz2,xz} [...] *should not* contain any file
that does not come from the upstream author(s), or whose contents has
been changed by you.
My recent attempt to upload grub2 2.02-3 was rejected due to
https://bugs.debian.org/745409, which I admit I've been putting off
dealing with for a while; but the relevant tag
(license-problem-non-free-RFC) was added to the ftpmaster auto-reject
list a while back. I considered overriding it temporarily, but I don't
think I have a very good reason for doing so. I also cannot simply
remove the relevant file in this case (a CRC implementation), as doing
that would break too many existing parts of GRUB.
Fortunately, libgcrypt upstream implemented unencumbered replacement CRC
code a while back, and over the weekend I worked on backporting this to
the version of libgcrypt imported into GRUB [2]. I'm not sure when I
should expect this to be actually reviewed upstream and committed to
master, as review has been pretty slow of late, but I think it's a safe
and reasonable patch given that it's a pretty clean backport.
I considered just applying this as a patch in debian/patches/, but of
course that's still distributing the encumbered file in the
.orig.tar.xz, and Lintian just issues license-problem-non-free-RFC about
the patch file instead. (Again, I could override this, but it seemed
questionable to do so.) So my proposal is to commit this patch to my
"upstream" git branch, prepare grub2_2.02+dfsg1.orig.tar.xz from that
branch, and document this in debian/copyright and debian/README.source.
However, I know it's a bit unconventional to change files in a +dfsg
tarball rather than merely deleting them, and I can't meet the
recommendation of the developer's reference above.
Does this seem like a reasonable way forward, or should I instead just
apply the backport as an ordinary patch and override
license-problem-non-free-RFC for the patch file?
[1]
https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#repackagedorigtargz
[2] https://lists.gnu.org/archive/html/grub-devel/2018-02/msg00033.html
Thanks,
--
Colin Watson [cjwat...@debian.org]
Re: Debian part of a version number when epoch is bumped
On Tue, Feb 06, 2018 at 03:34:50PM +0200, Lars Wirzenius wrote: On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote: On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote: > This is one of the many situations where I'd like developers to *ask* > when unsure or uncertain of something. > So, in fact, the epoch bump was totally useless, and as it often happens > in those cases, it's causing headaches for somebody. Maybe introducing epochs should force a round-trip through NEW... That would completely ruin my plan to only ever release version 1.0 of all of my future projects, but increase the epoch instead. Good :> -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#890227: ITP: dump1090 -- Mode S decoder specifically designed for RTLSDR devices
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: dump1090 Version : unreleased (git) Upstream Author : Salvatore Sanfilippo * URL : https://github.com/antirez/dump1090 * License : BSD Programming Lang: C Description : Mode S decoder specifically designed for RTLSDR devices Main features: - Robust decoding of weak messages, with mode1090 many users observed improved range compared to other popular decoders. - Network support: TCP30003 stream (MSG5...), Raw packets, HTTP. - Embedded HTTP server that displays the currently detected aircrafts on Google Maps. - Single bit errors correction using the 24 bit CRC. - Ability to decode DF11, DF17 messages. - Ability to decode DF formats like DF0, DF4, DF5, DF16, DF20 and DF21 where the checksum is xored with the ICAO address by brute forcing the checksum field using recently seen ICAO addresses. - Decode raw IQ samples from file (using --ifile command line switch). - Interactive command-line-interfae mode where aircrafts currently detected are shown as a list refreshing as more data arrives. - CPR coordinates decoding and track calculation from velocity. - TCP server streaming and receiving raw data to/from connected clients (using --net). For now, I intend to maintain this myself under my salsa namespace. In the future this will likely be moved to a team who might share interest with this package.
