Re: julia_1.0.0-1_amd64.changes REJECTED

[Niels Thykier]

Sean Whitton:
> 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 bit of things in unstable, that are neither getting
>>> fixed, nor getting removed. And are in this limbo state of "no longer
>>> in testing no longer in stable no longer in old-stable...
>>> still in unstable".
>>
>> I'm all for it.
> 
> What harm are the packages doing sitting in unstable?  Distributing them
> does not have much point, but neither does removing them.
> 

Hi,

Since most of our QA is based on unstable, it is hard to tell when some
particular problem is *solved* when we got a number of extra packages in
sid that are RC-buggy and that you can "ignore".

Presumably this is an argument for having dedicated QA reports only for
testing, so you can tell the state of a particular issue only for the
next stable release.

> If someone does want to come along and fix the package, having it pass
> through NEW again is not a good use of ftpteam time.
> 

Nothing is gratis.  Currently, our archive-wide QA is paying the price
by making it difficult to see when we can stop supporting deprecated
features (or which packages to focus on to fix it).

Plus our current garbage collection process for unstable is not gratis
either on volunteer time.  It involves someone identifying a package for
removal and then asking the FTP team to spend time removing it.
  If we automated the removal here (with some trivial stop gaps for
people in the situation you refer to), then we could save time from the
FTP team and distribute it to the people actively working on the packages.

~Niels

Re: usrmerge -- plan B?

[Philip Hands]

Svante Signell  writes:

...
> Who can even thake the time to read all these verbalism.

This is a criticism of an attempt to educate, made from a position of
ignorance.  I don't think we need we need this on our mailing lists.

> Things could be written more condensed.

Given that Simon was replying to a mail that was complaining about a
lack of detailed justification, criticising him for providing a series
of detailed justifications is deranged.  If you don't like reading about
the details, you should have killed the thread at the first mail.

...
> Maybe he is a politcian?

I guess that was supposed to be a joke, but sadly it reads like an ad
hominem attack (as did your opening sentence for that matter: the one
about Simon writing long emails, which I trimmed in an attempt to
accommodate your tiny attention span).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Jonathan Dowland]

On Wed, Nov 21, 2018 at 04:21:42PM -0500, 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 to doing so. I'd also expect those to be the systems most 
likely to have issues.


Long-running production systems would presumably be running Stable. We
need testing or unstable systems to try usrmerge. I don't think even
reporting on the success of usrmerge on current-Stable¹ would be
necessarily useful.

My gut feeling is we should do this transition; and we should not target
our next release but the one after.



¹ I can't remember our own code names any more.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: usrmerge -- plan B?

[Jonathan Dowland]

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?


I don't think this is a constructive comment.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: julia_1.0.0-1_amd64.changes REJECTED

[Holger Levsen]

On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
> What harm are the packages doing sitting in unstable?  Distributing them
> does not have much point, but neither does removing them.

the rather few people working on (fully and partly) automated QA have to
spend brain and cpu cycles on it

> If someone does want to come along and fix the package, having it pass
> through NEW again is not a good use of ftpteam time.

first, that's partly why I suggested 3 months delays/warnings for these
autoremovals. second, during this time, like for the testing
autoremovals, a simple mail to that bug could+should reset the counter
of that 3 months period again. third, ftpmasters are smart, if exactly the
same package gets reuploaded i'm pretty confident the ftpmasters
can+will detect that easily and make it go through NEW faster. fourth,
sometimes people need incentives to do some work, I believe autoremovals
provide such incentives.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Jonathan Dowland  wrote:

> Long-running production systems would presumably be running Stable. We
> need testing or unstable systems to try usrmerge. I don't think even
> reporting on the success of usrmerge on current-Stable¹ would be
> necessarily useful.
I use merged-/usr without any issues on many stable systems, both new 
and upgraded.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Ian Jackson]

Michael Stone writes ("Re: usrmerge -- plan B?"):
> No way we can hit that date with a forced merge. Where are the testing 
> reports showing that this actually works on a broad range of systems? 
> And now we're getting into the winter holiday season? Pushing that now 
> would be nuts.

I would also like to point out that change planning is the job of
someone who wants to change something.  That includes not only:
 - figuring out what the new state should look like
 - developing tools to switch individual systems etc.
which has been done but also:
 - planning what changes need to happen throughout Debian and
   its ecosystem, in what order, to avoid lossage
 - writing that plan up and getting it reviewed by everyone who
   is likely to have useful input
 - specifically covering what kinds of residual lossage can be
   expected, and what the plan is for handling that
 - in a case like this, getting at least a semiformal sign-off
   from the Release Team
 - throughout, engaging positively with sceptics, to reassure
   them (rather than pressing on or dismissing concerns)
none of which seem to have been done.

We should back off at the very least until we have a transition plan
which we can discuss and possibly get rough consensus on.  Personally
what I have seen so far gives me little confidence.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Ian Jackson]

Andreas Henriksson writes ("Re: usrmerge -- plan B?"):
> Here's a dumbed down narrative for you:

Svante's message was pretty bad but yours is even worse.
Would everyone please stop it.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Ian Jackson]

Holger Levsen writes ("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 (when we know it's
> rc-buggy), whether at NEW time or with any following upload?

Because:

 * Discussions about the RC bugs can be more effectively dealt with
   using our existing discussion mechanisms, including primarily the
   Debian BTS.  Compared to REJECT mails:
 - Discussions in the BTS are more transparent
 - Discussions in the BTS are better organised
 - Discussions in the BTS can have wider participation
 - Discussions in the BTS are better archived
 - Discussions in the BTS have better metadata

 * Publishing a work-in-progress in the Debian archive enables more
   people to more easily help improve and fix it.

 * Once a package is accepted metadata about it, and parts of it, are
   automatically published by a variety of Debian services, making it
   much easier to work with - for example, one can see who the
   maintainer is and what its issues are.

 * ftpmasters are already far too overloaded looking for problems like
   unredistributability, dfsg-nonfreeness, malformed packages,
   breakages of the archive, etc.

 * It is not ftpmasters' role to determine whether a package is
   RC-buggy; that task is for the Release Team.

> (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.)

I agree that automatic checking is fine, but humans should be able to
override it.  I have no problem with auto-REJECTs, which are generally
either for really serious problems, or can be overridden.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Holger Levsen]

On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Because:
> 
>  * Discussions about the RC bugs can be more effectively dealt with
>using our existing discussion mechanisms, including primarily the
>Debian BTS.  Compared to REJECT mails:
>  - Discussions in the BTS are more transparent
>  - Discussions in the BTS are better organised
>  - Discussions in the BTS can have wider participation
>  - Discussions in the BTS are better archived
>  - Discussions in the BTS have better metadata
> 
>  * Publishing a work-in-progress in the Debian archive enables more
>people to more easily help improve and fix it.
> 
>  * Once a package is accepted metadata about it, and parts of it, are
>automatically published by a variety of Debian services, making it
>much easier to work with - for example, one can see who the
>maintainer is and what its issues are.
> 
>  * ftpmasters are already far too overloaded looking for problems like
>unredistributability, dfsg-nonfreeness, malformed packages,
>breakages of the archive, etc.
 
thanks! nice summary.

>  * It is not ftpmasters' role to determine whether a package is
>RC-buggy; that task is for the Release Team.

point taken as well.

still I think we should only stuff in unstable which is suited for
testing. So while you have convinced me that it's good to have those
packages in Debian I now think that experimental would be a fine place
for those, but not unstable.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Michael Stone]

On Thu, Nov 22, 2018 at 12:32:14PM +0100, Marco d'Itri wrote:

I use merged-/usr without any issues on many stable systems, both new
and upgraded.


Again, how many weren't systems you're responsible for? I have no doubt 
that you took care of the problems that you encountered personally when 
you wrote the tool. I've seen a lot of problems on systems in the wild 
that don't exist on my systems, but I don't expect that every one of our 
users is a debian developer; sometimes other people solve problems in a 
way that we didn't really expect or plan for them to.


Let's restate this so it can stand clearly on its own:

"We ran into some unanticipated issues when we usrmerged our build 
systems, and we think the way to fix that is to force merge every one of 
our users' systems."

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Ian Jackson]

Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes 
REJECTED)"):
> still I think we should only stuff in unstable which is suited for
> testing. So while you have convinced me that it's good to have those
> packages in Debian I now think that experimental would be a fine place
> for those, but not unstable.

Well, of course people may disagree about whether the bugs are RC.
That seems to be happening in the case of julia.  In such a situation
having the package in unstable is probably better.  If the conclusion
is that the bugs are not RC, no new upload is needed.

In general, I think it can be sensible to have things in unstable
which are *intended for*, or *wanted in* testing, even if there are
known problems with it that prevent that right now.

And, finally, I don't think really it is ftpmaster's job to REJECT an
upload on the grounds that it should be in experimental rather than
unstable.  Unless it's an overrideable auto-REJECT of course.  As I
say, I'm a fan of those.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Ian Jackson]

Michael Stone writes ("Re: usrmerge -- plan B?"):
> Let's restate this so it can stand clearly on its own:
> 
> "We ran into some unanticipated issues when we usrmerged our build 
> systems, and we think the way to fix that is to force merge every one of 
> our users' systems."

That does seem to be the position that is being advanced.  It's quite
striking, isn't it ?  At the very least more comprehensive thought and
planning is needed.  And very probably more time.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Michael Stone  wrote:

> Again, how many weren't systems you're responsible for? I have no doubt that
> you took care of the problems that you encountered personally when you wrote
> the tool. I've seen a lot of problems on systems in the wild that don't
No: what I meant is that I did not encounter any problems.

I reject the narrative that switching to a merged-/usr system generally 
causes problems. So far nobody reported anything significant.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Ian Jackson]

Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes 
REJECTED)"):
> On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> > Because:
> > ...
>  
> thanks! nice summary.

I replied in my other mail to the things I disagreed with (as is
traditional) but it occurred to me I ought to send a positive note
about this:

Thanks for being easy to convince!

I also commend the phrasing of your original question with `why'.
That could be read as rhetorical, but even so it invited a reasoned
disagreement.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Ian Jackson]

Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> So far nobody reported anything significant.

I hear there was a major free software project who accidentally
usrmerged their build systems and discovered that they then built
broken packgaes.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Ian Jackson  wrote:

> I hear there was a major free software project who accidentally
> usrmerged their build systems and discovered that they then built
> broken packgaes.
And it was quickly fixed, so no big deal.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Ian Jackson]

Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> On Nov 22, Ian Jackson  wrote:
> > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > So far nobody reported anything significant.
> >
> > I hear there was a major free software project who accidentally
> > usrmerged their build systems and discovered that they then built
> > broken packgaes.
> 
> And it was quickly fixed, so no big deal.

I think this allows us to calibrate what you consider `anything
significant'.

There is tradeoff here between risk of breakage, and reduction of
future work (as most clearly explained by Russ).  The argument that is
being made is that the risk is low because of a lack of reports of
breakage.

Others have observed that systems most likely to experience trouble
will not have been upgraded.  For example, chiark was first installed
with Debian 0.93R5 in 1993.  Obviously I haven't usrmerged it.  No-one
sensible in my position would do so.  So the `lack of reports'
probably stems from a lack of contact of this proposal with the more
difficult parts of the real world.

But what we see here is that the `lack of reports' somehow ignores a
problem sufficiently serious to generate more than one RC bug in
Debian itself, and to require the usrmerge to be reverted at least
temporarily.  (Bear in mind of course that happily our build machines
*can* be reverted because they are frequently re-imaged.  Others may
not be so lucky.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: julia_1.0.0-1_amd64.changes REJECTED

[Sean Whitton]

Hello,

On Thu 22 Nov 2018 at 11:20AM GMT, Holger Levsen wrote:

> On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
>> What harm are the packages doing sitting in unstable?  Distributing them
>> does not have much point, but neither does removing them.
>
> the rather few people working on (fully and partly) automated QA have to
> spend brain and cpu cycles on it

Thank you to both you and Niels for the explanations.  I see what you
mean now.

>> If someone does want to come along and fix the package, having it pass
>> through NEW again is not a good use of ftpteam time.
>
> first, that's partly why I suggested 3 months delays/warnings for these
> autoremovals. second, during this time, like for the testing
> autoremovals, a simple mail to that bug could+should reset the counter
> of that 3 months period again. third, ftpmasters are smart, if exactly the
> same package gets reuploaded i'm pretty confident the ftpmasters
> can+will detect that easily and make it go through NEW faster.

I don't think this is realistic, however -- it's not likely to be the
same ftpteam member who reviews the package the second time.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Chris Lamb]

Ian Jackson wrote:

>[..]  Compared to REJECT mails:
>
>  - Discussions in the BTS are more transparent
>  - Discussions in the BTS are better organised
>  - Discussions in the BTS can have wider participation
>  - Discussions in the BTS are better archived
>  - Discussions in the BTS have better metadata

This would be a fairly-accurate precis of my position.

Indeed, I tend to ACCEPT whilst filing a bug at the same time with
varying degrees of severity through RC-level (#910031, #910656),
normal (#911532) and wishlist (#910029, #910330), etc. etc.

> I have no problem with auto-REJECTs, which are generally
> either for really serious problems, or can be overridden.

On that note, please suggest additions to the auto-REJECT list as
MRs against dak. It is likely missing many useful tags that have
been added since it was last refreshed.

(As an aside, some tags cannnot be overridden but that's not quite
on-topic here…)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Ian Jackson]

Chris Lamb writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes 
REJECTED)"):
> Ian Jackson wrote:
> >[..]  Compared to REJECT mails:
> >  - Discussions in the BTS are more transparent
> >  - Discussions in the BTS are better organised
> >  - Discussions in the BTS can have wider participation
> >  - Discussions in the BTS are better archived
> >  - Discussions in the BTS have better metadata
> 
> This would be a fairly-accurate precis of my position.
> 
> Indeed, I tend to ACCEPT whilst filing a bug at the same time with
> varying degrees of severity through RC-level (#910031, #910656),
> normal (#911532) and wishlist (#910029, #910330), etc. etc.

I think this is exemplary practice.

> (As an aside, some tags cannnot be overridden but that's not quite
> on-topic here…)

I doubt these are likely to be very controversial.  And, yes.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Do not contact this person IRL either (Re: I resigned in 2004)

[Ian Jackson]

A Debian contributor tells me in private conversation that they
encountered this ex-Developer in real life, and that during that
conversation they told this ex-Developer they disapproved of the
ex-Developer's messages in this thread.

DO NOT DO THIS.  Do not raise these issues with this ex-Developer
unless they invite you to do so.

I have spoken in private to the Debian contributor in question and
made it clear that I felt what they did was harassment of our former
colleague.  As an isolated incident it is a very minor abuse, but from
the other end, if done by several people, it might easily amount to a
serious harassment or retaliation campaign.


Furthermore, the current contributor in question confessed to me that
they made these remarks even after being told that our former
colleague didn't want to talk about it.

IF SOMEONE TELLS YOU, IN PERSON, THAT THEY DO NOT WANT TO TALK ABOUT
SOMETHING, DO NOT TALK TO THEM ABOUT IT.


Finally, this does not mean you should ostracise or exclude our former
colleague in other contexts, or refuse to speak to them.  If you
cannot bring yourself to be friendly, at least be formal but cordial.
(I don't know that this advice is actually necessary but it seems wise
to write it.)


Excuse the shouting, but, really.  It is very unfortunate that I am
having to explain these rather basic principles.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

[Russ Allbery]

Ian Jackson  writes:
> Michael Stone writes ("Re: usrmerge -- plan B?"):

>> Let's restate this so it can stand clearly on its own:

>> "We ran into some unanticipated issues when we usrmerged our build
>> systems, and we think the way to fix that is to force merge every one
>> of our users' systems."

> That does seem to be the position that is being advanced.

I think this is an unfair characterization of the thread, and adds
considerably more heat than light.

We ran into unanticipated problems *with supporting full portability of
packages between usrmerged systems and non-usrmerged systems*.  (And I'm
not sure the problems were really that unanticipated -- that problem is
hard.)  We're now evaluating what that means for the overall goal of
supporting systems with merged /usr.  One possibility is to not attempt to
support that use case, which can be done in two ways: never merging /usr,
or merging all systems.

In this sort of discussion, it's very important to keep distinct the point
we're discussing and our positions on that point, and try to maintain our
agreement on what is even under discussion while we disagree.

To support my side of that, I promise to not mischaracterize consensus on
*what we're debating* as consensus on *what the outcome should be*, and
keep those two things entirely separate.

-- 
Russ Allbery (r...@debian.org)   

Re: usrmerge -- plan B?

[Ansgar Burchardt]

On Thu, 2018-11-22 at 13:56 +, Ian Jackson wrote:
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > On Nov 22, Ian Jackson  wrote:
> > > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > > So far nobody reported anything significant.
> > > 
> > > I hear there was a major free software project who accidentally
> > > usrmerged their build systems and discovered that they then built
> > > broken packgaes.
> > 
> > And it was quickly fixed, so no big deal.
> 
> I think this allows us to calibrate what you consider `anything
> significant'.

Causing problems with a few packages is not a significant problem.  We
should stop upgrading GCC to newer versions otherwise as doing so
generates tons of RC bugs every time.

> There is tradeoff here between risk of breakage, and reduction of
> future work (as most clearly explained by Russ).  The argument that
> is
> being made is that the risk is low because of a lack of reports of
> breakage.

Moving files around in such a matter that they are still available in
the old location (via a symlink) is not a very invasive change, so
there is only a small risk of problems.  That matches what was reported
so far.

Very few changes come with zero problems.

> Others have observed that systems most likely to experience trouble
> will not have been upgraded.  For example, chiark was first installed
> with Debian 0.93R5 in 1993.  Obviously I haven't usrmerged it.  No-
> one sensible in my position would do so.

Why should "originally installed in 1993" make moving files from one
location to another more difficult?  It's not different than having to
add LSB init headers to local init scripts (or just replace them with
systemd units these days), having to purge leftover conffiles from
removed packages or similar changes on upgrades.

If the system is prone to breakage on upgrades in general, I would
expect anyone sensible to fix that.

Ansgar

Re: usrmerge -- plan B?

[Russ Allbery]

Ansgar Burchardt  writes:

> Moving files around in such a matter that they are still available in
> the old location (via a symlink) is not a very invasive change, so there
> is only a small risk of problems.

I think it's fair to note that our past experience in Debian doesn't
really support this.  I've run into multiple problems in unstable with
uninstallable packages due to various bugs in this sort of change, most
recently with iptables.  We repeatedly get the details of this change
wrong in various subtle ways that create issues in some upgrade paths and
not others.

This may be acceptable temporary breakage, and I don't think any of it
made it into stable (and it usually doesn't even make it into testing),
but if we're going to do a lot of this, I think we need better tools, such
as declarative support in packaging metadata that tells dpkg to do the
right thing, so that we can lean on a single, well-tested, robust
implementation.

-- 
Russ Allbery (r...@debian.org)   

Re: usrmerge -- plan B?

[Michael Stone]

On Thu, Nov 22, 2018 at 05:15:53PM +0100, Ansgar Burchardt wrote:

Moving files around in such a matter that they are still available in
the old location (via a symlink) is not a very invasive change, so
there is only a small risk of problems.  That matches what was reported
so far.


That's not actually what happens: the files are still available in the 
old location *if and only if the process is fully successful*. If there 
are any issues you have a partially migrated system in which the files 
are *not* still available in the old location, and which cannot be 
reverted back to the original state.

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Ian Jackson  wrote:

> I would also like to point out that change planning is the job of
> someone who wants to change something.  That includes not only:
I planned for everything that I could foresee.
I did not think about the buildds issue, but this is hardly the first 
time that some complex software/process has bugs that nobody tought 
about until it was deployed.
Actually I believe that the fact that this could be solved quickly and 
with a trivial change is a great argument in favour of the quality of my 
plan and work for switching to merged-/usr.

> We should back off at the very least until we have a transition plan
> which we can discuss and possibly get rough consensus on.  Personally
> what I have seen so far gives me little confidence.
You should have asked for an explicit plan three years ago when I first 
announced that I was working on this. At this point you are just 
creating arbitrary requirements that would delay forever this change.

The reality is that the usrmerge conversion program has been available 
for three years and all the conversion problems that were unconvered by 
users have been addressed.
If you have further doubts about its general viability then it is up to 
you to report specific issues.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Michael Stone  wrote:

> That's not actually what happens: the files are still available in the old
> location *if and only if the process is fully successful*. If there are any
> issues you have a partially migrated system in which the files are *not*
> still available in the old location, and which cannot be reverted back to
> the original state.
This is not true: the convert-usrmerge program was designed to keep the 
system consistent at all times, even while it is being run, by creating 
symlinks when binaries are being moved.
In the worst case it will fail explaining that some local change (in
a directory which should not have been modified by the local admin, BTW)
needs to be addressed by the local admin and then it can be restarted 
and continue its work.
And if it will fail due to some other unexpected bug then it will still 
leave behind a working system.

Maybe you could actually look at the code and/or try it?
You can even test it on a live system by booting it again in kvm with 
a snapshot.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Michael Stone]

On Thu, Nov 22, 2018 at 06:00:45PM +0100, Marco d'Itri wrote:

You should have asked for an explicit plan three years ago when I first
announced that I was working on this. At this point you are just
creating arbitrary requirements that would delay forever this change.


Three years ago we were told this was to enable people to optionally do 
something, not that all users would be forced to migrate. That's a 
pretty substantial change.

Re: usrmerge -- plan B?

[Matthew Vernon]

Marco d'Itri  writes:

> In the worst case it will fail explaining that some local change (in
> a directory which should not have been modified by the local admin, BTW)
> needs to be addressed by the local admin and then it can be restarted 
> and continue its work.

Could you expand on this? I'm responsible for enough systems with enough
"interesting historical artifacts" that I'd bet that pretty much every
directory has been modified on at least some of them.

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: usrmerge -- plan B?

[Ian Jackson]

Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson  writes:
> >> "We ran into some unanticipated issues when we usrmerged our build
> >> systems, and we think the way to fix that is to force merge every one
> >> of our users' systems."
> 
> > That does seem to be the position that is being advanced.
> 
> I think this is an unfair characterization of the thread, and adds
> considerably more heat than light.

I'm afraid I see it as totally fair.  (And I do very much hesitate to
disagree with you since you are usually right about everything.)

> We ran into unanticipated problems *with supporting full portability of
> packages between usrmerged systems and non-usrmerged systems*.

It was very clear that what was proposed, some months ago, was
*optional* usrmerge, which necessarily involves cross-compatibility.
It was on that basis that there were few objections.  Thus the
original design promise from usrmerge proponents, when these changes
were last discussed here, was indeed full portability of packages.
(Whether the usrmerge proponents realised that or not.)

>  (And I'm not sure the problems were really that unanticipated --
> that problem is hard.)

No doubt there were misgivings in several quarters.  I had my own
misgivings.  But I kept them to myself, in a spirit of not picking an
unnecessary fight.  After all if something is optional then I can just
not opt in.  If someone wants to do something that might break their
system then why not let them ?  They can keep all the pieces.

But when I said `unanticipated issues' I meant, of course,
unanticipated by the usrmerge designers and implementers.  Yes,
those problems were unanticipated problems *of full portability*
rather than of usrmerge as an abstract principle.  But the usrmerge
designers and implementers either (i) did not realise that their
actions depended on full portability, or (ii) did not realise how hard
it would be.  That's why there was no plan for how to achieve it.


My position as a usrmerge sceptic, of letting them get on with doing
their thing, now seems to have been unwise.  The idea that it would be
optional mutated, without proper discussion, and without a transition
plan, into it being the default for new installs.

And now there are serious suggestions that to solve this lack of
foresight, lack of proper planning, lack of proper consultation, and
lack of attention to detail, we should press ahead even faster and
make the new scheme mandatory ?

On a narrow technical level I can see why that is attractive.  But in
the wider world, when a particular project team has caused lossage due
to poor technical judgement, excessive haste, and at least a perceived
reluctance to accomodate feedback, it is rarely the right response to
be *less* critical of their plans and recommendations, and push on
harder.

Especially if that risks alienating objectors who will rightly feel
that they would have predicted a mess, if anyone had been prepared to
listen to them.


I'm sorry to have to put these things this way.  This will no doubt
read as a criticism of the people rather than of the code, which is
difficult and undesirable.  But, whether the problems are cultural, or
whatever, the dispute here is not only about technical details.

We cannot resolve the risk/reward tradeoff of usrmerge with a
definitely correct answer because we do not have, and will never have,
all the necessary information.  We cannot know how many systems in the
field would break from a forced usrmerge; even if we were to go ahead
with that we would probably never know the real cost.

Necessarily this is going to be a matter of judgement and guesswork.
The question then: whose judgement and guesswork ?


I would like to contrast the approach here to the way that the
AppArmor team have conducted their transition.  Throughout they have
been alert to problems; sought feedback; avoided commitment; and
generally brought the vast majority of the Debian community along with
them.  They have gained not only rough consensus but what looks like
real consent (insofar as such a thing might be possible collectively).


On the narrower question it must surely be obvious that it is far too
late to try to do a forced usrmerge of all systems in buster.
Certainly we should not be discussing forced usrmerge as anything but
a theoretical option, given that there is not even any transition plan
for it and the buster transition freeze is weeks away.

The default should be changed back not just in our buildds but also
for ordinary new installs.  usrmerge proponents can use the time
between now and the release of buster to refine their understanding of
the issues, do the necessary research, and write a transition plan.

We can then have this discussion again early in the bullseye release
cycle.  If we must.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

Hi all!

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.

However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.

We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

So far we are going to make this change starting with the Qt 5.11.3 packages.
In case you already want to test it, the updated qtbase package is available
in experimental [2]. However the reverse dependencies are not yet rebuilt.

This change will affect packages using Qt Gui [3], Qt Widgets [4], Qt Quick
and some other modules. It will not affect packages using the deprecated Qt
OpenGL module because it loads the OpenGL library at runtime.

The best way to check whether some package needs changes is checking Ubuntu
[5], which has been building Qt with OpenGL ES on arm64 since version 16.10
(yakkety) [6].

We will send a new mail with DD-list of packages that we detect to be affected
a bit later.

There are some packages that are not compatible with OpenGL ES. For example,
packages using libglu and Qt simultaneously will most likely have to drop
their arm64 binaries (like they already have no armel or arm64 binaries).
An example of such package is qwtplot3d.

Also note that as this change breaks ABI on arm64, we are renaming libqt5gui5
to libqt5gui5a, which will need binNMUs of all reverse dependencies. The list
of all such dependencies is available here [7]. This will happen together with
the Qt 5.11.3 transition.

Please Cc me or pkg-kde-talk on reply.

[1]: https://bugs.debian.org/881333
[2]: https://tracker.debian.org/news/1004843/
[3]: https://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration
[4]: https://doc.qt.io/qt-5/qopenglwidget.html
[5]: https://launchpad.net/ubuntu/+source/${SOURCE_PACKAGE_NAME},
 or the “ubuntu patches” link in the right panel of tracker.debian.org
[6]: https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/197063f08928ac9c
[7]: https://perezmeyer.com.ar/ben/qtbase.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Russ Allbery]

Ian Jackson  writes:

> It was very clear that what was proposed, some months ago, was
> *optional* usrmerge, which necessarily involves cross-compatibility.  It
> was on that basis that there were few objections.  Thus the original
> design promise from usrmerge proponents, when these changes were last
> discussed here, was indeed full portability of packages.  (Whether the
> usrmerge proponents realised that or not.)

This is a much better summary of the thread, and I wish that you would
have said this instead of claiming incorrectly that those same people are
the ones advocating for a full merge of all systems.

*I've* been one of the people advocating for that on this thread, and I've
not previously been involved in the usrmerge proposal at all.  I'm not
sure how many of the other people advocating it have been involved in the
project.  Neither Marco nor Simon have taken a position that I've seen,
and so far as I can tell are still interested in the optional approach.

I'm stating the advantages of fully converting Debian to merged /usr for
engineering reasons: I don't think the existing optional migration is
going to work very well or be supportable.  On this point, I'm
*disagreeing* with the usrmerge maintainer, who holds the opposite view.

Can you see from this why I think your and Michael's collapsing of nuance
into a claim that the usrmerge proponents are trying to react to a setback
by moving faster is unfair and harmful?  It's reducing a more complex
discussion to a simple us vs. them narrative.

> But when I said `unanticipated issues' I meant, of course, unanticipated
> by the usrmerge designers and implementers.  Yes, those problems were
> unanticipated problems *of full portability* rather than of usrmerge as
> an abstract principle.  But the usrmerge designers and implementers
> either (i) did not realise that their actions depended on full
> portability, or (ii) did not realise how hard it would be.  That's why
> there was no plan for how to achieve it.

I generally agree with this.  I also don't think this is particularly
unusual, or should be considered some sort of major failing.  A lot of us,
particularly on volunteer projects, are not going to get our analysis
right the first time.  That's why we stop, and think, and adjust when
something unexpected goes wrong, like now.

> My position as a usrmerge sceptic, of letting them get on with doing
> their thing, now seems to have been unwise.  The idea that it would be
> optional mutated, without proper discussion, and without a transition
> plan, into it being the default for new installs.

I agree with wanting more discussion and more of a plan before making it
the default for new installs, and I'm skeptical this is a good idea for
buster.

> And now there are serious suggestions that to solve this lack of
> foresight, lack of proper planning, lack of proper consultation, and
> lack of attention to detail, we should press ahead even faster and make
> the new scheme mandatory ?

Again, I think you're mixing up two separate issues in a way that adds
more noise than clarity.  There are two separate decisions here:

* Do we want to back off from supporting an optional switch and instead
  pursue converting all Debian installations to merged /usr?

* If we do want to do that, *when* should we do that, and what should the
  timeline look like?

The question of "faster" is about the second point, not the first one.
Personally, I think I agree with the comments here that it's too late to
do this for buster, and if we're going to work towards fully merging /usr,
this is something to tackle for buster+1 (preferrably by significant
testing very early in the cycle).

The first question is still open.  Various people have stated their
opinions, but I'm not sure we're having a proper debate about it because
it keeps getting mixed into other issues, such as people's opinion of the
planning and communication strategy of people working on usrmerge, or what
the timeline could look like.

I understand that those are all issues that matter.  What I'm objecting to
is (unintentionally, I think) muddling them all together into a giant,
upsetting mess of conflict.  I don't blame you for finding that upsetting
-- when everything is mixed together like that, it's all very upsetting!
That's why we need to break this down into separate points of
disagreement, separate the engineering decisions from the communication
and community decisions, and figure out where we actually disagree and
what the most constructive path forward is.

> Necessarily this is going to be a matter of judgement and guesswork.
> The question then: whose judgement and guesswork ?

Are we not a community?  We're providing input as a community in this
thread, providing some judgement and guesswork from lots of different
contributors.

I agree that at some point someone needs to step forward to pull that all
together into a set of possible strategies to move forward, but I don't
feel like we've e

individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt  writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to note that our past experience in Debian doesn't
> really support this.  I've run into multiple problems in unstable with
> uninstallable packages due to various bugs in this sort of change, most
> recently with iptables.  We repeatedly get the details of this change
> wrong in various subtle ways that create issues in some upgrade paths and
> not others.

Well, the iptables case is different: those are compat symlinks created
by the package's maintainer scripts, not the /bin -> /usr/bin symlinks
that merged-/usr sets up.

If we want to support packages such as iptables moving binaries from
/{s,}bin to /usr/{s,}bin while setting up compat symlinks on
non-merged-/usr systems, it might be useful to have a dh-usrmerge
package creating the maintainer scripts.  (Also for some files below
/lib, but most libraries could just be moved without compat symlinks.)

This should be similar to what OpenSUSE has done; see the section around
`#UsrMerge` on https://en.opensuse.org/openSUSE:Usr_merge

This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without).  Less static files would
be on a read-write root file system (if /usr is a separate read-only
fs).

In case a later Debian release would merged-/usr mandatory, the
conversion process would be less problematic as no files would be left
to move (just replace individual symlinks with a directory symlink).

Ansgar

Re: individual packages moving binaries from /bin to /usr/bin

[Russ Allbery]

Ansgar Burchardt  writes:

> If we want to support packages such as iptables moving binaries from
> /{s,}bin to /usr/{s,}bin while setting up compat symlinks on
> non-merged-/usr systems, it might be useful to have a dh-usrmerge
> package creating the maintainer scripts.  (Also for some files below
> /lib, but most libraries could just be moved without compat symlinks.)

> This should be similar to what OpenSUSE has done; see the section around
> `#UsrMerge` on https://en.opensuse.org/openSUSE:Usr_merge

> This could also be seen as a slower path to merged-/usr: programs such
> as `sed` would be in both /bin and /usr/bin and hard-coding either would
> be fine (as with merged-/usr, but not without).  Less static files would
> be on a read-write root file system (if /usr is a separate read-only
> fs).

Yes, this exactly, thank you.  This is a much better description of what I
was seeing as an alternative to the current usrmerge approach, assuming a
(not yet decided) project consensus that we want to do something like
usrmerge in the long run.

This approach will obviously take forever, and be another one of those
Debian transitions that someone five years from now has to do a bunch of
work to finally finish, assuming that happens at all.  But it would be
backward-compatible the entire way.

-- 
Russ Allbery (r...@debian.org)   

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[Simon McVittie]

On Thu, 22 Nov 2018 at 21:08:14 +0100, Ansgar Burchardt wrote:
> If we want to support packages such as iptables moving binaries from
> /{s,}bin to /usr/{s,}bin

To be honest, I'm not sure whether we do want this. We should be careful,
at least.

Now that we don't support booting without /usr[1], it is no longer
necessary to move an executable from /bin to /usr/bin if it gains
a dependency on a library that is in /usr/lib, and similarly, it is
unnecessary to move executables in the opposite direction to make them
available in early boot.

Unlike merged /usr, doing this move doesn't make things like containers
any simpler until literally every executable in /bin has undergone this
transition; the work happens now, but the benefit doesn't happen until
the transition is complete. If the compat symlink isn't created
carefully, it can easily break merged-/usr systems.

However, it can easily cause the same issue that started this thread -
when a dependent package detects "the" path to the iptables executable,
it will get different answers depending on $PATH order, just like it would
on a merged /usr system. That's fine if we can guarantee that iptables
exists in both places, but during a partial upgrade, we can't count on
that being the case without a versioned dependency on the moved iptables,
which I assume nobody is seriously intending to mass-bug-file?

For iptables, maybe that's no big deal, because not many packages depend
on it and hard-code its path, but we have evidence from our accidental
merged-/usr-buildds experiment (and its subsequent intentional equivalent
in reproducible-builds) that the paths to programs like grep, sed and
(of course) sh are more widespread.

(Everything I've said about /bin applies equally to /sbin of course,
I just didn't want to keep typing /{s,}bin.)

I'm not sure yet what the best plan for merged /usr is. I would definitely
like to make sure it's at least possible to continue to use merged
/usr for special-purpose systems (particularly containers and embedded
systems), even if it comes with major caveats like "can't reliably build
Debian packages suitable for other systems"; I personally think everyone
should be using sbuild or equivalent, either on a buildd or locally,
to build "release-quality" packages suitable for distribution to other
systems *anyway*, but I know that view isn't necessarily universal.

For at least special-purpose systems, merged /usr seems to work fine with
stretch, and I was able to get it working in an Ubuntu 12.04 derivative
by backporting a single-digit number of changes, so that particular genie
has been out of the bottle for quite some time anyway.

smcv

[1] in the sense that if /usr is separate, we require it to be mounted
by the initramfs

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[W. Martin Borgert]

Quoting Ansgar Burchardt :

This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without).  Less static files would
be on a read-write root file system (if /usr is a separate read-only
fs).

In case a later Debian release would merged-/usr mandatory, the
conversion process would be less problematic as no files would be left
to move (just replace individual symlinks with a directory symlink).


Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
times. And we did not even have dh in those days. Sounds good to me!

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Holger Levsen]

On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > Because:
> > > ...
> > thanks! nice summary.
> I replied in my other mail to the things I disagreed with (as is
> traditional) but it occurred to me I ought to send a positive note
> about this:
> 
> Thanks for being easy to convince!
 
:) thanks, appreciate!

> I also commend the phrasing of your original question with `why'.
> That could be read as rhetorical, but even so it invited a reasoned
> disagreement.

I absolutly ment it the simple way I wrote it: "why" and I'm glad you
understood it that way. I've found that often, short, friendly mails to the
point are much better than long emails.

(and the last sentence is the reason why I choose to send this mail to
the list and not to Ian only, as originally intended.)

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[Holger Levsen]

On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote:
> Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
> times. And we did not even have dh in those days. Sounds good to me!
 
ITYM s#potato#slink, potato, woody, sarge, etch and lenny#

(Started in 1999 and finally fully finished on Sep 25th 2008 with
closing #322762.)

So I don't think this transition is such a positive example :-D


-- 
cheers,
Holger, SCNR

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Marcin Juszkiewicz]

W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:

> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
> support. At the moment we are building it with OpenGL ES on armel and armhf,
> and with desktop OpenGL on all other architectures.
> 
> However we have received a request [1] from two different persons to add arm64
> to the list of architectures where OpenGL ES is used.
> 
> We want your feedback! If you are using an arm64 device or board with Qt,
> please let us know your opinion about this change, by replying to this mail
> or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

>From what I see the problem is with Qt not being able to be built with
support for both OpenGL and OpenGLES ;(

Re: Upcoming Qt switch to OpenGL ES on arm64

[John Paul Adrian Glaubitz]

> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz  
> wrote:
> 
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> 
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all other architectures.
>> 
>> However we have received a request [1] from two different persons to add 
>> arm64
>> to the list of architectures where OpenGL ES is used.
>> 
>> We want your feedback! If you are using an arm64 device or board with Qt,
>> please let us know your opinion about this change, by replying to this mail
>> or to [1], and describe your use case.
> 
> Does it mean that arm64 box with PCI Express graphics card will be not
> able to use Qt based software? I can put Radeon or NVidia card into my
> box and use it as a normal OpenGL accelerated desktop (did that already
> few years ago).

Correct. After this switch, Qt on arm64 will be forced into embedded mode when 
it comes to graphics.

Not sure whether it’s the right decision to be made. Might be an idea to ask 
more users on their opinions on this issue.

Granted, I don’t really know what the real world distribution of embedded and 
desktop/server/laptop devices of arm64 is.  But I could imagine that there will 
be more arm64 devices in the future which are desktops, servers or laptops.

Adrian

Re: Upcoming Qt switch to OpenGL ES on arm64

[Julien Cristau]

On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> 
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all other architectures.
>>
>> However we have received a request [1] from two different persons to add 
>> arm64
>> to the list of architectures where OpenGL ES is used.
>>
>> We want your feedback! If you are using an arm64 device or board with Qt,
>> please let us know your opinion about this change, by replying to this mail
>> or to [1], and describe your use case.
> 
> Does it mean that arm64 box with PCI Express graphics card will be not
> able to use Qt based software? I can put Radeon or NVidia card into my
> box and use it as a normal OpenGL accelerated desktop (did that already
> few years ago).
> 
At least mesa drivers can be used for desktop GL or GLESv2 just fine,
AFAIK.  Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making it
spread? :)

Cheers,
Julien

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> > ES support. At the moment we are building it with OpenGL ES on armel and
> > armhf, and with desktop OpenGL on all other architectures.
> > 
> > However we have received a request [1] from two different persons to add
> > arm64 to the list of architectures where OpenGL ES is used.
> > 
> > We want your feedback! If you are using an arm64 device or board with Qt,
> > please let us know your opinion about this change, by replying to this
> > mail
> > or to [1], and describe your use case.
> 
> Does it mean that arm64 box with PCI Express graphics card will be not
> able to use Qt based software? I can put Radeon or NVidia card into my
> box and use it as a normal OpenGL accelerated desktop (did that already
> few years ago).

"Depends". The change is only for software using some specific classes inside 
libqt5gui5. If your video card supports GLES (aka OpenGL ES) then you should 
be fine.

I *think* that most video cards support both GLES and Desktop OpenGL, but feel 
free to point me wrong.

Also I understand that if your video card does not supports GLES then 
software-based rendering might happen.

The real issue here is that *many* arm64 boards currently do not support 
Desktop OpenGL, but do support GLES.

Also applications using GLU[T] or glew will not be able to compile anymore on 
arm64. GLU[T] has not been ported to GLES, glew somehow differs in a type 
definition.

> >From what I see the problem is with Qt not being able to be built with
> 
> support for both OpenGL and OpenGLES ;(

That would be ideal, but yes, it's currently a build-time selection.

-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
  George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 22 de noviembre de 2018 18:51:20 -03 John Paul Adrian Glaubitz 
escribió:
> > On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz
> >  wrote:> 
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are building it with OpenGL ES on
> >> armel and armhf, and with desktop OpenGL on all other architectures.
> >> 
> >> However we have received a request [1] from two different persons to add
> >> arm64 to the list of architectures where OpenGL ES is used.
> >> 
> >> We want your feedback! If you are using an arm64 device or board with Qt,
> >> please let us know your opinion about this change, by replying to this
> >> mail
> >> or to [1], and describe your use case.
> > 
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or NVidia card into my
> > box and use it as a normal OpenGL accelerated desktop (did that already
> > few years ago).
> 
> Correct. After this switch, Qt on arm64 will be forced into embedded mode
> when it comes to graphics.

s/graphics/OpenGL specific classes.
 
> Not sure whether it’s the right decision to be made. Might be an idea to ask
> more users on their opinions on this issue.

Well, it's not a new thing for us:




I encourage anyone who wants to know more details to dig into that bug. As you 
can see the first one was filled by myself on 2015...


> Granted, I don’t really know what the real world distribution of embedded
> and desktop/server/laptop devices of arm64 is.  But I could imagine that
> there will be more arm64 devices in the future which are desktops, servers
> or laptops.

...and that was exactly what we have been doing since 2015. Now in #881333 
Raphael pointed for new data and the need for GLES as one thing is having 
software-based rendering and quite another having hardware-accelerated 
rendering.


-- 
Only wimps use tape backup: real men just upload their important stuff on
ftp, and let the rest of the world mirror it ;)
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau escribió:
> On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are building it with OpenGL ES on
> >> armel and armhf, and with desktop OpenGL on all other architectures.
> >> 
> >> However we have received a request [1] from two different persons to add
> >> arm64 to the list of architectures where OpenGL ES is used.
> >> 
> >> We want your feedback! If you are using an arm64 device or board with Qt,
> >> please let us know your opinion about this change, by replying to this
> >> mail
> >> or to [1], and describe your use case.
> > 
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or NVidia card into my
> > box and use it as a normal OpenGL accelerated desktop (did that already
> > few years ago).
> 
> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
> AFAIK.  Maybe the answer for Qt is to switch to GLESv2 for all
> architectures, to stop the special-casing madness, instead of making it
> spread? :)

That would mean that anything using Qt + [GLU[T] glew] will have to get 
removed from the archive.

Now let's suppose for a minute that the above could be solvable: it would be 
good to know whether this is in fact a possible solution.

In this case the question would be: do the major part of the video cards out 
there support GLES?


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Matthew Vernon  wrote:

> > In the worst case it will fail explaining that some local change (in
> > a directory which should not have been modified by the local admin, BTW)
> > needs to be addressed by the local admin and then it can be restarted 
> > and continue its work.
> Could you expand on this? I'm responsible for enough systems with enough
> "interesting historical artifacts" that I'd bet that pretty much every
> directory has been modified on at least some of them.
usrmerge cannot convert a system which has two different binaries (not 
symlinks) with the same name in {/usr,}/s?bin/, because it cannot know 
which one should be kept.
This condition does not happen on regular systems: only if somebody 
manually copied something to {/usr,}/s?bin/, which is not supposed to 
happen.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> Hi all!
> 
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> ES support. At the moment we are building it with OpenGL ES on armel and
> armhf, and with desktop OpenGL on all other architectures.

Maybe we missed to properly explain the main point of this change: currently 
most arm64 boards are using software rasterization because their video cards 
do not support Desktop OpenGL. If we switch to GLES then most amr64 boards 
will be able to render using their video hardware, thus greatly improving 
speed to the point of being actually usable for some stuff.

I imagine (but would *love* hard data) that any PCI video card added to an 
arm64 machine will probably also support GLES, so they will still have use.

But one thing is for sure: it's not a decision in which everyone wins, so we 
are trying to make a decision on which *most* of our users wins.  


-- 
When the winds of change are blowing, some people are building shelters, and
others are building windmills.
  Old Chinese Proverb

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Michael Stone  wrote:

> Three years ago we were told this was to enable people to optionally do
> something, not that all users would be forced to migrate. That's a pretty
> substantial change.
At this point there is no plan to force anybody to migrate. It has just 
been argued that it would be more convenient.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 22, Russ Allbery  wrote:

> I'm stating the advantages of fully converting Debian to merged /usr for
> engineering reasons: I don't think the existing optional migration is
> going to work very well or be supportable.  On this point, I'm
> *disagreeing* with the usrmerge maintainer, who holds the opposite view.
I am not disagreeing with you at all. I just do not want to start 
another fight with the people who are scared by changes.

> I agree with wanting more discussion and more of a plan before making it
> the default for new installs, and I'm skeptical this is a good idea for
> buster.
But nobody so far has explained exactly what could be done better by 
waiting more time.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
>> Hi all!
>>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
>> ES support. At the moment we are building it with OpenGL ES on armel and
>> armhf, and with desktop OpenGL on all other architectures
> 
> Maybe we missed to properly explain the main point of this change: currently 
> most arm64 boards are using software rasterization because their video cards 
> do not support Desktop OpenGL. 

I am not sure that is correct.  I certainly don't agree...

There is no special case here.  If you have a video card in your ARM64
PC then it is likely the same video card that you have for an AMD64 PC -
i.e. it is an off the shelf PCIe card.

Now it is correct that there is a large number of ARM64 based SoC
solutions out there with an embedded GPU - these are aimed mainly at the
mobile market (but as the computational power in these SoCs increases we
are already seeing that is enough for a lot of peoples 'PC' needs)

I guess what I am trying to say here is the GPU architecture is NOT tied
to the CPU architecture.


If we switch to GLES then most amr64 boards
> will be able to render using their video hardware, thus greatly improving 
> speed to the point of being actually usable for some stuff.
> 
> I imagine (but would *love* hard data) that any PCI video card added to an 
> arm64 machine will probably also support GLES, so they will still have use.
> 

So 
any PCI video card added to s/amr64/AMD64 machine will probably also
support GLES, so they will still have use.
OK that is true - lets enact this across ALL architectures, but I
suspect that there may be a bit of pushback from the AMD64 heavy graphic
users...


> But one thing is for sure: it's not a decision in which everyone wins, so we 
> are trying to make a decision on which *most* of our users wins.  
> 
> 
Agreed

Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
exclusive from an install POV, but give the end user the choice which to
install?  Why should we have one Architecture forced down a path
different to another architecture?

/Andy

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Please let me reply first to your last part:

> Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
> exclusive from an install POV, but give the end user the choice which to
> install?  Why should we have one Architecture forced down a path
> different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but 
is definitely too much work to hack on.

So we need to force an architecture (actually, all of them!) to either one or 
the other.


El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:
> On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> >> Hi all!
> >> 
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL
> >> ES support. At the moment we are building it with OpenGL ES on armel and
> >> armhf, and with desktop OpenGL on all other architectures
> > 
> > Maybe we missed to properly explain the main point of this change:
> > currently most arm64 boards are using software rasterization because
> > their video cards do not support Desktop OpenGL.
> 
> I am not sure that is correct.  I certainly don't agree...
> 
> There is no special case here.  If you have a video card in your ARM64
> PC then it is likely the same video card that you have for an AMD64 PC -
> i.e. it is an off the shelf PCIe card.
> 
> Now it is correct that there is a large number of ARM64 based SoC
> solutions out there with an embedded GPU - these are aimed mainly at the
> mobile market (but as the computational power in these SoCs increases we
> are already seeing that is enough for a lot of peoples 'PC' needs)
> 
> I guess what I am trying to say here is the GPU architecture is NOT tied
> to the CPU architecture.

- GPU architecture is not tied to the arch: right.
- Qt is tied to either Desktop or GLES: yes

So we need to pick one. The question is then which one will benefit our users 
most.

So far I personally know 0 people with an arm64 board with PCI slots, while I 
know many with arm64 boards with hardware GLES support.

> If we switch to GLES then most amr64 boards
> 
> > will be able to render using their video hardware, thus greatly improving
> > speed to the point of being actually usable for some stuff.
> > 
> > I imagine (but would *love* hard data) that any PCI video card added to an
> > arm64 machine will probably also support GLES, so they will still have
> > use.
> 
> So 
> any PCI video card added to s/amr64/AMD64 machine will probably also
> support GLES, so they will still have use.
> OK that is true - lets enact this across ALL architectures, but I
> suspect that there may be a bit of pushback from the AMD64 heavy graphic
> users...
> 

No need to use sarcasm. Yes, it's a matter of choice. No one noted yet that 
all archs except armel and armhf have Desktop support and not GLES. And this 
is because, so far and to the best of our knowledge, that has been the right 
thing to do.

So: what's the best outcome for our *current* users? Again, pick only one.


-- 
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
  Unknown - http://www.linfo.org/q_unix.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Eremin-Solenikov]

Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
:
>
> Hi! Please let me reply first to your last part:
>
> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
> > exclusive from an install POV, but give the end user the choice which to
> > install?  Why should we have one Architecture forced down a path
> > different to another architecture?
>
> No, I'm afraid there is no way to do that. We did consider it many times, but
> is definitely too much work to hack on.
>
> So we need to force an architecture (actually, all of them!) to either one or
> the other.

Can you build two packages and allow user to select, which one he wants to
install? Or those packages will be binary incompatible?

> El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:
> > On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> > >> Hi all!
> > >>
> > >> The Qt framework can be built either with “desktop” OpenGL, or with
> > >> OpenGL
> > >> ES support. At the moment we are building it with OpenGL ES on armel and
> > >> armhf, and with desktop OpenGL on all other architectures
> > >
> > > Maybe we missed to properly explain the main point of this change:
> > > currently most arm64 boards are using software rasterization because
> > > their video cards do not support Desktop OpenGL.
> >
> > I am not sure that is correct.  I certainly don't agree...
> >
> > There is no special case here.  If you have a video card in your ARM64
> > PC then it is likely the same video card that you have for an AMD64 PC -
> > i.e. it is an off the shelf PCIe card.
> >
> > Now it is correct that there is a large number of ARM64 based SoC
> > solutions out there with an embedded GPU - these are aimed mainly at the
> > mobile market (but as the computational power in these SoCs increases we
> > are already seeing that is enough for a lot of peoples 'PC' needs)
> >
> > I guess what I am trying to say here is the GPU architecture is NOT tied
> > to the CPU architecture.
>
> - GPU architecture is not tied to the arch: right.
> - Qt is tied to either Desktop or GLES: yes
>
> So we need to pick one. The question is then which one will benefit our users
> most.
>
> So far I personally know 0 people with an arm64 board with PCI slots, while I
> know many with arm64 boards with hardware GLES support.

I'm working with big arm64 iron, so for me a server arm64 board with PCIe slots
(and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more common
compared to GLES-enabled arm64 SoC.

-- 
With best wishes
Dmitry

Work-needing packages report for Nov 23, 2018

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1314 (new: 7)
Total number of packages offered up for adoption: 158 (new: 0)
Total number of packages requested help for: 57 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cmdtest (#914030), orphaned 4 days ago
 Description: blackbox testing of Unix command line programs
 Reverse Depends: vmdb2
 Installations reported by Popcon: 386
 Bug Report URL: http://bugs.debian.org/914030

   multistrap (#914282), orphaned yesterday
 Description: multiple repository bootstrap based on apt
 Installations reported by Popcon: 286
 Bug Report URL: http://bugs.debian.org/914282

   pdf2htmlex (#914264), orphaned yesterday
 Description: Converts PDF to HTML while retaining most formatting
 Installations reported by Popcon: 460
 Bug Report URL: http://bugs.debian.org/914264

   python-cliapp (#914028), orphaned 4 days ago
 Description: Python framework for Unix command line programs
 Reverse Depends: cmdtest freedom-maker live-wrapper vmdb2
   vmdebootstrap
 Installations reported by Popcon: 1068
 Bug Report URL: http://bugs.debian.org/914028

   python-coverage-test-runner (#914029), orphaned 4 days ago
 Description: fail Python program unit tests unless they test
   everything
 Installations reported by Popcon: 137
 Bug Report URL: http://bugs.debian.org/914029

   python-ttystatus (#914026), orphaned 4 days ago
 Description: terminal progress bar and status output for Python
 Reverse Depends: cmdtest
 Installations reported by Popcon: 821
 Bug Report URL: http://bugs.debian.org/914026

   vmdb2 (#914027), orphaned 4 days ago
 Description: creator of disk images with Debian installed
 Installations reported by Popcon: 49
 Bug Report URL: http://bugs.debian.org/914027

1307 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 158 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

[NEW] influxdb (#914035), requested 4 days ago
 Reverse Depends: golang-github-google-cadvisor-dev
   golang-github-osrg-gobgp-dev influxdb-dev
 Installations reported by Popcon: 560
 Bug Report URL: http://bugs.debian.org/914035

   autopkgtest (#846328), requested 722 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: autodeb-worker debci-worker
 Installations reported by Popcon: 1156
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2615 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 712
 Bug Report URL: http://bugs.debian.org/642906

   broadcom-sta (#886599), requested 318 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1946
 Bug Report URL: http://bugs.debian.org/886599

   cargo (#860116), requested 590 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 724
 Bug Report URL: http://bugs.debian.org/860116

   cyrus-sasl2 (#799864), requested 1156 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs adcli autofs-ldap
   cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier
   claws-mail-address-keeper claws-mail-archiver-plugin
   claws-mail-attach-remover (114 more omitted)
 Installations reported by Popcon: 201250
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 860 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 62582
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1545 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 11610
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 1150 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   autodeb-worker brz-debian bzr-builddeb customdeb debci
   debian-

Bug#914401: ITP: node-d3-contour -- Computes contour polygons by applying marching squares to a rectangular array.

[Kannan V M]

Package: wnpp
Severity: wishlist
Owner: Kannan V M 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : node-d3-contour
 Version : 1.3.2
 Upstream Author : Mike Bostock (http://bost.ocks.org/mike)
* URL : https://d3js.org/d3-contour/
* License : BSD-3-Clause
 Programming Lang: JavaScript
 Description : Computes contour polygons by applying marching
 squares to a rectangular array

 Computes contour polygons by applying marching
 squares to a rectangular array of numerical values.
 .
 Contour polygons are GeoJSON, you can transform and display
 them using standard tools.
 .
 Contour plots can also visualize continuous functions by sampling.
 .
 Contours can also show the estimated density of point clouds,
 which is especially useful to avoid overplotting in large
 datasets. This library implements fast two-dimensional kernel
 density estimation.

This package is a dependency for gitlab.
There are no other similar packages are available in debian alternative
to d3-contour. It uses rollup to transform the source code, so it is not
usable for embedding.

I want to maintain this package under JavaScript maintainers team.
Praveen has agreed to sponsor this package.
-kannan

Re: usrmerge -- plan B?

[Vincent Bernat]

 ❦ 22 novembre 2018 18:00 +0100, Marco d'Itri :

> Actually I believe that the fact that this could be solved quickly and 
> with a trivial change is a great argument in favour of the quality of my 
> plan and work for switching to merged-/usr.

Thank you for that! My workstation was switched to merged-/usr without
issue three years ago. It is running the same Debian unstable
installation since 2002.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[Marco d'Itri]

On Nov 22, Ansgar Burchardt  wrote:

> Well, the iptables case is different: those are compat symlinks created
> by the package's maintainer scripts, not the /bin -> /usr/bin symlinks
> that merged-/usr sets up.
Actually iptables is different because it mixes (incorrectly) 
compatibility symlinks and diversions.

Correctly creating just compatibility symlinks is trivial and has been 
documented for years on the wiki.

> In case a later Debian release would merged-/usr mandatory, the
> conversion process would be less problematic as no files would be left
> to move (just replace individual symlinks with a directory symlink).
No: it would not be any easier than it is now because every Debian 
system can already be converted automatically. Having usrmerge move 
files /installed by packages/ is well tested.

-- 
ciao,
Marco


signature.asc
Description: PGP signature