Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 03:29:38PM -0500, Jeremy Bicha wrote: > On Wed, Nov 21, 2018 at 10:57 AM Holger Levsen wrote: > > (in that sense I would appreciate packages getting automatically tested > > (and rejected if needed) before they enter *unstable*, and then again, > > with stricter automatic t

Re: julia_1.0.0-1_amd64.changes REJECTED

Quoting Sean Whitton : On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote: On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote: Before we get there, we should first start autoremoving packages from unstable, if we consider rc-buggy in unstable to be unacceptable. We do have

Re: usrmerge -- plan B?

On Thu, Nov 22, 2018 at 12:54:45AM +0100, Svante Signell wrote: > Unfortunately Simon writes too long mails. Who can even thake the time to read > all these verbalism. Things could be written more condensed. Please, can > somebody summarize his verbosity! Maybe he is a politcian? Here's a dumbed d

Re: julia_1.0.0-1_amd64.changes REJECTED

Hello, On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote: > On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote: >> Before we get there, we should first start autoremoving packages from >> unstable, if we consider rc-buggy in unstable to be unacceptable. We >> do have quite a

Bug#914312: ITP: node-istanbuljs -- monorepo containing the various nuts and bolts that facilitate istanbul.js test instrumentation

Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-istanbuljs Version : 1.x Upstream Author : Ben Coe * URL : https://github.com/istanbuljs/istanbuljs * License : ISC Programming Lang: JavaSc

Re: usrmerge -- plan B?

On Wed, 2018-11-21 at 14:43 +, Holger Levsen wrote: > Hi Simon, > > On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote: > [...] > > > Another question is, why? > > [...] > > thank you very much for explaining in detail why usrmerge is sensible > and the right thing to do for Deb

Re: usrmerge -- plan B?

On 2018-11-22 00:33:25 +0100 (+0100), Svante Signell wrote: > On Wed, 2018-11-21 at 13:09 +0100, Marc Haber wrote: > > On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski > > wrote: > > > I am seriously claiming that RHEL is in the place Solaris was > > > in 2010. Rapidly falling user share (like So

Re: usrmerge -- plan B?

On Wed, 2018-11-21 at 13:09 +0100, Marc Haber wrote: > On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski > wrote: > > I am seriously claiming that RHEL is in the place Solaris was in 2010. > > Rapidly falling user share (like Solaris, it was ubiquitous in the past!), > > acquired by a company kno

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 02:55:56PM -0800, Russ Allbery wrote: I don't believe supporting legacy installs *without doing the migration* is an option, or at least an option that we should take. We could theoretically make it work, but the ongoing burden to packagers and to our testing infrastructu

Re: usrmerge -- plan B?

Michael Stone writes: > On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote: >> Doing this check in reproducible-builds definitely helps allievate my >> concerns as a backstop, but this is still fragile and we don't have a >> tight test/fix cycle. And, in general, I'm dubious of a path

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote: Doing this check in reproducible-builds definitely helps allievate my concerns as a backstop, but this is still fragile and we don't have a tight test/fix cycle. And, in general, I'm dubious of a path where we support building a packa

Re: usrmerge -- plan B?

Matthias Klumpp writes: > (At the moment I don't actually see the upcoming doom - a few packages > broke, bugs were fixed, life goes on. If it turns out that we are not > able to cope with new bugs in time, we can always change decisions > later). The reason why I personally jumped into this thr

Re: usrmerge -- plan B?

Am Mi., 21. Nov. 2018 um 22:51 Uhr schrieb Marco d'Itri : > > On Nov 21, Michael Stone wrote: > > > How many long-running production systems do you think people have run > > usrmerge on? I'd guess close to zero, since there is no advantage whatsoever > Actually I have quite a lot personally, with

Re: usrmerge -- plan B?

Holger Levsen writes: > On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote: >> But it's not just my opinion that matters. I think we need to decide >> this somehow as a project, whether via the TC or via GR or something, >> because there's a real disagreement here over whether we can o

Re: usrmerge -- plan B?

Michael Stone writes: > How many long-running production systems do you think people have run > usrmerge on? I'd guess close to zero, since there is no advantage > whatsoever to doing so. I'd also expect those to be the systems most > likely to have issues. Yup, lack of testing is definitely a v

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 10:49:54PM +0100, Marco d'Itri wrote: On Nov 21, Michael Stone wrote: How many long-running production systems do you think people have run usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally, with exactly

Re: usrmerge -- plan B?

On Nov 21, Michael Stone wrote: > How many long-running production systems do you think people have run > usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally, with exactly zero problems. On some of them I also enjoy advantages of mer

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 09:28:11PM +, Holger Levsen wrote: Or what am I missing? The possibility that your system will break? The current usrmerge package has no test mode, will bail with a partially-converted system if it runs into problems, and has no way to revert the process. A sysadm

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote: > But it's not just my opinion that matters. I think we need to decide this > somehow as a project, whether via the TC or via GR or something, because > there's a real disagreement here over whether we can or should > force-upgrade all

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 03:45:35PM -0500, Jeremy Bicha wrote: On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote: But it's not just my opinion that matters. I think we need to decide this somehow as a project, whether via the TC or via GR or something, because there's a real disagreement here

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 12:49:04PM -0800, Russ Allbery wrote: This seems like too high of a level of pessimism given that the usrmerge package already implements this sort of force-merge and some people have it installed and don't seem to be running into a bunch of bugs. The last round of proble

Re: usrmerge -- plan B?

On Mi, Nov 21, 2018 at 01:09:47 +0100, Marc Haber wrote: Debian, is, btw, also losing quickly for not keeping pace with the world around it. Or maybe it scares people away with its bullshit decisions. Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s D

Re: usrmerge -- plan B?

Jeremy Bicha writes: > On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote: >> But it's not just my opinion that matters. I think we need to decide >> this somehow as a project, whether via the TC or via GR or something, >> because there's a real disagreement here over whether we can or should >

Re: Porting rust

Josh Triplett, le mer. 21 nov. 2018 12:39:35 -0800, a ecrit: > I'm not an expert in that mechanism, but my understanding is that the > vast majority is shared among multiple systems. > > There probably *should* be a way to autogenerate these, but I don't > think there is. But I wouldn't be surpris

Re: usrmerge -- plan B?

Michael Stone writes: > On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote: >> If we just force-merge every system on upgrade, none of those >> inconsistencies matter, and I do believe we could successfully complete >> that process (with some bumps, of course). > I think that's likely

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote: > But it's not just my opinion that matters. I think we need to decide this > somehow as a project, whether via the TC or via GR or something, because > there's a real disagreement here over whether we can or should > force-upgrade all Debian sy

Re: Porting rust

On Tue, Nov 20, 2018 at 09:00:23PM +0100, Samuel Thibault wrote: > Hello, > > Josh Triplett, le lun. 05 nov. 2018 21:02:32 -0800, a ecrit: > > Speaking with an upstream Rust hat on in addition to a Debian hat: > > what could Rust do to make life easier for porters? > > After Adrian's announce I t

Re: usrmerge -- plan B?

Marco d'Itri writes: > On Nov 21, Russ Allbery wrote: >> I think there are some arguments to be made for just force-merging and >> moving on, but they're mostly "tidiness" arguments (letting everyone > No, they are not that at all. I have never argued about "tidiness", nor > did anybody else th

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 10:57 AM Holger Levsen wrote: > (in that sense I would appreciate packages getting automatically tested > (and rejected if needed) before they enter *unstable*, and then again, > with stricter automatic tests before they enter testing.) This sounds to me like what Ubuntu d

Bug#914302: ITP: liblingua-en-sentence-perl -- Perl module to split text into sentences

Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: liblingua-en-sentence-perl Version : 0.31 Upstream Author : Kim Ryan * URL : https://metacpan.org/release/Lingua-EN-Se

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 06:19:49PM +, Holger Levsen wrote: > On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote: > > Before we get there, we should first start autoremoving packages from > > unstable[...] > I'm all for it. also with a 3 month delay (instead of the 2 weeks or w

Re: usrmerge -- plan B?

On Nov 21, Russ Allbery wrote: > I think there are some arguments to be made for just force-merging and > moving on, but they're mostly "tidiness" arguments (letting everyone No, they are not that at all. I have never argued about "tidiness", nor did anybody else that is working to support merge

Re: julia_1.0.0-1_amd64.changes REJECTED

On 2018-11-21 18:47 +0100, Matthias Klose wrote: > On 21.11.18 16:56, Holger Levsen wrote: > > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > >> Why is any of this a reason for an ftpmaster REJECT ? I still think > >> all of this should be handled as bugs (possibly RC bugs) in the

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote: If we just force-merge every system on upgrade, none of those inconsistencies matter, and I do believe we could successfully complete that process (with some bumps, of course). I think that's likely to be the most painful upgrade sin

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote: > Before we get there, we should first start autoremoving packages from > unstable, if we consider rc-buggy in unstable to be unacceptable. We > do have quite a bit of things in unstable, that are neither getting > fixed, nor gett

Re: usrmerge -- plan B?

Adam Borowski writes: > Thus, either usrmerge Essential or not included in Buster -- no middle > way. I think I agree with this. My impression is that most of the problems with usrmerge are because we're trying to support a halfway position that Red Hat did not try to support, where some system

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, 21 Nov 2018 at 15:57, Holger Levsen wrote: > > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > > Why is any of this a reason for an ftpmaster REJECT ? I still think > > all of this should be handled as bugs (possibly RC bugs) in the BTS > > in the conventional way, after AC

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 06:47:52PM +0100, Matthias Klose wrote: I really like the approach of some ftp-masters to accept a package and then file rc-issues, if there are some, like adding updated copyright information. If the copyright info is wrong then it definitely shouldn't be in the archiv

Re: julia_1.0.0-1_amd64.changes REJECTED

On 21.11.18 16:56, Holger Levsen wrote: > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: >> Why is any of this a reason for an ftpmaster REJECT ? I still think >> all of this should be handled as bugs (possibly RC bugs) in the BTS >> in the conventional way, after ACCEPT. > > becaus

Re: julia_1.0.0-1_amd64.changes REJECTED

El miércoles, 21 de noviembre de 2018 12:56:42 -03 Holger Levsen escribió: > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > > Why is any of this a reason for an ftpmaster REJECT ? I still think > > all of this should be handled as bugs (possibly RC bugs) in the BTS > > in the conve

Bug#914296: ITP: node-path-parse -- Node.js path.parse() ponyfill

Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-path-parse Version : 1.0.6 Upstream Author : Javier Blanco * URL : https://github.com/jbgutierrez/path-parse * License

Bug#914295: ITP: node-fileset -- Wrapper around miniglob / minimatch combo

Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-fileset Version : 2.0.3 Upstream Author : mklabs * URL : https://github.com/mklabs/node-fileset * License : Expat Programming Lang: JavaScri

Bug#914294: ITP: node-default-require-extensions -- Node's default require extensions as a separate module

Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-default-require-extensions Version : 2.0.0 Upstream Author : James Talmage (github.com/jamestalmage) * URL : https://github.com/avajs/default-requi

Bug#914293: Subject: ITP: node-append-transform -- Install a transform to require.extensions that always runs last

Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-append-transform Version : 1.0.0 Upstream Author : James Talmage (github.com/jamestalmage) * URL : https://github.com/istanbuljs/append-transform *

Re: usrmerge -- plan B?

Am Mittwoch, 21. November 2018, 11:34:47 CET schrieb Adam Borowski: Thanks Adam for the fast response. I am looking forward to usrmerge, as I see only advantages at the moment. Best Hans > On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote: > > However, this did not answer my question, so I li

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > Why is any of this a reason for an ftpmaster REJECT ? I still think > all of this should be handled as bugs (possibly RC bugs) in the BTS > in the conventional way, after ACCEPT. because why accept rc-buggy software in the archive (wh

Re: julia_1.0.0-1_amd64.changes REJECTED

Emilio Pozuelo Monfort writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): > > On 2018/10/25 12:24, Ian Jackson wrote: > >> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): > >>> My main concern here is this: AFAICT this package has been REJECTed > >>> solely for this reason. Why

Re: julia_1.0.0-1_amd64.changes REJECTED

Hi, On 21/11/2018 14:56, Graham Inggs wrote: > Hi Bastian > > My apologies in advance for doing this, but another month has passed. > Another ping from me. > > On 2018/10/25 12:24, Ian Jackson wrote: >> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): >>> Lumin writes ("Re: julia

Re: usrmerge -- plan B?

Hi Simon, On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote: [...] > > Another question is, why? [...] thank you very much for explaining in detail why usrmerge is sensible and the right thing to do for Debian, the universal OS. I'll link your mail on wiki.debian.org/UsrMerge now a

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 03:56:44PM +0200, Graham Inggs wrote: > > Ping, ftpmaster ? Please read https://ftp-master.debian.org/REJECT-FAQ.html Of cause lintian errors and warnings are reasons to reject packages. Overriden ones without proper explanation more so. > From the original REJECTion emai

Re: julia_1.0.0-1_amd64.changes REJECTED

Hi Bastian My apologies in advance for doing this, but another month has passed. Another ping from me. On 2018/10/25 12:24, Ian Jackson wrote: Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): 1. Isn't "incomplete backt

Re: usrmerge -- plan B?

On Tue, 20 Nov 2018 at 22:16:17 +0100, Adam Borowski wrote: > There's been another large bout of usrmerge issues recently These are one example of a wider class of issues, which Debian is going to keep running into, and solving, as long as we're a binary distribution (as opposed to a source distri

Re: usrmerge -- plan B?

On Wed, 21 Nov 2018 11:57:14 +, Ian Jackson wrote: >I suspect you meant to refer to this: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > >2. Solaris compatibility > >Well, this is a real argument. But, seriously, do we care ? I find it very interesting to re

Re: usrmerge -- plan B?

On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski wrote: >I am seriously claiming that RHEL is in the place Solaris was in 2010. >Rapidly falling user share (like Solaris, it was ubiquitous in the past!), >acquired by a company known for wringing dry a small number of lucratious >customers -- jus

Re: Bug#914253: ITP: python-sqlalchemy-migrate -- Database schema migration for SQLAlchemy

Per Andersson writes: > Package: wnpp > Severity: wishlist > Owner: Per Andersson > > * Package name: python-sqlalchemy-migrate > Version : 0.11.0 > Upstream Author : OpenStack > * URL : https://pypi.org/project/sqlalchemy-migrate/ > * License : MIT/Expat >

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 11:31:40AM +, Jonathan Dowland wrote: I'll upgrade to 7.6 and see what happens. I've upgraded and /bin -> /usr/bin However I didn't correctly check this before so it might have already happened. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄

Re: usrmerge -- plan B?

Marco d'Itri writes ("Re: usrmerge -- plan B?"): > On Nov 20, Adam Borowski wrote: > > Another question is, why? > > It has been documented here long ago: https://wiki.debian.org/UsrMerge . I looked at that page and it has no rationale. > You are misconstructing the arguments in favour of merge

Re: usrmerge -- plan B?

Hi, Adam Borowski writes: FTR, I agree with the broad thrust of your mail; I'm not sure I've seen a convincing case for /usr-merge yet. > I am seriously claiming that RHEL is in the place Solaris was in 2010. But I want to take issue with this. RHEL is moderately-widely used, because if you w

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 11:02:44AM +0100, Marc Haber wrote: Did RHEL do that from 7.x to 7.x+1 (where updates are supported)? Or from x.y to z.0 where ther recommended migration way is a reinstall? I don't know the answer to when or how this happens, but my local RHEL VM is on 7.5 and doesn't h

Re: usrmerge -- plan B?

Am Mittwoch, 21. November 2018, 11:34:47 CET schrieb Adam Borowski: Thanks Adam for the fast response. I am looking forward to usrmerge, as I see only advantages at the moment. Best Hans > On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote: > > However, this did not answer my question, so I li

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote: > However, this did not answer my question, so I like to aksk here: > > Will usrmerge break my system? > > I have /usr on a seperate partition and I have it encrypted with luks. > Of course I am running a standard kernwel with initrd. No it

Re: usrmerge -- plan B?

Hi folks, I am following this thread qwith great interest. And I also read about usrmerge, too. However, this did not answer my question, so I like to aksk here: Will usrmerge break my system? I have /usr on a seperate partition and I have it encrypted with luks. Of course I am running a sta

Re: usrmerge -- plan B?

On Wed, 21 Nov 2018 08:56:58 +0100, Marco d'Itri wrote: >it's RHEL that matters and it switched to >a merged-/usr Did RHEL do that from 7.x to 7.x+1 (where updates are supported)? Or from x.y to z.0 where ther recommended migration way is a reinstall? Greetings Marc --

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 08:56:58AM +0100, Marco d'Itri wrote: > On Nov 20, Adam Borowski wrote: > > If you are seriously concerned with the small issuses caused by the > transition to merged-/usr then I have a better proposal. > Plan C: just stop supporting non-merged-/usr systems since these >

Re: usrmerge -- plan B?

On Wed, Nov 21, 2018 at 06:37:11AM +, Domenico Andreoli wrote: > On November 20, 2018 9:16:17 PM UTC, Adam Borowski > wrote: > > >Thus, it seems to me that the plan A for usrmerge has serious downsides for > >dubious benefits. What about the plan B I described above? > > My preferred plan