Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

ah!

some fascinating news (from another discussion) pulled up the fact
that ADA converted to a Certification Mark, back in 1987

http://archive.adaic.com/pol-hist/policy/trademrk.txt

In order to be a validated Ada compiler, a compiler must pass an extensive
suite of programs called the Ada Compiler Validation Capability (ACVC).  The
AJPO has adopted a certification mark to show that a compiler has passed the
ACVC and is a validated compiler or a compiler derived from a validated base
compiler as defined in the Ada Compiler Validations Procedures and Guidelines
(version 1.1 of which was issued in January 1987).  The certification mark may
also be used on certain literature accompanying or documenting a validated
compiler.  Information concerning the proper use of the certification mark was
distributed to interested parties during the summer of 1987.

*that* is what the Rust Foundation *should* be doing.
messing about prohibiting patching is going to end in tears.

if they instead state, "You must run the Test Suite (unmodified, as provided by
us), and it the results are a 100% pass then you're free and clear to distribute
without limitation [and use the word "rust"] in the distributed package"

then *that* would solve all of the problems.

unfortunately, as i said in comment #40
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

if the Rust Foundation tries right now to convert the Trademark into a
Certification Mark it will be DENIED because they are selling product
(hats, T-shirts) and a Certification Mark Holder cannot compete with
its Licensees.

if they stop selling T-shirts and Merchandise and give assurances to
the Trademark Office that they will not do so then they should be ok
to convert to a Certification Mark.

l.

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

On Mon, Jul 18, 2022 at 11:06 AM Sylvestre Ledru  wrote:
>
> This bug is fixed.

i can see that you believe that to be true, otherwise you would
not have closed it.

what i am upset by is that you did not consider my opinion or
insight to be worth consulting.

i am deeply offended by that.

l.

Bug#1013920: closed by Sylvestre Ledru (Re: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[Luke Kenneth Casson Leighton]

reopen 1013920

sorry, Sylvestre, if you could possibly wait, on something this serious,
for a response as to whether the fix is valid, that will avoid me having
to spend my time reopening the issue or creating a second bugreport.

On Mon, Jul 18, 2022 at 10:21 AM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the rust-all package:
>
> #1013920: rust-all: Debian violating Rust Trademark (as serious a situation 
> as "iceweasel")
>
> It has been closed by Sylvestre Ledru .

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Jul 18, 2022 at 10:16 AM Sylvestre Ledru  wrote:
>
> Thanks for bringing it to our attention, I have consulted with the Rust
> foundation, we have agreed a change, we think this change solves it.

ah! we may have just had some cross-over.

> See
> https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/
> for the updated policy.

did you mean the sections "fixing local paths" (etc)?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#60

no, that would not be sufficient.  it still violates DFSG (most of it).

there is also the issue that even placing a public copy of source
code on a git repository also constitutes "Distribution".

i gave some suggestions which would be much more reasonable
(and general) already, they may have been missed:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

those much more general statements basically say

"we trust you not to do any damage under our name"

the new additions basically say:

"you're clearly too stupid to be trusted so we're going to
 lock out your rights"

it should therefore come as no surprise that trying to go in
that direction would directly conflict with everything that DFSG
strives towards.

l.

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

i've opened up a second bug for gcc because it is also about to
become affected, not in the same way, but in a worse way.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015242

whilst 50% of DFSG 2 is violated by the Rust Trademark
(as it stands, with the new clauses), gcc is in an even worse
situation because the Rust Trademark conficts directly with
the GPL as well.

this is a complex multi-faceted issue: please do not close the
bugreport until all facets of the conflict brought to your attention
have been resolved.

or... you can... but that will force me into the position of re-raising
another report, and i am too busy to do that, and you risk me
giving up and not caring.

l.

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Luke Kenneth Casson Leighton]

https://developers.slashdot.org/story/22/07/17/0110250/gcc-rust-approved-by-steering-committee-beta-likely-next-april

and now it becomes Unlawful for Debian to distribute gcc with patches,
as well [without the explicit consent of the Mozilla Foundation, an action
which is in direct violation of DFSG]

l.

Bug#993957: closed by Christoph Biedl (Re: Bug#993957: (no subject))

[Luke Kenneth Casson Leighton]

On Sun, May 29, 2022 at 12:16 PM Debian Bug Tracking System
 wrote:

> #993957: schroot: fails with non-existent subdirectory
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Christoph Biedl 
>  by
> replying to this email.

christoph has misunderstood that i have provided the repro circumstances:
sysvinit is required to be installed and utilised before this bug will occur.

with sysvinit being a supported debian boot mechanism the closure
of this bugreport is not the correct action to take.

this bug is not unreproducible: the declaration that it is unreproducible
is invalid.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

well, i just checked after upgrading to 3.6.11-2 and the repository
in question has now *entirely disappeared* from the config!

i've had to downgrade to 3.6.6-1 to get things functional
(it's a live-running server)

this does actually work, so during scheduled downtime
moments i can switch to the broken version (3.6.11-2)
and find out what the heck is going on.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

i've created a test account, stupidly upgraded first so i cannot check
the "broken" case.

i will therefore use the original account with the underscore, however
i need to ask a 3rd  party to run the ssh command.

the setup i have is quite comprehensive, 30 ssh keys 25 projects, it
may be an interaction between them.

l.

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

Package: gitolite3
Version: 3.6.6-1
Severity: important
Tags: upstream

Dear Maintainer,

i have used gitolite3 for many years, this is the first time i have ever
had a major bug, and it involved a username with an underscore in it.
ssh to the server reported "hello user" not "hello user_", and
COMPLETELY the wrong repository was granted write access.

this is an extremely serious security issue.


-- System Information:
Debian Release: 9.12
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gitolite3 depends on:
ii  adduser  3.115
ii  debconf [debconf-2.0]1.5.61
ii  git [git-core]   1:2.29.2-1~bpo10+1
ii  libjson-perl 2.90-1
ii  openssh-client   1:7.4p1-11.0nosystemd1
ii  openssh-server [ssh-server]  1:7.4p1-11.0nosystemd1
ii  perl 5.28.1-6

gitolite3 recommends no packages.

Versions of packages gitolite3 suggests:
pn  git-daemon-sysvinit  
ii  gitweb   1:2.29.2-1~bpo10+1

-- debconf information excluded

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Luke Kenneth Casson Leighton]

On Wed, Aug 19, 2020 at 3:29 PM Tristan Seligmann
 wrote:
>
> Control: tags -1 - upstream
> Control: forcemerge 968563 -1
>
> On Wed, 19 Aug 2020 at 14:48, lkcl  wrote:
> >
> > ValueError: Non keyword-only attributes are not allowed after a 
> > keyword-only attribute.  Attribute in question: Attribute(name='invoice', 
> > default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True, 
> > metadata=mappingproxy({}), type=, converter=None, 
> > kw_only=False)
>
> This is a consequence of #968563; upgrading python3-attr should fix it.

the normal approach to this would be to release a version of the
electrum packaging that specifically depends on that specific version
of python3-attr or above. the following to go into debian/control:

Depends: python3-attr >= 19.3.0-5

l.

Bug#968666: electrum: exception which prevents startup "Non keyword-only attributes not allowed after..."

[Luke Kenneth Casson Leighton]

On Wed, Aug 19, 2020 at 6:34 PM Tristan Seligmann
 wrote:

> > the normal approach to this would be to release a version of the
> > electrum packaging that specifically depends on that specific version
> > of python3-attr or above. the following to go into debian/control:
>
> Yes, the next upload will fix this as well as some other dependency issues.

fantastic, thanks tristan.

l.

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:

> #958166: python3-all: python3 can't import gmpy2
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.

if you were talking about python 3.6, there would be absolutely no
problem, because python 3.6 is not the default version of python3
that's installed in the current LTS stable release (debian 10).

the fact that python 3.7 is the default LTS stable *and is being
removed* leaves an extremely serious situation for anyone that
attempts to dist-upgrade from debian 10 to debian 11.

that was the lesson learned - the mistake made - by the ubuntu team,
made all the more serious that the entire apt packaging system was
critically dependent on a version of python that was *being removed*
(!!)

forget for one moment that i'm using debian/testing (which you should
not in any way find it "acceptable" to callously dismiss people in the
position that i am in such an unthinking fashion) - people doing
*stable* dist-upgrades will end up with broken systems.

and it's part of debian that stable-to-stable dist-upgrades must
*always work*, ok?  you should know this.

and *that* is why i raised this as a critical bugreport, ok?

*please think* before arbitrarily closing critical bugreports, ok?

l.

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

here is a package that contains a build system that, unlike the
python3-numpy team, relies exclusively on python3-all.  like
python3-gmpy2, note that it does not contain enumeration of the minor
versions of python.  its control file does not list multiple versions
of python3, either, choosing instead to rely on the macros.

thus this particular package is critically subject to your arbitrary
and unthinking "whims", where python3-numpy is not.

i strongly suggest that you investigate precisely and exactly what
happened, historically, when ubuntu tried to do what you are forcing
onto people in an unthinking and inconsiderate way.

l.


rules-pythonmagick
Description: Binary data

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

you do realise, scott, that python3-numpy has been forced into a
position of bypassing the careless unthinking decision that you've
made, by including the capability to manually enumerate and compile up
multiple versions for different versions of python3?

instead of closing the bugreport and making a callous "declaration",
you could instead have said,

"um, that's really strange, because we have done this several times in
the past.  what do *you* think makes this situation different, which
warrants a critical bugreport status?"

and we could have worked TOGETHER to find the answer.

people don't raise critical bugreports without good justification,
scott.  it's the first time i've ever considered it, in over 16 years
of continuously using debian.

would you like to reconsider, or do i have to escalate this further?

l.


On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the python3-all package:
>
> #958166: python3-all: python3 can't import gmpy2
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.
>
>
> --
> 958166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 958166-d...@bugs.debian.org
> Cc: 958...@bugs.debian.org
> Bcc:
> Date: Sun, 19 Apr 2020 12:32:31 +
> Subject: Re: [Python-modules-team] [critical] #958166 - python3-all has had 
> python3.7 removed
> Alternately, you could just update python3-gmpy2 to the latest version of the 
> package, which is built to support python3.8:
>
> https://packages.debian.org/sid/amd64/python3-gmpy2/filelist
>
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.
>
> What you are observing is a perfectly normal transition to a newer version of 
> python3.  If such things bother you this much, you should probably stick to a 
> Debian Stable release.
>
> This is the 7th time we've done this for Python3.  It happens once or twice a 
> release cycle.  There's no bug at all here.
>
> Scott K
>
>
> -- Forwarded message --
> From: lkcl 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 19 Apr 2020 09:28:54 +0100
> Subject: python3-all: python3 can't import gmpy2
> Package: python3-all
> Version: 3.8.2-2
> Severity: important
>
> see #958043
>
> it has now become impossible to install python3-gmpy2.  however that
> is just one symptom of this serious issue.
>
> with python3-all no longer dependent on both python3.7 and python3.8,
> transitioning from python3.7 to python3.8 has just become a nightmare.
>
> with some packages being built that are dependent on 3.7 and some on 3.8,
> any packages which have dependencies that import from both sets during
> the transition will cause a serious install failure
>
>
>
> -- System Information:
> Debian Release: 8.1
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages python3-all depends on:
> ii  python33.8.2-2
> ii  python3-distutils  3.8.2-2
> ii  python3.7  3.7.2-1
> ii  python3.8  3.8.2-1+b1
>
> python3-all recommends no packages.
>
> python3-all suggests no packages.
>
> -- no debconf information


rules
Description: Binary data

Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)

[Luke Kenneth Casson Leighton]

On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the python3-all package:
>
> #958166: python3-all: python3 can't import gmpy2
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.
>
>
> --
> 958166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Scott Kitterman 
> To: 958166-d...@bugs.debian.org
> Cc: 958...@bugs.debian.org
> Bcc:
> Date: Sun, 19 Apr 2020 12:32:31 +
> Subject: Re: [Python-modules-team] [critical] #958166 - python3-all has had 
> python3.7 removed
> Alternately, you could just update python3-gmpy2 to the latest version of the 
> package, which is built to support python3.8:
>
> https://packages.debian.org/sid/amd64/python3-gmpy2/filelist
>
> Python3.7 is no longer supported in Debian Unstable and Testing and will be 
> removed shortly.

this is a serious mistake.  did you not read what i wrote?  did you
not learn from the lesson of ubuntu when it made the same mistake,
with apt depending on the version that was removed, at the time?

> What you are observing is a perfectly normal transition to a newer version of 
> python3.  If such things bother you this much, you should probably stick to a 
> Debian Stable release.

that's absolutely impossible.  i cannot believe that you are seriously
asking that people quotes stick to debian stable quotes as a quotes
solution quotes.

did you not read that i have over 5 million source code files on this
system?  did you imagine that as a software developer i would be
*able* to quotes use debian stable quotes?

software developers *need* to be able to use debian/testing, if
debian/stable does not do what they need.  expecting them to compile
up packages and custom-maintain vast swathes of packages from source
in /usr/local is hopelessly unrealistic and is precisely why distros
exist in the first place.

do you not understand how seriously cavalier and unthinking your response is?


> This is the 7th time we've done this for Python3.

that would explain why i have encountered problems like this in the past.

question.  was a version removed that happened to also be the "stable" version?

did you not read what i wrote?

> It happens once or twice a release cycle.

> There's no bug at all here.

that is false: what it means is that you do not understand the serious
consequences of the decision that's being made.

you have completely failed to acknowledge what i wrote, choosing
instead to selectively quote your own past experience.

not only that, you've closed this critical bugreport without a wider
consultation.

why did you do that?

l.

Bug#958166: severity 958166 critical

[Luke Kenneth Casson Leighton]

after some consideration, i realised that the removal of python3.7 as
a dependency from python3-all results in "unrelated software on the
whole system break", and that this is reminiscent of the critical
error made by ubuntu, over 10 years ago.

1 criticalmakes unrelated software on the system (or the whole system)
  break, or causes serious data loss, or introduces a security
  hole on systems where you install the package.

the steps to reproduce this are:

1. install debian 10 (which has python 3.7 as a dependency)
  https://packages.debian.org/buster/python3

2. install (for example) python3-gmpy2 which is dependent on version 3.7
  https://packages.debian.org/buster/python3-gmpy2

3. install N.E.Other python package which also specifically depends on
version 3.7
  but which has *NOT* yet been recompiled / upgraded in debian/testing for
  version 3.8

4. install a python package (named python-dualdep) which:
  (A) depends on python3-gmpy2
  (B) depends on python3-NEOther package from step 3

5. add debian/testing to /etc/apt/sources.list

6. apt-get install python3-gmpy2 to bring in the *NEW* version of
python3-gmpy2 which SPECIFICALLY now ONLY depends on python3.8
   https://packages.debian.org/testing/python3-gmpy2

7. the result is a completely broken system.

this is basically a repeat of the nightmare scenario / mistake that
ubuntu made 10+ years ago in the transition from python 2.5 to python
2.6.

upgrades from ubuntu *STABLE* resulted in the *REMOVAL* of python 2.5
(and all python packages)... actually during the upgrade process
(leaving no version of python with which to *continue* the upgrade
process), because due to the polarisation caused by some packages
being built for python 2.5 and some for python 2.6, it was impossible
to satisfy both at the same time.

the only "solution" for apt: REMOVE either the packages that depend on
python 3.7 OR remove the packages that depend on python 3.8
(in some cases this becomes impossible to do, resulting in a broken
system).

this is extremely serious and needs to be fixed as fast as possible,
before more packages get compiled up only depending on python 3.8.

in particular, if python3-numpy hits the debian repository whilst only
depending on python 3.8, having zero packages which support python 3.7
simultaneously whilst transitioning to python 3.8, i guarantee that
all hell will break loose, due to the sheer number of packages that
depend on it:

$ apt-cache rdepends python3-numpy | sort | uniq | wc
439

that's 439 ongoing dependencies, which would cause absolute chaos for
the entire scientific community, as their packages would fail to
properly transition over during a stable (debian 10) to stable (debian
11) upgrade.

at present (thank god) it is still depending on python3.7 and python 3.8
https://packages.debian.org/testing/python3-numpy

l.

Bug#958166: Processed: severity 958166 critical

[Luke Kenneth Casson Leighton]

https://alioth-lists.debian.net/pipermail/python-modules-team/2020-April/066373.html

we're starting to see additional evidence of the seriousness of this
one.  an attempt to (auto-) build python3-pythonmagick failed due to
libboost-python however i just attempted it myself, and:

* apt-get build-dep pulled in replacements for python3-all and
python3-dev (which no longer contain python3.7 or python3.6)
* the linker phase failed with "/usr/bin/ld: cannot find -l-lboost_python-py36"

this is supposed to be linking against *python3.8* (and *only* against
python 3.8).

even if i were to install libboost-python 3.7 (which i am certainly
not going to attempt because boost causes such massive problems) it
would still fail.

even if this build problem were to be "fixed" by the maintainers of
pythonmagick, the result would be the creation ONLY of a version of
python3-pythonmagick that could be installed for python 3.8.

a corresponding version that was safe for installation and use with
python 3.7 would *NOT BE BUILT*.

i cannot emphasise enough how much damage this is going to do to the
python eco-system - first for people using rolling debian/testing
systems and ultimately for people trying debian/10 to debian/11
apt-get dist-upgrades, if not fixed as fast as possible.

l.

Bug#958043: [critical] #958166 - python3-all has had python3.7 removed

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958166

this is serious enough to bring to a wider audience's attention,
immediately.  just as happened over 10 years ago, a mistake made by
the ubuntu team making python-all depend on only a single version of
python has just been repeated, in debian.

the consequences are not immediately obvious however are beginning to
bleed through already.  the issue is *not* if a "fresh install" (in
this case of debian/testing) is carried out, it's if someone tries to
do a rolling-update.  i managed to catch this because i never do
apt-get dist-upgrade (or full reinstalls - never going to happen with
5 million source code files accumulated over 8 years).  instead i add
debian/testing and "on-demand" perform periodic apt-get installs which
will pull in required dependencies.

this allows me early detection the scenarios that would cause
stable-to-stable upgrades to FAIL, 100%, just as they did for the
ubuntu team when transitioning from python 2.5 to python 2.6.

with python3-all having had python 3.7 removed, c-based python3
packages are now being built that can NEVER be simultaneously
installed whilst python 3.8 is also installed on the same system.

likewise, if python 3.8 is ever also installed on the same system and
packages which *do* depend solely and exclusively on python 3.8 get
installed, if there are any dependencies further up the chain, one of
which depends on one c-module-based package compiled exclusively for
python 3.7 AND ONE WHICH DEPENDS ON 3.8, all hell will break loose.

i cannot emphasise enough how serious this will become if
python3-numpy gets recompiled and uploaded as only depending on python
3.8
https://packages.debian.org/testing/python3-numpy

right now - thank goodness - the current version in sid is dependent
on both 3.7 and 3.8:
https://packages.debian.org/sid/python3-numpy

martin points out that python3-all is critical in determining how
multi-python c-based module compilation works:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958043

thus, when python3-numpy is next recompiled, it's going to be for a
single version of python3.  with apt-cache rdepends showing 439
packages depending on python3-numpy, that's going to create absolute
havoc.

the versions of python3 that are in python3-all *must* cover at least
the current stable LTSes *right* the way through to the current
version of python.  with debian 10 being dependent on python 3.7, that
means it *must* stay in python3-all at least until debian 11 is
released.

if python 3.9 is ever included in debian/testing, then that means that
python3-all *must* depend on python 3.7, 3.8 *and* python 3.9.  the
last time this happened was (i think) debian 8, where python 2.4, 2.5
*and* 2.6 had to be included for a while.

i cannot emphasise enough how critical this is to rectify as fast as
possible before any further python3 c-based packages are compiled up,
mistakenly, for only the one version of python3.  the more that get
uploaded, the more reports will come in of package conflicts during
upgrades.

l.

Bug#958043: Acknowledgement (python3-gmpy2: import gmpy2 fails)

[Luke Kenneth Casson Leighton]

unfortunately, because of the way that python3-gmpy2 has been
compiled, attempting to install an older version FORCE removes (or
conflicts with) an existing installation of python 3.8.

therefore if, as many people will have, they are transitioning from
python 3.5 to 3.6, 3.6 to 3.7, 3.7 to 3.8, the way that python3-gmpy2
has been installed will cause serious problems, particularly if there
are other dependencies... which there are:

$ apt-cache rdepends python3-gmpy2
python3-gmpy2
Reverse Depends:
  python-gmpy2-doc
  python-gmpy2-common
  pyecm
  python3-ppl
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python-gmpy2-common
  python3-mpmath
  python3-mpmath
  python-gmpy2-doc
  python-gmpy2-common

i'd therefore recommend upgrading the severity of this bugreport.

martin, can i suggest taking a look at this:
http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.17.4-5.debian.tar.xz

and look at the debian/rules file.  it deliberately depends on *both*
python3.7 and python3.7, followed by auto-detecting the versions
installed.  it has heavy dependence on c compilation so should work
absolutely fine



# apt-get install python3-gmpy2=2.1.0~a4-1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-gmpy2 : Depends: python3 (< 3.8) but 3.8.2-3 is to be installed
E: Unable to correct problems, you have held broken packages.


rules
Description: Binary data

Bug#949747: closed by Simon McVittie (Re: Bug#949747: gimp: dependency versions missing)

[Luke Kenneth Casson Leighton]

thank you simon, i've passed that on to christian.
l.

Bug#864997: DEP-5 copyright checker

[Luke Kenneth Casson Leighton]

[apologies i can't reply inline, very limited HTML mailer due to
seriously bandwidth/reliability-compromised internet connection]

hi felix,

violates my copyright by not containing my authorship assertion.  in
combination with no license file they should have contacted me for
permission to distribute.  whoops.  they *assumed* that because it was
in some other work that *was* licensed that it was "okay".

ironic, huh?

yes it's my work (entirely), yes, confirmed, GPLv2+ licensed.
("public domain" statements are *ineffective* due to the very annoying
Berne Convention).  the only modifications that people have made in
the copies that you can find online are to default paths (something
like that, it's been a while).

there is *one* annoying buglet in copyright_check.py: the search
mechanism i couldn't find a way to get it to go from the "root" level
using wildcards.  consequently, you have to use a copyright file that
specifies matches against files and subdirectories, *even if those are
wildcards*.

this is the primary reason why copyright_check.py doesn't "detect"
anything on lintian itself... because lintian's *own* copyright file
is a one-liner-wildcard-match.

a way to get round that would be to take one-liner-wildcard-match
files, do a sweep of the top-level root directory, and apply the
one-liner-wildcard-match to every single entry... *then* pass that
through to the algorithm.

no, god no, i'll never rewrite it in perl: perl is a "WORN" language -
write-once, read-never :)  i'm dead serious.  the readability is so
bad in perl, and the algorithm itself in copyright_check.py
sufficiently obtuse that it would be a... "inadviseable" combination
:)

those false positives look... err fun.  welcome to
arbitrary-pattern-matching against random human-written text: i used
qgrams to help with that, however, just as with when i was working for
Internet Security Systems and we were doing packet-pattern-recognition
it is *guaranteed* to be a losing battle that will *never* be
"complete" or "successful", please do bear that in mind, ok?

with many apologies, i have so much else going on: if you ping me
regularly and keep me interested in a conversation i will respond with
insights and so on (because i like copyright_check.py and the time it
saves), however i simply don't have time to take "initiative" if you
know what i mean, there.

thanks felix.

l.

On 12/14/19, Felix Lechner  wrote:
> Hi Luke,
>
>> so i wrote a program called copyright_check.py which covers every single
>> possibility of what is correctly matched, what is incorrectly matched,
>> and what is missing.
>
> That's great! I have been looking for such a tool.
>
>> copies of the original program are being made and distributed
>> arbitrarily.
>> one such copy (which ironically violates copyright) is here:
>> https://fossies.org/dox/drizzle-7.2.4-alpha/copyright__check_8py_source.html
>>
>> one version may also be found here:
>> https://github.com/jaredly/pyjamas/blob/master/contrib/copyright_check.py
>
> Does it violate your copyright or someone else's? I see an assertion
> of your authorship only in the second file. Neither file shows license
> terms.
>
> For Debian's benefit, would you please reply with a statement that the
> program is solely your work? Please also attach a copy (not a link) or
> alternatively, a pointer to a repository under your control. The copy
> you send must further include the terms of your DFSG-compliant license
> (preferably GPL-2+, which would be like Lintian) or a statement
> placing your work in the public domain. Thank you!
>
> Two more things: First, Lintian runs on Perl. Did you ever port your
> program to any other languages? Second, I plan to rework the copyright
> check, which has many open bugs. Please let me know if are interested
> in helping:
>
>
> https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/copyright.pm
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=lintian
>
> Kind regards
> Felix Lechner
>

Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

[Luke Kenneth Casson Leighton]

On Fri, May 31, 2019 at 5:09 AM Dmitry Bogatov  wrote:

> > Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
> >  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in 
> > package libgdbm3:amd64 1.8.3-11
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb
>
> Issue, yes. But you are upgrading from rather old version of libgdbm3.
> According to https://tracker.debian.org/gdbm, it predates even
> old-stable.

 ah ok, not a problem then - i thought the existing version was more
recent than that, missed that it was 1.8 rather than 1.18.

l.

Bug#909630: gitlab: no sysvinit scripts installed or available

[Luke Kenneth Casson Leighton]

On Wed, Sep 26, 2018 at 10:30 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 3:05:32 PM AEST Luke Kenneth Casson Leighton
> wrote:
>> appreciated, dmitry: apologies, it catches me off-guard when things
>> don't work.
>
> No worries. It would be nice to introduce init scripts to GitLab.
> With your motivation it looks like it might actually happen. :)

 :)

>> it was just that the decision to rail-road systemd in
>
> Hold on here please. Using systemd as a default init system was well
> balanced, collective decision, thoroughly discussed with all pros and cons
> carefully considered.

 somewhere i have the post-analysis from the voting: i can't remember
off the top of my head, however if you look it up the records of the
votes clearly show that systemd was absolute dead-last in all respects
on all questions asked in the vote.

> You have to respect that.

 if the people who made the decision had respected the actual wishes
of the debian developers who voted, i would be tempted to agree...
however as a *user* i was not consulted about the consequences of the
decision... so i *genuinely* can't agree.

 i can *understand* why the decision was made...

> There is nothing unethical in choosing technically superior init system that
> suits most GNU/Linux distributions. We have made a choice and moved on -
> what's done is done and there is no point complaining about it.
>
>
>> (which is software that itself is being developed incredibly
>> unethically)
>
> I do not understand what do you mean.

 it's a long, long story, that takes quite a lot of time to explain
(and that's one of the problems: most people simply don't have time to
go over this, comprehensively).  perhaps it might be best to take this
offline from this bugreport, if you're interested to do so?

l.

Bug#909630: initscript found

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Sep 26, 2018 at 6:03 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 2:10:09 PM AEST Luke Kenneth Casson Leighton 
> wrote:
>> https://gitlab.com/gitlab-org/gitlab-ce/raw/master/lib/support/init.d/gitlab
>
> Thanks, Luke. It could be a good starting point but IMHO this script can not
> be used as-is and it needs a lot of work...

 yeah i agree: it does however get things up and running (where there
was no service *at all* for about half an hour).

it definitely needs splitting down into separate services: i'll take a
look over the next few days.

> Instead of using sloppy init script you might find it useful to try
>
>   https://github.com/gdraheim/docker-systemctl-replacement

 the majority of services that i've deployed over the past 20+ years
typically have always had an initscript: it's quite rare not to find
any (at all).

 i know you didn't suggest it, i wouldn't recommend including (or
depending on) that package for this task: it may however prove useful
to submit as a WNPP/ITP.

 for solving the issue here of gitlab needing to start when systemd
isn't around (and sysvinit is), i'll help sort that by creating 4
initscripts, i think that's the best solution for gitlab.

l.

Bug#909630: gitlab: no sysvinit scripts installed or available

[Luke Kenneth Casson Leighton]

appreciated, dmitry: apologies, it catches me off-guard when things
don't work.  it was just that the decision to rail-road systemd in
(which is software that itself is being developed incredibly
unethically) - was itself made unethically (not thinking of the harm
that could result, and without wider consultation, and the
consultation that *was* done was completely ignored!).  *some* of the
damage has been undone by allowing sysvinit to be used.

i've sent in what i could find: it's nothing like the postinst script
expects, which is a series of 4 separate initscripts (that's very
strange, btw, that there's some code in the postinst that *expects*
the 4 /etc/init.d/gitlab- init scripts to be there), however i can
confirm that what i found actually works.

gitlab is very very resource-heavy, so if i make the decision to keep
it, i will definitely (need to) create separate initscripts, and will
send them in, ok?

good luck, and apologies for getting annoyed, i was really caught off-guard.

l.


---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Sep 26, 2018 at 4:51 AM, Dmitry Smirnov  wrote:
> On Wednesday, 26 September 2018 11:45:02 AM AEST lkcl wrote:
>> it would be really helpful if people could stop assuming that everyone
>> forcibly fucking wants systemd shoved at them.  and no, ordering people
>> to go use freebsd or devuan is not acceptable.
>>
>> for goodness sake please be a little more careful and considerate.
>> i'll try to track down some sysvinit scripts in a followup and post
>> them later.
>
> It would be polite not to assume that lack of SysV scripts is deliberate.
> There are not enough people involved into maintenance of such a complex
> package as GitLab and writing init scripts from scratch and maintaining them
> is not an easy task.
> Yes, your help would be appreciated if you care enough for init scripts to
> contribute them or to fund/sponsor someone who could write them.
>
> Until then systemd remains a viable option for those who have no systemd-
> fobia and wishes to run GitLab...
>
> --
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> It is impossible to imagine Goethe or Beethoven being good at billiards
> or golf.
> -- H. L. Mencken

Bug#909630: initscript found

[Luke Kenneth Casson Leighton]

https://gitlab.com/gitlab-org/gitlab-ce/raw/master/lib/support/init.d/gitlab

this is semi-suitable: at least it has been possible to get things up
and running, by removing the section starting "Script variable names"
and relying on the entries in /etc/default/gitlab that are absolutely
fine in the debian package

please for goodness sake do not assume that absolutely everyone is
happy to be forced to use systemd, it's incredibly unethical.

plus, sysvinit is still a legitimately-installed and supported *and
commonly-used" debian package.

l.

Bug#901006: closed by Ben Hutchings (Re: Bug#901006: linux-image-4.16.0-2-amd64: "core has locked up" kernel messagee)

[Luke Kenneth Casson Leighton]

On Fri, Jun 8, 2018 at 2:27 AM, Debian Bug Tracking System
 wrote:
> -- Forwarded message --
> From: Ben Hutchings 
> To: 901006-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 08 Jun 2018 02:24:57 +0100
> Subject: Re: Bug#901006: linux-image-4.16.0-2-amd64: "core has locked up" 
> kernel messagee
> Sorry, we can't do anything with this.

 that's ok, ben: the report was more fyi, as it's so unusual (never
seen anything like it before, didn't even know it was *possible* for
one single core on an SMP system to end up "frozen"), however it's
pretty highly indicative that whatever changes have gone into 4.16 are
clearly *completely* unsuited to being propagated for advancement to
debian/stable status.

l.

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Luke Kenneth Casson Leighton]

On Fri, Mar 9, 2018 at 8:31 PM, Karsten Merker  wrote:

> There is one thing that I am a bit unsure about, though, and that
> is Mozilla's use of WORD and DWORD in their size definitions as I
> haven't found any documentation about that.

hiya karsten,

ok so someone from mozilla is really going to have to double-check
this, or perhaps todd from activestate would know, or brendan eitch
may know (i don't have an active email address for him).

my understanding is that the mozilla team copied microsoft's DCE/RPC
implementation (which microsoft called MSRPC) and also wrote something
that was "inspired" by COM, called XPCOM: they screwed it up royally
by leaving out the absolutely critical critical part, which is
co-classes (a run-time version of c++ multiple inheritance:
unnnbelievably important, and because they didn't implement it, the
problems kept compounding, and eventually they ripped XPCOM out).

now, because the decision and "inspiration" was such a long time ago,
they cut over the *win32* code, and hence some of the win32
code-conventions.  WORD in win32 is *specifically* defined as 16-bit,
and DWORD *specifically* as 32-bit.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx?f=255=-2147217396

now, what i don't know is: did they keep those conventions during the
f***-up known as "ripping out XPCOM"?  the purpose of XPCOM was to
provide a stable standard / API for their own developers  and for 3rd
party developers.  they failed on both counts... so may no longer care
and may have changed the definition of WORD and DWORD... but this is a
bit of a stretch.

honestly, this is something that really needs an answer and
clarification from mozilla, or someone like todd (hi todd) who knows
more about it.

l.

Bug#891411: Acknowledgement (mailman critically (and unnecessarily) linked to apache2 (and not nginx))

[Luke Kenneth Casson Leighton]

On Mon, Feb 26, 2018 at 7:51 AM, Thijs Kinkhorst <th...@debian.org> wrote:
> On Sun, February 25, 2018 12:13, Luke Kenneth Casson Leighton wrote:
>> apologies, after downloading the source i noted that the debian/rules
>> debian package.  i've installed lighthttpd, disabled it, and thus
>> "worked around" the "problem".
>
> Maybe for a next time, you can use the "equivs" package if you want to
> simulate that something is installed.

 thanks thijs i'll remember that, really appreciated.

l.

Bug#872036: Acknowledgement (AH00060: seg fault or similar nasty error detected in the parent process)

[Luke Kenneth Casson Leighton]

ok so a little more info here: the segfault occurs *directly* after a
logrotate-inspired signal is received.

[Sat Aug 19 06:25:37.746265 2017] [mpm_event:notice] [pid 21345:tid
3074504512] AH00493: SIGUSR1 received.  Doing graceful restart
[Sat Aug 19 06:25:39.647852 2017] [core:notice] [pid 21345] AH00060:
seg fault or similar nasty error detected in the parent process

an attempt to get more information by using mod_pagespeed's crash
handler *failed*.  one of the developers mentioned that there's an
option to get stack trace output put into the error logs, but
bizarrely (no explanation yet) we got absolutely no output when
the segfault occurred: just the standard apache2 AH00060 notice.

this is all very strange and i can't keep risking a live-running
client's system by using unstable software.  so, apologies, i'm going
to have to return to using mpm_prefork (i.e. can't risk doing further
tests with mpm_event on the live system).  performance was
*significantly* degraded around the time of the segfault.

Bug#860789: Acknowledgement (freecad: import of openscad file turns "differences" into "unions")

[Luke Kenneth Casson Leighton]

ah: i hadn't spotted this: it would appear that a legitimate scad file
is considered to be a syntax error by freecad's parser.

Parser Loaded
Start Parser
Vector
Vector
Vector
Vector
Vector
Matrix
Syntax error in input!
LexToken(SEMICOL,';',23,603)
Vector
Vector
Vector
Vector
Matrix
('$fn', '100')
('$fa', '12')
('$fs', '2')
('h', '19')
('r1', '2.5')
('r2', '2.5')
('center', 'true')
Cylinder
{'r1': '2.5', 'r2': '2.5', 'h': '19', '$fs': '2', '$fn': '100', '$fa':
'12', 'center': 'true'}
Make Cylinder
Center = true
End Cylinder
Block List
[]
End Block List
MultMatrix
Multmatrix
[['1', '0', '0', '2.5'], ['0', '1', '0', '2.5'], ['0', '0', '1',
'9.5'], ['0', '0', '0', '1']]
Matrix ((1,0,0,2.5),(0,1,0,2.5),(0,0,1,9.5),(0,0,0,1))
Apply Multmatrix
special orthogonal
rotation rounded
Multmatrix applied
Block List
[]
End Block List
Syntax error in input!
LexToken(EBRACE,'}',27,855)
Vector
Vector
Vector
Vector

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 4:08 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 18/04/17 11:55 AM, Luke Kenneth Casson Leighton wrote:
>> On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>
>>>> far from being 100% reproducible when resizing glxgears under fvwm2
>>>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>>>
>>> Please attach the Xorg log file.
>
> [...]
>
>> [   274.721] xorg-server 2:1.19.0-2.0nosystemd1 
>> (https://www.debian.org/support)
>
> The "nosystemd1" suggests that your xserver-xorg-core package isn't from
> Debian.

 it is... it's a modified recompiled version that is exactly identical
to debian, with the sole exception being that its compile-time options
are modified to include "--without-systemd" in the configure phase.

> Please report wherever you got it from that this support URL is
> misleading.
>
> The symptoms you're describing match a known bug in Xorg 1.19.0.

  ah ha!  at last!  dang was that hard to find someone who knows what
the underlying issue is.

> Please
> upgrade to 1.19.1 or newer.

 will do.

 l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer  wrote:

>> far from being 100% reproducible when resizing glxgears under fvwm2
>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>
> Please attach the Xorg log file.

 not too much to see, here, michel (yes it really is only 58 lines
long).  also including cat /proc/version and relevant section from
xorg.conf


lkcl@fizzy:/etc/X11$ cat /proc/version
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 6.3.0 20170124 (Debian 6.3.0-5) ) #1 SMP Debian 4.9.6-3
(2017-01-28)


Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
BusID   "PCI:0:2:0"
#Driver  "nvidia"
#BusID   "PCI:1:0:0"
#Option "SwapBuffersWait"   "false"
Option "AccelMethod""sna"
Option "TearFree"   "true"
Option  "DRI"   "3"
EndSection
[   274.305] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[   274.383] X Protocol Version 11, Revision 0
[   274.428] Build Operating System: Linux 4.8.10+ x86_64 Debian
[   274.483] Current Operating System: Linux fizzy 4.7.8lkcl #1 SMP Sun Dec 11 00:13:10 GMT 2016 x86_64
[   274.534] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.8lkcl root=/dev/mapper/pc-root ro quiet rcutree.rcu_idle_gp_delay=1
[   274.676] Build Date: 25 November 2016  03:55:18AM
[   274.721] xorg-server 2:1.19.0-2.0nosystemd1 (https://www.debian.org/support) 
[   274.765] Current version of pixman: 0.33.6
[   274.815] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   274.855] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   275.250] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 12 00:03:16 2016
[   275.600] (==) Using config file: "/etc/X11/xorg.conf"
[   275.644] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   275.982] (==) ServerLayout "X.org Configured"
[   276.013] (**) |-->Screen "Screen0" (0)
[   276.043] (**) |   |-->Monitor "Monitor0"
[   276.074] (**) |   |-->Device "Intel Graphics"
[   276.103] (**) |-->Input Device "Mouse0"
[   276.134] (==) Automatically adding devices
[   276.164] (==) Automatically enabling devices
[   276.194] (==) Automatically adding GPU devices
[   276.225] (==) Max clients allowed: 256, resource mask: 0x1f
[   276.286] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.318] 	Entry deleted from font path.
[   276.481] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.511] 	Entry deleted from font path.
[   276.645] (**) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins,
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[   276.674] (**) ModulePath set to "/usr/lib/xorg/modules"
[   276.705] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[   276.734] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   276.765] (WW) Disabling Mouse0
[   276.795] (II) Loader magic: 0x55f4e523cd40
[   276.826] (II) Module ABI versions:
[   276.856] 	X.Org ANSI C Emulation: 0.4
[   276.887] 	X.Org Video Driver: 23.0
[   276.917] 	X.Org XInput driver : 24.1
[   276.947] 	X.Org Server Extension : 10.0
[   277.386] (II) xfree86: Adding drm device (/dev/dri/card0)

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok so i ended up with an unancipated reboot, which meant i had an
opportunity to test DRI3 and since setting Option DRI "3" in
xorg.conf i have *not* encountered a *single* lock-up, not with
chromium, nor glxgears, nor openscad.

far from being 100% reproducible when resizing glxgears under fvwm2
with DRI2, glxgears freezing is now 100% *un*reproducible.

so there is definitely a case to be said that this is a mesa / x11
bug, *not* an application-specific bug.

does anyone know how to move bugs to a different package?

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok i've raised this directly upstream with the mesa-dev team on
freedesktop.org and also done a little investigation, and found that
the processes are hanging waiting in a poll in libxcb.  the mesa-dev
team asked everyone who is affected *AND NOT* affected to report which
version of DRI is being used in their xorg.conf file (2 or 3) and also
which version of mesa is installed.

if that information could be sent here to 848895 then i can refer the
mesa-dev team to this bugreport.

i'm using DRI2 and mesa 13.0.6

btw if someone familiar with the debian bugtracker system could also
add the magic "control affects openscad" to this bugreport that would
be great.

l.

Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)

[Luke Kenneth Casson Leighton]

ok yes after using openscad consistently for several days now, i get
recurrence of this well-known behaviour quite frequently.  if i was to
put an arbitrary percentage on it, it would be about... 2% (1-in-50)
of every attempted move/rotate operation with the mouse.

anyway, main point of this bugreport is to alert you: it's not
openscad, it's definitely a dependency *of* openscad.

l.

Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)

[Luke Kenneth Casson Leighton]

hi chrysn,

i have an extremely powerful machine with 16gb of 2400mhz DDR4 RAM, 8-core i7
and a 2500mbyte/sec SSD.  speed is *not* a problem :)  a simple model easily
gives a framerate of appx 30fps.


however it is working really rather hard: i had openscad run with a
window @ 1940 x 1400
and was rotating the object round with the mouse for just over 30
seconds, possibly
longer.  one core jumped to a frequency of 2.27ghz and CPU usage was 50%.

i've just tried this again but could not reproduce it.

it *really* is a bit of a bitch i'm afraid.

two circumstances where it's *definitely* reproducible:

* current version of chrome browser when you're using the web-based
facebook "chat".
* resizing glxgears under fvwm2 (this one is 100%)

this latter causes fvwm2 to show a wire-frame only, during which time
the race condition is triggered instantly.

other circumstances are much much harder to reproduce, which is why
it's been well over a year, now, and this bug is still outstanding
(wherever it is).

sorry i couldn't give better news!

l.



On 3/28/17, chrysn  wrote:
> Hi,
>
> On Tue, Mar 28, 2017 at 01:56:21PM +0100, lkcl wrote:
>> the issue appears to be that a race condition causes a frame to be
>> dropped.  however once there is only one frame dropped, *all*
>> subsequent frames stop from that point onwards.
>
> that is a tricky one.
>
> I've tried to reproduce the issue with octave-gui as described in
> #848895 (even under full CPU load as "helped" with the chromium
> version), but it did not trigger a lockup on my machine.
>
> Are there any other known ways to trigger this (to find out which
> machines are affected at all), or to trigger this in OpenSCAD?
>
> Best regards
> chrysn
>

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ha, that's very interesting: since starting the chat with my friend on
facebook (a developer in china) for about 90 minutes i have had
*three* lockups (each time recoverable with ctrl-alt-f1, ctrl-alt-f7).
one in particular the cursor moved off-screen for a fraction of a
second and back again (which is enough to cause fvwm to move very
rapidly from one virtual desktop to the next, requesting a complete
refresh obviously)

now, it *happened* that, at the exact same time, chromium was again
hogging CPU resources.  it would appear that the increased CPU usage
is the "vulnerable to lock-up" time.

hmmm :)

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

haaa!  finally... after waiting for well over a week, at last!  the
bug *did* in fact reoccur.
just to make sure we're on the right page this is from the chrome://version

Chromium 56.0.2924.76 (Developer Build) built on Debian 9.0, running
on Debian 7.4 (64-bit)
Revision 314da7cc1e56fc9fa9271bac2b029922feb4b6f2

now, here's the circumstances:

* i was using facebook "chat" web variant (don't tell no-one in the
software libre world that, ok? :)
* CPU usage climbed *really* high - 3 processes each hit around 20%
and the CPU speed had to jump to around 2ghz to cope (fans came up)
* after flipping to a separate screen (i use fvwm) and returning
ta-d, freeze!

so whatever has been added that "fixes" the problem does NOT actually
fix the *ACTUAL* underlying race-condition / problem... it just avoids
*most* circumstances where it occurs... but not all.

l.

Bug#857552: i965-va-driver: failing to play videos (stops half-way through)

[Luke Kenneth Casson Leighton]

[off-topic for this bugreport, separate response later, much
appreciated the advice on mpv nicholas!]

On Wed, Mar 15, 2017 at 11:03 PM, Nicholas D Steeves  wrote:
> I noticed something strange in the original bug report:
>
>> > > On 2017-03-12 13:31:24, lkcl wrote:
>> > >> Package: i965-va-driver
>> > >> Severity: important
>> > >> Tags: upstream
>> > >>
>> > >> -- System Information:
>> > >> Debian Release: 7.4
>> > >>   APT prefers testing
>> > >>   APT policy: (500, 'testing'), (500, 'stable')
>> > >> Architecture: amd64 (x86_64)
>> > >> Foreign Architectures: i386
>
> Debian Release: 7.4 with i965-va-driver and kernel from Debian 9?
>
> Luke, I think your base-files needs to be upgraded ;-) Out of
> curiousity, does (as root) "echo n | apt-get dist-upgrade" want to
> upgrade anything?

 it's down to unusual circumstances (constant travel being one of
them).  i run with debian/testing, always have done, and, amazingly,
it works really well.  what's needed gets pulled in on an ad-hoc basis
through "apt-get install {arbitrary package}".  every few years i do a
hardware upgrade: i do a copy of the laptop's hard drive to the new
hard drive, and have repeated that about... errr... four times now :)

 basically i have far too much on here to risk doing anything else.
millions of files, software dating back 10 years.  i use fvwm2 which
is remaining "timeless" and doesn't have the context/snapshot-critical
dependencies that other desktops have.

 it's pretty unusual but works very very well... and is necessary to
minimise the risk of losing the only development machine that i have.

 :)

Bug#857552: i965-va-driver: failing to play videos (stops half-way through)

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Sun, Mar 12, 2017 at 7:01 PM, Sebastian Ramacher
 wrote:
> Control: tags -1 + moreinfo
>
> On 2017-03-12 13:31:24, lkcl wrote:
>> Package: i965-va-driver
>> Severity: important
>> Tags: upstream
>>
>> i'm getting a video stopping half-way through with the following errors
>> (reported under vlc):
> ...
>> [7f16c0d62ff8] avcodec decoder: Using Intel i965 driver for Intel(R) 
>> Skylake - 1.7.3 for hardware decoding.
>> [7f16c0c01978] mkv demux error: Dummy Element at unexpected position... 
>> corrupted file?
>> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced at 
>> 770798513... skipping to next upper element
>> [7f16c0c01978] mkv demux error: Dummy Element at unexpected position... 
>> corrupted file?
>> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced at 
>> 772666289... skipping to next upper element
>> [7f16c0c01978] mkv demux error: Dummy Element at unexpected position... 
>> corrupted file?
>> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced at 
>> 774009777... skipping to next upper element
>> [7f16c0c01978] mkv demux error: This element is outside its known 
>> parent... upping level
>> [h264 @ 0x7f16c0c3f460] co located POCs unavailable
>> [h264 @ 0x7f16c0c30420] co located POCs unavailable
>> [h264 @ 0x7f16c0c3f460] co located POCs unavailable
>> [h264 @ 0x7f16c0c30420] co located POCs unavailable
>> [h264 @ 0x7f16c0c30420] co located POCs unavailable
>
> Or is that a problem with the file?

 yes... but it certainly shouldn't just bomb-out like that (it's not a
corrupted file from being downloaded, it's a correctly-downloaded
confirmed uncorrupted download)

> Does the issue happen with every file or only that one?

 on occasion, several files (not all), but it's repeatable and at the
exact same place if it occurs.  so for example let's say that vlc
stops with the above error at 1m30s into the file, it's going to
happen *exactly* at that point *every* time *specifically* for that
file and that file only.

> Does it happen with any
> other video player (or when disabling hardware acceleration)?

 hmmm good points, i'll find out.  of course i'll have to set up hw
accel for other players... resource-hogging might make playback
difficult without hwaccel these are 720p files, quite
resource-intensive: just have to see how it goes.

l.

Bug#857552: Acknowledgement (i965-va-driver: failing to play videos (stops half-way through))

[Luke Kenneth Casson Leighton]

p.s. it's repeatable (stops at exactly the same point)

Bug#614296: xserver-xorg-video-intel: additional rendering corruption (screenshot included)

[Luke Kenneth Casson Leighton]

On Sat, Feb 25, 2017 at 3:54 AM, Luke Kenneth Casson Leighton
<l...@lkcl.net> wrote:
> is linux-kernel driver-related.  4.9.6 problem is gone.  bug may be closed.

 darn it, sorry - no it can't: bug is still present, encountered on
xpdf and gerbv.  rendering still corrupted and requires multiple
refreshes or attempts.

l.

Bug#614296: xserver-xorg-video-intel: additional rendering corruption (screenshot included)

[Luke Kenneth Casson Leighton]

is linux-kernel driver-related.  4.9.6 problem is gone.  bug may be closed.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Jan 27, 2017 at 7:37 AM, lkcl  wrote:
> Package: xserver-xorg-video-intel
> Version: 2:2.99.917+git20161105-1+b1
> Followup-For: Bug #614296
>
> this is a complex setup on very modern (skylake) hardware, so may actually
> be linux-kernel 4.8.11-related: am raising it here however.
>
> screenshot: http://hands.com/~lkcl/screen_corruption.png
>
>
>
>
> -- Package-specific info:
> X server symlink status:
> 
> lrwxrwxrwx 1 root root 13 Apr 17  2014 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 274 Nov 25 03:52 /usr/bin/Xorg
>
> Diversions concerning libGL are in place
> 
> diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
> diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
> glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by 
> glx-diversions
> diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
> by glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by 
> glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
> diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
> /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
> glx-diversions
> diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
> by glx-diversions
> diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
> glx-diversions
> diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
> glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
> diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
> glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
> diversion of /usr/lib/libGLESv1_CM.so to 
> /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGL.so to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
> diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
> /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
> diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
> diversion of /usr/lib/libGLESv1_CM.so.1 to 
> /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by 

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

On Thu, Feb 23, 2017 at 9:41 PM, Ximin Luo <infini...@debian.org> wrote:
> Luke Kenneth Casson Leighton:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87
>>
>> now ain't that fascinating.  optirun combined with fvwm2 is a
>> sure-fire extremely fast and 100% *guaranteed* way to repro this
>> "freezing but you can ctrl-alt-f1 then ctrl-alt-f7 and it miraculously
>> all works whoopidoo" problem.
>>
>> [..]
>
> Hi,
>
> I am not sure if primus is the problem. I don't have it installed.

 primus is an example of another application, like the many other
applications, where this underlying bug occurs for reasons as yet
unresolved.  we may therefore logically deduce that it's not a
chromium bug *per se* but is something to do with the dependencies
and/or interaction with the dependencies.

 the fact that running glxgears (or in fact *any* application -
openscad, vlc, *anything*) under optirun results pretty much
immediately (i.e. within seconds or minutes) in this bug being
reproduced is itself fascinating and also a useful setup for working
out what the hell is going on.

> In fact when I had the bug (on chromium 55.0.2883.75-6) I was using the free 
> nouveau drivers, not the nvidia drivers.

 from scanning the various responses it seems not to matter precisely
which underlying GPU hardware is used.  you're using nvidia, or
nouveau, others have reported different GPUs: it's not the GPU
*itself* which is the problem.


> I am now using the nvidia drivers with the same chromium version, and I have 
> not seen the bug for a few days. But if you do see it with nvidia drivers, 
> then something else must be the actual problem.

 it's not chromium itself that is the problem.  i can run "optirun
glxgears" then move / resize the window and it freezes.  therefore we
*know* that it's going to reoccur with chromium.

> I haven't yet tried 56.0.2924.76-4 that Michael says is fixed. BTW he has 
> closed the bug report #848895, I did not get a notification about this and I 
> only noticed when visiting the bug report web page. If any of you can 
> reproduce the bug with version 56.0.2924.76-4 please let us know so we can 
> re-open the bug.

prediction with 95% confidence: you'll need to reopen the bug.  the
remaining 5%, if it *has* been "fixed" with some form of workaround,
it should be very well documented *exactly* how, so that other
software can deploy the exact same "fix".  also the xorg team can be
alerted as there might be something that they can do which stops this
(endemic) bug from affecting other applications.

remember it's *not* just chromium that's affected.


 root@fizzy:/home/lkcl# apt-get install chromium
Reading package lists... Done
Building dependency tree
Reading state information... Done
chromium is already the newest version (55.0.2883.75-6).

so it's not hit debian/testing yet.  i'll wait another week until it does.

l.

Bug#855557: Acknowledgement (primus: gl framedropping isn't handled correctly, apps need a restart to recover)

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848895

fascinating.  seems to be related.  using ctrl-alt-f1 followed by
ctrl-alt-f7 "fixes" the problem.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, Feb 20, 2017 at 3:45 AM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian NVIDIA Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 855...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 87: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87

now ain't that fascinating.  optirun combined with fvwm2 is a
sure-fire extremely fast and 100% *guaranteed* way to repro this
"freezing but you can ctrl-alt-f1 then ctrl-alt-f7 and it miraculously
all works whoopidoo" problem.

primus (and optirun) is a headless gpu thingy where you have a main
CPU/GPU which actually does the screen writing, then you have a
*second* xorg server running (this time into a framebuffer) which you
have a *second* GPU writing to, where OpenGL is told to use the
*second* GPU's acceleration libraries, then primus takes care of
dropping the resultant frame(s) into the *first* xorg's screenspace.

fascinatingly it's very very easy to make primus/optirun "hang" under
fvwm2: all you need to do is resize the window: that results in a
wireframe, then primus goes into a *permanent* loop "primus: warning:
dropping a frame to avoid deadlock"

which is clearly where chromium is obviously going wrong: it's *not*
doing the required "frame dropping" and is (surprise!) ending up
in deadlock.

now, the hardware shouldn't *BE* getting into deadlock in the first
place, and chromium shouldn't *BE* relying on the hardware to quotes
get itself out of deadlock quotes, but that's beside the point.

this all seems to be, then, a series of overlapping cross-project
errors, each inter-related.  hardware shouldn't *be* failing but it
is.  xorg shouldn't *be* deadlocking due to those hardware-related
errors but it is.  chromium and other programs shouldn't *be*
deadlocking because xorg is deadlocking... but they are.

l.

Bug#855558: linux-image-4.9.0-1-amd64: ACPI boot error causes /sbin/init to segfault (!)

[Luke Kenneth Casson Leighton]

faakin 'ell :)  woo, ok.  setting acpi_os_name="Windows 2009" and also
removing vesafb from /etc/initramfs-tools/modules resulted in a boot
(attaching dmesg boot which contains two ACPI-related kernel-level
warnings).
sorry it's an attachment rather than inline.  i don't know if it was
the setting acpi_os_name or removing vesafb that caused the successful
boot - i'll try one without the other on next boot and report if it
makes a difference

the ACPI bug still came up at startup time but it was followed by
"Firmware Bug BIOS _OSI(Linux) query ignored" and no "could not
execute /init".  which is good :)

[0.810439] ACPI Error: No handler for Region [ECF2]
(9d30ee0e89d8) [EmbeddedControl] (20160831/evregion-166)
[0.810456] ACPI Error: Region EmbeddedControl (ID=3) has no
handler (20160831/exfldio-299)
[0.810469] ACPI Error: Method parse/execution failed
[\_SB.PCI0.LPCB.EC._REG] (Node 9d30ee0ea820), AE_NOT_EXIST
(20160831/psparse-543)
[0.814994] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

only by setting OSI to "Windows 2009" would it boot.   setting to
Windows 2001, or 2012, or 2015, all failed.  suggestion is from here:
https://wiki.archlinux.org/index.php/DSDT

mwaa this is scary as hell to have such an expensive ridiculously
high-spec'd machine, and it going wrong like this :)  but... it's up.
once i know it's stable (ish) for a couple days that 4.8.0 bug can be
closed, ben.

thanks for prompting me to investigate further.


f
Description: Binary data

Bug#855558: linux-image-4.9.0-1-amd64: ACPI boot error causes /sbin/init to segfault (!)

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Feb 22, 2017 at 12:06 PM, Ben Hutchings  wrote:
> Control: retitle -1 linux-image-4.9.0-1-amd64: Failed to execute /init
> Control: tag -1 moreinfo
>
> On Mon, 20 Feb 2017 04:00:03 + lkcl  wrote:
>> Package: src:linux
>> Version: 4.9.6-3
>> Severity: important
>> Tags: upstream
>>
>> this is a very recent (skylake) very expensive laptop with an intel core i7
>> full report is here, with a link (at the bottom of the report) to
>> hardware info:
>> http://lkcl.net/reports/aorus_x3_plus_v6.html
>>
>> it includes some information not listed below in the usual automated
>> info-collection (below)
>>
>>
>> i cannot boot the 4.9.0 kernel because of a segfault on /sbin/init.
>> a screenshot is here:
>> http://hands.com/~lkcl/IMG_20170220_1127225_rewind.jpg
> [...]
>
> I see no segfault.  I do see:
>
> "Failed to execute /init (Error -2)"
>
> That would be "file not found".

 ah!  i didn't see that - i focussed on the first error.

> Is this a standard initramfs built by
> initramfs-tools?

 it is indeed.  the only thing i've been forced to do is specify a
hard-coded list of modules because "all" gives an INSANE 200mybte
initramfs - something i've never encountered before and the only
reason it loaded so quickly is because this is an NVMe SSD with a
staggering 2500 Mbyte/sec read speed (yes, really - 2.5gbyte/sec!) - i
didn't feel comfortable with that so cut it down to "most", which
failed so i hard-coded a list after doing "lsmod" and that worked
fine.  that's the *only* difference.

lkcl@fizzy:~$ dpkg -l | grep initramfs
ii  initramfs-tools   0.127
   all  generic modular initramfs generator
(automation)
ii  initramfs-tools-core  0.127
   all  generic modular initramfs generator (core
tools)
ii  libklibc  2.0.4-9
   amd64minimal libc subset for use with initramfs


>  Can you check whether /init and /bin/sh are included
> in it, using the "lsinitramfs" command?

 root@fizzy:/boot# lsinitramfs initrd.img-4.9.0-1-amd64  | grep init
scripts/init-bottom
scripts/init-bottom/udev
scripts/init-bottom/ORDER
scripts/init-top
scripts/init-top/blacklist
scripts/init-top/all_generic_ide
scripts/init-top/udev
scripts/init-top/ORDER
scripts/init-top/keymap
bin/run-init
sbin/init
init
conf/initramfs.conf

root@fizzy:/boot# lsinitramfs initrd.img-4.9.0-1-amd64  | grep sh
bin/sha512sum
bin/sha1sum
bin/sh
bin/sha256sum
bin/ash
lib/modules/4.9.0-1-amd64/kernel/arch/x86/crypto/ghash-clmulni-intel.ko
lib/modules/4.9.0-1-amd64/kernel/drivers/md/dm-snapshot.ko
lib/modules/4.9.0-1-amd64/kernel/drivers/md/dm-region-hash.ko
lib/modules/4.9.0-1-amd64/kernel/drivers/pci/hotplug/shpchp.ko

hmmm, they are indeed.  so we are left with the perplexing /
paradoxical interpretation that *trying* to run /init results in
that... oh wait: look at line 5: it says "Method parse/execution
failed"

i bet you that's related to the "failed to run /init".  i'll do some
google searches on that and see what i can find.

l.

Bug#855558: linux-image-4.9.0-1-amd64: ACPI boot error causes /sbin/init to segfault (!)

[Luke Kenneth Casson Leighton]

http://www.linuxquestions.org/questions/linux-from-scratch-13/acpi-errors-when-booting-927408/

ah christ almighty, they're talking about "updating the bios fixes the
problem" *sigh*.

3.16, 4.7 and 4.8 are all fine - so wtf is 4.9 doing not being capable
of running /init when all prior version can...

https://forum.manjaro.org/t/acpi-error-on-boot-after-updating-to-4-9/12894/9

argh, wtf https://wiki.archlinux.org/index.php/DSDT

!! :)

wtf??? apparently you can fix ACPI DSDT errors by disassembling the
acpi table, hand-ending the bastard thing and recompiling it.

this is a $USD 2,600 laptop.  i don't fink i will be doin that.

i'll try the trick of setting acpi_os_name to see if it tricks the
ACPI BIOS into going via a different codepath.

l.

Bug#855818: linux-image-4.8.0-2-amd64: segfault in intel 9815 drm kernel module

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Feb 22, 2017 at 2:38 AM, Ben Hutchings  wrote:
> Control: tag -1 - upstream
> Control: tag -1 moreinfo
>
> On Wed, 2017-02-22 at 01:45 +, lkcl wrote:
>> Package: src:linux
>> Version: 4.8.15-2
>> Severity: normal
>> Tags: upstream
>>
>> not sure what's going on, or why.  reporting as-is fyi.  can't upgrade
>> to 4.9 due to other issues (also reported)
>
> We don't support 4.8 any more; let us know when you're able to test on
> 4.9.

 i would if it was possible, but i can't, ben:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=88

 that's a severity "important".  total boot failure.  segfault running
/init from the initramfs, a DMAR ACPI error accessing the PCIe bus
0xf0:1f.0 which doesn't actually exist.

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

btw fyi https://bugs.chromium.org/p/chromium/issues/detail?id=675411

i noted a vast and i mean constant monotonous barely-tolerable number
of gpu freezing errors when operating inside of china.  i therefore
suspect that this is a race condition between networking code and the
gpu code.

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ah ha!  when i did the latest "kill" i got this:

 [11121:11121:0207/112924:ERROR:gpu_process_transport_factory.cc(844)]
Lost UI shared context.

Bug#848895: chromium: still freezing randomly but usually on changing virtual screens

[Luke Kenneth Casson Leighton]

oky, finally: yes, i can confirm that killing the gpu-process (ps
aux | grep gpu) will make things "work" again... without actually
having to kill off the entire chromium browser.

examples where hanging occurred include PDF viewing (where, clearly,
the GPU was asked to do the rendering).  just killing the process
--type=gpu-process resulted in the browser recovering from its "hang",
leaving a blank part in the middle where the PDF should be.  a simple
"scroll" operation resulted in things going back to normal.

the full set of options (the process that needed killing) is below.

context: this is an extremely powerful skylake-based system (i7) with
a headless nvidia 1050 GPU which should NOT be being used... but might
be, if you look closely at the options of the gpu-process, below i
think it's saying because "support-dual-gpus=false" that the answer
really is "no, the NVIDIA headless GPU is not being used"... but
you'll have to check that (ask me if you need info or commands to be
run).

however i can *definitely* confirm that i am *NOT* running chromium
through optirun (bumblebeed / primus).



00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06) (prog-
if 00 [VGA controller])
DeviceName:  Onboard IGD
Subsystem: Gigabyte Technology Co., Ltd Device 3457
Flags: bus master, fast devsel, latency 0, IRQ 139
Memory at dd00 (64-bit, non-prefetchable) [size=16M]
Memory at b000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: 
Kernel driver in use: i915


01:00.0 VGA compatible controller: NVIDIA Corporation Device 1c20 (rev a1) (prog
-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device 3457
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at de00 (32-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at d000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at df00 [disabled] [size=512K]
Capabilities: 
Kernel driver in use: nvidia


 6679 pts/2Sl 0:31 /usr/lib/chromium/chromium
--type=gpu-process
--enable-features=AutofillCreditCardSigninPromo

Bug#848895: chromium: still freezing randomly but usually on changing virtual screens

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Jan 24, 2017 at 5:44 PM, lkcl  wrote:
> Package: chromium
> Version: 55.0.2883.75-3
> Followup-For: Bug #848895
>
> (hi!  note: after the other bug in which virtualbox was being a pain i removed
> virtualbox and upgraded to latest testing)
>
> this randomly-freezing issue has been around for a considerable time,
> and is reproducible albeit on a 2-3 day basis.
>
> i run with about 20-30 tabs open (10x that many in firefox) and i've noticed
> that chromium stops updating the screen after returning to it from an
> alternative virtual screen with fvwm2.
>
> now, that's *not* when i return and click *on* chromium (or, more 
> specifically,
> move the mouse over it - i've set up fvwm2 to use "mouse move to highlight")
> that really is: just come back to a different virtual screen, to find that
> it's simply... hung and is no longer responding to X11 events... at all.
>
> interestingly the CPU usage is absolutely minimal.
>
> i'm currently going through the list of processes killing them one by
> one to see if that helps...
>
>
>
> -- System Information:
> Debian Release: 7.4
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.8lkcl (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages chromium depends on:
> ii  libasound2   1.1.2-1
> ii  libatk1.0-0  2.18.0-1
> ii  libavcodec57 10:3.2.2-dmo3
> ii  libavformat5710:3.2.2-dmo3
> ii  libavutil55  10:3.2.2-dmo3
> ii  libc62.23-4
> ii  libcairo21.14.8-1
> ii  libcups2 2.2.1-6.0nosystemd1
> ii  libdbus-1-3  1.10.14-1.0nosystemd1
> ii  libevent-2.0-5   2.0.19-stable-3
> ii  libexpat12.2.0-1
> ii  libflac8 1.3.1-4
> ii  libfontconfig1   2.11.0-6.7
> ii  libfreetype6 2.6.3-3+b1
> ii  libgcc1  1:6.2.1-5
> ii  libgdk-pixbuf2.0-0   2.36.0-1
> ii  libglib2.0-0 2.50.1-1
> ii  libgtk2.0-0  2.24.29-1
> ii  libharfbuzz0b1.2.7-1+b1
> ii  libicu57 57.1-5
> ii  libjpeg62-turbo  1:1.5.1-2
> ii  libminizip1  1.1-8
> ii  libnspr4 2:4.12-2
> ii  libnss3  2:3.26-2
> ii  libpango-1.0-0   1.38.1-1
> ii  libpangocairo-1.0-0  1.38.1-1
> ii  libpng16-16  1.6.26-6
> ii  libpulse09.0-5.0nosystemd1
> ii  libre2-3 20170101+dfsg-1
> ii  libsnappy1v5 1.1.3-3
> ii  libstdc++6   6.2.1-5
> ii  libvpx4  1.6.0-3
> ii  libwebp6 0.5.1-2
> ii  libwebpdemux20.5.2-1
> ii  libx11-6 2:1.6.4-2
> ii  libx11-xcb1  2:1.6.4-2
> ii  libxcb1  1.12-1
> ii  libxcomposite1   1:0.4.4-1
> ii  libxcursor1  1:1.1.14-1+b1
> ii  libxdamage1  1:1.1.4-2+b1
> ii  libxext6 2:1.3.3-1
> ii  libxfixes3   1:5.0.3-1
> ii  libxi6   2:1.7.8-2
> ii  libxml2  2.9.4+dfsg1-2.1
> ii  libxrandr2   2:1.5.1-1
> ii  libxrender1  1:0.9.10-1
> ii  libxslt1.1   1.1.29-2
> ii  libxss1  1:1.2.2-1
> ii  libxtst6 2:1.2.3-1
> ii  x11-utils7.7+3
> ii  xdg-utils1.1.0~rc1+git20111210-7
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> Versions of packages chromium recommends:
> ii  fonts-liberation  1.07.3-3
>
> Versions of packages chromium suggests:
> pn  chromium-l10n  
>
> -- no debconf information

Bug#848895: chromium: still freezing randomly but usually on changing virtual screens

[Luke Kenneth Casson Leighton]

On Tue, Jan 24, 2017 at 5:44 PM, lkcl  wrote:
> Package: chromium
> Version: 55.0.2883.75-3
> Followup-For: Bug #848895

> i'm currently going through the list of processes killing them one by
> one to see if that helps...

 ah ha!  it does.  okay so *one* of the processes is causing a lock-up
of all the others.  finally after issuing "kill {PID}" in succession
on the (20) highest PIDs, *eventually* i got chromium back with 15
"aw snap" tabs... :)

 i can't tell you which one actually was responsible for the problem
unless there's a way to find out which process is responsible for
which URL.

 if you know how i can always run the exercise again... WHEN it
happens again (not if)

l.

Bug#851984: dpkg failing with "locked by another process" on apt-get build-dep

[Luke Kenneth Casson Leighton]

On Sun, Jan 22, 2017 at 12:17 PM, Guillem Jover  wrote:
> Control: forcemerge 850417 -1
>
> Hi
>
> On Fri, 2017-01-20 at 15:26:19 +, lkcl wrote:
>> Package: dpkg
>> Version: 1.18.18
>> Severity: important
>
>> weirdest bug i've encountered on debian, yet, in 12 years!
>> simply running "apt-get build-dep blender" causes the
>> /var/lib/dpkg/lock file to exist during *and after*
>> the completion of that command:
>
> This file always exists.
>
>> The following NEW packages will be installed:
>>   libalut-dev libalut0 libass9 libavdevice-dev libavfilter-dev 
>> libavformat-dev
>>   libavresample-dev libboost-filesystem-dev libboost-filesystem1.62-dev
>>   libboost-locale-dev libboost-locale1.62-dev libboost-regex-dev
>>   libilmbase-dev libjbig-dev libjemalloc-dev liblzma-dev libopenal-dev
>>   libopencolorio-dev libopenexr-dev libopenimageio-dev libopenimageio-doc
>>   libopenjp2-7-dev libopenvdb-dev libpostproc-dev libspnav-dev libtbb-dev
>>   libtiff5-dev libtiffxx5 opencollada-dev python3-chardet python3-requests
>>   python3-six python3-urllib3
>> The following packages will be upgraded:
>>   libavdevice57 libavfilter6 libavformat57 libopenexr22 libpostproc54
>>   libswscale-dev libswscale4
>> 7 upgraded, 33 newly installed, 0 to remove and 1566 not upgraded.
>> Need to get 0 B/13.6 MB of archives.
>> After this operation, 111 MB of additional disk space will be used.
>> Do you want to continue? [Y/n] y
>> Reading changelogs... Done
>> Extracting templates from packages: 100%
>> dpkg: error: dpkg status database is locked by another process
>> E: Sub-process /usr/bin/dpkg returned an error code (2)
>> E: Failed to process build dependencies
>>
>> no, there is no other command running that locks the database.
>>
>> if i do "rm /var/lib/dpkg/lock" and run "apt-get install libadvdevice57"
>> for example it's absolutely fine: no problems.
>
> This should never *ever* be done:

 well, it's the only thing that fixed the problem.

>   
> 
>
> I guess you run something like lsof on the lockfile to see if anything
> was keeping a lock?

 of course.  and fuser.  there were absolutely no processes, programs,
users, or any output of any kind, produced by *either* lsof *or*
fuser.


>> the moment apt-get build-dep  is used, splat.
>
> Is this always reproducible?

 it is 100% reproducible.

>> i'm including a complete list of all software packages (and versions)
>> as this is really rather important, this one!  the workaround is to manually
>> list (and install) all the packages listed by apt-get build-dep.
>
> There is probably something else that has run a dpkg instance,

 there is not.

> or has
> locked the dpkg lock meanwhile.

 there is not.

 unfortunately, once the lock file is made, despite there being
*absolutely no* other programs running, i cannot use apt-get, aptitude
or dpkg... period.  the *only* way which allows me to continue is to
remove the lock file.


> These have started appearing in recent
> times (see the merged bug). So, while I don't think this is a problem
> in dpkg, as we do not know what is triggering this, I have no clue where
> to reassign to.

 yeah me neither: however it was important enough to at least list
for... something.

> My instinct tells me something apt related, but no
> idea really. :(
>
> Something has probably started running dpkg or apt commands asynchronously
> somewhere?

that's a perfectly reasonable suggestion to make...  this is a
single-user system... it doesn't quite fit the symptoms of only
occurring with "apt-get build-dep" but not occurring with "apt-get
install"...

i'll run an strace -ff -o log.txt and see what happens.

l.

Bug#851984: dpkg failing with "locked by another process" on apt-get build-dep

[Luke Kenneth Casson Leighton]

upgraded to apt 1.4~beta3 and the problem's "gone away".  so, this bug
can be closed but can i suggest (i don't know how to do it myself,
guillem) reassigning it to apt... and *then* closing it, so that
there's a proper record associated with the right program, in case
someone also encounters this same bug over the next few weeks/months?

l.

Bug#851984: dpkg failing with "locked by another process" on apt-get build-dep

[Luke Kenneth Casson Leighton]

htttp://hands.com/~lkcl/dpkg_strace_851984_bug.tgz

ah.  we now have a candidate for a reassign: after doing that strace i
tried doing "apt-get install libavdevice57" (one of the dependencies
of blender) and that *worked*.  so, it's *only* when doing "apt-get
build-dep" that the dpkg bug-out occurs making this *not* a dpkg
bug but something related to apt-get.

which i'll now upgrade...

... and test again.

l.

Bug#851179: closed by Michael Gilbert <mgilb...@debian.org> (re: chromium: dependency conflict)

[Luke Kenneth Casson Leighton]

it appears that there isn't a version of virtualbox from debian-testing.

root@fizzy:/home/lkcl# apt-cache show virtualbox
Package: virtualbox
Version: 4.3.36-dfsg-1+deb8u1
Installed-Size: 56553
Maintainer: Debian Virtualbox Team

Architecture: amd64
Depends: adduser, python (<< 2.8), python (>= 2.7~), python2.7,
python:any (>= 2.7.5-5~), libc6 (>= 2.15), libcurl3-gnutls (>=
7.16.2), libgcc1 (>= 1:4.1.1), libgsoap5, libpng12-0 (>= 1.2.13-4),
libpython2.7 (>= 2.7), libsdl1.2debian (>= 1.2.11), libssl1.0.0 (>=
1.0.0), libstdc++6 (>= 4.9), libvncserver0 (>= 0.9.9), libvpx1 (>=
1.0.0), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxml2 (>=
2.7.4), libxmu6, libxt6, zlib1g (>= 1:1.1.4), virtualbox-dkms (>=
4.3.36-dfsg-1+deb8u1) | virtualbox-source (>= 4.3.36-dfsg-1+deb8u1) |
virtualbox-modules
Recommends: virtualbox-qt (= 4.3.36-dfsg-1+deb8u1), libgl1-mesa-glx |
libgl1, libqt4-opengl (>= 4:4.5.3), libqtcore4 (>= 4:4.5.3), libqtgui4
(>= 4:4.5.3)
Suggests: vde2, virtualbox-guest-additions-iso
Conflicts: virtualbox-2.0, virtualbox-2.1, virtualbox-2.2,
virtualbox-3.0, virtualbox-3.1, virtualbox-3.2, virtualbox-4.0,
virtualbox-4.1, virtualbox-4.2, virtualbox-4.3, virtualbox-5.0
Description-en: x86 virtualization solution - base binaries
 VirtualBox is a free x86 virtualization solution allowing a wide range
 of x86 operating systems such as Windows, DOS, BSD or Linux to run on a
 Linux system.
 .
 This package provides the binaries for VirtualBox. Either the virtualbox-dkms
 or the virtualbox-source package is also required in order to compile the
 kernel modules needed for virtualbox. A graphical user interface for
 VirtualBox is provided by the package virtualbox-qt.
Description-md5: 30f96d22c1a6ca04db16bdc1e79ad965
Homepage: http://www.virtualbox.org/
Tag: hardware::emulation, implemented-in::c, interface::x11, role::program,
 scope::application, uitoolkit::qt, uitoolkit::sdl, x11::application
Section: contrib/misc
Priority: optional
Filename: pool/contrib/v/virtualbox/virtualbox_4.3.36-dfsg-1+deb8u1_amd64.deb
Size: 13465384
MD5sum: 600eca648bb6819de5e6683e77614d98
SHA1: b8d62ea34818a3ac82780b1549ad0ae2df810750
SHA256: 5d18a18000ebc312ae5f01d9a64c5d652dcbc535e3c27d92b289c402c2df8e86


---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Sat, Jan 14, 2017 at 7:51 PM, Debian Bug Tracking System
 wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the chromium package:
>
> #851179: chromium: dependency conflict
>
> It has been closed by Michael Gilbert .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Gilbert 
>  by
> replying to this email.
>
>
> --
> 851179: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851179
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Michael Gilbert 
> To: 851179-cl...@bugs.debian.org
> Cc:
> Date: Sat, 14 Jan 2017 14:49:17 -0500
> Subject: re: chromium: dependency conflict
> The conflict is correct.  The problem is that you have a mixed system
> with chromium from testing and virtualbox from stable.  You should
> either choose both from stable, or both from testing.
>
> Best wishes,
> Mike
>
> -- Forwarded message --
> From: lkcl 
> To: Debian Bug Tracking System 
> Cc:
> Date: Thu, 12 Jan 2017 19:06:22 +
> Subject: chromium: dependency conflict
> Package: chromium
> Version: 53.0.2785.143-1
> Severity: important
>
> best illustrated as follows:
>
> # apt-get install chromium virtualbox
>
> virtualbox is already the newest version (4.3.36-dfsg-1+deb8u1).
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  chromium : Conflicts: libnettle4 but 2.7.1-5+deb8u1 is to be installed
> E: Unable to correct problems, you have held broken packages.
>
>
>
> -- System Information:
> Debian Release: 7.4
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.8lkcl (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages chromium depends on:
> ii  libasound2   1.1.2-1
> ii  libatk1.0-0  2.18.0-1
> ii  libavcodec57 10:3.2-dmo1
> ii  libavformat5710:3.2-dmo1
> ii  libavutil55  

Bug#824848: xchat current debian/testing is out-of-date and specifically depends on libperl5.20

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, May 25, 2016 at 1:14 PM, Andreas Beckmann  wrote:
> Hi,
>
> On Fri, 20 May 2016 12:48:28 +0100 lkcl  wrote:
>> currently having to manually rebuild xchat (which is possible thanks to
>> all the source being available, yay!) because it has a critical dependency
>> on libperl5.20 (or whatever it happened to be built on)
>
> xchat has been removed from testing and unstable since it unmaintained
> upstream,

 argh!  it actually works!  unmaintained _can_ mean "it's so stable
that it doesn't need maintaining"... but there's a fork... so..

> see https://bugs.debian.org/811007 for details.
> xchat has been superseded by the actively maintained fork "hexchat",
> which is available in Debian since jessie.

... hexchat seems to recommend gvfs (which is part of gnome, which i
don't want).  fortunately it's possible to do "apt-get
--without-recommends install hexchat"

> If you think there should be a transitional xchat package in stretch to
> pull in hexchat on upgrades, please file a bug against hexchat.

 ack.

> I also tested rebuilding xchat from jessie in both sid and jessie
> environments (via pbuilder) and didn't see any "artefacts" (like /DEBIAN
> directories in the filesystem root of the generated packages), therefore
> I'm closing this bug report now. Maybe something in your build
> environment is/was broken.

 it's a continually-upgraded debian/testing system so... yeah quite likely :)

 thanks for the info, andreas.

l.

Bug#806670: rotation is dragging

[Luke Kenneth Casson Leighton]

On Thu, Jan 7, 2016 at 9:47 PM, Torsten Paul  wrote:

> That basically sums up the reports so far. On my system I can
> reproduce the issue with debug builds, but not with release builds.

 right - i have a possible explanation for that.  if there are two
threads now in qt5, one handling mouse-events and the other handling
draw-events, if the draw events are *too slow*, then the mouse events
get stuffed into the system, queue up and flood the application with
redraws.

 sooo... a debug build would, on *your* system, be slower thus the
redraws would take longer... thus you would see the problem.  but,
when you do a release build, it's much much quicker... problem goes
away.

 the reason why i'm seeing this using the models that i'm working with
even on release builds is because the models are so fricking complex
that i'm looking at SECONDS per frame.  yes, really SECONDS to do a
single frame, and yes that's genuinely hardware OpenGL not software
opengl.  to develop the applications i'm doing, i have to code in some
special "comment out sections of the model" booleans, so that i can at
least get down to a manageable 2 fps (yes, really - *two* frames per
second is the compromise i have to work with).

so if you have a really really fast desktop system with a high-end
NVidia or Radeon graphics with 768Mb or 1gb of RAM and/or a
not-so-complex model where the refresh rate is a hundred frames per
second, you are pretty much guaranteed *never* to see this problem:
the rate at which mouse-events are generated will never, ever stack up
to overwhelm such monstrously-fast systems (or such simple models).

 does that make sense, and fit with the observed incidents seen so far?

 the solution is to have a boolean or a semaphore around the redraw
and the mouse-event logic.  on redraw completion, you free the
semaphore.  just before redraw, you set it.  when there's a
mouse-event, you don't immediately call "redraw", you check to see if
one's in progress (because the flag will be set), instead you set a
"redraw is needed" flag.  after the redraw completes, you check that
"another redraw is needed" flag.  if it is, you clear it and... do
another redraw.

you would, obviously, still need to adjust the positions (rotation) of
what's being rotated on each mouse-event.  on each mouse-event you
would still accumulate the amount of "rotation" (or movement) you
just wouldn't actually do the "draw" because the computer is still
busy doing one.

 as it's extremely likely that qt5 uses separate threads, you might
need mutex's instead (round the various flag-setting and clearing) but
you get the general idea.

 not knowing if it's true or not, but if qt4 is a single-threaded
design, the reason the problem wouldn't occur would be because the
mouse-events would stack up *externally* (in X11) and, in between
redraws, i assume that qt4 (or X11) amalgamates multiple mouse-moves
into a single mouse-move something like that.

 GUI design is harder than people realise! :)

l.

Bug#820729: openscad: chris palmer's mendel90 openscad scripts cause a compile failure

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, Apr 11, 2016 at 8:43 PM, Torsten Paul  wrote:
> On 04/11/2016 08:15 PM, lkcl wrote:
>> Debian Release: 7.4
>>
> That's Wheezy which has OpenSCAD 2011.12-3, right?

 sorry, the meta-tag information is misleading.  i'm running
debian/testing, i just never do "apt-get dist-upgrade", i just
continue to do "apt-get update" followed by "apt-get install
{randompackage}" and let whatever dependencies are needed get dragged
in.  done that for over 10 years, now, only very occasionally run into
problems.

 in this case, what i did was, for an earlier bugreport (the one about
compiling with libqt4), i did "apt-get source openscad" - this was
what... mm. 2 months ago?, and compiled up manually.

 that version was, if i recall, dated 2016-01.  now, i spoke to chris,
and he has i believe a more recent version - a "stable" release of
openscad - and it works.  he did wonder where i got the odd version
from, i forgot to mention to him it was a debian/testing release.  so,
anyway, it looks like there's a bug that went into the 2016-01 version
which was pulled for the current debian/testing release.

l.

Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

[Luke Kenneth Casson Leighton]

simon, hi, many apologies for not following up: my friend running the
server discovered, after around 18 months of puzzled investigation,
that he had (or perhaps had not) added a certain critical
system-required file to .gitignore as part of the upgrade to
gitolite3.  exact details are hard to remember (plus it wasn't me
doing the investigating) but this was very obscure, but finally
solved.

the typical ikiwiki git arrangement was as you described.  although it
would only be a kludge, the "manual recovery" i propose(d) would be an
"rm -fr * and a git clone", or a "git reset --hard".  this would at
least permit people in similar circumstances to at least run a
functioning web site from a remote laptop whilst there was a sysadmin
(2nd person) who could only respond on a delayed schedule.

l.

Bug#806670: rotation is dragging

[Luke Kenneth Casson Leighton]

On Thu, Jan 7, 2016 at 9:25 PM, chrysn <chr...@fsfe.org> wrote:
> On Thu, Jan 07, 2016 at 06:36:07PM +0000, Luke Kenneth Casson Leighton wrote:
>> On Thu, Jan 7, 2016 at 6:00 PM, lkcl <l...@lkcl.net> wrote:
>>
>> > so what i'm going to do is to find an older version of the openscad source
>> > code, compile that up and use it.  i had a version that used to work, from
>> > source, before openscad was added to debian, it will do the job.
>>
>>  right.  i've just done exactly that: compiled up the version that i
>> had previously checked out:
>>  commit 21c8d2fc98723ba1e10b7066e1f203444f5e83f3
>> Author: Marius Kintel <mar...@kintel.net>
>> Date:   Sun Mar 9 15:04:07 2014 -0400
>
> hm ... i was just going to bisect this, but when i checked out that very
> version and built it directly from git, i saw the same dragging.
>
> my installed libraries are generally a little newer than what you
> reported before, but then again, if the old version works for you and
> the new one doesn't, it's hard to figure why the old doesn't work for
> me.

 the possibility exists that the pseudo-code loop previously mentioned
exists in qt5 rather than actually in openscad.  if qt5 has been
"updated" without the knowledge of the upstream authors they could
have been caught off-guard.

 in particular, if qt5 has changed in some way such that it now has an
extra background thread to handle mouse/keyboard events, for example,
then that would explain the current behaviour.

 so, assuming that the event-handling in openscad has *always* been of
the form "case MOUSE_EVENT: do_opengl_redraw()" and that ended up
_blocking_ previously, such that the underlying qt5 code couldn't
*generate* mouse-events until the opengl rendering had completed, then
that would be absolutely fine.

 but, obviously, if qt5 has changed (become multi-threaded) such that
it _does_ now generate exactly one opengl redraw per mouse-event, that
would explain the change in behaviour

 the solution then would be to add in some bool values that monitor
the completion status of the redraw, which allow communication between
"case MOUSE_EVENT" and opengl_draw rendering

> luke, could you, for comparison, on the system where the new .deb
> dragged and the fresh 21c8d2fc9 (that's openscad-2014.03, by the way)
> build worked, build the current master as well?

 sure.  previously was using gitorious now url =
git://anonscm.debian.org/collab-maint/openscad.git  compile under
way y gods, loadavg over 10 at one point, one of those c++
files is waaay too large, that's going to hammer some of the build
machines esp. the arm ones which only typically have 1gb or 2gb of
RAM...

 l.

Bug#806670: rotation is dragging

[Luke Kenneth Casson Leighton]

On Thu, Jan 7, 2016 at 9:47 PM, Torsten Paul  wrote:
>> torsten, can you make anything of this? (lkcl's messages in full at 
>> http://bugs.debian.org/806670)
>>
> Yes, the event handling is likely the root cause of the issue, but
> the exact same code works fine with Qt4 and in some cases also with
> Qt5.
> There were a number of issues in Qt5 that caused problems, but
> according to their bug tracker those are fixed (basically
> https://github.com/openscad/openscad/blob/master/src/openscad.cc#L722)

 // The default SwapInterval causes very bad interactive behavior as
 // waiting for the buffer swap seems to block mouse events. So the

 clearly, by stating this, the upstream authors are, i have to be
absolutely frank here, blithering idiots.  "waiting for the buffer
swap" - which i infer and assume means that there's a means by which
it's possible to detect when the opengl rendering has completed - is
PRECISELY the behaviour that's required, without which you get exactly
the EVEN WORSE behaviour of having one mouse-event generate exactly
one redraw event all of which back up in a logjam that totally
overwhelms even a dual-core 2.4ghz system with 8gb of RAM and nvidia
hardware acceleration.

 it would appear then that the upstream authors assume that end-users
are using openscad to make absolutely tiny models (including
themselves), and that they've likely never encountered anyone using
openscad with .scad files of over 1,000 lines of source code before.

 if they had, they would have gone "my god this is totally
intolerable, we have to change our assumptions and expectations about
what's acceptable: maybe a 60fps or greater rendering target wasn't so
realistic of us, after all".

 in rendering some of these incredibly complex objects, i'm *really
happy* if i get 3-4 frames per second, and if i get one second per
frame when zooming in on some of the detail, i'm likewise really
happy.

 ... sounds strange, if you're used to 60fps or 200fps rendering,
yeah?  i've got used to it.  i move the mouse carefully, a bit at a
time, and wait for 1 second for the drawing to catch up.  or, i zoom
out a little, get a decent framerate back, get the angle right, and
zoom back in.

 with that SwapInterval set to zero, i can't even do that trick,
because *everything's* screwed!

l.

Bug#806670: rotation is dragging

[Luke Kenneth Casson Leighton]

On Fri, Jan 8, 2016 at 2:22 AM, Luke Kenneth Casson Leighton
<l...@lkcl.net> wrote:
> On Thu, Jan 7, 2016 at 9:25 PM, chrysn <chr...@fsfe.org> wrote:

>> luke, could you, for comparison, on the system where the new .deb
>> dragged and the fresh 21c8d2fc9 (that's openscad-2014.03, by the way)
>> build worked, build the current master as well?
>
>  sure.  previously was using gitorious now url =
> git://anonscm.debian.org/collab-maint/openscad.git  compile under
> way y gods, loadavg over 10 at one point, one of those c++
> files is waaay too large, that's going to hammer some of the build
> machines esp. the arm ones which only typically have 1gb or 2gb of
> RAM...

 ok, done.  bizarrely, that's behaving ok as well.

 attached is a record of the libraries the just-compiled code uses...
just going over it myself, i see that i haven't updated libqtopengl
from version 4 to version 5 for example.

  as this point, i have to say: if i were to update to libqt5-dev,
(with an apt-get install) then it would become challenging and
difficult to go _back_ to libqt4, so i would be reluctant to do that,
even though i'd like to help get this resolved.

lkcl@bigmac:~/src/openscad$ dpkg -l | grep libqt5 | grep dev
lkcl@bigmac:~/src/openscad$ dpkg -l | grep libqt4 | grep dev
ii  libqt4-dev
4:4.8.6+git64-g5dc8b2b+dfsg-2+b1amd64Qt 4 development
files
ii  libqt4-dev-bin
4:4.8.6+git64-g5dc8b2b+dfsg-2+b1amd64Qt 4 development
programs
ii  libqt4-opengl-dev
4:4.8.6+git64-g5dc8b2b+dfsg-2+b1amd64Qt 4 OpenGL library
development files

yep no libqt5-dev libraries - compiling with libqt4, and latest
master works fine, even with that SwapInterval=0 code (line 704 in
master).

just to confirm the git master branch being used, for the record:

commit d60691b9951c6b2eba4c606b570adf260bad43a7
Merge: 1c5ac3b a17b894
Author: Marius Kintel <mar...@kintel.net>
Date:   Tue Aug 11 12:11:44 2015 +0200

Merge pull request #1411 from chrysn-pull-requests/chrysn/fixes-from-debian

Minor fixes from Debian's checks

so, a temporary "fix", to get a stable and working package out the
door for debian, would be to compile with libqt4, not libqt5.

l.


f
Description: Binary data

Bug#806670: rotation is dragging

[Luke Kenneth Casson Leighton]

On Fri, Jan 8, 2016 at 3:12 AM, Torsten Paul <torsten.p...@gmx.de> wrote:
> On 01/08/2016 03:36 AM, Luke Kenneth Casson Leighton wrote:

> Thanks for providing this nice motivation to help.

 i was concerned for a moment that i'd misunderstood, and that the
code-comment meant that the issue was well-understood.  i'm relieved
(even though i can tell you're being sarcastic, which is fine with me,
i don't mind) that i correctly understood the code-comment.  it would
be really dumb of me to have been so blunt and brutally honest... and
then be totally wrong!  done that enough times in the past *sigh*...

> Without the swap buffer setting, it was unusable with early Qt5
> releases.

 which sounds like a familiar story with code that's in development.

  so the question is, then, why, if qt5 is problematic, continue
to use it at all?  (especially for something as important as a stable
release of a debian package)  it sounds like simply making trouble
without actually having any real benefit.  i've shown that the code is
compile-compatible, you don't *actually* need to use qt5.

 think of it another way: what's the easiest, quickest solution that
enables you to get a stable, useable debian package out the door, with
the minimum amount of developer time and the minimum amount of
maintainer time spent?  is it (a) compile with qt4 (b) modify the code
to use the new OpenGL widget (c) wait for the qt team to fix the
issues with qt5.

 if you're happy to help the qt5 team debug qt5, by providing updates,
bugreports and so on, great, but from what you're saying, the team's
small, they have other issues that are higher priority - why cause
extra pain and hassle... and release packages that are completely
unusable for the majority of people?  this bug's marked "important"
for a reason.

 something to think about, yeah?

 btw, apologies but the laptop i'm using has an SSD which, if it is
hammered with swaps, causes big delays due to continuous PCIe resets.
debug builds, especially at the linker stage and especially with c++,
use up so much memory that i won't be able to help test by doing
debug-build compiles, it's too risky, even with 8gb of RAM.  i will
say that the difference between debug and release builds sounds like
there's some sort of race condition somewhere in qt5 - something
that's execution-time-dependent: events where if one is completed
first everything's fine but if a system is slower (because of a debug
build or just because of different performance) then it's not...

this hypothesis - that there's some reordering of events occurring due
to execution time differences on different platforms - would explain
why you're seeing some people be able to repro the problem whereas
others cannot, and why some people have the problem and others do not.

l.

Bug#787127: closed by chr...@fsfe.org (Christian M. Amsüss) (Bug#787127: fixed in openscad 2015.03-1+dfsg-1)

[Luke Kenneth Casson Leighton]

On Wed, Aug 12, 2015 at 2:27 PM, chrysn chr...@fsfe.org wrote:
 hello luke,

 On Wed, Aug 12, 2015 at 01:39:55PM +0100, Luke Kenneth Casson Leighton wrote:
 i'm not seeing a version 2015.03-1+dfsg-1 here:
 https://packages.debian.org/search?keywords=openscad

 or here:
 http://ftp.uk.debian.org/debian/pool/main/o/openscad/

 there is only 2014.03-1+dfsg-1.

 ... what gives?

 it's been only just uploaded; give it some time to find its way through
 the archive!

 ok :)

Bug#787127: closed by chr...@fsfe.org (Christian M. Amsüss) (Bug#787127: fixed in openscad 2015.03-1+dfsg-1)

[Luke Kenneth Casson Leighton]

hi chris,

i'm not seeing a version 2015.03-1+dfsg-1 here:
https://packages.debian.org/search?keywords=openscad

or here:
http://ftp.uk.debian.org/debian/pool/main/o/openscad/

there is only 2014.03-1+dfsg-1.

... what gives?

l.


On Wed, Aug 12, 2015 at 1:24 PM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the openscad package:

 #787127: openscad segfault

 It has been closed by chr...@fsfe.org (Christian M. Amsüss).

 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact chr...@fsfe.org 
 (Christian M. Amsüss) by
 replying to this email.


 --
 787127: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787127
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems


 -- Forwarded message --
 From: Christian M. Amsüss chr...@fsfe.org
 To: 787127-cl...@bugs.debian.org
 Cc:
 Date: Wed, 12 Aug 2015 12:20:50 +
 Subject: Bug#787127: fixed in openscad 2015.03-1+dfsg-1
 Source: openscad
 Source-Version: 2015.03-1+dfsg-1

 We believe that the bug you reported is fixed in the latest version of
 openscad, which is due to be installed in the Debian FTP archive.

 A summary of the changes between this version and the previous one is
 attached.

 Thank you for reporting the bug, which will now be closed.  If you
 have further comments please address them to 787...@bugs.debian.org,
 and the maintainer will reopen the bug report if appropriate.

 Debian distribution maintenance software
 pp.
 Christian M. Amsüss chr...@fsfe.org (supplier of updated openscad package)

 (This message was generated automatically at their request; if you
 believe that there is a problem with it please contact the archive
 administrators by mailing ftpmas...@ftp-master.debian.org)


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Format: 1.8
 Date: Tue, 11 Aug 2015 18:15:32 +0200
 Source: openscad
 Binary: openscad openscad-testing openscad-testing-data openscad-dbg
 Architecture: source amd64 all
 Version: 2015.03-1+dfsg-1
 Distribution: unstable
 Urgency: medium
 Maintainer: Christian M. Amsüss chr...@fsfe.org
 Changed-By: Christian M. Amsüss chr...@fsfe.org
 Description:
  openscad   - script file based graphical CAD environment
  openscad-dbg - script file based graphical CAD environment (debugging 
 symbols)
  openscad-testing - script file based graphical CAD environment (test suite)
  openscad-testing-data - script file based graphical CAD environment (test 
 suite data)
 Closes: 781638 787127 789318
 Changes:
  openscad (2015.03-1+dfsg-1) unstable; urgency=medium
  .
[ Chow Loong Jin ]
  .
* New upstream version
  + Language Features
- Added text() module for 2D text
- Added offset() module for 2D offsets
- Added list comprehensions and let()
- Added concat() function
- Added chr() function
- surface() can now take PNG images as input
- min() and max() can now take a vector argument
- 2D minkowski can now handle polygons with holes
- Variables can now be assigned in local blocks without using assign()
  + Program Features
- Added Toolbar icons
- New code editor based on QScintilla
- Added Splash screen
- Added SVG export
- Added AMF export
- Added --viewall and --autocenter cmd-line parameters
- GUI is now translated into German, Czech, Spanish, French and Russian
- MDI (Multiple Document Interface) is now available on all platforms
- Color schemes for viewer and editor can be user-edited using JSON 
 files
- GUI components are now dockable
- Added Tickmarks on axes
  + Bugfixes/improvements
- Performance improvement: 2D (clipper), preview, hull, minkowski, 
 surface
- Performance improvement: Reduce duplicate evaluation of identical
  expressions
- Better recursion behavior
- STL export and import is now more robust
- Internal cavities are better supported
- New examples
- Windows cmd-line behaves better
- Better mirror() and scale() behavior when using negative factors
- Fixes a segfault bug (Closes: #787127)
- Removes __DATE__ reference (Closes: #781638)
  + Deprecations
- polyhedron() now takes a faces= argument rather than triangles=
- assign() is no longer needed. Local variables can be created in any
  scope
* Use qt5
* Bump Standards-Version to 3.9.6
* Fix up watch file options
* Update what goes in the +dfsg package
  - Remove src/SparkleAutoUpdater.* from dfsg branch
* Update +dfsg branch mechanisms to uscan
* Update debian/copyright
* Set uversionmangle in debian/watch for microreleases
* New patches
  * Build system: Work 

Bug#792670: androidsdk-ddms: android sdk license appears to violate debian charter

[Luke Kenneth Casson Leighton]

hi emmanuel, dr stallman investigated and has this to point out:

The Google SDK license contains this text

3.5 Use, reproduction and distribution of components of the SDK
licensed under an open source software license are governed solely
by the terms of that open source software license and not this
License Agreement.

Since (as far as we know) all free software is open source, this has
the effect of withdrawing all their conditions from the SDK components
that are free.  They are not violating the GNU GPL.

Of course, the rest of their SDK is unethical because it is nonfree,
and people should not accept their conditions.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792670: androidsdk-ddms: android sdk license appears to violate debian charter

[Luke Kenneth Casson Leighton]

On Fri, Jul 17, 2015 at 1:11 PM, Emmanuel Bourg ebo...@apache.org wrote:
 Le 17/07/2015 12:06, Luke Kenneth Casson Leighton a écrit :

 thoughts?

 The code from android.googlesource.com clearly comes with an Apache-2.0
 license though. I wonder if these terms and conditions only apply to the
 SDK distributed by Google on developer.android.com. That would be
 somewhat similar to Oracle distributing Java with different terms than
 OpenJDK.

 the discussion is ongoing on a gnu list, and there it was raised that
the TC are a generic overview that is required to be agreed with *in
addition* to the licenses, some of which, it was pointed out, are GPL
as well as apache2.

 there was an announcement only a few days ago where the FSF pointed
out that canonical's TCs clearly contradict the GPL...

  so this is not something that can be taken lightly.

 (case 1) - the TCs are over-and-above (i.e. in addition to) the
apache2 license, making the entire software non-free.  this would be
acceptable if and only if the android sdk code was moved to the
nonfree section.

 (case 2) the TCs *contradict* the GPL (if the person who assessed
the software on the gnu list is correct in that there is some GPL
software), thus placing debian in the rather awkward position of
violating its charter and quite possibly copyright law as well.

 this is why i raised this as important as it really really needs a
full and thorough review.  this _should_ be quite straightforward as
the rules on checking that the software is properly compliant
(copyright file) are very clear.  however if you'd like to do a more
thorough audit i have a program called copyright_check.py which does a
heck of a lot more than lintian.  it's an O(N^3) algorithm that
carries out a two-way verification of the copyright file's regexps
with the *actual* copright notices.

it would at least help you to verify that the copyright file correctly
matches (with nothing missing for example) the actual files.

 ... apologies for the extra work!

l.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792670: androidsdk-ddms: android sdk license appears to violate debian charter

[Luke Kenneth Casson Leighton]

On Fri, Jul 17, 2015 at 1:39 PM, Emmanuel Bourg ebo...@apache.org wrote:
 I couldn't find these TC in the upstream Git repository [1].

 oh - that's very good.  ok, that helps enormously... you don't need
to go to the sdk site, you can just bypass it and compile the code
directly from source.  i like that.  ok sorry to have taken up your
time emmanuel, but better safe than sorry :)

l.

 They seem
 to be specific to the SDK package distributed by Google at
 https://developer.android.com/sdk. That doesn't prevent downstream
 packagers like Debian from distributing it under the original Apache-2.0
 license.

 [1] https://android.googlesource.com/platform/tools/base/+/master


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792670: androidsdk-ddms: android sdk license appears to violate debian charter

[Luke Kenneth Casson Leighton]

Package: androidsdk-ddms
Severity: important

Dear Maintainer,

i've been alerted to the following in the android sdk terms and conditions:

  3.4 You agree that you will not take any actions that may cause or
  result in the fragmentation of Android, including but not limited to
  distributing, participating in the creation of, or promoting in any
  way a software development kit derived from the SDK.

this is, in my mind, in clear violation of the debian charter and,
if correct, means that the entire android sdk should be pulled,
or at least moved to non-free.

thoughts?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787127: openscad segfault

[Luke Kenneth Casson Leighton]

On Fri, May 29, 2015 at 1:08 PM, chrysn chr...@fsfe.org wrote:
 hello lkcl,

 On Thu, May 28, 2015 at 09:33:15PM +0100, lkcl wrote:
 openscad segfaults with the file that may be downloaded from the
 following location: http://lkcl.net/openscad_bug.scad

 thans for reporting this; i can reproduce the problem with the current
 debian version of openscad.

 the issue is already fixed in openscad 2015.03, which i'm currently
 preparing for upload based on hyperair's work. i've had a hard time
 already trying to fix openscad crashes, and given the new release, i
 won't look into this much deeper and rather focus on getting the next
 version into sid, unstable, and backports.

 ah, great - if there's a version that works, that's fantastic.  i
found that the model was nonsense, anyway: correcting the errors in
the model caused the segfault to go away, but it took a binary search
[segfault / no-segfault] to find it :)

 l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#399608: fixed in sysvinit 2.88dsf-59.1

[Luke Kenneth Casson Leighton]

On Sun, May 17, 2015 at 3:48 PM, Andreas Henriksson andr...@fatal.se wrote:
 Hello Adrian!

 Thanks for raising awareness about this issue. If there's anything
 I can do to help please tell me. That the new util-linux version hasn't
 been built yet sounds like it can't be avoided as it was just uploaded
 and unfortunately the sysvinit and util-linux update is a lockstep
 upgrade where both change at the same time as things are moved between
 the packages. There's no intermediate step possible, because the
 moved binaries always needs to be available at all times and thus
 have tight dependencies in both directions. Not sure how dependencies
 affects the build of these packages though They should both be
 able to build on systems with older versions of the packages installed
 and build independently.

 that sounds like the kind of thing that would cause nightmare
circular build dependencies for anyone porting to a new architecture
[which i'm considering doing: mvp from icubecorp].

 would that be correct - that if there *is* no older version it
would now be impossible to build both [or either] of the packages - or
am i mistaken?

 if it is correct, do you happen to know if they would cross-build, at all?

 l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776959: linux-image-3.16.0-4-amd64: [regression] sd card reader in retina macbook pro no longer working

[Luke Kenneth Casson Leighton]

On Tue, Feb 3, 2015 at 7:58 PM, Ben Hutchings b...@decadent.org.uk wrote:
 Control: tag -1 important

 On Tue, 2015-02-03 at 15:39 +, lkcl wrote:
 Package: src:linux
 Version: 3.16.7-ckt2-1
 Severity: important

 after upgrading from 3.13 where the built-in sd card worked perfectly,
 there is no longer even any kernel events or anything remotely indicating
 that the apple sd card reader is recognised.

 i note that there is a similar bug
 https://lists.debian.org/debian-kernel/2014/09/msg00170.html

 however this is for an entirely different laptop.
 [...]

 And a different device ID.

 yeh.

 Which driver is being used in 3.13?

 well... as rebooting the machine to find out would be too disruptive
(termination of dozens of long-running programs) i can't directly find
out immediately, so i did some investigation.

 according to these:

 https://usb-ids.gowdy.us/read/UD/05ac
https://wiki.debian.org/InstallingDebianOn/Apple/MacBookPro/11-1#lsusb

 it should be 0a5c:8406

 (i have the same hardware as on the debian page)

 but what's startling is that the expected usb device is... *entirely
missing* from lsusb.  i mean it's _gone_.  so this is going to have to
be something that i will need to schedule a reboot when it is
convenient to do so, and find out if it reappears under 3.13.

 but before i do that, what i'm doing to do is an s2disk, and make
sure that the power adaptor is not plugged in at the time (it causes
*massive* EMI spiking which causes me to get electric shocks off of
the aluminium casing if i touch a well-earthed ground point, and
causes the logs to be filled up every second with SATA hard resets).

 give me a few minutes i'll make a report with the findings.

 l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776959: linux-image-3.16.0-4-amd64: [regression] sd card reader in retina macbook pro no longer working

[Luke Kenneth Casson Leighton]

On Tue, Feb 3, 2015 at 9:28 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
 On Tue, Feb 3, 2015 at 7:58 PM, Ben Hutchings b...@decadent.org.uk wrote:
 Control: tag -1 important

 On Tue, 2015-02-03 at 15:39 +, lkcl wrote:
 Package: src:linux
 Version: 3.16.7-ckt2-1
 Severity: important

 after upgrading from 3.13 where the built-in sd card worked perfectly,
 there is no longer even any kernel events or anything remotely indicating
 that the apple sd card reader is recognised.

 i note that there is a similar bug
 https://lists.debian.org/debian-kernel/2014/09/msg00170.html

 however this is for an entirely different laptop.
 [...]

 And a different device ID.

  yeh.

 Which driver is being used in 3.13?

  well... as rebooting the machine to find out would be too disruptive
 (termination of dozens of long-running programs) i can't directly find
 out immediately, so i did some investigation.

  according to these:

  https://usb-ids.gowdy.us/read/UD/05ac
 https://wiki.debian.org/InstallingDebianOn/Apple/MacBookPro/11-1#lsusb

  it should be 0a5c:8406

  (i have the same hardware as on the debian page)

  but what's startling is that the expected usb device is... *entirely
 missing* from lsusb.  i mean it's _gone_.  so this is going to have to
 be something that i will need to schedule a reboot when it is
 convenient to do so, and find out if it reappears under 3.13.

  but before i do that, what i'm doing to do is an s2disk, and make
 sure that the power adaptor is not plugged in at the time (it causes
 *massive* EMI spiking which causes me to get electric shocks off of
 the aluminium casing if i touch a well-earthed ground point, and
 causes the logs to be filled up every second with SATA hard resets).

  give me a few minutes i'll make a report with the findings.


root@bigmac:/home/lkcl/src/quarks# lsusb
Bus 002 Device 003: ID 05ac:8406 Apple, Inc.

okaaay, after an s2disk and powering up, the device is back.  this
does not inspire me with confidence in $1500 worth of hardware!

 so i think ben this one can be closed - if it happens again i'll
investigate further. that just leaves the audio one to resolve.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748373: python-lmdb

[Luke Kenneth Casson Leighton]

On Thu, Dec 11, 2014 at 6:30 PM, Robert Edmonds edmo...@debian.org wrote:
 Hi,

 I'm planning on using py-lmdb for a project, and it appears no one else
 is working on a package, so I'll be happy to take this RFP.

 David Wilson wrote:
 * The binding is still receiving significant development, so before any
   particular version becomes frozen, please drop me an e-mail to ensure
   the latest and greatest (and possibly stablest) release is available
   prior to the freeze.

 As jessie is now frozen without a py-lmdb package in the archive, it
 won't be part of the next stable release.  So you have a few more years
 before a particular version of py-lmdb becomes frozen :-)

 pffh, who works with debian/stable anyway? :)

 actually doing the packaging robert is very very straightforward, i
did it once (in a proprietary environment), i just followed the
standard python arrangement, i think the debian/rules file was about 7
or 8 lines long, absolutely nothing special whatsoever was needed.

 the only thing is: david committed a copy of liblmdb into python-lmdb
- smacked wrist there david :) - it's statically compiled into
python-lmdb's lmdb.so and is very small...

 ... whilst this does have the advantage that the (closely-tied)
version of liblmdb to python-lmdb needs no further thought or work, if
you want to consider separating it so that there's a dependency on
liblmdb0, you're in for a bit of a mess as whatever stable version of
liblmdb0 is nailed to the floor, that's what you have to restrict
python-lmdb to.

 honestly my advice, given that liblmdb is so small, would be to stick
to what david's done, for now, and once python-lmdb can be considered
stable in a few years time the situation can be revisited.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768171: RFP: yacy -- A free (libre) decentralised Internet Search Engine

[Luke Kenneth Casson Leighton]

Package: wnpp
Severity: wishlist

* Package name: yacy
  Version : 1.8
  Upstream Author :
* URL : http://www.yacy-websuche.de/wiki/index.php/En:DebianInstall
* License : GPL
  Programming Lang: java
  Description : A free (libre) decentralised Internet Search Engine

[debian packages already exist for this software]

YaCy is a free search engine that anyone can use to build a search
portal for their intranet or to help search the public internet. When
contributing to the world-wide peer network, the scale of YaCy is
limited only by the number of users in the world and can index
billions of web pages. It is fully decentralized, all users of the
search engine network are equal, the network does not store user
search requests and it is not possible for anyone to censor the
content of the shared index


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745147: closed by Ben Hutchings b...@decadent.org.uk (Re: WARNING on removal of SCSI device which is still in use)

[Luke Kenneth Casson Leighton]

thanks for keeping an eye on this ben


On Wed, Sep 24, 2014 at 2:42 PM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:

 Subject: Re: WARNING on removal of SCSI device which is still in use
 Version: 3.15~rc5-1~exp1

 This is supposed to be fixed in 3.15-rc1 by:

 commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59
 Author: James Bottomley jbottom...@parallels.com
 Date:   Tue Jan 21 07:00:50 2014 -0800

 [SCSI] fix our current target reap infrastructure

 Ben.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745142: Acknowledgement (debootstrap functions rely on Packages file existing (it doesn't in lenny archive))

[Luke Kenneth Casson Leighton]

ahh... a bit more investigation showed that this *might* have been due
to running out of disk space.  that may have masqueraded the error: a
better error should really have been presented.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744994: linux-image-3.13-1-amd64: segfault on use of external (usb) dvdrw

[Luke Kenneth Casson Leighton]

On Fri, Apr 18, 2014 at 2:11 PM, Ben Hutchings b...@decadent.org.uk wrote:

 Apr 17 09:24:08 teenymac kernel: [1201449.213969] usb 2-5: USB disconnect, 
 device number 18

 Drive removed.

 yes. bit of a melt-down on another USB hub, i had to unplug it (and
the attached nothing-to-do-with-the-USB-DVD-drive USB hub).

 Apr 17 09:30:02 teenymac kernel: [1201802.581323] Read(10): 28 00 00 00 00 
 00 00 00 01 00

 I don't understand why there is attempted I/O to a device that was
 physically removed 6 minutes earlier!  Maybe something has kept the
 block device open, but no other processes should be allowed to open it.

 there aren't any.  i'm running fvwm, and commands are run explicity.
 i usually use curses-based tools, explicitly typed from the command
 line in an xterm.

 so there's no gnome or kde or any kind of file managers, file commanders,
 nothing.  nothing that could  be f**g around without my knowledge or
 permission, and that's the way i like it :)

 the only other thing is: there is actually a built-in CD/DVD drive, listed
 as /dev/cdrom1 (not /dev/cdrom), so the USB device came up as
 /dev/cdrom11 - all a bit weird, but hey.

 Apr 17 09:33:07 teenymac kernel: [1201988.327917] sr1: scsi3-mmc drive: 
 62x/24x writer dvd-ram cd/rw xa/form2 cdda tray
 Apr 17 09:33:07 teenymac kernel: [1201988.328255] sr 9:0:0:0: Attached scsi 
 CD-ROM sr1

 Drive reattached.  Note it's now 'sr1', as 'sr0' seems to still be
 hanging around.

  or it might have been the other DVD drive (apologies i might have given
 you too much kmesg with not enough context).

 so sr0 is the internal DVD writer, sr1 is the external (USB) one.

 This looks similar to (though not quite the same as)
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1283604 which is
 supposed to be fixed in 3.15.  The fixes might get into Debian sooner
 than that, although James Bottomley recommended waiting some time to see
 if this causes regressions in 3.15.

 ok

 [snip]

 More attempted I/O to 'sr0' which was supposed to be removed 15 minutes
 ago.

 probably the internal DVD

 Apr 17 09:42:12 teenymac kernel: [1202533.365582] sr 0:0:0:0: Attached scsi 
 CD-ROM sr0
 [...]

 sr_mod module reinserted, tries to re-register the block queue for sr0.

 unf??   ok so that's definitely happening on the internal drive, not
the external one.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745038: sgml-base: dependency xml-core missing (missing update-xmlcatalog)

[Luke Kenneth Casson Leighton]

it's ok adam, i was reporting from a different machine, and somehow
/usr/sbin was not in $PATH.  bug's been closed.

On Thu, Apr 17, 2014 at 2:39 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 Control: tags -1 + moreinfo unreproducible

 On 2014-04-17 14:24, lkcl wrote:

 Package: sgml-base
 Version: 1.26+nmu3


 That version isn't in any Debian release. More specifically, it's not the
 version that's in wheezy, which you said you were upgrading from.

 Severity: serious
 Justification: 2

 the command update-xmlcatalog is used by sgml-base however the
 dependency xml-core is missing.


 Really?

 $ egrep -ir update-xmlcatalog sgml-base-1.26+nmu4/
 sgml-base-1.26+nmu4/debian/README.Debian:just as update-xmlcatalog(8) in the
 xml-core package is the standard
 $

 For completeness, I grabbed 1.26+nmu3 from snapshot. That package also
 contains no mentions of update-xmlcatalog other than the one line of
 documentation above.

 Regards,

 Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745038: Acknowledgement (sgml-base: dependency xml-core missing (missing update-xmlcatalog))

[Luke Kenneth Casson Leighton]

apologies please disregard this bugreport, /usr/sbin was somehow
missing from $PATH.

l.

On Thu, Apr 17, 2014 at 2:27 PM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
 Thank you for filing a new Bug report with Debian.

 This is an automatically generated reply to let you know your message
 has been received.

 Your message is being forwarded to the package maintainers and other
 interested parties for their attention; they will reply in due course.

 Your message has been sent to the package maintainer(s):
  Debian XML/SGML Group debian-xml-sgml-p...@lists.alioth.debian.org

 If you wish to submit further information on this problem, please
 send it to 745...@bugs.debian.org.

 Please do not send mail to ow...@bugs.debian.org unless you wish
 to report a problem with the Bug-tracking system.

 --
 745038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745038
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730482: linux-image-3.9.6: PCI/USB reset not being done on Geode LX800 / CS5536

[Luke Kenneth Casson Leighton]

On Thu, Nov 28, 2013 at 9:22 AM, Andrei POPESCU
andreimpope...@gmail.com wrote:
 Hi Kernel Maintainers,

 Since the package doesn't exist this landed in the wrong place. Could
 you please have a look and take over the bug if useful?

 thanks andrei.  i've since observed that the two ethernet ports of
the alix6f2 (which are PCI devices) are also giving symptoms which are
consistent with not being reset [on soft-power-cycle].   the symptoms
are that when using the alix6f2 as a router and DHCP server to another
system which has ifplugd to monitor the up/down state of its network
interface it *fails* to get a new lease.  as in consistently fails,
not maybe once or twice.

 as you're aware ifplugd monitors *hardware* ethernet up/down states.
if the ethernet PCI devices (two on the alix6f2) are not being reset
by the CS5536 kernel module on first load, then they will remain in an
up state even whilst the board is going through its reboot sequence.
the consequence of that is that there will be no notification to
ifplugd, and thus any systems on the other end will lose connectivity
but will not have any normal way to detect that.

 i've fixed this by reducing the DHCP lease time on the alix6f2's
dnsmasq entry to 1 minute (blegh).

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721924: Acknowledgement (linux-image-3.10-2-amd64: btrfs writing several small files causes massive load spike)

[Luke Kenneth Casson Leighton]

https://bugzilla.kernel.org/show_bug.cgi?id=60860

cf upstream bugreport.

On Thu, Sep 5, 2013 at 3:36 PM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
 Thank you for filing a new Bug report with Debian.

 This is an automatically generated reply to let you know your message
 has been received.

 Your message is being forwarded to the package maintainers and other
 interested parties for their attention; they will reply in due course.

 Your message has been sent to the package maintainer(s):
  Debian Kernel Team debian-ker...@lists.debian.org

 If you wish to submit further information on this problem, please
 send it to 721...@bugs.debian.org.

 Please do not send mail to ow...@bugs.debian.org unless you wish
 to report a problem with the Bug-tracking system.

 --
 721924: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721924
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718281: Acknowledgement (race condition on execution of /etc/ifplugd/ifplug.action script and exit)

[Luke Kenneth Casson Leighton]

after some reflection overnight, i think a minor workaround would be
to have in /lib/udev/ifplugd.agent a check to see if '-M' is in the
$ARGS and if it is to *not* try to kill the ifplugd instance. for now
however i am just commenting out the kill:

remove|unregister)
debug_mesg Stopping $DAEMON_NAME for $INTERFACE

# kill a running ifplugd daemon
# NO!  DO NOT PERMIT THIS TO HAPPEN!
# let ifplugd exit on its own
#exec $DAEMON -k -i $INTERFACE

but this really is not the solution.  really, ifplugd should not be so
aggressive as to try to kill itself off without first letting it
complete the running of the down actions.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#471076: inkscape: tutorialare installed making a MASSIVE package not possible to install on low-disk-space machines

[Luke Kenneth Casson Leighton]

On Mon, Jul 8, 2013 at 2:19 PM, Matteo F. Vescovi mfv.deb...@gmail.com wrote:
 Hi!

 place: removing the tutorials fom the inkscape program.

 This is one of the things on my TODO list about inkscape.

 Probably not with the upcoming upload to unstable (that should happen
 during next weekend) but soon enough I'm about splitting the monolithic
 inkscape package in two or more related packages and tutorials is one of
 them.

 matteo: although this was a heck of a long time ago, i'm very
grateful to see that you're on the case, i have some other smaller
systems i'd like to install inkscape on in the future.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#715370: Acknowledgement (linux-image-3.9-1-486: CONFIG_GPIO_CS5535 has been set to 'y' when it should be 'M')

[Luke Kenneth Casson Leighton]

right.  having enormous difficulty tracking this down, but there
appears to be some kernel config dependencies of CONFIG_GPIO_CS5535
which are set to Y which are forcing CONFIG_GPIO_CS5535 to y.

... but that actually turns out not to be the main problem: the main
problem is that although GPIO_CS5535 has been converted (since 3.2.0)
to the standard GPIO format, CONFIG_GPIO_SYSFS isn't set, making it
impossible to gain access to it!

as this is for an AMD Geode LX (PC-Engines alix6f2), gaining access to
the GPIO in order to pull relays, change the LED status and so on, is
somewhat essential.

could i therefore request that CONFIG_GPIO_SYSFS be set to Y so that
GPIO - which is protected by having to explicitly take action in
userspace in order to gain access to it anyway - is accessible?

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706476: Info received (Bug#706476: Info received (Bug#706476 closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being compile

[Luke Kenneth Casson Leighton]

ok, it turns out that CONFIG_SYSFS_GPIO is safe, because you have to
explicitly take action in order to make GPIO accessible (export).
following the instructions here was easy to do:
https://sites.google.com/site/bifferboard/Home/gpio

so, basically, CONFIG_SYSFS_GPIO could be switched on (as built-in).

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706476: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being compiled (needed for alix6f2))

[Luke Kenneth Casson Leighton]

On Wed, May 1, 2013 at 3:33 AM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the linux-image-3.2.0-4-486 package:

 #706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being 
 compiled (needed for alix6f2)

 It has been closed by Ben Hutchings b...@decadent.org.uk.

 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Ben Hutchings 
 b...@decadent.org.uk by
 replying to this email.


 --
 706476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706476
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems


 -- Forwarded message --
 From: Ben Hutchings b...@decadent.org.uk
 To: 706476-d...@bugs.debian.org
 Cc:
 Date: Wed, 01 May 2013 03:31:35 +0100
 Subject: Re: Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 
 module not being compiled (needed for alix6f2)
 On Tue, 2013-04-30 at 18:39 +0100, Ben Hutchings wrote:
 On Tue, Apr 30, 2013 at 05:22:56PM +0100, lkcl wrote:
  Package: linux-image-3.2.0-4-486
  Severity: important
 
 
  discovered from another debian bugreport that pc-engines systems can be
  upgraded to more recent firmware and work with linux-image-3.2.0-4-486
  (which is great!) and also discovered that the geodewdt kernel module
  has been compiled, which is also great (as it's missing from the 2.6.32
  debian kernel builds)
 
  however what's not so great is that the GPIO 5535 kernel driver has been
  left out, and it is a requirement for the project.  as native builds on
  500mhz AMD Geodes take absolutely forever it would be nice if this could
  be corrected. kernel option is GPIO_CS5535
 [...]

 That's odd, this was enabled in 3.1.0~rc4-1~experimental.1:

   * [i386] Enable GPIO_CS5535, MFD_CS5535, CS5535_MFGPT,
 CS5535_CLOCK_EVENT_SRC, GPIO_VX855, MFD_VX855 as modules;
 [i386/486] Enable OLPC_XO1_PM, OLPC_XO1_RTC, OLPC_XO1_SCI, OLPC_XO15_SCI
 (Closes: #639113)

 and is still enabled in the config files in the source package.
 There must be some new dependency that has forced it off again.  I'll
 look at this later.

 It *is* still enabled, but it's built-in on the 486 flavour because
 OLPC_XO1_SCI selects it.

thanks ben... investigating further:

# PCI GPIO expanders:
#
CONFIG_GPIO_CS5535=y
# CONFIG_GPIO_LANGWELL is not set
CONFIG_GPIO_PCH=m
CONFIG_GPIO_ML_IOH=m
# CONFIG_GPIO_RDC321X is not set

bizarre.  so why the heck is i think it's changed quite a lot from
2.6.32, no major-minor numbers any more, to a generic GPIO interface
which i've not yet understood/tracked down.

so yes, more work to do but at least a route to investigate.  thanks ben.

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706476: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being compiled (needed for alix6f2))

[Luke Kenneth Casson Leighton]

On Wed, May 1, 2013 at 10:56 AM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:

 It *is* still enabled, but it's built-in on the 486 flavour because
 OLPC_XO1_SCI selects it.

 thanks ben... investigating further:

 # PCI GPIO expanders:
 #
 CONFIG_GPIO_CS5535=y
 # CONFIG_GPIO_LANGWELL is not set
 CONFIG_GPIO_PCH=m
 CONFIG_GPIO_ML_IOH=m
 # CONFIG_GPIO_RDC321X is not set

 bizarre.  so why the heck is i think it's changed quite a lot from
 2.6.32, no major-minor numbers any more, to a generic GPIO interface
 which i've not yet understood/tracked down.

 so yes, more work to do but at least a route to investigate.  thanks ben.

 right.  the issue is this: CONFIG_GPIO_CS5535 appears to hook into
the standard linux kernel gpio subsystem (gpiolib), which is *not*
exposed to userspace unless you set CONFIG_EXPERIMENTAL, CONFIG_SYSFS
and CONFIG_SYSFS_GPIO.

 contrast this with 2.6.32 where CONFIG_CS5535_GPIO exposed GPIO
directly into userspace as a major/minor device and you see what the
issue is.

 #
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

right.  that's the problem - CONFIG_GPIO_SYSFS isn't set.

as this alix6f2 board is being used for pulling relays on powered
equipment which is mission-critical, using the LEDs for status
information, resetting the internal MiniPCIe modem if it goes belly-up
and so on, this is a major functional step backwards, and we may have
to return to the 2.6.32 kernel with *no* watchdog support.

also of note is that i had to put this into modprobe.d for 2.6.32:
cs5535_gpio
options cs5535_gpio mask=0x

this allows us to use GPIOs which were allocated to LEDs, buzzer and
so on on *this* device, whereas other devices may use those GPIOs for
functions that may not be appropriate for general use.

in resolving this it would be appreciated to bear in mind that we
*need* that mask value.  also, if the GPIO_CS5535 module is built-in
and GPIO_SYSFS is enabled as well, then there's the possibility that
people will randomly poke around ... but only the once :)

if these are done as modules then even if GPIO_SYSFS is built-in and
populates /sys/class/gpio it will at least be empty until modprobe
gpio_cs5535 is called (and in our case with the mask parameter), and
that will only really be done by people who know what they're doing.

now to work out how to re-open this bug :)

l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706476: Info received (Bug#706476 closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being compiled (needed for alix6f2)))

[Luke Kenneth Casson Leighton]

i've added these at the end of debian/config/i386/none/config.i486 and
then checked debian/build/build_i386_none_486/.config but
CONFIG_GPIO_CS5535 had been modified to y, ah well.

fakeroot make -f debian/rules.gen -j16 binary-arch_i386_none_486

still running...

#
# GPIOLIB and SYSFS
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y

#
# PCI GPIO expanders:
#
CONFIG_GPIO_CS5535=m


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706476: linux-image-3.2.0-4-486: amd geode gpio-cs5535 module not being compiled (needed for alix6f2)

[Luke Kenneth Casson Leighton]

On Tue, Apr 30, 2013 at 6:39 PM, Ben Hutchings b...@decadent.org.uk wrote:
 On Tue, Apr 30, 2013 at 05:22:56PM +0100, lkcl wrote:
 Package: linux-image-3.2.0-4-486
 Severity: important


 discovered from another debian bugreport that pc-engines systems can be
 upgraded to more recent firmware and work with linux-image-3.2.0-4-486
 (which is great!) and also discovered that the geodewdt kernel module
 has been compiled, which is also great (as it's missing from the 2.6.32
 debian kernel builds)

 however what's not so great is that the GPIO 5535 kernel driver has been
 left out, and it is a requirement for the project.  as native builds on
 500mhz AMD Geodes take absolutely forever it would be nice if this could
 be corrected. kernel option is GPIO_CS5535
 [...]

 That's odd, this was enabled in 3.1.0~rc4-1~experimental.1:

   * [i386] Enable GPIO_CS5535, MFD_CS5535, CS5535_MFGPT,
 CS5535_CLOCK_EVENT_SRC, GPIO_VX855, MFD_VX855 as modules;
 [i386/486] Enable OLPC_XO1_PM, OLPC_XO1_RTC, OLPC_XO1_SCI, OLPC_XO15_SCI
 (Closes: #639113)

 and is still enabled in the config files in the source package.
 There must be some new dependency that has forced it off again.  I'll
 look at this later.

 star, thanks ben, really appreciated. if i get clearance at work to
spend more time on this i'll attempt a kernel build myself.  i was
expecting to upgrade and to build geodewdt, ironic that it's the other
way round.

 l.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684999: ekiga: segfault on exit from video call

[Luke Kenneth Casson Leighton]

On Sun, Sep 9, 2012 at 6:22 PM, Paul Menzel pm.deb...@googlemail.com wrote:
 Am Sonntag, den 09.09.2012, 16:53 +0100 schrieb Luke Kenneth Casson Leighton:
 On Sun, Sep 9, 2012 at 2:25 PM, Paul Menzel pm.deb...@googlemail.com wrote:
  forwarded 684999 https://bugzilla.gnome.org/show_bug.cgi?id=683668
  tags 684999 upstream
  quit

  Am Mittwoch, den 15.08.2012, 17:13 +0100 schrieb lkcl:
  Package: ekiga
  Version: 3.2.7-5+b1
  Severity: important
 
  thank you for taking the time to report this error to the Debian BTS.
 
  === Backtrace: =
  /lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7f78e839b606]
  /usr/lib/x86_64-linux-gnu/libavutil.so.51(av_freep+0xc)[0x7f78d711433c]
  /usr/lib/x86_64-linux-gnu/libavutil.so.51(av_opt_free+0x3c)[0x7f78d7114a7c]
  /usr/lib/x86_64-linux-gnu/libavcodec.so.53(avcodec_close+0xf5)[0x7f78d738bd9d]
  /usr/lib/opal-3.10.4/codecs/video/mpeg4_ffmpeg_ptplugin.so(_ZN13FFMPEGLibrary12AvcodecCloseEP14AVCodecContext+0x38)[0x7f78d8609e50]

 I am sorry, I forgot to ask, if this was just a one time occurrence or
 if you hit this problem reliably.

 pretty much all the time.

  I am no expert, but this looks like the segmentation fault happens in
  `libavutil.so.51` or `libc.so.6`.

  yeahh... but... ah i've learned that actually there's a severe
 problem with opal 3.10 that is *not* present with the latest svn of
 opal.

 Interesting! Could you point me to the source of your information
 please?

 it's empirical observation.  learned is perhaps too strong a word.
but after compiling half a dozen applications and servers in a
desperately-widening search for at least... *some* stable free
software voip conferencing client-server combination, i've kinda
covered most of the field here :)

 the only client-server combination that offered any level of
stability was opalgw + openphone from the latest svn direct out of the
opal repository.  *every* single release of opal prior to that - and i
checked them all, all the way back i think it was to opal 3.8 - every
minor and major release - was unstable and crashed in some way.

 i have tried compiling ekiga straight from latest svn source code but
 it's not having any of it.

 I am sorry. I do not understand that sentence. Could you please clarify
 it? Git is used for Ekiga now [1]. What does it not have? libopal should
 be an external library, should not it?

 yes it is.  i compiled the latest ekiga svn with the latest libopal
and there were compile-time incompatibilities (in the ekiga source
code) that stopped me from proceeding.

  Could you please paste the output of the following command.
 
  $ dpkg -l libavcodec53 libavutil51 libc6

 lkcl@MacbookXP:~/src/rhombus/allwinner_a10$ dpkg -l libavcodec53
 libavutil51 libc6
 Desired=Unknown/Install/Remove/Purge/Hold
 | 
 Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name   VersionDescription
 +++-==-==-
 ii  libavcodec53   7:0.10.3-dmo1  Library to encode decode multimedia streams
 ii  libavutil517:0.11.1-dmo4  FFmpeg avutil library - runtime files
 ii  libc6  2.13-21Embedded GNU C Library: Shared libraries

 Hmm, so you are using the packages from deb-multimedia.org [1]. If these
 packages were updated maybe the bug you reported was fixed by an update.

 ... mmm... if i had even a little bit more space on my system, and
bandwidth even 5x higher than our current 256mbits/sec limit, i'd be
tempted to try that.

 Please look at `/usr/share/doc/libavutil51/changelog.Debian.gz` and see
 if it has changed from August 15th.

ffmpeg-dmo (7:0.11.1-dmo4) unstable; urgency=low

  * Build with --enable-libcdio, --enable-gnutls, --enable-frei0r,
--enable-openssl and --enable-libass and add libcdio-paranoia-dev,
libgnutls-dev, libssl-dev, libass-dev and frei0r-plugins-dev to
Build-Depends.

 -- Christian Marillat maril...@deb-multimedia.org  Tue, 31 Jul 2012
18:01:28 +0200


 As a side not, most of these packages should be in Debian now [3][4].

 ... including H.264?  the 3 codecs i've been trying out are H.261,
H.263 (and variants) and H.264.  in a desperate attempt to find 
at least _one_ bloody codec that works, i have to admit :)

 I will add the Opal folks to the CC field. Maybe they can share their
 view on this issue. Maybe it is possible to release 3.10.5 with all
 these fixes added to it.

 i tried 3.10.5 as well.  it really didn't work.  it really is only
3.11alpha2 that had *any* level of success or stability.

 if i recall correctly (it was a week ago) 3.10.5 worked i.e. didn't
crash when used in opalmcu and openphone, but both
openphone/opal3.10.5 and ekiga/opal3.10.4 (which works other than the
crash at the end) wouldn't do two-way video.  something like that.
the amount of testing i've had to do, to be honest i was getting numb.
 oh look, it's another crash: let's try yet

Bug#637039: Re: lsb-release: parse_apt_policy in lsb_release.py fails

[Luke Kenneth Casson Leighton]

On Fri, Mar 2, 2012 at 8:50 AM, Didier 'OdyX' Raboud o...@debian.org wrote:
 tags 637039 +unreproducible +moreinfo
 thanks

 ok it's not exactly a patch but close:
 policy = commands.getoutput('LANG=C apt-cache policy 2/dev/null')

 should be:
 policy = commands.getoutput('LANG=C apt-cache policy 2/dev/null')

 in lsb_release.py parse_apt_policy function

  ok, yep, right, i know i know - this is completely wrong :)  there's
 something else going belly-up - shown here:

 lsb_release.py has seen various improvements before the upload of lsb
 3.2+Debian29; could you please try to reproduce your bug with
 lsb-release=3.2+Debian29 currently available in unstable ?

 ahh, didier, many apologies, this was such a long time ago, i can't
remember what i was doing which triggered the bug! :)

l.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660487: xulrunner-dev: instant segfault in startup (related to jemalloc)

[Luke Kenneth Casson Leighton]

On 2/19/12, Mike Hommey m...@glandium.org wrote:
 On Sun, Feb 19, 2012 at 03:29:03PM +, lkcl wrote:
 Package: xulrunner-dev
 Version: 10.0.1-1
 Severity: normal

 https://bugzilla.mozilla.org/show_bug.cgi?id=728500
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660178

 there's a segfault been noted when using hulahop which was not present
 in version 9 of xulrunner.  the mozilla team kindly advised to stop
 using jemalloc (--disable-jemalloc) whilst the issue was being
 investigated but that may not be the root cause of the problem.

 I guess this is https://bugzilla.mozilla.org/show_bug.cgi?id=720682

 don't know - i've mentioned it in there so that someone can make a
decision to either investigate further or mark it as a duplicate.

 l.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660487: xulrunner-dev: instant segfault in startup (related to jemalloc)

[Luke Kenneth Casson Leighton]

https://bugzilla.mozilla.org/show_bug.cgi?id=678977#c46

mike hi, it looks like this has been solved, and i leave it in your
capable hands to sort out xulrunner - the question remaining is: what
to do now about hulahop?  i've been asked to help get hulahop into a
working state, but xulrunner 10 is so badly borked that that's
impossible.  that would be fine, if it wasn't for the fact that
xulrunner-dev has now overwritten and replaced xulrunner-9-dev, making
it impossible to now compile up python-hulahop.

l.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org