Re: Non-free RFCs in stretch

On Wed, Mar 8, 2017 at 12:16 PM, Tollef Fog Heen wrote: > A package can only be in a single section. That wouldn't prevent adding subsetted Packages files: deb http://ftp.debian.org/debian/ unstable main non-free/firmware non-free/docs Types: deb URIs: http://ftp.debian.org/debian/ Suites:

Re: mining system information of bugs

On Thu, Feb 23, 2017 at 2:16 AM, Adam Borowski wrote: > Anything else you'd want me to get? Core counts for >1? UTC hours or days > of week when bugs are filed? Kernels that've been in the archive vs those > that haven't? I'd be interested in stats of Debian releases, preferred suites, apt

Re: Help requested: Packages which FTBFS randomly

On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote: > This is a charming idea altough I have doubt it will work out: As > usual the information has to be kept up-to-date, so unless it is > collected and verified every now and then automatically, it will > become unsuable pretty soon. FYI the

Re: Personal Git repositories on Alioth (was: manpages.debian.org has been modernized!)

On Sat, Feb 18, 2017 at 9:39 AM, Ben Finney wrote: > Does the resulting repository automatically get published on Alioth, > managed by ‘cgit’ at a ‘anonscm.debian.org’ URL? cgit doesn't do any management, it just publishes existing repos. User repositories are available at URLs like these:

Re: lircd daemon as regular user => device access problems

On Fri, Feb 10, 2017 at 11:13 PM, Alec Leamas wrote: > Thoughts? Your post reminds me of the uaccess and AppStream items here: https://lists.debian.org/debian-devel-announce/2016/11/msg8.html -- bye, pabs https://wiki.debian.org/PaulWise

Re: manpages.debian.org has been modernized!

On Mon, Jan 30, 2017 at 8:54 PM, Alec Leamas wrote: > But, we cannot just say "our tools are as good as github". > Because they are not. That is a very subjective statement. I for one really really dislike github and much prefer other workflows. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Running Debian in the Web browser (JS VM)?

On Thu, Jan 26, 2017 at 11:25 PM, Olivier Berger wrote: > Is anyone working on a "port" of Debian for running in the browser, Probably WebAssembly is a better bet for a Debian port to browsers. > over the JS VM, like what jor1k [0] does ? There was a Debian port to OpenRISC, but it is dead due

Re: HELP - Español and English

On Thu, Jan 26, 2017 at 11:16 PM, Jeans Manuel Morell Veliz wrote: > Can you tell me what is happening to the Debian system? Please contact the Debian user support channels for help: https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise

Re: New user willing to help with Wayland WM packages

On Thu, Jan 26, 2017 at 8:11 AM, Riley wrote: > I am not a DD yet, but I am looking to offer any help I can These pages might be interesting to you: https://www.debian.org/intro/help https://wiki.debian.org/how-can-i-help > Mainly I want to focus on packaging Wayland > tiling window managers,

Re: manpages.debian.org has been modernized!

On Wed, 2017-01-25 at 09:09 +0100, Michael Stapelberg wrote: > Could you please verify whether the -based fallback works for > you? See https://people.debian.org/~stapelberg/fallback/i3.1.en.html > for a demo. The SVG is downloaded but there is no fallback on high security. I wouldn't worry

Re: [Pkg-rust-maintainers] Release impact of introducing a new archive section?

On Tue, Jan 24, 2017 at 4:30 AM, Josh Triplett wrote: > How long does it typically take for that to sync to > https://packages.debian.org/unstable/ and (for instance) The descriptions for that are hardcoded in lib/Packages/Sections.pm, you might want to submit an update for the master branch of

Re: manpages.debian.org has been modernized!

On Mon, 2017-01-23 at 08:47 +0100, Michael Stapelberg wrote: > Could you clarify how I can implement a fallback in a way that works > for Tor Browser please? The solution here appears to work: https://css-tricks.com/a-complete-guide-to-svg-fallbacks/#fallback-object In this case, the page

Re: manpages.debian.org has been modernized!

On Mon, 2017-01-23 at 08:45 +0100, Michael Stapelberg wrote: > What would be the best way to trigger on mirror pushes? I'm not sure about that, please ask #debian-mirrors or failing that #debian-admin, and or the lists. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: manpages.debian.org has been modernized!

On Thu, 2017-01-19 at 09:35 +0100, Michael Stapelberg wrote: > To: Paul Wise <p...@debian.org> I'm subscribed :) > No. Isn’t that a violation of the FHS (see > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA) > and Debian policy? I suppose

Re: manpages.debian.org has been modernized!

On Thu, Jan 19, 2017 at 6:37 AM, Ian Jackson wrote: > As you might expect, I'm uncomfortable about the use of the > proprietary github service for this. I realise that we don't > necessarily have entirely comparable alternatives, but Free Software > needs free tools.[1] Agreed for both bugs and

Re: manpages.debian.org has been modernized!

On Thu, Jan 19, 2017 at 1:23 AM, Michael Stapelberg wrote: > https://manpages.debian.org has been modernized! We have just launched > a major update to our manpage repository. What used to be served via a > CGI script is now a statically generated website, and therefore > blazingly fast. My dman

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

On Wed, Jan 18, 2017 at 1:08 AM, Russ Allbery wrote: > Santiago Vila writes: >> In this context, I refer specifically to flaky tests. What I call >> questionable is keeping a flaky test making the build to fail when the >> test fails so much that it's clearly a wrongly designed test. > > Oh, sure,

Accepted check-all-the-things 2017.01.15 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 15 Jan 2017 10:37:30 +0800 Source: check-all-the-things Binary: check-all-the-things Architecture: source Version: 2017.01.15 Distribution: unstable Urgency: high Maintainer: Paul Wise <p...@debian.org> Changed-By: Pau

Re: Feedback on 3.0 source format problems

On Sun, Jan 8, 2017 at 8:05 PM, Johannes Schauer wrote: > I'm not very familiar with pbuilder. Looking at the man page it seems that > pbuilder itself exclusively accepts a source package .dsc and for building a > source directory one needs the pdebuild wrapper? Right. > If that is the case,

Re: Newcomer to Debian: Help wanted

On Sun, Jan 8, 2017 at 5:05 PM, Vijeth T Aradhya wrote: > Hey guys I'd like to start contributing to Debian and be a part of the > community. I just need some help getting started! Great! Here are some ideas for things to work on: https://www.debian.org/intro/help > When I looked at the bug

Re: unattended-upgrades by default

On Sat, Jan 7, 2017 at 6:29 AM, Nikolaus Rath wrote: > What now? Clearly the answer of unattended-upgrades or not is situation dependent and the solution should depend on who is running Debian in what context. Desktop users should get whatever UI is available for the particular desktop that is

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

On Fri, Jan 6, 2017 at 3:27 AM, Sean Whitton wrote: > Could you explain "lower bus factor" a bit more, please? Don already explained this for the BTS, but in general, many if not most of the services Debian provides are maintained by 0.5 person (one busy person who already has lots of other

Re: Hiding library packages from apt searches by default? (was: Re: Worthless node-* package descriptions in ITPs)

On Thu, Jan 5, 2017 at 9:32 PM, Christian Seiler wrote: > Could we maybe hide library packages from apt searches by default? This is going to have unintended consequences; for example, if we base it on Debian Section fields, library source packages that build a binary package containing tools,

Re: Feedback on 3.0 source format problems

On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote: > But I am not sure if a package structure like > > mypkg/upstream/* > mypkg/debian/* > mypkg/patches/* (?) > > would have any *practical* benefits over the current situation, because > this transformation could be trivially automated in either

Re: Feedback on 3.0 source format problems

On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote: > I'm interested in what things people still find so off-putting to the > point of not wanting to use the new 3.0 source formats. I've been reading this thread and keep being reminded of our discussion on #debian-dpkg a while ago. I think

Re: Feedback on 3.0 source format problems

On Wed, Jan 4, 2017 at 2:54 AM, Russ Allbery wrote: > Well, if we had one more thing: a patches.debian.org service that would > show the git-debcherry-extracted patches against upstream. I really like > being able to just point upstream at all the patches relevant to them that > Debian has

Accepted autorevision 1.20-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 04 Jan 2017 10:03:03 +0800 Source: autorevision Binary: autorevision Architecture: source Version: 1.20-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise <p...@debian.org> Changed-By: Paul Wise <p...@d

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

On Tue, Jan 3, 2017 at 5:38 PM, Abou Al Montacir wrote: > What about requiring signed mail for closing a bug report? We have sponsored maintainers, who theoretically could get by entirely without an OpenPGP key. I don't know if any exist but I don't think they should be blocked from -done. Also,

Re: [Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

On Tue, Jan 3, 2017 at 2:28 AM, Andrey Rahmatullin wrote: > Probably we don't have enough people looking at the spam reports. That > probably could be improved with better advertising, e.g. on > https://www.debian.org/intro/help Right now only the BTS admins can look at and act on spam reports.

Re: wanna-build doesn't email the maintainer on build failures by default

On Sat, Dec 31, 2016 at 9:23 PM, Mattia Rizzolo wrote: > But you should probably remove mips64el, which is a release arch now. Not hard-coding the list of release architectures would be best. -- bye, pabs https://wiki.debian.org/PaulWise

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

On Tue, Dec 27, 2016 at 7:03 AM, Ian Jackson wrote: > When I decided that debbugs should work like this: I think this was the right decision and still is, with this additional reason: Folks are much busier these days and every extra unnecessary email takes extra time and brain space that could

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

On Tue, Dec 27, 2016 at 12:29 AM, Samuel Thibault wrote: > This happens again and again... Quite a few maintainers don't seem to > realize that mails sent to n...@bugs.debian.org are not sent to the bug > submitter, and the bug tracking thus halts down completely when the > maintainer asks for

Re: unattended-upgrades by default?

On Tue, Dec 27, 2016 at 12:35 AM, Paul van der Vlis wrote: > I use a script on a few servers to realize this, it's not perfect: > http://vandervlis.nl/files/updateafter It might be interesting to contribute this to unattended-upgrades. > I use "at" to reboot very early in the morning:

Re: Bug#817602: olpc-xo1: Removal of debhelper compat 4

On Sun, Dec 25, 2016 at 10:38 AM, Andres Salomon wrote: > Thanks for the patch. Given that OLPC isn't really alive any more, > I'm thinking the OLPC packages should probably just be removed from the > archive for Stretch. Popcon shows exactly 1 installation of this > package..

Re: unattended-upgrades by default?

On Sun, Dec 25, 2016 at 8:34 AM, Paul van der Vlis wrote: > I am doing this myself already on desktop systems so I have some > experiences with it. Thanks for sharing your experience. > What I would really like is a mechanism where the user can tune after > how many days the upgrade will occur.

Accepted check-all-the-things 2016.12.25 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 25 Dec 2016 08:02:09 +0800 Source: check-all-the-things Binary: check-all-the-things Architecture: source Version: 2016.12.25 Distribution: unstable Urgency: medium Maintainer: Paul Wise <p...@debian.org> Changed-By: Pau

Re: Help with watch file

On Thu, Dec 22, 2016 at 5:33 AM, Ghislain Vaillant wrote: > I am trying to write a watch file suitable for fetching tarballs from a > *link* published on a GitHub release page [1]. It seems this link > points to a different location on Amazon S3 [2]. For the arrayfire-full tarballs: version=3

Accepted autorevision 1.19-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Dec 2016 08:32:37 +0800 Source: autorevision Binary: autorevision Architecture: source Version: 1.19-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise <p...@debian.org> Changed-By: Paul Wise <p...@d

Re: which JavaScript dependencies really need a separate package?

On Mon, Dec 19, 2016 at 4:30 PM, Daniel Pocock wrote: > - For those JavaScript libs that have complicated build systems that are > not (yet) supported on Debian, is it reasonable for a package like > homer-ui to simply include the intermediate product of the build, just > before it is minified,

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote: > Is there any way to simplify? Remove the obsolete armel binaries where they occur and then mark the packages as NFU on armel: https://wiki.debian.org/ftpmaster_Removals https://wiki.debian.org/PackagesArchSpecific -- bye, pabs

Accepted debian-installer-launcher 27 (source) into unstable

org> Changed-By: Paul Wise <p...@debian.org> Description: debian-installer-launcher - Debian Installer desktop launcher Changes: debian-installer-launcher (27) unstable; urgency=medium . [ Paul Wise ] * QA upload. * Drop codename from the desktop file . [ scootergrisen ]

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote: > Yes, but that still says: Ack. > I think a proper procedure should involve a script that: > > - is packaged in Debian; Ack. > - checks whether the hardware it's running on has all the hardware >   requirements for the new

Re: Auto-detecting -dev package dependences from pkg-config

On Thu, Dec 15, 2016 at 8:43 PM, Guillem Jover wrote: > There's also . I'd be happy to > include such tool in dpkg itself. I think this is one of the current > limitations we have in dpkg-dev compared to say rpm, which has many > build-time dependency generators.

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to armhf ones, without > requiring a reinstall. There is a script for that here: https://wiki.debian.org/CrossGrading

Re: Re: Does or will Debian support NVDIMM?

On Wed, Dec 14, 2016 at 11:57 AM, Qi Zhang wrote: > Can I understand it as once Debian has package ndctl, NVDIMM will be fully > supported? It sounds like it, but probably someone who owns NVDIMM hardware will need to test everything works. > BTW, do you know when bug #829257 will be resolved?

Re: Release impact of introducing a new archive section?

On Mon, Dec 12, 2016 at 5:22 AM, Josh Triplett wrote: > If we can get every package to handle this entirely at runtime, then > ideally I'd suggest archive metadata downloaded by apt. That would have > the advantage of automatically handling new sections, including for > third-party archives.

Re: Hello: https://manpages.debian.org/man/1/uscan

You can read about the plans for manpages here: https://wiki.debian.org/manpages.debian.org The debmans software renders manual pages to proper HTML that looked reasonable to me. -- bye, pabs https://wiki.debian.org/PaulWise

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote: > Also, dedicated tiny flash partitions for the kernel and initrd. I > wouldn't be surprised to be find that by the time we want to release > buster we can't build a useful kernel that fits into the 2 MB partition > that most of these devices

Re: Test instance of our infrastructure

On Thu, Dec 8, 2016 at 10:24 PM, Javier Fernandez-Sanguino wrote: > ... and there are no real requirements to > test the current setup with new Debian releases. You may want to subscribe to debian-services-admin, where DSA have requested testing of services against Debian stretch:

Re: Test instance of our infrastructure

On Mon, Nov 28, 2016 at 8:04 PM, Ian Jackson wrote: > Should we not have public test instances of all these things ? If this will increase the bus factor of Debian services, that would be great. If this will just be a time sink for the people involved, that would be less great. On balance, it

Re: debian-keyring not updated?

On Sun, Dec 4, 2016 at 2:09 AM, Pirate Praveen wrote: > Previous uploads were more frequent so I wondered if there was an issue. Probably best to talk to keyring maint than debian-devel. -- bye, pabs https://wiki.debian.org/PaulWise

Re: [Letsencrypt-devel] Certbot in Debian Stretch

On Thu, Dec 1, 2016 at 5:34 AM, Christian Seiler wrote: > Ah, and I ran my strace earlier with -e open,access, but after > rechecking it, it does in fact check for the file's existence > via stat(). I should remember to use -e open,access,stat when > checking for file access with strace. [1] ...

Re: about build flavours

On Wed, 2016-11-30 at 11:11 +0100, Arturo Borrero Gonzalez wrote: > I don't think hyperscan currently is able to detect SSE3 support at runtime. Sounds like a bug. > Do you think that the warning at install-time is not enough? Sounds like a reasonable workaround for the bug. -- bye, pabs

Re: about build flavours

On Wed, Nov 30, 2016 at 6:01 PM, Sascha Steinbiss wrote: > Yes, the libhyperscan package alerts the user at pre-install time if > SSE3 is not supported on the target system. That's one of the reasons > why I think there should still be a version of suricata that works > without Hyperscan. Sounds

Re: about build flavours

On Tue, Nov 29, 2016 at 8:35 PM, Arturo Borrero Gonzalez wrote: > we are trying to create a build flavour for the suricata package [0], > which we would like to link to hyperscan, which uses SSSE3. I hope it detects the presence of SSE3 at runtime. -- bye, pabs

Re: Certbot in Debian Stretch

On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote: > currently working with an ACME backwards compatibilty window of 6-12 months, > but probably not longer than that. I note that letsencrypt 0.4.1-1 (before the rename to certbot) is available in Ubuntu xenial, which is scheduled for 5 years

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

On Wed, Nov 23, 2016 at 5:24 PM, Simon McVittie wrote: > (I'm not entirely sure why we consider hardening packaged code to be so > much more important than hardening the locally-built code compiled by > our users, which changed compiler defaults like those in Ubuntu > would also give us.) IIRC,

Accepted autorevision 1.18-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 23 Nov 2016 10:23:57 +0800 Source: autorevision Binary: autorevision Architecture: source Version: 1.18-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise <p...@debian.org> Changed-By: Paul Wise <p...@d

Re: Let's stop using CVS for debian.org website

On Sun, Nov 20, 2016 at 10:45 AM, Boyuan Yang wrote: > Needless to say there are various tools that can help convert a CVS repo into > a SVN repo or Git repo and they handle this job properly. This idea comes up every few years but we haven't yet found someone with the time, skills and

Re: Bug#805116: ITP: wifi-switcher

On Sat, Nov 19, 2016 at 10:18 AM, Oleg SHALAEV wrote: > but I can not do it because I am not a Debian Developer. > Is it possible to submit the program to a Debian Developer, > or I have to register as a a Debian Developer myself? Please read this page:

Accepted autorevision 1.17-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 19 Nov 2016 08:32:27 +0800 Source: autorevision Binary: autorevision Architecture: source Version: 1.17-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise <p...@debian.org> Changed-By: Paul Wise <p...@d

Re: Building architecture:all packages

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote: > implies "src:foo" must build on *all* architectures In general, Debian does not define the build architecture for any package, no matter what the Architecture of the package is. In practice, arch:all packages must build on either amd64

Re: Building architecture:all packages

On Sat, Nov 12, 2016 at 6:32 AM, Christoph Biedl wrote: > How would this affect your assessment of the situation? The details matter, without them I don't think any assessment is useful. > In my feeling, revealing the packages' names would give the story some kind of > blaming. That's not my

Re: Building architecture:all packages

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote: > Other suggestions? Include information about which packages/issues you are talking about. -- bye, pabs https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

On Wed, 2016-11-09 at 22:55 +0200, Adrian Bunk wrote: > Is anyone tracking what packages are installed from backports on > Debian machines, and the CVEs in them? backports is unsupported by the security team, so DSA & backports users rely on service maintainers and backporters to do the right

Re: unattended-upgrades by default?

On Wed, 2016-11-09 at 23:06 +0200, Adrian Bunk wrote: > Any "solution" for the reboot problem that assumes that there is a > user who regularly logs into the machine misses the problem. Any solution that is the same for every device is completely wrong. Cloud images should probably auto-reboot

Re: More 5 november in the release schedule

On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote: > Right. We want auto-removals to be useful for the release process, so that we > don't end up with a thousand of RC bugs in testing when we freeze, most of > them > on packages that nobody cares about, not even their maintainers. > >

Re: More 5 november in the release schedule

On Tue, Nov 8, 2016 at 3:19 PM, Brian May wrote: > The problem is if the maintainer is not responding to RC bug reports, > and you don't realize a package you depend on has RC bugs. This happened > several times to me during the last freeze. Assuming you have your package and its dependencies

Re: unattended-upgrades by default?

On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote: > Forced reboot on upgrade is damage. Let's learn from errors of others. needrestart has a mechanism (needrestart-session) to hook into user sessions, perhaps that could be extended to request users reboot for security updates. -- bye, pabs

Re: unattended-upgrades by default?

On Sat, Nov 5, 2016 at 1:25 PM, Michael Vogt wrote: > Thanks for this reminder Paul! #828215 is fixed in git and will be > part of the next upload (which should happy early next week). Thanks! If you have time, a fix for jessie/wheezy would be appreciated too. -- bye, pabs

Re: Bug#843185: ITP: aravis -- A vision library for genicam based cameras

On Sat, Nov 5, 2016 at 1:13 AM, Chiara Marmo wrote: > Description : a vision library for genicam based cameras It would be great if you could add some metadata about which hardware is supported. By doing so, you will enable users to discover your package when they plug in a new device

Re: unattended-upgrades by default?

On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote: > * it will be a different experience compared to what people will get >when installing Debian normally, using d-i / debootstrap. That should be fixed in d-i IMO. > To solve the issue and provide security updates by default, I'm >

Accepted apt-move 4.2.27-5 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 02 Nov 2016 13:11:28 +0800 Source: apt-move Binary: apt-move Architecture: source Version: 4.2.27-5 Distribution: unstable Urgency: medium Maintainer: Debian QA Group <packa...@qa.debian.org> Changed-By: Paul W

Re: Lots and lots of tiny node.js packages

On Wed, Nov 2, 2016 at 9:04 AM, Russ Allbery wrote: > If upstream themselves aggregates, then this works well. (See, for > instance, TeX Live, which is basically an upstream aggregation of > independently-released packages.) That gets its own version number and > its own unique existence and

Re: Rebuilds with unexpected timestamps [and 1 more messages]

On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote: > At that point the best solution would be an alternative source > package format that is based on git. That already exists (see the dpkg-source manual page), but IIRC isn't allowed in the archive because the ftp-masters do not want to have

Re: Rebuilds with unexpected timestamps

On Mon, Oct 31, 2016 at 12:02 AM, Ian Jackson wrote: > Could someone point me at some tools, or volunteer to help, or something ? Check out the wiki page about this: https://wiki.debian.org/qa.debian.org/ArchiveTesting > I ask because have found a new way to break packages :-). Whee! > What

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

On Sun, Oct 30, 2016 at 12:05 PM, Adam Borowski wrote: > That database looks like something easy to check, and since most if not all > Debian node.js packages use naming consistent with npm, it could be > automated. (Please tell me it already is.) It is not automated. Every few months I find a

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

On Sat, Oct 29, 2016 at 12:00 AM, Russ Allbery wrote: > such as patching Javascript for security vulnerabilities FYI, the Debian security team does not support the NodeJS ecosystem. We probably need more folks following Node security issues. Some of those are listed here:

Accepted apt-show-source 0.10+nmu5 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 24 Oct 2016 14:49:40 +0800 Source: apt-show-source Binary: apt-show-source Architecture: source Version: 0.10+nmu5 Distribution: unstable Urgency: medium Maintainer: OHURA Makoto <oh...@debian.org> Changed-By: Paul W

Re: Planned NMU of w3-recs would use much archive disk space

On Thu, Oct 27, 2016 at 8:16 AM, Thaddeus H. Black wrote: > I am moving [1] to NMU a big non-free package, w3-recs [2][3], > last updated five years ago. During the last five years, > upstream has grown, both in volume [4] and in scope [5], for > legitimate reasons. The new *.orig.tar.gz or

Re: "Dear Customer" spam in the BTS

On Wed, Oct 26, 2016 at 7:43 PM, Tomas Pospisek wrote: > Has anyone tried to do such a thing yet (methodically clean the bug > archive of spam)? Where and how could I start such an effort? How would > I get read/write access to the BTS archive? The BTS admins do that regularly, based on people

Accepted debdry 0.2.2-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 25 Oct 2016 09:19:23 +0800 Source: debdry Binary: debdry Architecture: source Version: 0.2.2-1 Distribution: unstable Urgency: medium Maintainer: Debian QA Group <packa...@qa.debian.org> Changed-By: Paul Wise <p...@d

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

On Tue, Oct 25, 2016 at 7:33 AM, Russ Allbery wrote: > Tor is easier for us as a project, since we don't really have to do > anything (assuming we just rely on existing exit nodes). Debian has Tor onion service frontends to various Debian services, including several Debian machines with archive

Re: client-side signature checking of Debian archives

On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote: > The point is to improve privacy. Better privacy than https can be had using Tor: https://onion.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

On Fri, Oct 21, 2016 at 2:35 PM, Ian Campbell wrote: > I think there are also physical arm64 systems using EDK2/Tianocore as > their firmware. Unmodified upstream versions that you can re-flash? I got the impression most UEFI firmware is based on EDK2/Tianocore, even on x86, but it has

Re: NRSS has been deprecated [#696302]

On Fri, Oct 21, 2016 at 1:34 PM, Adam Borowski wrote: > we should have some way to query if anybody would object to a package's > removal? We definitely need better ways to connect with package users, but it might be hard to do that in a privacy preserving way. Perhaps something similar to

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

On Fri, Oct 21, 2016 at 4:20 AM, Tollef Fog Heen wrote: > If there are machines with free firmware that also support secure boot, > we can look at this. So far, I don't believe there are any. Tianocore (edk2 in Debian) supports virtual machines and also any device that supports coreboot could

Re: NRSS has been deprecated [#696302]

On Fri, Oct 21, 2016 at 12:17 AM, Enrico Rossi wrote: > I saw that the upstream devel of NRSS has deprecated it in favour of > another software. This has been already reported in the #696302. This is what the nrss upstream website says: NRSS has been deprecated. Use Canto in the future. You

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

On Wed, Oct 19, 2016 at 12:03 AM, Jakub Wilk wrote: > it's only used as a fallback for nodejs < 4. Debian currently has 4.6.0. Does this mean the ITP can be closed? -- bye, pabs https://wiki.debian.org/PaulWise

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote: > I'm afraid I can't make sense of this. You have posted it to > debian-devel, but without any kind of sensible explanation of the > context. It was posted to bug #820036, which is tracking Debian support for secure boot. Peter was advocating

Accepted apt-xapian-index 0.49 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 18 Oct 2016 11:15:35 +0800 Source: apt-xapian-index Binary: apt-xapian-index Architecture: source Version: 0.49 Distribution: unstable Urgency: medium Maintainer: Debian QA Group <packa...@qa.debian.org> Changed-By: Pau

Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

On Tue, Oct 18, 2016 at 4:21 AM, Josh Triplett wrote: > These are distinct packages, with distinct version numbers, and packages > will need to declare (potentially versioned) dependencies on them. Has anyone involved in the node ecosystem tried to talk the respective upstreams into creating a

Re: uscan download from sourceforge doesn't download what you expect!

On Sun, Oct 16, 2016 at 2:49 AM, Dimitri John Ledkov wrote: > Yes, this is known to me, but I did not report. The redirector / > sourceforge make it hard to distinct identically named files in > different subfolders unfortunately. This was a bug in the redirector, I've added additional links

Re: When should we https our mirrors?

On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote: > Doing this for the per-country mirrors means that repointing mirrors > becomes a lot harder than it currently is, and this is something we do > on a daily basis. We'd need a solution for deploying the TLS cert for, > say, ftp.de.d.o to

Re: When should we https our mirrors?

On Sun, Oct 16, 2016 at 2:03 AM, Paul Tagliamonte wrote: > So, when are we going to push this? If not now, what criteria need to be > met? Why can't we https-ify the default CDN mirror today? Exactly what actions do you mean by this? Debian does not control what mirror operators do, they are

Re: uscan download from sourceforge doesn't download what you expect!

On Sun, Oct 16, 2016 at 1:47 AM, Steve M. Robbins wrote: > Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? These days the reflector is just a proxy for the sourceforge RSS feeds: https://sourceforge.net/projects/boost/rss?limit=1000 So check if the

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

On Thu, Oct 13, 2016 at 6:16 AM, Ben Finney wrote: > How will we know that those are the corresponding source for the work > Debian installs? The maintainer could have verified it before uploading. > One way is to actually use that exact source, to build the package. That is the only realistic

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

On Tue, Oct 11, 2016 at 8:56 PM, Ondřej Surý wrote: > Fine, I'll bundle them as well. Bundling the actual source instead of prebuilt files still doesn't solve the problem of not being able to build from source because the build tools are missing from Debian. It has always been ftp-master policy

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote: > Anybody is free to package epoch.js into separate package and I'll > switch to using it, just don't shove more work by using BTS severities. epoch.js upstream publishes their build info, so it looks like the first step would be to finish the

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

On Tue, Oct 11, 2016 at 8:30 PM, Ondřej Surý wrote: > Definitely not serious here, as I do ship original sources from within > the package: > > $ find . -name 'epoch*' > ./modules/http/static/epoch.css > ./modules/http/static/epoch.js > ./debian/missing-sources/epoch.css >

<    4   5   6   7   8   9   10   11   12   13   >