Release impact of introducing a new archive section?
[Please CC me on replies.] ftp.debian.org has a few outstanding bugs requesting new archive sections, such as "javascript" and "rust". Discussions on IRC #debian-devel led to the mail at https://lists.debian.org/debian-devel/2015/05/msg00287.html , which identifies a few different packages that hard-code section names and descriptions. Long-term, we should likely introduce a new repository metadata file listing archive sections and descriptions (including translations); that would allow software dealing with the archive to automatically handle new sections, as well as repositories that want to introduce their own sections. In the meantime, however, introducing a new section requires updating a half-dozen pieces of software, such as aptitude, synaptic, packagekit, lintian, and vim. Does it seem reasonable to attempt to introduce these new sections before the release, so that these pieces of software in stable can successfully work with upcoming sections that will appear in testing/unstable/backports? I'd be willing to write appropriate bug reports and patches for the various packages listed in the mail above. I (and ftpmaster) would like to get input from the release team if they see negative effects on the release from such a change. - Josh Triplett
What happened to the idea of using migrations and coordinated uploads when updating packages that has many reverse dependencies?
[adding -devel] On Sun, 4 Dec 2016 20:54:50 +0100 Paul Gevers wrote: > There was only major reshuffling in the building. The final js and css > files are, minus whitespace, identical to the files shipped upstream. So > if this is an issue with the js or css file, it is an upstream issue. > > I am very inexperienced in debugging javascript, so I'd appreciate any > help to fix this issue. This was caused by updating to 1.12.1 then. This needs changes even from 1.11 to 1.12 migration https://jqueryui.com/upgrade-guide/1.12/ I have asked upstream help https://gitlab.com/gitlab-org/gitlab-ce/issues/25302 Please give a heads up to maintainers of reverse dependencies before updating to a newer version next time. When many maintainers do this breaking updates without consulting maintainers of reverse dependencies (update of jquery to version 3 broke diaspora), it is seriously demotivating to maintain large packages like gitlab and diaspora. There will be many to break but not many to help fix. It took years of work to bring these packages to their current state and having to fix these issues at the last moment of a release is not fun. signature.asc Description: OpenPGP digital signature
Bug#847046: ITP: podcastparser -- Simple, fast and efficient podcast parser in Python
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: podcastparser Version : 0.6.0 Upstream Author : Thomas Perl * URL : https://github.com/gpodder/podcastparser * License : Expat/MIT Programming Lang: Python Description : Simple, fast and efficient podcast parser in Python The podcast parser project is a library from the gPodder project to provide an easy and reliable way of parsing RSS- and Atom-based podcast feeds in Python. This is being packaged as a dependency of gPodder version 3.9.2. signature.asc Description: PGP signature
Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
Philipp Kern wrote: > On 04.12.2016 15:47, Pirate Praveen wrote: > > Those of us feeling weird can go through the list here [1] and see > > which of those are weird and help create a patch for their parent > > module and convince their upstream to use a patch instead. If you > > can't convince them, maintaining a fork would be fine too. > > You'd think that the effort to package up [1] would be more than to > patch the software using it. Patching upstream source always makes more work (especially long-term) than packaging unmodified upstream source. Patched upstream source incurs technical debt. Getting the fix accepted upstream eliminates that technical debt, and if upstream will take the fix and just add a hard dependency on gulplog, that seems like an improvement. But if upstream won't take the patch, then packaging a tiny script seems *far* easier than maintaining a permanent fork to avoid it. - Josh Triplett
https: ę?p=líber &suite=sid ://buildd.debian.org/status/package.php?p=libdr-tarantool-perl&suite=río r ://buildd.debian.org/status/package.php?p=libdr-tarantool-perl&suite=sid ://buildd.debian.org/sta
El temeeporada de
Re: MIA maintainers and RC-buggy packages
On Sun, Dec 04, 2016 at 01:14:42PM +0100, Christoph Biedl wrote: >... > To add a few criteria, I'd remove a package from sid only if it >... > * has been orphaned for a longer time, say: a year > So again users of that package had a grace period to ask for work on > that package. >... Two questions: 1. Whom and how should a user ask? 2. How would a user even notice that a package that is important for him has been orphaned? The majority of Debian users are running stable, and upgrade to a new stable every 2 years. Example for the packages we are talking about: ispell-lt (#704968) Orphaned for 3.5 years, no open bugs. This is a package with relatively low popcon that is not being adopted, both for an obvious reason (Lithuania is a small country). There are likely *users* for whom this package is important, but the number of *developers* who did a package upload in 2016[1] and speak Lithuanian might be zero. > Christoph cu Adrian [1] any package, as definition of "active developer" -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#847003: ITP: connid -- framework for provisioning identities to repositories
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: connid Version : 1.4.2.0 Upstream Author : ConnId * URL : http://connid.tirasa.net/ * License : CDDL Programming Lang: Java Description : framework for provisioning identities to repositories Connectors for Identity Management (ConnId) is a framework for developing identity connectors, the technology layer that takes place in the exchange of identity-related information (password, attributes) between identity managers (such as Apache Syncope) and identity repositories (e.g. LDAP directories, relational databases). It is used in Free Identity Managers, including Apache Syncope and Evolveum midPoint. I plan to maintain it within the pkg-java team. I will need a sponsor.
Re: Building architecture:all packages
On Sun, Dec 04, 2016 at 07:39:44PM +0100, Christoph Biedl wrote: > Adam Borowski wrote... > > I see two problems in that code: > > * it's Launchpad-specific > > * it supports only a single build-indep architecture rather than a list > > Um, yes, perhaps, no. The important thing to me is there's already > something around that solves a problem I have. Of course this header > should see a formalization, and certainly this should be a list. I've > filed #846970. Looks great, thanks! > > With my 3270font maintainer hat on: I wouldn't even know of this if not for > > the reproducible builds project, despite doing lots of rebuilds on various > > architectures (albeit not really for this package). I guess there's a lot > > of other arch-dependant failures for arch:all packages. > > Err, hi. I admit I deliberately did not notice you beforehand - mostly > to keep you out of some hazzle you are not responsible for at all. Since > however even the recent fontforge upgrade did not change the situation, > I might ask you to include that header once the above process has come > to a result. Actually, I wonder if it's a good idea to differentiate somehow between transient bugs and architectures the package is not supposed to build on. Some kind of annotation? As for finding currently failing packages, it's a matter of looking at existing archive rebuild logs. -- u-boot problems can be solved with the help of your old SCSI manuals, the parts that deal with goat termination. You need a black-handled knife, and an appropriate set of candles (number and color matters). Or was it a silver-handled knife? Crap, need to look that up.
Re: Building architecture:all packages
Adam Borowski wrote... > I see two problems in that code: > * it's Launchpad-specific > * it supports only a single build-indep architecture rather than a list Um, yes, perhaps, no. The important thing to me is there's already something around that solves a problem I have. Of course this header should see a formalization, and certainly this should be a list. I've filed #846970. > With my 3270font maintainer hat on: I wouldn't even know of this if not for > the reproducible builds project, despite doing lots of rebuilds on various > architectures (albeit not really for this package). I guess there's a lot > of other arch-dependant failures for arch:all packages. Err, hi. I admit I deliberately did not notice you beforehand - mostly to keep you out of some hazzle you are not responsible for at all. Since however even the recent fontforge upgrade did not change the situation, I might ask you to include that header once the above process has come to a result. Regards, Christoph signature.asc Description: Digital signature
Bug#846967: ITP: r-cran-dbitest -- GNU R testing 'DBI' back ends
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-dbitest Version : 1.4 Upstream Author : Kirill Müller * URL : https://cran.r-project.org/package=DBItest * License : LGPL Programming Lang: GNU R Description : GNU R testing 'DBI' back ends This package provides a helper that tests 'DBI' back ends for conformity to the GNU R interface. Remark: This package is needed to run the autopkgtest of r-cran-rsqlite. It will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dbitest/trunk/
Re: MIA maintainers and RC-buggy packages
Michael Meskes wrote... > Sure, but then it would be nice if you'd tried finding out if nobody > cares. As usual the real world is neither white not black, but some > shade of gray. The problem with the package is that the new version > does not build on my system but I lack the time to debug, could be > minor but still. Did you document your attempts so people willing to help have a point to start from? > If anyone wants to help, the package is tora. At least the current serious bug #811663 was rather easy to handle. You should have got mail. Christoph signature.asc Description: Digital signature
Bug#846962: ITP: r-cran-withr -- GNU R package to run code 'With' temporarily modified global state
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-withr Version : 1.0.2 Upstream Author : Jim Hester * URL : https://cran.r-project.org/package=withr * License : GPL Programming Lang: GNU R Description : GNU R package to run code 'With' temporarily modified global state A set of functions to run code 'with' safely and temporarily modified global state. Many of these functions were originally a part of the 'devtools' package, this provides a simple package with limited dependencies to provide access to these functions. Remark: This package is a precondition for r-cran-dbitest which is in turn needed to run the autopkgtest for the new version of r-cran-rsqlite. It will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-withr/trunk/
Re: debian-keyring not updated?
On Sat, Dec 03, 2016 at 11:39:44PM +0530, Pirate Praveen wrote: > On ശനി 03 ഡിസംബര് 2016 11:26 വൈകു, Mattia Rizzolo wrote: > > Yes, the package is not updated every time there is a keyring push. > > What's tagged is what is live on the debian.org infrastructure, not > > what's in the package (and probably you shouldn't rely on that either if > > you need an up-to-date keyring locally). > > > Thanks for the info. Previous uploads were more frequent so I wondered > if there was an issue. If you want the active keyring then the canonical way to get it is use rsync from keyring.debian.org::keyrings/keyrings/ - the sha512sums.txt file is always signed by one of keyring-maint. We also try to keep the read-only copy of the keyring git repo at https://anonscm.debian.org/cgit/keyring/keyring.git/ up to date when a new keyring is made active (pending changes are kept within a private repo for potential security reasons), but that's primarily because there are various things that use the git changelog to understand what changes have happened. The only time we make a concerted effort to ensure the debian-keyring package is up to date in the archive is around the release, so that stable has as current a copy as possible at the point of release. We do generally try and keep it up to date in unstable, but if you care about what's current you should always use the rsynced version. J. -- /-\ | 101 things you can't have too much |@/ Debian GNU/Linux Developer | of : 34 - Beaches. \- | signature.asc Description: Digital signature
Bug#846957: ITP: jid -- json incremental digger
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: jid Version : 0.6.0 Upstream Author : Copyright (c) 2016 simeji * URL : https://github.com/simeji/jid/ * License : Expat Programming Lang: golang Description : json incremental digger jid is simple tool to inspect json. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Bug#846955: ITP: node-flagged-respawn -- A tool for respawning node binaries when special flags are present
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-flagged-respawn Version : 0.3.2 Upstream Author : Tyler Kellen (http://goingslowly.com/) * URL : https://github.com/js-cli/js-flagged-respawn * License : Expat Programming Lang: JavaScript Description : A tool for respawning node binaries when special flags are present. signature.asc Description: OpenPGP digital signature
Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
On 04.12.2016 15:47, Pirate Praveen wrote: > Those of us feeling weird can go through the list here [1] and see which of > those are weird and help create a patch for their parent module and convince > their upstream to use a patch instead. If you can't convince them, > maintaining a fork would be fine too. You'd think that the effort to package up [1] would be more than to patch the software using it. Especially when it boils down to a "true" because gulplog is actually a dependency here. I understand why you are annoyed, but some of these are silly. I think we are beyond the "let's collect random modules into big packages" at this point but it's IMO still fair to call out problematic ones like this one. Kind regards Philipp Kern [1] https://github.com/gulpjs/has-gulplog/blob/master/index.js signature.asc Description: OpenPGP digital signature
i'am back in control of my life
http://rentkievapartment.com/14.php?nt&4vq3zqf=pjz&s=bfj5wt8&y27&wtfr==u7&prf329= http://rentkievapartment.com/14.php?nt&4vq3zqf=pjz&s=bfj5wt8&y27&wtfr==u7&prf329= -
Bug#846947: ITP: node-sequencify -- A module for sequencing tasks and dependencies
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-sequencify Version : 0.0.7 Upstream Author : Rob Richardson (http://robrich.org/) * URL : https://github.com/robrich/sequencify * License : Expat Programming Lang: JavaScript Description : A module for sequencing tasks and dependencies signature.asc Description: OpenPGP digital signature
Bug#846949: ITP: node-stream-consume -- Consume a stream to ensure it keeps flowing
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-stream-consume Version : 0.1.0 Upstream Author : Aron Nopanen * URL : https://github.com/aroneous/stream-consume * License : Expat Programming Lang: JavaScript Description : Consume a stream to ensure it keeps flowing signature.asc Description: OpenPGP digital signature
Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
On 2016, ഡിസംബർ 4 8:03:01 PM IST, Tollef Fog Heen wrote: >]] Pirate Praveen > >> Description : Check if gulplog is available before attempting >to >> use it > >Is there a node-has-has-gulplog too, to check for if has-gulplog is >available before attempting to use it? This package sounds a bit >weird, >even as Node.js packages go. Those of us feeling weird can go through the list here [1] and see which of those are weird and help create a patch for their parent module and convince their upstream to use a patch instead. If you can't convince them, maintaining a fork would be fine too. [1] https://wiki.debian.org/Javascript/Nodejs/Tasks/gulp If some one is willing to be an upstream for a combined gulp package, that would be amazing too. You can also help by substituting bigger libraries like lodash for these tiny ones. You could also help maintain such combined libraries. I'm not stopping anyone from doing these supposed to be better way of doing things. As long as no one steps up to do these tasks, you'll have to bear with the tiny packages. And its tiring to keep replying the same thing often, so I won't reply to any more tiny module email. Thanks everyone. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it
]] Pirate Praveen > Description : Check if gulplog is available before attempting to > use it Is there a node-has-has-gulplog too, to check for if has-gulplog is available before attempting to use it? This package sounds a bit weird, even as Node.js packages go. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#846942: ITP: r-cran-dynlm -- GNU R package for dynamic linear models and time series regression
Package: wnpp Severity: wishlist Owner: "Sébastien Villemot" * Package name: r-cran-dynlm Version : 0.3.5 Upstream Author : Achim Zeileis * URL : https://cran.r-project.org/web/packages/dynlm/index.html * License : GPL-2 | GPL-3 Programming Lang: R Description : GNU R package for dynamic linear models and time series regression This R package provides a user-friendly interface for fitting dynamic linear models and time series regression relationships The interface and internals of dynlm are very similar to lm, but currently dynlm offers three advantages over the direct use of lm: 1. extended formula processing 2. preservation of time series attributes 3. instrumental variables regression (via two-stage least squares). The package will be maintained within the Debian Science Team. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: PGP signature
Re: MIA maintainers and RC-buggy packages
Emilio Pozuelo Monfort wrote... > I would suggest to come up with some algorithm to determine if a package is > effectively unmaintained, and implement it in an automatic way that gives > maintainers prior notice and a chance to react, like we do with auto-removals. > Then if nothing happens in a reasonable time frame, the package gets orphaned. This seems very reasonable, go for it. Such an approach would also ease QA uploads for packages and should overall improve package quality. It is quite disturbing to see how many packages dropped out of stretch due to the three big migrations (gcc-6, openssl 1.1, debhelper), even if fixing it would take less that an hour. Also, in spite of all the work the people behind them did, including long grace periods. So we have a lot of de-facto orphaned packages and it's about time to make such a status official sooner. FWIW, I consider salvaging several packages that are debhelper compat level 4 or earlier. But I always wondered whether this wasn't a good time to go beyond the bare necessities and do all the good things in packaging that were introduced in the past ten years, like dh7 style debian/rules, 3.0 (quilt) source format, machine readable debian/copyright etc.etc. - although this is rather QA work than NMU. But assuming the package is technically unmaintained, why not do work that has to be done anyway and will help a future maintainer? > I think we should also have an auto-removals-from-sid[1] (...) > [1] With a *very* conservative criteria. We don't want to remove a package > from > the archive after 30 days because of 1 RC bug. Not so sure about this. There still might be folks around that find that particular package useful for their work. In an ideal world they'd let us know. In real life I've experienced they are not sure about the procedures and are always happy to meet a Debian guy so they can tell about their concerns. My usual answer "File a bug, it's just an e-mail, you won't get eaten for small mistakes in form" sometimes worked, often it was better I took care of that myself. So we (as in Debian) suffer from the usual problem of not getting enough feedback, having to guess. Therefore, in case of doubt, rather keep a package. Also resuming work on a existing though pretty broken package is a lower bar then doing the re-entry procedure. To add a few criteria, I'd remove a package from sid only if it * is plain broken This means the code, not the packaging. * (no longer) serves a reasonable purpose If a package is specific for a task or feature that is no longer supported (think set6x86 which was for CPUs that are now pretty old), there is no reason to keep it. * no longer exists in older supported distributions Since still users might not learn their package is no longer part of the now-stable until they upgrade. * has been orphaned for a longer time, say: a year So again users of that package had a grace period to ask for work on that package. Personally, I'd also appreciate notifying debian-devel about an upcoming removal from sid, somewhat similar to ITPs, so there's a last chance for any interested party to pick the package. And there's still the shortcut using RM: Christoph signature.asc Description: Digital signature
Bug#846915: Fixing OpenRC halt/reboot behavior by updating initscripts
Package: initscripts
Version: 2.88dsf-59.8
Severity: important
Tags: patch
X-Debbugs-CC: 844...@bugs.debian.org,
pkg-sysvinit-de...@lists.alioth.debian.org,
openrc-de...@lists.alioth.debian.org, debian-devel@lists.debian.org
Hello guys,
I find a simple way to fix an OpenRC bug [1] by updating initscripts
package. So both sysvinit list and openrc list are rolled in the CC list.
The OpenRC bug [1] is introduced by this commit:
https://anonscm.debian.org/cgit/openrc/openrc.git/commit/?id=f1ec5852df7db55e7bb170b26997c75676430c5b
It removed the "transit" script and the "reboot" and "halt"
behavior gets broken in my kfreebsd-amd64 virtual machine.
>From the openrc maintainer's comments and logs, it seems that
keeping "transit" script is a pain to them.
However, I fixed this problem in my kfreebsd virtual machine
adding merely two lines of code in initscripts. Maybe this
is better than bringing the "pain" back to openrc maintainers?
I'm not quite familiar with openrc and initscripts so I'm not
sure if my solution is correct.
P.S. It is really annoying when I cannot poweroff my kfreebsd
virtual machine with any of them: "poweroff" "halt" "shutdown"
except for "/etc/init.d/halt stop".
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844685From 1b32fc20368f008ab1f5f9197ef8b294efdb76f9 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sun, 4 Dec 2016 09:22:59 +
Subject: [PATCH] fix openrc halt and reboot behavior from initscripts side
Make sure that the "halt" and "reboot" services are both added into
runlevel "off":
# rc-update add halt off
# rc-update add reboot off
---
debian/changelog | 8
debian/src/initscripts/etc/init.d/halt | 1 +
debian/src/initscripts/etc/init.d/reboot | 1 +
3 files changed, 10 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 1b4d1b9..ab7a61d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sysvinit (2.88dsf-59.9) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add OpenRC support to /etc/init.d/{halt,reboot}, which fixes OpenRC
+halt and reboot behavior since openrc version 0.21-4 . (Closes: #844685)
+
+ -- Zhou Mo Sun, 04 Dec 2016 09:18:29 +
+
sysvinit (2.88dsf-59.8) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/src/initscripts/etc/init.d/halt b/debian/src/initscripts/etc/init.d/halt
index c179a25..45b82de 100755
--- a/debian/src/initscripts/etc/init.d/halt
+++ b/debian/src/initscripts/etc/init.d/halt
@@ -72,6 +72,7 @@ case "$1" in
exit 3
;;
stop)
+if [ "$RC_REBOOT" = "YES" ]; then exit 0; fi
do_stop
;;
*)
diff --git a/debian/src/initscripts/etc/init.d/reboot b/debian/src/initscripts/etc/init.d/reboot
index e1dcb1c..1b61ee5 100755
--- a/debian/src/initscripts/etc/init.d/reboot
+++ b/debian/src/initscripts/etc/init.d/reboot
@@ -29,6 +29,7 @@ case "$1" in
exit 3
;;
stop)
+if [ "$RC_REBOOT" != "YES" ]; then exit 0; fi
do_stop
;;
status)
--
2.10.2
Bug#846912: ITP: node-rechoir -- Require any supported file as a node module
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-rechoir Version : 0.6.2 Upstream Author : Tyler Kellen (http://goingslowly.com/) * URL : https://github.com/tkellen/node-rechoir * License : Expat Programming Lang: JavaScript Description : Require any supported file as a node module. signature.asc Description: OpenPGP digital signature
Bug#846910: ITP: node-path-root-regex -- Regular expression for getting the root of a posix or windows filepath
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-path-root-regex Version : 0.1.2 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/regexhq/path-root-regex * License : Expat Programming Lang: JavaScript Description : Regular expression for getting the root of a posix or windows filepath signature.asc Description: OpenPGP digital signature
Bug#846909: ITP: node-multipipe -- pipe streams with centralized error handling
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-multipipe Version : 1.0.2 Upstream Author : FIX_ME upstream author * URL : https://github.com/juliangruber/multipipe#readme * License : Expat Programming Lang: JavaScript Description : pipe streams with centralized error handling signature.asc Description: OpenPGP digital signature
Fw4:
http://saintraphaelpreschool.com/9.php?pfe5i&2il1=o2umhm&0xugh=s3h&puqjg&1fqc==mizek74&lzpxf= http://saintraphaelpreschool.com/9.php?pfe5i&2il1=o2umhm&0xugh=s3h&puqjg&1fqc==mizek74&lzpxf= -
