Hi Bret!
El viernes, 23 de noviembre de 2018 11:14:34 -03 psi...@gmail.com escribió:
> Just chiming in here as package maintainer of an effected package, OpenMW
> and also an upstream developer of said software, along with contributor to
> OpenSceneGraph.
>
> Here are some related open bugs invol
El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > > I would still like to know if the upcoming arm64 desktop devices have
> > > any problems worki
Hi Wookey!
El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> > Hello,
> >
> > > - Qt is tied to either Desktop or GLES: yes
> > >
> > > So we need to pick one. The question is then which one will benefit our
> > > user
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 pack
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij
* Package name: python-milksnake
Version : 0.1.5
Upstream Author : Armin Ronacher
* URL : https://github.com/getsentry/milksnake
* License : Apache
Programming Lang: Python, Rust
Description : A s
Hello Adam,
On 23/11/2018 08:19, Adam Borowski wrote:
> On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
>> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
>> :
>>>
>>> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
If there are actual issues encountere
Hi!
On Wed, 2018-11-21 at 10:23:46 +0100, Adam Borowski wrote:
> with less confidence:
> • making usrmerge Essential (large amount of effort, known issues)
Oh dear, no, please!
First off, as I've said in the past, I have no problem whatsoever with
the concept, I think it brings both advantages
On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> > - Qt is tied to either Desktop or GLES: yes
> >
> > So we need to pick one. The question is then which one will benefit our
> > users
> > most.
> >
> > So far I personally know 0 people with an arm64 board with PCI slots, while
On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
> :
> >
> > On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> > >If there are actual issues encountered, we can always revert a change
> >
> > And how do you rev
Graham Inggs writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes
REJECTED"):
> On 2018/11/21 16:11, Bastian Blank wrote:
> > I have not seen a real explanation why it needs to be this and exactly
> > this way. This setup was explained as either
> > - a workaround for a bug,
> > - a way to
Hi Bastian
On 2018/11/21 16:11, Bastian Blank wrote:
I have not seen a real explanation why it needs to be this and exactly
this way. This setup was explained as either
- a workaround for a bug,
- a way to get stacktraces from users or
- a way to make autopkgtest run.
Stripping sys.so breaks
package: usrmerge
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
On Fri, Nov 23, 2018 at 03:28:37PM +0100, Stephan Seitz wrote:
> > at the moment, the only issues that are known when installing the
> > usrmerge package is when there are different binaries with the same
> > name in
On Fr, Nov 23, 2018 at 03:14:44 +0100, Matthias Klumpp wrote:
There are always unforseen issues to be expected when upgrading. And
Of course, and since a dist-upgrade will bring newer software you may
already have to fix configuration files.
at the moment, the only issues that are known whe
On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
For these cases though maybe the usrmerge script could ask the admin
on what to do to handle these particular binaries, instead of failing.
Maybe, as I suggested upthread, there could be a preview mode in which
the admin could be
On Fr, Nov 23, 2018 at 03:02:00 +0100, Hans wrote:
Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz:
And how do you revert this change? As far as I have understand you
can’t remove the usrmerge package and have your system in the old
state again.
Making an image of the whole h
Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
:
>
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> >If there are actual issues encountered, we can always revert a change
>
> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.
Here are some related open bugs involving Qt and GLESv2 and arm*:
https://bugs.debia
Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz:
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge package and have your system in the old state again.
Making an image
On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
If there are actual issues encountered, we can always revert a change
And how do you revert this change? As far as I have understand you can’t
remove the usrmerge package and have your system in the old state again.
As others in t
Am Fr., 23. Nov. 2018 um 13:45 Uhr schrieb Ian Jackson
:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full mer
On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge
Simon McVittie writes ("Re: individual packages moving binaries from /bin to
/usr/bin (was: Re: usrmerge -- plan B?)"):
> I'm not sure yet what the best plan for merged /usr is. I would definitely
> like to make sure it's at least possible to continue to use merged
> /usr for special-purpose syste
Package: wnpp
Severity: wishlist
Owner: Iain Lane
* Package name: gnome-shell-extension-desktop-icons
Version : 18.11~rc1
Upstream Author : Carlos Soriano , Sergio Costas
* URL : https://gitlab.gnome.org/World/ShellExtensions/desktop-icons
* License : GPL-3+
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> This is a much better summary of the thread, and I wish that you would
> have said this instead of claiming incorrectly that those same people are
> the ones advocating for a full merge of all systems.
Marco d'Itri writes ("Re: usrmerge -- plan B?
On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > I would still like to know if the upcoming arm64 desktop devices have
> > any problems working with OpenGL ES.
>
> Arm64 desktop systems use Radeon or NVidia cards with same o
On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote:
> > According to config_help.txt [1], Qt uses ES2 by default on Windows.
> > It probably means that it will work fine with most desktop video cards.
> >
> > But as Lisandro says, such a change in Debian will break many packages
> > (wh
W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> I would still like to know if the upcoming arm64 desktop devices have
> any problems working with OpenGL ES.
Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with OpenGL
On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote:
> I do understand that there would be a lot of effort required to support OGL
> and OGLES but as you have already pointed out "you are doing this already"
> because OGL is provided for all platforms except armel & armhf which have
> OGL
Hi all,
is anyone still interested in the citadel packages? I stopped using them ages
ago and finally ran out of time maintaining them. If anyone has interest and is
willing to put a bit of time into them, be my guest. They are in a decent
shape, but a new upstream version needs to get uploaded. I
On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> I think a better question would be: Does it improve, or disable, decent
> video support for the dozens of arm64 cards in the r-pi format, such as
> the arm64 based $44 rock64? [...]
As far as I know Raspberry Pi 3 and similar devices
On 11/23/18 12:18 PM, Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
>> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
>> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
>> architectures, to stop the special-casing madn
On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
> architectures, to stop the special-casing madness, instead of making it
> spread? :)
According
Quoting John Paul Adrian Glaubitz :
Granted, I don’t really know what the real world distribution of
embedded and desktop/server/laptop devices of arm64 is. But I could
imagine that there will be more arm64 devices in the future which
are desktops, servers or laptops.
There is e.g. this p
Quoting Holger Levsen :
On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote:
Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
times. And we did not even have dh in those days. Sounds good to me!
ITYM s#potato#slink, potato, woody, sarge, etch and lenny#
(St
On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
>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
>> > exclusi
On 23/11/2018 00:17, Lisandro Damián Nicanor Pérez Meyer wrote:
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 A
36 matches
Mail list logo
