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 a
❦ 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 me
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
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 reques
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? W
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 architect
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 arm
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
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 hold
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.
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
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 buil
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 suppo
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
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 o
> 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 des
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 req
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 final
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 convinc
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 sep
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], i
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
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
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
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
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 be
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 r
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 to
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 locati
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
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 a
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
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
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' system
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-Develope
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
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
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
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 dis
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
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.
I
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
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 no
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 b
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 pl
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
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 mor
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
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.u
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 al
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
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 o
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 i
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.
Lo
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 replyi
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 unacceptab
56 matches
Mail list logo
