Re: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez 
> Meyer escribió:
> [snip]
> > > > prepare dual stack packages that use the symbols file magic from
> > > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > > packages which are libraries and which end up with a dependency only on
> > > > the
> > > > GL version of the package instead of a dependency on GL | GLES.

> > On a second thought: suppose a library libexample that uses the symbols as
> > provided by the current libqt5gui5 (either with one or the other version)
> > but does not exposes it's symbols. The end result will not make
> > libexample's symbols change but will for sure it's internal usage of
> > libqt5gui5. How can one differentiate libraries like libexample from other
> > libraries that do use libqt5gui5 but not it's OpenGL stuff?

> Or maybe even applications! Let's suppose libqt5qml5 follows the libexample 
> example (it *does* requires some kind of OpenGL). Now qtcreator (to name just 
> one application) does usage of it, and users will surely want to use the 
> right 
> build for their use case. Building two qtcreator binaries sounds like just 
> too 
> much.

> Now get Plasma. It does a heavy usage of QML. In *lots* of places and 
> packages.

> At this point I really feel that, except I am missing something, double 
> building is just not a good idea :-/

Ok, I don't think you've understood then.  Perhaps a further example from
the Ubuntu archive would help.  As of Ubuntu 16.04, here is the *complete*
list of packages that had a hard dependency on any of the 5 GL-linked Qt
libraries, where that dependency could not instead be satisfied by the GLES
build:

$ grep-dctrl -n -sSource:Package -FDepends \
-e 
'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
 5\.[0-9.]*\))(?|$),' \

/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages
 | sort -u
maliit-plugins
ovito
pyqt5
qml-box2d
qt3d-opensource-src
qtbase-opensource-src
qtdeclarative-opensource-src
qtubuntu-cameraplugin-fake
stellarium
wallch
$

Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu
16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles.

Three of the results in this list are familiar; they were already in the set
of dual-stack libraries.

Several are applications (ovito, stellarium, wallch), and if they say they
require full GL, that's legitimate, and that just means users would only be
able to install them on systems using the full desktop GL.  (That's fine,
and certainly better than not being able to build/install them at all.)

maliit-plugins is not an application, but it's a rather specialized
component with no reverse-dependencies (i.e. not a library).

qml-box2d is likely to have never been uploaded after the symbols handling
was implemented in Ubuntu, therefore never picked up the alternate
dependencies (the package isn't in Debian, anyway).

And pyqt5, since it's language bindings for the full Qt API, would also need
to be double-built (but had not been in Ubuntu).

The qml packages built from these libraries - qml-module-qtlocation,
qml-module-qtmultimedia, qtdeclarative5-qtlocation-plugin - would also need
proper handling, but the impact on dependency graphs should be similarly
self-limiting; because just as for C programs, the vast majority of QML
applications don't care about the distinction between GL and GLES backends
and *expect* Qt to abstract this away for them.

So based on this, Ubuntu missed exactly one package in order to fully
support both GL and GLES builds of Qt, bringing the total to 6 instead of 5.

There might be more now, but I'd be surprised if the total number of
affected source packages in Debian today reached double digits; and in any
case the question lends itself to the same sort of analysis as above, so
anyone interested in doing this in Debian can reasonably work out the scope.

And each of those gles source packages is a purely mechanical transformation
of the base Qt source package.

So perhaps someone in this thread is willing to put in this effort to
maintain 6 source packages, in order to avoid having to make a choice
between GL and GLES on arm64.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 28, "Alexander E. Patrakov"  wrote:

> Well, the buildd configuration change has been reverted. What worries me now
> is that there is a risk not yet mitigated, coming from personal systems of
> Debian developers, and we should also check porter boxes.
This is not a new problem at all: in my long Debian career I have 
misbuilt more than one upload by not using a chroot. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Paul Wise]

On Wed, Nov 28, 2018 at 7:30 AM Lisandro Damián Nicanor Pérez Meyer wrote:

> Just curious: is there any project alive for the PowerVR SGX530 ?

There used to be a very brief effort around PowerVR devices but it
looks like that has died now. Some of the project site was captured by
archive.org and lkcl's part of the work is still on his site. If
anyone wants to start a new reverse engineering effort, I strongly
suggest to start it on a hosting service close to the existing
Xorg/etc communities that will last long-term (like
freedesktop.org/x.org) instead of one that might disappear at any
moment.

https://wiki.debian.org/Mobile#software-drivers
https://web.archive.org/web/20170620135604/http://powervr.gnu.org.ve:80/doku.php
https://libreplanet.org/wiki/Group:PowerVR_drivers
http://lkcl.net/powervr/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Re: usrmerge -- plan B?

[Alexander E. Patrakov]

Russ Allbery wrote:


We had some things break because of a change to buildd configuration that
caught some people by surprise.


Well, the buildd configuration change has been reverted. What worries me 
now is that there is a risk not yet mitigated, coming from personal 
systems of Debian developers, and we should also check porter boxes.


As long as there is one Debian Developer (or any other person who has 
the right to upload binary packages) who has a merged /usr on his system 
used for building packages, there is a risk of reintroducing the bug 
through his package. Maybe we should somehow, in the short term, modify 
dpkg to add something like "Tainted-By: usr-merge" control field to all 
binary packages produced, if a package is built on a system with merged 
/usr (detected via /bin being a symlink). And a corresponding automatic 
check that would auto-reject binary packages with any Tainted-By control 
field from being uploaded to the Debian archive.


P.S. I am not even a Debian Maintainer, so all of the above may be 
rubbish. Would appreciate a reply that confirms or disproves that my 
thoughts make any sense.


--
Alexander E. Patrakov



smime.p7s
Description: S/MIME Cryptographic Signature

Re: usrmerge -- plan B?

[Alf Gaida]

>> I think it would be good to hear from any derivatives in this
>> position.  We should probably ask them more formally than by having a
>> horrible flamewar on -devel ...

With my siduction dev hat on i want to have usrmerge as soon as
possible. Built the last months with usrmerge activated and can't see
any downsides. Ok, we had to modify some things in our iso build process
and some minor things in our scripts, nothing important.

So we will have indeed the situation that new systems will be usrmerged,
old systems not. We will solve this the nice way: We will strongly
recommend to merge and help with problems. If all things go well -
there will be no reports, if things go south, expect some bugs filed
together with patches.

> I don't mean that I'm unsympathetic to downstreams in that situation, or
> that I wouldn't want to help them; only that their plight /should not/ be an
> obstacle to Debian doing the right thing.

We switched to systemd before debian, i guess we will switch before
debian in the usrmerge case - i don't see any problems doing so.

Cheers Alf

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end up with a dependency only on
> > > the
> > > GL version of the package instead of a dependency on GL | GLES.
> 
> On a second thought: suppose a library libexample that uses the symbols as
> provided by the current libqt5gui5 (either with one or the other version)
> but does not exposes it's symbols. The end result will not make
> libexample's symbols change but will for sure it's internal usage of
> libqt5gui5. How can one differentiate libraries like libexample from other
> libraries that do use libqt5gui5 but not it's OpenGL stuff?

Or maybe even applications! Let's suppose libqt5qml5 follows the libexample 
example (it *does* requires some kind of OpenGL). Now qtcreator (to name just 
one application) does usage of it, and users will surely want to use the right 
build for their use case. Building two qtcreator binaries sounds like just too 
much.

Now get Plasma. It does a heavy usage of QML. In *lots* of places and 
packages.

At this point I really feel that, except I am missing something, double 
building is just not a good idea :-/


-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

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 martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
> 
> Meyer wrote:
> [snip]
> 
> > > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > > maintainer).  He points me out that those 7 packages were needed for the
> > > Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> > > libraries.  The question is then: how would this affect other stacks
> > > like
> > > the ones I mentioned before?  And then there might be other libraries
> > > involved.  Granted, we do not know exactly which ones but...
> > 
> > It is actually fairly easy to answer this question as well: simply
> > identify
> > all the packages in the archive that depend on one of the known dual-stack
> > libraries,
> 
> That's libqt5gui5:
> 
> 
> 
> And that's just the tip of the iceberg. libqt5gui5 is surely the second most
> used library provided by Qt just before libqt5core5.
> 
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > packages which are libraries and which end up with a dependency only on
> > the
> > GL version of the package instead of a dependency on GL | GLES.

On a second thought: suppose a library libexample that uses the symbols as 
provided by the current libqt5gui5 (either with one or the other version) but 
does not exposes it's symbols. The end result will not make libexample's 
symbols change but will for sure it's internal usage of libqt5gui5. How can 
one differentiate libraries like libexample from other libraries that do use 
libqt5gui5 but not it's OpenGL stuff?

Maybe there is a way, but I sincerely do not know (other tan trial and error, 
of course).

-- 
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem
and you will not get to space today.
  http://xkcd.com/1133/

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 martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
[snip] 
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer).  He points me out that those 7 packages were needed for the
> > Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> > libraries.  The question is then: how would this affect other stacks like
> > the ones I mentioned before?  And then there might be other libraries
> > involved.  Granted, we do not know exactly which ones but...
> 
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, 

That's libqt5gui5:



And that's just the tip of the iceberg. libqt5gui5 is surely the second most 
used library provided by Qt just before libqt5core5.

> prepare dual stack packages that use the symbols file magic from
> Ubuntu, rebuild all the reverse-dependencies, and identify all those
> packages which are libraries and which end up with a dependency only on the
> GL version of the package instead of a dependency on GL | GLES.
> 
> A fair amount of compile time required to do this analysis, but relatively
> little human time.

As long as the human behind it has a way to simply trigger this rebuilds 
automatically. I think Ubuntu has by using launchpad. We in Debian don't 
(please prove me wrong!). On my current machine that would take 
approximately... a couple of months. Without using it for anything else.

Of course, if anyone feels like doing it... :-)

-- 
http://mx.grulic.org.ar/lurker/message/20081108.174208.4f42e55c.es.html
Así se corrobora el software legal en Argentina

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

[Steve Langasek]

On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> >  2ubuntu4~1

> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped development on this:

> > $ wget -O - -q
> > http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.g
> > z \ zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
> > Package: qt3d-opensource-src-gles
> > Package: qtbase-opensource-src-gles
> > Package: qtdeclarative-opensource-src-gles
> > Package: qtlocation-opensource-src-gles
> > Package: qtmir-gles
> > Package: qtmultimedia-opensource-src-gles
> > Package: qtubuntu-gles
> > $

> > i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
> > qtubuntu).

> And to be honest two of those packages where exclusive to ubuntu: qtmir-gles 
> and qtubuntu-gles.

> > Maybe you were already aware of this, but it didn't come across to me in
> > your mail, sorry. 

> Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> maintainer).  He points me out that those 7 packages were needed for the
> Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> libraries.  The question is then: how would this affect other stacks like
> the ones I mentioned before?  And then there might be other libraries
> involved.  Granted, we do not know exactly which ones but...

It is actually fairly easy to answer this question as well: simply identify
all the packages in the archive that depend on one of the known dual-stack
libraries, prepare dual stack packages that use the symbols file magic from
Ubuntu, rebuild all the reverse-dependencies, and identify all those
packages which are libraries and which end up with a dependency only on the
GL version of the package instead of a dependency on GL | GLES.

A fair amount of compile time required to do this analysis, but relatively
little human time.

If someone was interested in volunteering to ensure both GL and GLES were
supported by Qt, this is where I would suggest they start, in order to
accurately size the effort involved and know what they're signing up for.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió:
> Hi Rohan!
> 
> On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> > [...]
> > 
> > I concur here. It was correctly pointed out in another reply that by using
> > OpenGL we're specifically catering to software that doesn't support
> > GLES while making performance worse for mature applications that
> > do implement both OpenGL and GLES. The reality of the situation is that
> > the market currently favors GLES over GL on ARM SBC's, delivered with
> > proprietary blobs. I think a more pragmatic view of this reality would be
> > to deliver the best FOSS user experience that's possible with the
> > proprietary drivers while the open source drivers are being improved. To
> > that extent, by switching to GLES we improve the overall situation since
> > OpenGL applications can fall back to software rendering via mesa on
> > platforms where mesa does not support the GPU.
> 
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
> 
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.

I can't but agree here.

-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 25 de noviembre de 2018 21:18:39 -03 Paul Wise escribió:
> On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > Both Dmitry and I just learned that the RPI has the VC4 driver which
> > enables it to do hardware acceleration for Desktop OpenGL, we must admit
> > that this is a game changer in many ways, even if we are talking on just
> > one board (but quite an ubiquitous one).
> 
> I expect this also applies to any driver in (or soon to be in) mesa,
> including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv
> (Vivante), Tegra etc. Drivers only supporting GLES seems to be a
> something that happens only with the proprietary drivers. I don't have
> any ARM devices with GPUs to be able to test this though.

Just curious: is there any project alive for the PowerVR SGX530 ?

Yes, they are mostly found on armhf devices, but as far as I know there is 
only the proprietary (and crappy) driver.

-- 
La vida no se mide por la cantidad de veces que respiramos,
sino por la cantidad de momentos que nos quitan la respiración.
  Anónimo

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.

Bug#914853: ITA: yaml-cpp

[Simon Quigley]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org ti...@debian.org

This is being filed to publicly state what I have discussed in private
with Andreas Tille (and what he recently publicly stated[1]), that I
plan on adopting this package.

I understand that a recent upload has triggered a transition, and I plan
on helping finish that before proceeding with a 0.6.2 upload.

Thanks.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911956#30

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi Steve!

First of all: thanks for chiming in!

El martes, 27 de noviembre de 2018 19:06:27 -03 Steve Langasek escribió:
> Hi Lisandro,
[snip]
> > This waterfall schema means *multiple* libraries would have to start doing
> > this two-binaries thing, as Ubuntu devs discovered. But remember that Qt
> > is
> > really a set of submodules, so in any later version any submodule could
> > start using this switch for something. So whatever change could mean yet
> > another set of binaries with a transition with multiple rebuilds of the
> > big part of rdeps of Qt... no, we don't want to enter that mess.
> 
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> 
> Yes, GL vs. GLES impacts the ABI of libqt5gui5; HOWEVER, the set of
> reverse-dependencies that are actually impacted by the GL-specific ABI
> difference is actually quite small; and by using clever symbols files, the
> impact on the dependency tree can be minimized.
> 
> If anyone wants to dig into this further, perhaps for proof-of-concept, here
> is packaging that could be used as a starting point for the symbols files:
> 
>  
> https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg-> 
> 2ubuntu4~1
> 
> And here is the list of all packages that required dual-stack at least as of
> 2017, when Ubuntu stopped development on this:
> 
> $ wget -O - -q
> http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.g
> z \ zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
> Package: qt3d-opensource-src-gles
> Package: qtbase-opensource-src-gles
> Package: qtdeclarative-opensource-src-gles
> Package: qtlocation-opensource-src-gles
> Package: qtmir-gles
> Package: qtmultimedia-opensource-src-gles
> Package: qtubuntu-gles
> $
> 
> i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
> qtubuntu).

And to be honest two of those packages where exclusive to ubuntu: qtmir-gles 
and qtubuntu-gles.

> Maybe you were already aware of this, but it didn't come across to me in
> your mail, sorry. 

Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt 
maintainer). He points me out that those 7 packages were needed for the Ubuntu 
Touch port which, I presume, does not counts KDE's Plasma or KF libraries. The 
question is then: how would this affect other stacks like the ones I mentioned 
before? And then there might be other libraries involved. Granted, we do not 
know exactly which ones but...

> If you still think it is too much maintenance overhead to
> provide a dual stack for these 5 libraries (plus any others that later
> start to use GL-dependant ABIs), I think you're absolutely entitled to that
> view.

..yes, we are a team of roughly 3 people, mostly not available the three at 
the same time. It is not a strange situation that *just* one of us prepares 
almost (if not all) the full stack when a new release happens and sometimes 
even one of the others gets to handle the transition needed for private 
symbols (and thus getting it into unstable properly).

We are indeed having help from new contributors in some points, and I really 
hope they step up even more in the future, but currently the stack is huge for 
us. Heck, we don't even manage to handle tests for some submodules, let's not 
even think on autopkgtests.

But then let's suppose new manpower arrives, maybe dedicated to the task. The 
question is then: how many other packages this will affect? Will all the other 
maintainers be able to handle double stacks if needed? Is it really good to 
"kind of" impose even more work to maintainers? The KDE-related stack is 
possibly even bigger than Qt, and to the best of my knowledge there are just a 
handful of people maintaining it.

My current answer is: I really don't know.

-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

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.

Bug#914849: ITP: junixsocket -- Unix Domain Sockets in Java

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: junixsocket
  Version : 2.0.4
  Upstream Author : Christian Kohlschütter
* URL : https://github.com/kohlschutter/junixsocket
* License : Apache-2.0
  Programming Lang: Java, C++
  Description : Unix Domain Sockets in Java

junixsocket is a Java/JNI library that allows the use of Unix Domain Sockets
(AF_UNIX sockets) from Java. In contrast to other implementations, junixsocket
extends the Java Sockets API (java.net.Socket, java.net.SocketAddress etc.)
and even supports RMI over AF_UNIX. It is also possible to use it in
conjunction with Connector/J to connect to a local MySQL server via Unix domain
sockets.

This package is required to build the byte-buddy-agent module in src:byte-buddy,
and then upgrade Mockito to the version 2.x.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

Hi Lisandro,

On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you 
> did but in another part of the thread.

> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> > On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
> [snip]
> > >Can you build two packages and allow user to select, which one he wants to
> > >install? Or those packages will be binary incompatible?

> > That's a good question, yes. It'w ahst I was wondering too.

> And that's a perfectly valid question, one we did in 2015, Ubuntu tried out 
> (as Dmitry pointed out) and did not work.

> Why?

> Short story: really *too* complicated and error prone.

> Long story:

> Please first check this image:

> 

> That's almost all of Qt for 5.10 (we have now new submodules, so I need to 
> update it).

> The Desktop/GLES decision is done at the root of the graph, qtbase. This 
> decision changes the API/ABI of libqt5gui5, one of the libraries provided by 
> qtbase.

> So, as the API/ABI changes then we would need to (probably) ship two set of 
> headers and (for sure) two different libraries, let's say libqt5gui5 for 
> Desktop and libqt5gui5gles for GLES.

> But it doesn't ends there. The whole graph you saw is actually the *entire* 
> Qt. Upstream provides it either as a big fat tarball or as submodules. We 
> took 
> the submodules route because building the whole tarball as one would take 
> literally days in slow arches. And a single mistake could be disastrous.

> Now whatever switch is applied to qtbase it's "inherited" by the rest of the 
> submodules. So if we ship two versions of libqt5gui5 then we would probably 
> need to ship two versions of the libs provided by qtdeclarative, which is 
> affected by this switch.

> This waterfall schema means *multiple* libraries would have to start doing 
> this two-binaries thing, as Ubuntu devs discovered. But remember that Qt is 
> really a set of submodules, so in any later version any submodule could start 
> using this switch for something. So whatever change could mean yet another 
> set 
> of binaries with a transition with multiple rebuilds of the big part of rdeps 
> of Qt... no, we don't want to enter that mess.

Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.

Yes, GL vs. GLES impacts the ABI of libqt5gui5; HOWEVER, the set of
reverse-dependencies that are actually impacted by the GL-specific ABI
difference is actually quite small; and by using clever symbols files, the
impact on the dependency tree can be minimized.

If anyone wants to dig into this further, perhaps for proof-of-concept, here
is packaging that could be used as a starting point for the symbols files:

  
https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg-2ubuntu4~1

And here is the list of all packages that required dual-stack at least as of
2017, when Ubuntu stopped development on this:

$ wget -O - -q 
http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.gz \
zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
Package: qt3d-opensource-src-gles
Package: qtbase-opensource-src-gles
Package: qtdeclarative-opensource-src-gles
Package: qtlocation-opensource-src-gles
Package: qtmir-gles
Package: qtmultimedia-opensource-src-gles
Package: qtubuntu-gles
$

i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
qtubuntu).

Maybe you were already aware of this, but it didn't come across to me in
your mail, sorry.  If you still think it is too much maintenance overhead to
provide a dual stack for these 5 libraries (plus any others that later start
to use GL-dependant ABIs), I think you're absolutely entitled to that view.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Josh Triplett]

Ian Jackson wrote:
> Unfortunately that means that while a properly planned and executed
> transition to mandatory merged-/usr might well have offered overall
> technical benefits for the Debian ecosystem, this is not now socially
> possible and pressing on is not worth the social costs of being seen
> to bulldoze opposition.

Prematurely declaring victory for an approach you prefer is a more
subtle tactic, but still an unproductive, escalating, and
heat-generating one. There is no such consensus at this time.

Perhaps the correct transition plan is a years-long transition that will
leave Debian unable to avail itself of any of the advantages until done.
Perhaps it isn't. Perhaps there are ways to accomplish that transition
more quickly. Perhaps there are ways we can provide the benefits in the
short term while accomplishing the transition in the long term. But
regardless, please refrain from declaring one of those positions
authoritatively (rather than as your opinion and position) unless that
becomes the consensus.

Nobody here is looking to *bulldoze* opposition. Rather, people are
mostly seeking to *understand* and *address* opposition. There's a big
difference between "this is going to break things" and "here's something
this is going to break, the current solution doesn't address that".  The
latter is a useful contribution; the former without any signs of the
latter is simply FUD. And it's not unreasonable to identify it as such.

For the record, I'm *not* in this mail suggesting a position on whether
the correct solution is to make usrmerge essential. I do think we should
move to moving merged /usr mandatory. Long-term, I *do* think we should
work on making all packages build to install no files to /bin and /lib
and similar, including lintian warnings for installing in / and
eventually autorejects for that. However, I also think it's unreasonable
for that transition to take years; if we can't reasonably accomplish it
in a few months, then 1) we need better mechanisms for distro-wide
changes, and 2) we should consider a solution like usrmerge in the
interim, until we get to the point that no package in the archive
installs to the directories directly in / and we have rejects in place
to prevent any new packages from doing so.

Here's a thought: we already mount /usr at boot time, could we have a
mechanism at boot time that uses some combination of a tmpfs, symlinks,
and mounts to create a /bin that includes individual symlinks to
corresponding binaries in /usr/bin if and *only* if /bin isn't already a
symlink to /usr/bin? That way, /bin on disk doesn't actually contain any
such symlinks, and we don't need an irreversible process like usrmerge.
Keep that up until the transition completes and the last package
transitions, then ship the symlinks in a new base-files and drop the
transitional startup script. Ditto for /sbin and /lib.

We could also have a dh-style script that automatically moves files and
creates a /usr/usrtransition.d/packagename.conf file read by that
boot-time mechanism. Then we know the transition will be handled
correctly, and we won't have packages getting the details wrong and
ending up with RC bugs.

Sound reasonable? I'd be happy to work on that.

- Josh Triplett

Re: usrmerge -- plan B?

[Steve Langasek]

On Tue, Nov 27, 2018 at 12:57:38PM +, Ian Jackson wrote:
> > In the case of unmerged /usr, the only benefits I'm aware of for the more
> > complex case (unmerged /usr) are circular: existing Debian installations
> > have it, so switching to merged /usr is a change;

> I think this is true for Debian itself now that we have bitten the
> bullet of requiring /usr to be mounted along with /, early during
> boot.  (For the record I think that was a good decision.)

> Unmerged /usr could have continuing benefits for Debian derivatives
> who have avoided requiring early mounting of /usr.  IDK whether such
> derivatives exist.  They could do, if they support a narrower range of
> approaches to storage access than Debian proper.  If such derivatives
> exist then Debian adopting merged /usr would be likely to cause
> problems for them, as we would introduce changes in Debian which would
> be bugs in those derivatives.  I don't know how serious a problem that
> would be.

Support for such a configuration is actively bitrotting as we speak. 
Library dependencies of /bin and /sbin are no longer isolated in /lib; udev
will not reliably set up all devices without access to programs under /usr. 
Even if some derivative based on a recent Debian release has managed to keep
usr-on-separate-partition-without-initramfs working for their purposes, this
is not sensibly maintainable over the longer term, and the existence of such
a derivative should carry very little weight with Debian when deciding
whether to merge /usr.

Example: even *without* merged /usr, an entirely sensible course of action
for any maintainer of a Debian library package is to undo all special casing
of /lib vs. /usr/lib in their debian/rules (.so -dev symlinks vs. runtime
libraries, etc) and ship everything in /usr/lib, because the maintainer can
rely on /usr/lib always being available.

> I think it would be good to hear from any derivatives in this
> position.  We should probably ask them more formally than by having a
> horrible flamewar on -devel: ie, in a way that invites the expression
> of concerns and which reassures people that they will not be flamed or
> dismissed.  That would satisfy what I see as our social duty to
> consult our downstreams.  And if we did that and didn't get replies,
> that might give us confidence that such derivatives don't exist.  So
> we could go ahead with a clear conscience.

I don't agree that there's a social duty to consult downstreams that have
made self-evidently poor engineering decisions, before making a change that
will inconvenience them solely as a result of those same poor decisions.

I don't mean that I'm unsympathetic to downstreams in that situation, or
that I wouldn't want to help them; only that their plight /should not/ be an
obstacle to Debian doing the right thing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

Hi Rohan!

On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> [...]
>
> I concur here. It was correctly pointed out in another reply that by using
> OpenGL we're specifically catering to software that doesn't support
> GLES while making performance worse for mature applications that
> do implement both OpenGL and GLES. The reality of the situation is that
> the market currently favors GLES over GL on ARM SBC's, delivered with
> proprietary blobs. I think a more pragmatic view of this reality would be to
> deliver the best FOSS user experience that's possible with the proprietary
> drivers while the open source drivers are being improved. To that extent,
> by switching to GLES we improve the overall situation since OpenGL
> applications can fall back to software rendering via mesa on platforms
> where mesa does not support the GPU.

Here I agree with Luke Kenneth Casson Leighton’s opinion [1].

I think we should aim to provide the best possible experience with the free
software ecosystem. The experience with proprietary drivers should be the
second priority, if priority at all.

> By choosing to build Qt with GLES on ARM64, we make Debian a more
> attractive platform for vendors who'd like to target ARM64 boards.

We should make it attractive for vendors to release their code under
a free software (DFSG) license. That way anyone would be able to hack on it
and add missing support for a different OpenGL variant, if needed.

That said, as Lisandro announced, we will be happy to make any decision
if there is either a consensus or a TC decision about it.

[1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Russ Allbery]

Michael Stone  writes:
> On Tue, Nov 27, 2018 at 08:54:43AM +, Simon McVittie wrote:

>> If I was wrong in assuming good faith and you were being argumentative
>> for the sake of being argumentative, please stop: that is not
>> constructive.
>>
>> Either way, please don't call me stupid. That is not *at all*
>> constructive - especially if you want things you say in future to
>> change my opinion on anything! - and contributes to an atmosphere of
>> hostility that drives away Debian contributors.

> I agree. I wish you were just as busy policing memes like "people who
> have issues with mandatory usrmerge are just scared of change".

There is not enough energy in the world to police all of the unnecessarily
confrontational and counter-productive things people have said in this
thread.  :(

I wholeheartedly agree: the argument here is not about fear of change.
It's primarily about a cost/benefit tradeoff and an orderly transition
that is well-understand and won't surprise anyone, and secondarily about
Debian's ongoing severe social problems around having a constructive
technical discussion.

Thank you so much, Simon, for your incredibly useful and productive
messages in this thread.

I am certain there are technical approaches and good compromises here that
will make everyone happy, but we're not going to be able to reach them if
everyone falls into the trap of loudly repeating their position, getting
defensive, and lashing out at each other.

We had some things break because of a change to buildd configuration that
caught some people by surprise.  It's entirely reasonable that the first
reaction to that was "woah, wait, hold on, slow down, what's going on
here?"  A wonderfully productive next step would be for someone with the
time to do so (which sadly I do not right now) to write up a summary of
what the desired end state should be for Debian (maybe with a few options)
and then a more detailed transition plan about how to get from where we
are now to where we want to be.  That will give us something concrete to
debate and to test against the risks that people perceive, and hopefully
will reduce the hardening of positions on all sides.

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

Re: Our build system may be broken: /bin vs /usr/bin

[Russ Allbery]

Wouter Verhelst  writes:

> How can it do so, though, if the build system hardcodes paths to
> binaries[1]? Isn't it better (and easier) to have non-usr-merged buildd
> chroots as long as we still support such systems?

> [1] Yes, I know policy says you shouldn't do that, but if there's a
> 3000-line upstream configure.ac file that does so all over the place,
> fixing that might be involved, for questionable benefit (exaggerating
> here, but you get the point).

This was mentioned elsewhere in the thread, but just for the sake of
clarity, Policy doesn't say that.  Policy says only that maintainer
scripts should not hard-code paths.

Whether other binaries should or should not is a somewhat complicated
question that is a little case-dependent.  For instance, we decided in an
earlier debian-devel thread that Perl and Python scripts should hard-code
paths rather than using the env trick.

This therefore makes your point even stronger.

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

Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek  writes:

> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a hardware-accelerated GLES driver where
> > possible, falling back to software GL where necessary.

> This seems unlikely -- I believe GLES and GL have different semantics in
> a few places which makes implementing GL on GLES inefficient; mostly
> that GLES is missing stuff that GL applications often use, but I think
> there are places where GLES is just different, including in how GLSL
> works.

Perhaps that explains why no one ever actually succeeded in implementing it,
then?

Thanks for the context.

> I haven't tried, but I would expect that applications could use both GL
> and GLES APIs at the same time, even to the same window. If this does
> work with Mesa, then linking Qt against GLES wouldn't restrict
> applications using free drivers at least?

My recollection is that this becomes a practical problem of applications
that want to use both Qt and GL being unbuildable due to namespace
collisions at build time.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Michael Stone]

On Tue, Nov 27, 2018 at 08:54:43AM +, Simon McVittie wrote:

If I was wrong in assuming good faith and you were being argumentative for
the sake of being argumentative, please stop: that is not constructive.

Either way, please don't call me stupid. That is not *at all*
constructive - especially if you want things you say in future to change
my opinion on anything! - and contributes to an atmosphere of hostility
that drives away Debian contributors.


I agree. I wish you were just as busy policing memes like "people who 
have issues with mandatory usrmerge are just scared of change".

Re: usrmerge -- plan B?

[Michael Stone]

On Tue, Nov 27, 2018 at 09:50:40AM +0100, Philip Hands wrote:

Michael Stone  writes:

On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote:

I disagree both that simple testing (that you could do with a KVM
snapshot as well) would be hard and I disagree that the benefits of
merged-/usr would be minor.


Nobody has thus far pointed out a single benefit to someone merging usr
on an ordinary system.


I'll bite.

I have systems that were installed ages ago, which now have
insufficiently large root partitions.


So that's not an "ordinary" system, it's a system with an insufficiently 
large root partition, right?



BTW whenever anyone says something like "Nobody" or "Never" in these
discussions, they are just asking to be contradicted.  I'm pretty sure
that people have been pointing out advantages of various sorts for some
time, but that you have your filters turned up high enough that none of
them have managed to lodge in your memory.  (I cannot be bothered to
actually come up with a citation, because it's pretty clear that doing
so would make no difference).


No, I really haven't seen anything. I'm sure there are a lot of great 
advantages for particular systems, but if someone has a system that's 
working perfectly well and they're happy with, I haven't seen any 
explanation for why they'd want this change.

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Rohan Garg]

Hey

On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog  wrote:
>
> Hello Lisandro,
>
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution, but I
> believe you took the wrong decision. Please consider deferring the
> decision to the technical committe by seeking his advice (point 6.1.3
> of the constitution https://www.debian.org/devel/constitution.en.html#item-6).
>

Having worked on multiple ARM boards over the past 3 years,
I agree very strongly with Raphael.

> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
>
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
>

As the person who opened #881333, I completely agree. I've been on vacation
the past 10 days and haven't had a opportunity to chime in.

> I also invited someone else who is working on a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.
>

I've had multiple concrete projects involving KDE, Qt and ARM over the past
few years, over multiple ARM platforms such as the ODROID C1, C2 and the
Pinebook. With my KDE hat on, we have a strong stake in having Plasma
perform decently well on these devices.

> Then I have read the whole discussion and I don't have the feeling that
> any consensus has been reached. It was largely driven by Andy Simpkins
> who explained his "gut feeling" as a tinkerer of arm* boards/devices and
> Bret Curtis who contributes to some applications with very specific OpenGL
> needs. While I value their contribution to the discussion, they both
> represent very specific classes of users.
>
> What I remember from this discussion is that the Windows build of Qt
> use GLES 2 by default. It would have been interesting to find out the
> rationale for this... because maybe the right decision for us would be
> to switch to GLES 2 by default as well (on all architectures as jcristau
> suggested). Someone else who likely also tried to ensure Qt for Windows is
> usable on most hardware made that choice.
>
> We got confirmation from many persons that almost all cards benefitting
> from Desktop OpenGL would also work with OpenGL ES. So in terms of
> hardware support, picking OpenGL ES is the right choice. In terms of
> sofware support, it looks like that Desktop OpenGL is better as there
> are a few applications that only work with Desktop OpenGL.
>
> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL
> when it has been designed for OpenGL ES only.
>

I concur here. It was correctly pointed out in another reply that by using
OpenGL we're specifically catering to software that doesn't support
GLES while making performance worse for mature applications that
do implement both OpenGL and GLES. The reality of the situation is that
the market currently favors GLES over GL on ARM SBC's, delivered with
proprietary blobs. I think a more pragmatic view of this reality would be to
deliver the best FOSS user experience that's possible with the proprietary
drivers while the open source drivers are being improved. To that extent,
by switching to GLES we improve the overall situation since OpenGL
applications can fall back to software rendering via mesa on platforms
where mesa does not support the GPU.

> When taking all this into account, I believe that the right solution is
> to use OpenGL ES on all architectures. This will provide the required
> incentives for application developers who stick only to Desktop OpenGL
> to support OpenGL ES (even it it's at the cost of using some intermediary
> layer like https://github.com/p3/regal) and would maximize hardware
> support on all architectures.
>
> That said, I'm fine with a decision to change only arm64 since that's
> an architecture were devices that support only OpenGL ES are in the
> majority.
>

By choosing to build Qt with GLES on ARM64, we make Debian a more
attractive platform for vendors who'd like to target ARM64 boards.

Cheers
Rohan Garg

Re: tracking OpenGL support for specific boards

[bret curtis]

On Tue, Nov 27, 2018 at 3:58 PM Stefan Monnier  wrote:
>
> >> What would help further would be for such information having references
> >> to sources, and each information point be referencable (not only the
> >> dataset as a whole).
> > Isn't this already done for us here?
> > https://gpuinfo.org/
>
> I don't see any reference to sources.
> Also I see it as "Ubuntu" and "Arch" as OSes, whereas I'd rather see the
> status of the underlying driver so I can easily extrapolate from it to
> what will happen in any particular GNU/Linux distribution.
>
> The database describes itself as "an online tool for developers that
> want to check out GPU hardware capabilites", so it seems to be focused
> on hardware, whereas I think we need something that focuses on
> the drivers.

Have you looked at https://mesamatrix.net/ ?  That is a list of
drivers, not exhaustive because VC4 and other's are not currently
tracked.

However Freedreno that supports all Adreno A4XX hardware does have a
debian package for armel and armhf.

Is that perhaps something to look into?

Here is the wikipedia page for Adreno and it lists the opengl support
per chipset:
https://en.wikipedia.org/wiki/Adreno
^-- it's fairly complete and says that they too fall under Freedreno

Then there is this for Mali400/450:
https://gitlab.freedesktop.org/lima/mesa

Cheers,
Bret

Bug#914807: ITP: muacrypt -- Autocrypt encryption for mail agents

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: muacrypt
  Version : 0.9
  Upstream Author : Holger krekel and the Autocrypt team
* URL : https://muacrypt.readthedocs.io
* License : GPL
  Programming Lang: Python
  Description : Autocrypt encryption for mail agents


muacrypt is a support tool for implementing Autocrypt Level 1 compliant
mail agents. Autocrypt state is kept in one or more accounts which
process and produce autocrypt headers from respective incoming and
outgoing e-mail. Each account is tied to a set of e-mail addresses,
specified as a regular expression. Functionality is exposed through a
command line tool muacrypt and a Python api obtained through import
muacrypt. There is an evolving plugin architecture which allows to add
and modify behaviour of muacrypt.

Re: tracking OpenGL support for specific boards

[Stefan Monnier]

>> What would help further would be for such information having references
>> to sources, and each information point be referencable (not only the
>> dataset as a whole).
> Isn't this already done for us here?
> https://gpuinfo.org/

I don't see any reference to sources.
Also I see it as "Ubuntu" and "Arch" as OSes, whereas I'd rather see the
status of the underlying driver so I can easily extrapolate from it to
what will happen in any particular GNU/Linux distribution.

The database describes itself as "an online tool for developers that
want to check out GPU hardware capabilites", so it seems to be focused
on hardware, whereas I think we need something that focuses on
the drivers.


Stefan

Re: tracking OpenGL support for specific boards

[bret curtis]

> > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
> >
> > Any feedback, correction and addition that could benefit this discussion 
> > would be appreciated.
>
> Great that you collected that dataset, and put it public.
>
> What would help further would be for such information having references
> to sources, and each information point be referencable (not only the
> dataset as a whole).
>

Isn't this already done for us here?
https://gpuinfo.org/

If anything, it should be used to fill in that list.
Many of those chipsets you list, as I understand, have a mesa driver
for them that support opengl and gles.
Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/

Keep in mind, only the proprietary drivers seem to not support opengl
while the hardware is perfectly capable of doing so.

Cheers,
Bret

Re: Is using experimental distribution for shelter during freeze useful?

[Andrey Rahmatullin]

On Tue, Nov 27, 2018 at 08:38:46PM +0900, Hideki Yamane wrote:
>  Cons)
>  - Harder to get users for test with testing-proposed-updates repository
My understanding of the current consensus is that this is the main reason
for using the current workflow. Nobody would test anything except sid and
testing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: tracking OpenGL support for specific boards

[Jonas Smedegaard]

Quoting Re4son (2018-11-27 11:38:14)
> On 2018-11-27 02:46 +, Wookey wrote:
> > >
> > > Well, that's at very least an interesting data point. So yes, they exist, 
> > > but 
> > > they are new and expensive. Can I assume that this means most of our 
> > > arm64 
> > > users do not yet get to them?
> 
> > Not yet, no although I think you can just buy one (Gigabyte 
> > ThunderXstation) now. But Machiato-bin exists with working PCI and 
> > you can buy one 
> > (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), 
> > and nvidia-based hardware is available and supports GL (Jetson TX1) 
> > (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). 
> > There is more hardware coming which will support GL, so it is 
> > definately not as simple as 'available hardware is all GLES'. 
> > (Perhaps someone has made a list in this long thread).
> 
> I have previously compiled this excel sheet with data relevant to this thread:
> 
> https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
> 
> Any feedback, correction and addition that could benefit this discussion 
> would be appreciated.

Great that you collected that dataset, and put it public.

What would help further would be for such information having references 
to sources, and each information point be referencable (not only the 
dataset as a whole).

In other words, your data gets 2 stars: https://5stardata.info/en/

I maintain https://wiki.debian.org/CheapServerBoxHardware and have for a 
long time wanted to make that 5-star data (currently that has 3 stars). 
Would be great to include your dataset in that, but I would then need to 
know the sources for the datapoints to be able to verify.  Also, ideal 
would be that you maintain your dataset yourself as 5-star reusable data 
instead of me needing to maintain a fork.

A user-visible benefit of 5-star data is the possibility for not only 
browsing it as tabular data, but also navigating multiple dimensions 
e.g. like https://kumu.io/DigLife/digital-life-collective#our-network

Please tell me if interested in helping out, and I will provide concrete 
examples of how to optimally organize data, as soon as I get it 
documented for my own work.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Is using experimental distribution for shelter during freeze useful?

[Thomas Goirand]

On 11/27/18 12:38 PM, Hideki Yamane wrote:
> Hi,
> 
>  Well, we use experimental as "shelter" during freeze, but it's not good
>  in my point of view.
> 
>  - During freeze, it is just ignored by most of the users since they
>wouldn't know there's a newer package in there (and they also afraid
>because it's in "experimental" ;). It means "not tested" if they were
>in Debian repository for a long time period
>  - Re-uploading to unstable is just boring, and no values are added by it
>  - unstable users wants new valued packages constantly. After release,
>"package flood" to unstable is not good.
> 
>  So, I guess putting fixed packages into "testing-proposed-updates" and
>  to continue to upload packages to unstable during freeze period is better.
> 
>  Pros)
>  - unstable distribution stays newest
>  - No "unintended" changes will be introduced into testing during freeze
> 
>  Cons)
>  - Maybe you should do cherry-picking changes from unstable to
>testing-proposed-updates, not just ask "unblock" to Release Managers.

The process would stay the same, just instead of uploading to unstable
during the freeze, we would upload to t-p-u.

>  - Harder to get users for test with testing-proposed-updates repository

Nothing would prevent one from uploading to both t-p-u and sid.

I very much support this proposal, but we're probably too close from the
freeze already, and this would probably also need some work on the
release team and/or FTP master side. If you want this to happen, maybe
you should get in touch with both teams directly and do the work *after*
buster is released? Anyway, they would tell...

Cheers,

Thomas Goirand (zigo)

Re: usrmerge -- plan B?

[Marc Haber]

On Tue, 27 Nov 2018 09:50:40 +0100, Philip Hands 
wrote:
>I have systems that were installed ages ago, which now have
>insufficiently large root partitions.

The usrmerge moves stuff from / to /usr, replacing /bin with a symlink
to /usr/bin. This is likely to relax space constraints on small root
file systems.

>Installing usrmerge seems like a way to restore sanity to the latter case.

Indeed.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Is using experimental distribution for shelter during freeze useful?

[Sean Whitton]

Hello,

On Tue 27 Nov 2018 at 08:38PM +0900, Hideki Yamane wrote:

>  Cons)
>  - Maybe you should do cherry-picking changes from unstable to
>testing-proposed-updates, not just ask "unblock" to Release Managers.
>  - Harder to get users for test with testing-proposed-updates repository

- Additional work for the release team as the testing-proposed-updates
  mechanism is more work to approve changes, AIUI.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Ian Jackson]

Firstly, thanks for your measured and helpful contributions to this
very unfortunate thread.

Simon McVittie writes ("Re: usrmerge -- plan B?"):
> I hope we can agree that unnecessary complexity is technical debt, but
> necessary complexity is necessary: if complexity exists for a reason,
> then the "cost" of the complexity should be compared with the benefit
> of having it, to decide whether the complexity needs to be kept.

I definitely agree with this.

> In the case of unmerged /usr, the only benefits I'm aware of for the more
> complex case (unmerged /usr) are circular: existing Debian installations
> have it, so switching to merged /usr is a change;

I think this is true for Debian itself now that we have bitten the
bullet of requiring /usr to be mounted along with /, early during
boot.  (For the record I think that was a good decision.)

Unmerged /usr could have continuing benefits for Debian derivatives
who have avoided requiring early mounting of /usr.  IDK whether such
derivatives exist.  They could do, if they support a narrower range of
approaches to storage access than Debian proper.  If such derivatives
exist then Debian adopting merged /usr would be likely to cause
problems for them, as we would introduce changes in Debian which would
be bugs in those derivatives.  I don't know how serious a problem that
would be.

I think it would be good to hear from any derivatives in this
position.  We should probably ask them more formally than by having a
horrible flamewar on -devel: ie, in a way that invites the expression
of concerns and which reassures people that they will not be flamed or
dismissed.  That would satisfy what I see as our social duty to
consult our downstreams.  And if we did that and didn't get replies,
that might give us confidence that such derivatives don't exist.  So
we could go ahead with a clear conscience.

Also, there is a social cost of pressing for change.  That could have
been minimised by taking a slow, measured, and consensual approach.
Other substantial changes in Debian have been achieved successfully
with few people getting upset.

Unfortunately the opportunity to do that for mandatory merged-/usr has
been lost.  Now, that transition would necessarily generate
significant ill-will.  Personally I doubt it is worth it.

> Now, it's entirely valid to trade off long-term complexity (unmerged
> /usr) against short-term complexity (applying the /usr merge); one
> possible answer to whether we should eliminate some unnecessary long-term
> complexity is "yes, but not yet" (and the reason for this entire thread is
> that part of the transition happened in the wrong order, with buildd and
> pbuilder chroots becoming merged-/usr sooner than they should have done).

Another possible answer is "yes but we should achieve this in a
different way".  That seems to be Adam's proposal.

Certainly I hope you agree with me that a transition of this magnitude
ought to be properly planned; the plan should be consulted on, with
real attention paid to feedback.

> If I was wrong in assuming good faith and you were being argumentative for
> the sake of being argumentative, please stop: that is not constructive.
> 
> Either way, please don't call me stupid. That is not *at all*
> constructive - especially if you want things you say in future to change
> my opinion on anything! - and contributes to an atmosphere of hostility
> that drives away Debian contributors.

I absolutely agree with this.  Some of the messages from merged-/usr
sceptics have been very bad (and I have said so in private and public
messages).

But also, right now I'm afraid that the most vigorous proponent of
merged-/usr, here on this list, is being extremely dismissive of
feedback.  The approach Marco is taking is generating ill-will amongst
existing contributors (some of whom will then inevitably lash out, bad
as that is), and it is attracting the attention of undesirables.

If you cannot persuade Marco to let you lead the discussion, I think
you should distance yourself from him.

Unfortunately that means that while a properly planned and executed
transition to mandatory merged-/usr might well have offered overall
technical benefits for the Debian ecosystem, this is not now socially
possible and pressing on is not worth the social costs of being seen
to bulldoze opposition.

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: Is using experimental distribution for shelter during freeze useful?

[Dominik George]

>  Your thoughts?

sid is not a rolling release for the public, it is a development area.
Some users use it as a rolling release to get bleeding edge software,
but in fact they become a developer that way (not meaning DD).

If you think regular development prevents you from staying up to date
during the freeze, install the packages you need from experimental. You
are a developer, after all.

-nik


signature.asc
Description: PGP signature

Re: Is using experimental distribution for shelter during freeze useful?

[Jonas Smedegaard]

Quoting Hideki Yamane (2018-11-27 12:38:46)
> Hi,
> 
>  Well, we use experimental as "shelter" during freeze, but it's not good
>  in my point of view.
> 
>  - During freeze, it is just ignored by most of the users since they
>wouldn't know there's a newer package in there (and they also afraid
>because it's in "experimental" ;). It means "not tested" if they were
>in Debian repository for a long time period
>  - Re-uploading to unstable is just boring, and no values are added by it
>  - unstable users wants new valued packages constantly. After release,
>"package flood" to unstable is not good.
> 
>  So, I guess putting fixed packages into "testing-proposed-updates" and
>  to continue to upload packages to unstable during freeze period is better.
> 
>  Pros)
>  - unstable distribution stays newest
>  - No "unintended" changes will be introduced into testing during freeze
> 
>  Cons)
>  - Maybe you should do cherry-picking changes from unstable to
>testing-proposed-updates, not just ask "unblock" to Release Managers. 
>  - Harder to get users for test with testing-proposed-updates repository
> 
>  Your thoughts?

Let's not make freeze more comfortable.

Let's make freeze more efficient - and uncomfortable to ignore.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: usrmerge -- plan B?

[Scott Leggett]

On 2018-11-27.08:54, Simon McVittie wrote:
> On Tue, 27 Nov 2018 at 09:18:08 +0100, Stephan Seitz wrote:
> > But I don’t want to get the /usr-merge forced upon my systems because this
> > minority is obviously too stupid to install the package and migrate their
> > systems on their own.
> 
> That would be a terrible justification for merged /usr, but it is also
> not a justification that anyone is using. In the interests of assuming
> good faith, I'll assume that you have missed the messages that describe
> why applying merged /usr to all Debian systems might be a good idea, and
> attempt to summarize them.
> 
> I hope we can agree that unnecessary complexity is technical debt, but
> necessary complexity is necessary: if complexity exists for a reason,
> then the "cost" of the complexity should be compared with the benefit
> of having it, to decide whether the complexity needs to be kept.
> 
> Merged /usr is a simplification. It takes a few classes of bugs -
> most obviously "a package refers to a command by its absolute path in
> /usr/bin, but really it's in /bin, so that won't work" and its opposite -
> and makes them disappear.
> 
> In the case of unmerged /usr, the only benefits I'm aware of for the more
> complex case (unmerged /usr) are circular: existing Debian installations
> have it, so switching to merged /usr is a change; and if build systems
> have unmerged /usr, then it's a lot more straightforward for packages to
> find the canonical paths of programs (such as the fact that it's /bin/sh
> and /usr/bin/perl, not the other way round), and packages sometimes
> need to know the canonical paths of programs so that the package will
> continue to work on unmerged /usr systems. If all systems were merged
> /usr, then there would be no reason why packages would need to know that
> sh is in /bin but perl is in /usr/bin, because both executables would
> (effectively) be in both places. So *all* systems being merged-/usr would,
> again, be a simplification.

Thanks for your multiple thoughtful and detailed contributions to this
discussion. They are greatly appreciated.

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Re: Our build system may be broken: /bin vs /usr/bin

[Dirk Eddelbuettel]

On 27 November 2018 at 08:04, Kurt Hornik wrote:
| The new r-base-core (3.5.1-2+b1) also seems fine on i386.  Thanks!

Great news, thanks for reporting back!

All systems green, and Chris (was usual) right along :)

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Is using experimental distribution for shelter during freeze useful?

[Hideki Yamane]

Hi,

 Well, we use experimental as "shelter" during freeze, but it's not good
 in my point of view.

 - During freeze, it is just ignored by most of the users since they
   wouldn't know there's a newer package in there (and they also afraid
   because it's in "experimental" ;). It means "not tested" if they were
   in Debian repository for a long time period
 - Re-uploading to unstable is just boring, and no values are added by it
 - unstable users wants new valued packages constantly. After release,
   "package flood" to unstable is not good.

 So, I guess putting fixed packages into "testing-proposed-updates" and
 to continue to upload packages to unstable during freeze period is better.

 Pros)
 - unstable distribution stays newest
 - No "unintended" changes will be introduced into testing during freeze

 Cons)
 - Maybe you should do cherry-picking changes from unstable to
   testing-proposed-updates, not just ask "unblock" to Release Managers. 
 - Harder to get users for test with testing-proposed-updates repository

 Your thoughts?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: Upcoming Qt switch to OpenGL ES on arm64

[Re4son]

Hi,

On 2018-11-27 02:46 +, Wookey wrote:

> >
> > Well, that's at very least an interesting data point. So yes, they exist, 
> > but 
> > they are new and expensive. Can I assume that this means most of our arm64 
> > users do not yet get to them?

> Not yet, no although I think you can just buy one (Gigabyte
> ThunderXstation) now. But Machiato-bin exists with working PCI and you
> can buy one
> (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), and
> nvidia-based hardware is available and supports GL (Jetson TX1)
> (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). There
> is more hardware coming which will support GL, so it is definately not
> as simple as 'available hardware is all GLES'. (Perhaps someone has
> made a list in this long thread).

I have previously compiled this excel sheet with data relevant to this thread:

https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls

Any feedback, correction and addition that could benefit this discussion would 
be appreciated.


> > > I recall Linaro doing some work on this back
> > > when it started (to make it easier to switch between GL and
> > > GLES). Possibly that work never actually got done, just talked out.
> > 
> > It would really help, indeed.
>
> OK. It seems that this project was started, but not completed due to a
> lack of interest at the time (2012) (people just started using GLES on
> dev boards/phones). It's here: https://code.launchpad.net/glproxy
> And here is the spec: 
> https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/GLProxy

> Perhaps it is worth resurrecting this project if it would let us
> acheive the nirvana of runtime selection between GL and GLES, thus
> making everyone happy.

> Jammy Zhou  cc:ed can say how much was/wasn't done.

That is extremely interesting, anything I can do to help?

> Wookey

Many thanks,
Re4son

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Re4son]

Hi,

On 26/11/18 11:54 pm, Riku Voipio wrote:
> On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
>> were in the week-end). I was aware of the discussion but did not
>> had the time to chime in, yet I was the person who re-opened the bug
>> #881333 in the first place.
>  
>> I also invited someone else who is working on a concrete project involving
>> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
>> now but he also did not have the time to contribute to the discussion.
>> Software can be fixed/improved to also work with OpenGL ES. However
>> hardware, once bought, cannot be fixed to support Desktop OpenGL
>> when it has been designed for OpenGL ES only.
> Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27,
> featuring Mali-T880. The hardware is not OpenGL ES only .. the
> propiertary driver is. Mesa-based panfrost driver should support both
> OpenGL and OpenGL ES:
>
> https://gitlab.freedesktop.org/panfrost
>
> The open source driver is of course not ready... ...but neither is
> Debian ES 2.0. In the long run, making the driver ready is time better
> spent than time spent trying to make Debian more friendly to a class
> of propiertary drivers.

I fully agree again.
Looking at the lengthy progress so far and the limited resources
available, I suggest supporting the development by switching to GLES and
work on the drivers to support that first. Once that has been achieved
we can aim for full OpenGL support and then we can switch back to
desktop if there is actual user demand. I'm not suggesting to make
Debian more friendly to proprietary drivers. The exact opposite:
switching to GLES to fill the void will give us time to aim for one
milestone at a time. The vast majority of devices we are talking about
are embedded systems, let's aim to bring them the drivers and interfaces
that have been designed for embedded systems before we reach for the stars.
A lot of the discussion in this thread seems off topic and academic but
I’m confident that the above approach is what we need to move on.

> Riku
>
Many thanks

Bug#914791: ITP: r-cran-rspectra -- GNU R solvers for large-scale eigenvalue and SVD problems

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-rspectra
  Version : 0.13
  Upstream Author : Yixuan Qiu
* URL : https://cran.r-project.org/package=RSpectra
* License : MPL-2.0
  Programming Lang: GNU R
  Description : GNU R solvers for large-scale eigenvalue and SVD problems
 This package provides a R interface to the 'Spectra' library
  for large-scale eigenvalue and SVD
 problems. It is typically used to compute a few
 eigenvalues/vectors of an n by n matrix, e.g., the k largest eigenvalues,
 which is usually more efficient than eigen() if k << n. This package
 provides the 'eigs()' function that does the similar job as in 'Matlab',
 'Octave', 'Python SciPy' and 'Julia'. It also provides the 'svds()' function
 to calculate the largest k singular values and corresponding
 singular vectors of a real matrix. The matrix to be computed on can be
 dense, sparse, or in the form of an operator defined by the user.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rspectra
This package is a predependency for my final target r-other-uwot.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Re4son]

Hi,

On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards currently do not support 
>> Desktop OpenGL, but do support GLES.
> The boards may or may not support Desktop GL. As far as debian is
> concerned, they remain headless devices until they have free drivers.
>
> See, most of the propiertary GLES drivers are craptastic and don't work
> with Debians kernel. Even ff you manage to dance the right kernel, device
> tree and userspace combo, you may still not get the desktop enviroment
> up. And nobody is going to fix the bugs you encounter.
>
> Debian does support Qualcomm based boards with freedreno driver, and
> work is progressing with etnaviv for Vivante. Both based on Mesa and
> support both OpenGL and GLES. With the MALI reverse engineering active
> again, it would seem rather short-sighted and counterproductive to
> put lots of energy in supporting the propiertary drivers.
>
I agree, hence let's do the switch and focus on developing free drivers.
I fully echo your sentiment and propose a practical approach to give the
best possible support to the developers whilst also providing something
real to the user. In awe of the efforts that have already gone into
these development activities - right now we don't have the drivers, thus
we lack both OpenGL & OpenGL ES support for the majority of the arm64
platforms and considering the hard work and time it has taken already, I
doubt that we will have stable full OpenGL support anytime soon.
Making the switch means that we can give the hardware the proprietary
support available right now, develop GLES support, roll it out, extend
it to full OpenGL support and once that is reasonably mature switch back
to desktop.

>> 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.
> I have an Synquacer box with nvidia card running Lxqt desktop, running
> fine most tasks. While none of the apps I run on it seem to be of the
> Qt + GLU/glew combo, it would be unfortunate if I ever need to use them.
>
> Riku
>
Many thanks

Re: usrmerge -- plan B?

[Simon McVittie]

On Tue, 27 Nov 2018 at 09:18:08 +0100, Stephan Seitz wrote:
> But I don’t want to get the /usr-merge forced upon my systems because this
> minority is obviously too stupid to install the package and migrate their
> systems on their own.

That would be a terrible justification for merged /usr, but it is also
not a justification that anyone is using. In the interests of assuming
good faith, I'll assume that you have missed the messages that describe
why applying merged /usr to all Debian systems might be a good idea, and
attempt to summarize them.

I hope we can agree that unnecessary complexity is technical debt, but
necessary complexity is necessary: if complexity exists for a reason,
then the "cost" of the complexity should be compared with the benefit
of having it, to decide whether the complexity needs to be kept.

Merged /usr is a simplification. It takes a few classes of bugs -
most obviously "a package refers to a command by its absolute path in
/usr/bin, but really it's in /bin, so that won't work" and its opposite -
and makes them disappear.

In the case of unmerged /usr, the only benefits I'm aware of for the more
complex case (unmerged /usr) are circular: existing Debian installations
have it, so switching to merged /usr is a change; and if build systems
have unmerged /usr, then it's a lot more straightforward for packages to
find the canonical paths of programs (such as the fact that it's /bin/sh
and /usr/bin/perl, not the other way round), and packages sometimes
need to know the canonical paths of programs so that the package will
continue to work on unmerged /usr systems. If all systems were merged
/usr, then there would be no reason why packages would need to know that
sh is in /bin but perl is in /usr/bin, because both executables would
(effectively) be in both places. So *all* systems being merged-/usr would,
again, be a simplification.

Now, it's entirely valid to trade off long-term complexity (unmerged
/usr) against short-term complexity (applying the /usr merge); one
possible answer to whether we should eliminate some unnecessary long-term
complexity is "yes, but not yet" (and the reason for this entire thread is
that part of the transition happened in the wrong order, with buildd and
pbuilder chroots becoming merged-/usr sooner than they should have done).

If I was wrong in assuming good faith and you were being argumentative for
the sake of being argumentative, please stop: that is not constructive.

Either way, please don't call me stupid. That is not *at all*
constructive - especially if you want things you say in future to change
my opinion on anything! - and contributes to an atmosphere of hostility
that drives away Debian contributors.

smcv

Bug#914785: ITP: ibus-keyman -- Input method engine for multiple languages using Keyman for IBus

[Daniel Glassey]

Package: wnpp
Severity: wishlist
Owner: Daniel Glassey 

* Package name: ibus-keyman
  Version : 10.99
  Upstream Author : SIL International
* URL : http://www.keyman.com
* License : GPL, MIT/X
  Programming Lang: C
  Description : Input method engine for multiple languages using Keyman for 
IBus

 This package provides the Keyman input method engine for IBus. With this
 module, you can use Keyman keyboard layouts designed for Keyman 11.0 or
 earlier under the IBus platform.

-

This will be maintained in the Debian Input Method team

This is different from ibus-kmfl. ibus-kmfl provides supports for existing
source keyboards up to version 6.0 with limited support for newer source
keyboards that don't use particular new syntax.

ibus-keyman will support the full range of desktop keyboard packages
on https://keyman.com which are already supported on Microsoft, Apple,
Android and web platforms for the next version 11.0

It is in alpha in git so will go into experimental to start with for
the ITP until it gets to beta in a few weeks, provided it isn't too close
to the freeze.

Thanks,
Daniel

Re: usrmerge -- plan B?

[Philip Hands]

Michael Stone  writes:

> On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote:
>>I disagree both that simple testing (that you could do with a KVM
>>snapshot as well) would be hard and I disagree that the benefits of
>>merged-/usr would be minor.
>
> Nobody has thus far pointed out a single benefit to someone merging usr 
> on an ordinary system.

I'll bite.

I have systems that were installed ages ago, which now have
insufficiently large root partitions.

Some of them I've gone through the rather delicate procedure of resizing
partitions, some of which contain LVM, to make things fit.  Some of them
I've been able to move / onto LVM (with the side benefit of being able
to combine / and /boot into one, and thus make it big enough to have a
copy of grml on there).  Some are now populated with a lot of symlinks
to other partitions in a painful attempt to keep them small enough to be
useful.

Installing usrmerge seems like a way to restore sanity to the latter case.

Any of the above fixes requires one to do things that can easily result
in a trashed system if you do things in the wrong order, or get the
details wrong, so are not for the faint-hearted.

BTW whenever anyone says something like "Nobody" or "Never" in these
discussions, they are just asking to be contradicted.  I'm pretty sure
that people have been pointing out advantages of various sorts for some
time, but that you have your filters turned up high enough that none of
them have managed to lodge in your memory.  (I cannot be bothered to
actually come up with a citation, because it's pretty clear that doing
so would make no difference).

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?

[Adam D. Barratt]

On 2018-11-27 08:18, Stephan Seitz wrote:

But I don’t want to get the /usr-merge forced upon my systems because
this minority is obviously too stupid to install the package and
migrate their systems on their own.


Please refrain from posting such messages; they are inappropriate and 
contribute nothing helpful to the discussion.


Regards,

Adam

Bug#914781: ITP: keyman-config -- Type in your language with Keyman for Linux

[Daniel Glassey]

Package: wnpp
Severity: wishlist
Owner: Daniel Glassey 

* Package name: keyman-config
  Version : 10.99.33
  Upstream Author : Daniel Glassey 
* URL : http://www.keyman.com
* License : MIT/X
  Programming Lang: Python
  Description : Type in your language with Keyman for Linux

 Install, uninstall and view information about Keyman keyboard
 packages.
 .
 This package depends on all that is needed for using Keyman
 for Linux.

-

It produces 2 packages
keyman: scripts - km-config gui and some command line scripts
python3-keyman-config: python module

The package will be maintained in the Debian Input Method team.

These programs manage the keyboards to be used (for now) by ibus-kmfl
and (in development) ibus-keyman, and make them available for IBus.
The keyboards are available on https://keyman.com for a large
number of languages.

The current release, late alpha, is at 
https://downloads.keyman.com/linux/alpha/10.99.33/keyman_config-10.99.33.tar.gz

Thanks,
Daniel

Re: usrmerge -- plan B?

[Stephan Seitz]

On Mo, Nov 26, 2018 at 11:05:02 +0100, W. Martin Borgert wrote:

I personally don't care about usrmerge, but if it is useful to a
relevant minority, we should not reject it.


Who says we should reject the usrmerge package? The minority who wishes 
for it can install it for years.


But I don’t want to get the /usr-merge forced upon my systems because 
this minority is obviously too stupid to install the package and migrate 
their systems on their own.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

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

[Andrey Rahmatullin]

On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > The experimental distribution is a good place for work in
> > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > experimental so a package can go into the archive (and have e.g. the BTS
> > > used for that version) if the maintainer doesn't want to fix the reject
> > > right away.
> > 
> > I see a problem with relaxing the rules - if a project is in
> > experimental one could (theoretical) upload it to unstable too - without
> > any changes, because it is in the repository.
> 
> Can we please work on the assumption that Debian Contributors know what
> they're doing? 
In that case please abolish NEW.

> Our (NM and other) processes are extensive enough to make
> that assumption valid in the general case.
Not all DDs got through NM AFAIK.

-- 
WBR, wRAR


signature.asc
Description: PGP signature