On Mon, Nov 19, 2018 at 04:59:57PM +0100, Matthias Klumpp wrote:
> Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel
> :
> >
> >
> > Hi Ian,
> >
> > Thanks for the follow-up.
> >
> > On 19 November 2018 at 15:45, Ian Jackson wrote:
> > | Dirk Eddelbuettel writes ("Our build system may b
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-rcppprogress
Version : 0.4.1
Upstream Author : Karl Forner
* URL : https://cran.r-project.org/package=RcppProgress
* License : GPL-3+
Programming Lang: GNU R
Description : int
On Tue, Nov 27, 2018 at 01:05:14AM +0100, Alf Gaida wrote:
> On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther 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 th
On Thu, Nov 22, 2018 at 09:16:59PM +, Holger Levsen wrote:
> On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > > Because:
> > > > ...
> > > thanks! nice summary.
> > I replied in my other mail to the things I disagreed with (as is
> > traditional) but it occurred to me I ought
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-rcppannoy
Version : 0.0.11
Upstream Author : Dirk Eddelbuettel
* URL : https://cran.r-project.org/package=RcppAnnoy
* License : GPL-2+
Programming Lang: GNU R
Description : Rcp
> Dirk Eddelbuettel writes:
> On 20 November 2018 at 02:35, Chris Lamb wrote:
> | Hi Dirk,
> |
> | > | > … Simon McVittie has actually patched our testing framework to vary
> | > | > this and this is now live.
> | > | >
> | > | > https://bugs.debian.org/901473#33
> | […]
> | > Are we sure t
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:
> So: what's the best outcome for our *current* users? Again, pick only one.
here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?
we k
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive), but I have
> > reason to b
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther 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 main
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
On Mon, Nov 26, 2018 at 12:21:25PM -0500, Alan Corey wrote:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program? Supply both libraries?
Because this requires providing two separate *stacks* of source packages,
one for GL and one for GLES, which from Ubuntu
Quoting Ben Hutchings :
Many of the rules in Debian policy are there to support a minority of
users, but we try to follow them anyway.
Hear, hear! I was about to write the same thing.
I personally don't care about usrmerge, but if it is useful to a
relevant minority, we should not reject it.
On Sat, 2018-11-24 at 21:51 +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > [...]
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver, whi
On Mon, 2018-11-26 at 15:34 +0100, Stephan Seitz wrote:
> On Mo, Nov 26, 2018 at 03:08:09 +0100, Marco d'Itri wrote:
> > snapshot as well) would be hard and I disagree that the benefits of
> > merged-/usr would be minor.
>
> There are no benefits of a merged /usr for users who don’t want to export
On Mon, 26 Nov 2018 at 15:00:41 +, Alastair McKinstry wrote:
> Moving config from /etc to below /usr becomes useful for containers, and
> hence clusters.
Both that and merged /usr are particularly useful for containers and
close-to-stateless embedded systems, but they are orthogonal. Please do
On Mon, 26 Nov 2018 17:12:34 +0100, Marco d'Itri wrote:
>In other words, you are concerned about failure modes which have never
>happened and that nobody has been able to explain how they may happen in
>the future.
s/you/customers looking for an excuse to ditch Debian/
Greetings
Marc
--
-
Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program? Supply both libraries? ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.
On 11/26/18, Lisandro Damián Nicanor Pérez Meyer wrote:
> El lunes, 26
On Mon, Nov 26, 2018 at 05:12:34PM +0100, Marco d'Itri wrote:
> So far the worst case of "usrmerge failure" can be fixed by
> deleting/moving some files (that were installed by you) and then running
> the program again. There has never been any case which required
> reinstalling/restoring a syst
El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?
It's a Qt build-time option. This in an upstream choice, not ours and not up
to us to fix.
> Supply both libraries?
Already answered
Dear Colleague,
You are kindly invited to participate and to submit an Abstract, Paper,
Invited Talk and/or an Invited Session (3-6 papers) to the forthcoming
Applied Stochastic Models and Data Analysis International Conference
(ASMDA2019) and the Demographics2019 Workshop (11-14 June 2019, Flore
On Nov 26, Marc Haber wrote:
> I would be willing to do this on production systems that can easily be
> snapshotted and reverted in no time during an upgrade change, such as
> VMs. Unless forced to, I'd rather not touch systems running on bare
> metal and would need a restore-from-backup should u
On Mon, Nov 26, 2018 at 03:00:41PM +, Alastair McKinstry wrote:
>
> On 26/11/2018 14:44, Adam Borowski wrote:
> > On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote:
> > > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote:
> > > > I disagree both that simple testing (that
On Mon, 26 Nov 2018 09:26:44 -0500, Michael Stone
wrote:
>On Mon, Nov 26, 2018 at 09:24:40AM +0100, Didier 'OdyX' Raboud wrote:
>>usrmerge is in the archive for 3+ years now. What seems to be needed now is
>>for a lot of us to actually _try_ it, find and report bugs, and get this
>>through.
>
>The
Hallo,
* Chris Lamb [Mon, Nov 26 2018, 03:16:55AM]:
> Just reviewing this in NEW and was briefly uneasy about a package with
> this name entering the package namespace. For example, given:
>
> $ apt-get source src
>
> … and that there are also many places in Debian where we would be
> using no
On 26/11/2018 14:44, Adam Borowski wrote:
On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote:
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 bene
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-rtsne
Version : 0.15
Upstream Author : Jesse Krijthe,
* URL : https://cran.r-project.org/package=Rtsne
* License : BSD-3-clause
Programming Lang: GNU R
Description : GNU R T-Di
Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You ca
El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> 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,
Our (team-wide) pleasure. This is something we have been d
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson writes:
> > We can then have this discussion again early in the bullseye release
> > cycle. If we must.
>
> That idea makes me wince. This will just result in the same thing
> happening again. Let's have the discussion *now*, when
On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote:
> 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
On Mo, Nov 26, 2018 at 03:08:09 +0100, Marco d'Itri wrote:
snapshot as well) would be hard and I disagree that the benefits of
merged-/usr would be minor.
There are no benefits of a merged /usr for users who don’t want to export
/usr via NFS or want to use clusters/docker images/etc. And this
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 Mon, Nov 26, 2018 at 09:24:40AM +0100, Didier 'OdyX' Raboud wrote:
usrmerge is in the archive for 3+ years now. What seems to be needed now is
for a lot of us to actually _try_ it, find and report bugs, and get this
through.
There's no way I'm running it on a production system. I would be wi
On Nov 26, Ian Jackson wrote:
> I could do it. But, frankly, this is quite a lot of work. I think
> the work (throughout the Debian ecosystem) to test this properly far
> outweighs the minor benefits.
I disagree both that simple testing (that you could do with a KVM
snapshot as well) would be
Hello Ian,
On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > The hardware that supports GLES also supports OpenGL because GLES is
> > a subset of OpenGL.
>
> I'm confused by this inference. If GLES is a subset of OpenGL then
> surely
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 proje
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
On Nov 26, Bjørn Mork wrote:
> "Migration is not (easily) reversible" was reported as important in
> 2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626
This is not a bug: nothing is misbehaving, so classifying this as
wishlist is correct.
I even doubt that it would be technically fea
Didier 'OdyX' Raboud writes ("Re: usrmerge -- plan B?"):
> Of course you do have backups. For the sake of the argument, would you
> consider trying an install of usrmerge on a restored backup VM somewhere?
I could do it. But, frankly, this is quite a lot of work. I think
the work (throughout t
Marco d'Itri writes:
> On Nov 26, Didier 'OdyX' Raboud wrote:
>
>> Sorry to be blunt about this, but have you reported these? Sniping at (any)
>
> No, they have not. There is a lot of handwaving in this thread but very
> few results of actual tests.
"Migration is not (easily) reversible" was r
Quoting Raphael Hertzog (2018-11-26 12:37:57)
> 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.
Is some _hardware_ really "designed for OpenGL ES only"?
I guess
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
Hi!
On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog wrote:
> >
> > What applications does Debian have in its repo that only support GLES?
>
> Wrong question. Maybe it makes sense for you at the application level for
> the application that are hooking into OpenGL directly. But we are speaking
> o
Hello,
On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]
That's a different claim to what you made in a former message.
> The problem is that
> On Sat, 24 Nov 2018, bret curtis wrote:
> > This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> > hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> > if you plan on having hardware a
On Nov 26, Didier 'OdyX' Raboud wrote:
> Sorry to be blunt about this, but have you reported these? Sniping at (any)
No, they have not. There is a lot of handwaving in this thread but very
few results of actual tests.
After creating again unmerged chroots for the buildds the only bugs
left, a
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ó:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or NVid
Hi,
On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
Interesting.
> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at th
Hello Bret,
On Sat, 24 Nov 2018, bret curtis wrote:
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardwar
On Mo, Nov 26, 2018 at 09:24:40 +0100, Didier 'OdyX' Raboud wrote:
usrmerge is in the archive for 3+ years now. What seems to be needed now
is for a lot of us to actually _try_ it, find and report bugs, and get
this through.
Why, if it was intended as an optional package for people who want
a
Le jeudi, 22 novembre 2018, 14.56:10 h CET Ian Jackson a écrit :
> There is tradeoff here between risk of breakage, and reduction of
> future work (as most clearly explained by Russ). The argument that is
> being made is that the risk is low because of a lack of reports of
> breakage.
>
> Others
Le jeudi, 22 novembre 2018, 00.17:54 h CET Michael Stone a écrit :
> Then this needs to be a very explicit (and much better advertised)
> decision, and it needs a much, much better implementation.
You keep referring to usrmerge as buggy:
> The current usrmerge package has no test mode, will bail w
retitle 881896 ITP: src -- Simple Revision Control, single-file and single-user
version tracking
thanks
[Adding debian-devel@lists.debian.org to CC]
Hi Mike et al.,
> Package: wnpp
> Severity: wishlist
>
> * Package name: src
> Version : 1.17
Just reviewing this in NEW and was b
53 matches
Mail list logo
