Bug#992940: jenkins.debian.org: f-droid reproducible builds need virtualbox (which is now gone)
Package: jenkins.debian.org Severity: important X-Debbugs-Cc: f...@obfusk.net Hi! F-Droid's reproducible build jobs are broken b/c they need virtualbox, which hasn't been available in Debian stable for some time [1]. We should probably migrate to libvirt, but in the short term, using virtualbox from unstable would probably be the "best" solution. - Felix [1] https://salsa.debian.org/qa/jenkins.debian.net/-/commit/210570694f21a88d0e925997d944991884328ccf
[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order
Change by Felix C. Stegerman : -- nosy: +obfusk ___ Python tracker <https://bugs.python.org/issue37596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What are desired semantics for /etc/shells?
* Helmut Grohne [2021-06-28 14:46]: > On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote: > > It also means that on /usr-merged systems e.g. /bin/screen is not a > > "valid" shell, but /usr/bin/screen is (even though they are the same > > file), which may be fine in practice but seems counter-intuitive to > > me. > > Valid concern. Do you think that I should include machinery specifically > for handling the /usr merge in update-shells? Automatically adding > /bin/screen on /usr-merged systems where shells.d contains > /usr/bin/screen is feasible. I see little value though as > /usr/bin/screen has always worked on Debian and why would anyone use > /bin/screen now? Few people would probably *change* /usr/bin/screen to /bin/screen. But some people -- maybe new users -- might not know that /usr/bin/screen is more "traditional"/"canonical" than /bin/screen. I myself might be tempted to use /bin/screen when editing a file (and knowing that /bin = /usr/bin on the relevant system(s)) since it's shorter :) Also: there's no /usr/bin/sh. Now *I* would always type /bin/sh, but setting my shell to $(which sh) would currently result in an invalid shell: |$ which sh |/usr/bin/sh |$ grep $(which sh) /etc/shells || echo OOPS |OOPS Personally, I'd prefer some consistency at least. Either always provide both paths on merged /usr systems, or only provide the "canonical" path on all systems. Not some shells with both entries and some with only one. > #699177 I didn't know about that bug. Thanks. - Felix
Bug#990388: ITP: jiten-nonfree-data -- non-free pitch & audio data for Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten-nonfree-data Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : CC-BY-NC (audio) + Wadoku.de-Daten-Lizenz (pitch) Description : non-free pitch & audio data for Jiten Japanese Dictionary Non-free data files for Jiten Japanese Dictionary. These files are optional, so the jiten and jiten-data packages should be able to go into main, whereas the jiten-audio and jiten-pitch packages go into non-free. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) Dependencies not yet in Debian: jiten [2], (transitively) kanjidraw [3]. The pitch data is licensed under the Wadoku.de-Daten-Lizenz [4]. - Felix [1] https://salsa.debian.org/obfusk/jiten-nonfree-data/-/tree/debian/sid [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990387 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516 [4] https://www.wadoku.de/wiki/display/WAD/Wadoku.de-Daten+Lizenz
Bug#990388: ITP: jiten-nonfree-data -- non-free pitch & audio data for Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-devel@lists.debian.org, f...@obfusk.net * Package name: jiten-nonfree-data Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : CC-BY-NC (audio) + Wadoku.de-Daten-Lizenz (pitch) Description : non-free pitch & audio data for Jiten Japanese Dictionary Non-free data files for Jiten Japanese Dictionary. These files are optional, so the jiten and jiten-data packages should be able to go into main, whereas the jiten-audio and jiten-pitch packages go into non-free. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) Dependencies not yet in Debian: jiten [2], (transitively) kanjidraw [3]. The pitch data is licensed under the Wadoku.de-Daten-Lizenz [4]. - Felix [1] https://salsa.debian.org/obfusk/jiten-nonfree-data/-/tree/debian/sid [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990387 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516 [4] https://www.wadoku.de/wiki/display/WAD/Wadoku.de-Daten+Lizenz
Bug#990388: ITP: jiten-nonfree-data -- non-free pitch & audio data for Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten-nonfree-data Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : CC-BY-NC (audio) + Wadoku.de-Daten-Lizenz (pitch) Description : non-free pitch & audio data for Jiten Japanese Dictionary Non-free data files for Jiten Japanese Dictionary. These files are optional, so the jiten and jiten-data packages should be able to go into main, whereas the jiten-audio and jiten-pitch packages go into non-free. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) Dependencies not yet in Debian: jiten [2], (transitively) kanjidraw [3]. The pitch data is licensed under the Wadoku.de-Daten-Lizenz [4]. - Felix [1] https://salsa.debian.org/obfusk/jiten-nonfree-data/-/tree/debian/sid [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990387 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516 [4] https://www.wadoku.de/wiki/display/WAD/Wadoku.de-Daten+Lizenz
Bug#990387: ITP: jiten -- Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : AGPLv3+ (code) + various other licenses (data) Programming Lang: Python Description : Jiten Japanese Dictionary Jiten is a Japanese dictionary based on JMDict/Kanjidic . Features: . Fine-grained search using regexes (regular expressions) * simple searches don't require knowledge of regexes * quick reference available in the web interface and android app . JMDict multilingual japanese dictionary * kanji, readings (romaji optional), meanings & more * meanings in english, dutch, german, french and/or spanish * pitch accent (from Wadoku, non-free) * browse by frequency/jlpt . Kanji dictionary * readings (romaji optional), meanings (english), jmdict entries, radicals & more * search using SKIP codes * search by radical * handwritten kanji recognition * browse by frequency/level/jlpt/SKIP . Example sentences (from Tatoeba) * with english, dutch, german, french and/or spanish translation * some with audio (non-free) . Stroke order * input a word or sentence and see how it's written . Interfaces: . Android app * wraps the web interface (running locally on your device) in a webview * completely offline, no internet access required * easily share and open jiten.obfusk.dev links * not included in this Debian package . Web interface * available online at https://jiten.obfusk.dev * light/dark mode * search history (stored locally) * tooltips to quickly see meanings and readings for kanji and words * use long press for tooltips on mobile * converts romaji to hiragana and between hiragana and katakana * can be run on your own computer . Command-line interface . WebView GUI * wraps the web interface (running locally on your computer) * requires python3-webview I'm the developer of Jiten Japanese Dictionary. I also maintain the NixOS package. The Android version is available on F-Droid. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) I'll upload a source package to mentors.debian.net after I release v1.1.0 in a few days. Dependencies not yet in Debian: kanjidraw [2]. - Felix [1] https://salsa.debian.org/obfusk/jiten/-/tree/debian/sid [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516
Bug#990387: ITP: jiten -- Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-devel@lists.debian.org, f...@obfusk.net * Package name: jiten Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : AGPLv3+ (code) + various other licenses (data) Programming Lang: Python Description : Jiten Japanese Dictionary Jiten is a Japanese dictionary based on JMDict/Kanjidic . Features: . Fine-grained search using regexes (regular expressions) * simple searches don't require knowledge of regexes * quick reference available in the web interface and android app . JMDict multilingual japanese dictionary * kanji, readings (romaji optional), meanings & more * meanings in english, dutch, german, french and/or spanish * pitch accent (from Wadoku, non-free) * browse by frequency/jlpt . Kanji dictionary * readings (romaji optional), meanings (english), jmdict entries, radicals & more * search using SKIP codes * search by radical * handwritten kanji recognition * browse by frequency/level/jlpt/SKIP . Example sentences (from Tatoeba) * with english, dutch, german, french and/or spanish translation * some with audio (non-free) . Stroke order * input a word or sentence and see how it's written . Interfaces: . Android app * wraps the web interface (running locally on your device) in a webview * completely offline, no internet access required * easily share and open jiten.obfusk.dev links * not included in this Debian package . Web interface * available online at https://jiten.obfusk.dev * light/dark mode * search history (stored locally) * tooltips to quickly see meanings and readings for kanji and words * use long press for tooltips on mobile * converts romaji to hiragana and between hiragana and katakana * can be run on your own computer . Command-line interface . WebView GUI * wraps the web interface (running locally on your computer) * requires python3-webview I'm the developer of Jiten Japanese Dictionary. I also maintain the NixOS package. The Android version is available on F-Droid. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) I'll upload a source package to mentors.debian.net after I release v1.1.0 in a few days. Dependencies not yet in Debian: kanjidraw [2]. - Felix [1] https://salsa.debian.org/obfusk/jiten/-/tree/debian/sid [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516
Bug#990387: ITP: jiten -- Jiten Japanese Dictionary
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: jiten Version : 1.1.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/jiten * License : AGPLv3+ (code) + various other licenses (data) Programming Lang: Python Description : Jiten Japanese Dictionary Jiten is a Japanese dictionary based on JMDict/Kanjidic . Features: . Fine-grained search using regexes (regular expressions) * simple searches don't require knowledge of regexes * quick reference available in the web interface and android app . JMDict multilingual japanese dictionary * kanji, readings (romaji optional), meanings & more * meanings in english, dutch, german, french and/or spanish * pitch accent (from Wadoku, non-free) * browse by frequency/jlpt . Kanji dictionary * readings (romaji optional), meanings (english), jmdict entries, radicals & more * search using SKIP codes * search by radical * handwritten kanji recognition * browse by frequency/level/jlpt/SKIP . Example sentences (from Tatoeba) * with english, dutch, german, french and/or spanish translation * some with audio (non-free) . Stroke order * input a word or sentence and see how it's written . Interfaces: . Android app * wraps the web interface (running locally on your device) in a webview * completely offline, no internet access required * easily share and open jiten.obfusk.dev links * not included in this Debian package . Web interface * available online at https://jiten.obfusk.dev * light/dark mode * search history (stored locally) * tooltips to quickly see meanings and readings for kanji and words * use long press for tooltips on mobile * converts romaji to hiragana and between hiragana and katakana * can be run on your own computer . Command-line interface . WebView GUI * wraps the web interface (running locally on your computer) * requires python3-webview I'm the developer of Jiten Japanese Dictionary. I also maintain the NixOS package. The Android version is available on F-Droid. I've already packaged it for Debian [1], but I need a sponsor and could use some advice on how best to deal with some of the remaining complaints from lintian :) I'll upload a source package to mentors.debian.net after I release v1.1.0 in a few days. Dependencies not yet in Debian: kanjidraw [2]. - Felix [1] https://salsa.debian.org/obfusk/jiten/-/tree/debian/sid [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988516
Re: What are desired semantics for /etc/shells?
Hi, * Helmut Grohne [2021-06-24 08:10]: > Felix C. Stegerman cautioned that the contents of /etc/shells depends on > whether the underlying system is /usr-merged. It also means that on /usr-merged systems e.g. /bin/screen is not a "valid" shell, but /usr/bin/screen is (even though they are the same file), which may be fine in practice but seems counter-intuitive to me. > * While the order of /etc/shells will not be sorted, it will be >deterministic if update-shells is run after all packages have been >unpacked. Installing two packages one after another will still cause >their order in /etc/shells to differ, but changing the order of >/etc/shells could break comments left by administrators. So this is a >compromise that partially improves reproducibility without regressing >maintainability of /etc/shells. I hope that it is sufficient in >practice. Sorting /etc/shells if the only comment in it is the current |# /etc/shells: valid login shells on line 1 would seem acceptable to me. > for f in "$PKG_DIR/"*; do Would it make sense to set LC_COLLATE for deterministic ordering here? - Felix
apksigcopier v1.0.0
Hi! > apksigcopier is a tool for copying APK signatures from a signed APK > to an unsigned one (in order to verify reproducible builds). It can > also be used to compare two APKs with different signatures. As apksigcopier [1] -- including the vendored copy in fdroidserver [2] -- has worked reliably ever since the release of v0.5.0 in April, I released v1.0.0 this week, which adds a "compare" subcommand to easily compare two APKs with different signatures (this requires apksigner). (Thanks to Holger, it will join v0.5.0 in Debian's NEW queue soon.) - Felix [1] https://github.com/obfusk/apksigcopier [2] https://gitlab.com/fdroid/fdroidserver
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Felix C. Stegerman added the comment:
https://github.com/obfusk/apksigcopier currently produces reproducible ZIP
files identical to those produced by apksigner using this code:
DATETIMEZERO = (1980, 0, 0, 0, 0, 0)
class ReproducibleZipInfo(zipfile.ZipInfo):
"""Reproducible ZipInfo hack."""
_override = {} # type: Dict[str, Any]
def __init__(self, zinfo, **override):
if override:
self._override = {**self._override, **override}
for k in self.__slots__:
if hasattr(zinfo, k):
setattr(self, k, getattr(zinfo, k))
def __getattribute__(self, name):
if name != "_override":
try:
return self._override[name]
except KeyError:
pass
return object.__getattribute__(self, name)
class APKZipInfo(ReproducibleZipInfo):
"""Reproducible ZipInfo for APK files."""
_override = dict(
compress_type=8,
create_system=0,
create_version=20,
date_time=DATETIMEZERO,
external_attr=0,
extract_version=20,
flag_bits=0x800,
)
def patch_meta(...):
...
with zipfile.ZipFile(output_apk, "a") as zf_out:
info_data = [(APKZipInfo(info, date_time=date_time), data)
for info, data in extracted_meta]
_write_to_zip(info_data, zf_out)
if sys.version_info >= (3, 7):
def _write_to_zip(info_data, zf_out):
for info, data in info_data:
zf_out.writestr(info, data, compresslevel=9)
else:
def _write_to_zip(info_data, zf_out):
old = zipfile._get_compressor
zipfile._get_compressor = lambda _: zlib.compressobj(9, 8, -15)
try:
for info, data in info_data:
zf_out.writestr(info, data)
finally:
zipfile._get_compressor = old
--
___
Python tracker
<https://bugs.python.org/issue43547>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Creëer initrd.img
* Cecil Westerhof [2021-06-16 11:44]: > Bij apt upgrade is er iets fout gegaan. in / zie ik: > lrwxrwxrwx 1 root root 30 Jun 12 09:54 initrd.img -> > boot/initrd.img-5.10.0-7-amd64 > lrwxrwxrwx 1 root root 30 Jun 12 09:54 initrd.img.old -> > boot/initrd.img-5.10.0-6-amd64 > > Maar ze bestaan allebei niet. > Hoe kan ik die opnieuw creëren? Als het goed is met update-initramfs. - Felix
Re: What are desired semantics for /etc/shells?
Hi! * Helmut Grohne [2021-06-10 20:00]: > […] > Inconsistency > = > > Some maintainer scripts take care to only run `add-shell` for initial > configuration or for upgrading from an ancient version that didn't call > `add-shell`. Others call `add-shell` for every invocation of `postinst`. > […] FYI I just noticed another inconsistency: on my merged /usr systems (installed as such, not converted later w/ usrmerge), /etc/shells contains both /bin/ and /usr/bin/ paths for some shells, but not all (e.g. no /usr/bin/sh, no /bin/screen). $ sort /etc/shells # /etc/shells: valid login shells /bin/bash /bin/dash /bin/rbash /bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/rbash /usr/bin/screen /usr/bin/tmux - Felix
Re: [Request for help] Making brian reproducible
Hi! * Nilesh Patra [2021-06-10 18:36]: > Many thanks for your patches, I applies both of them and reprotest CI goes > green now![1] \o/ > Super thanks for your help! > > I'll file a bug report now > > [1]: https://salsa.debian.org/med-team/brian/-/jobs/1694238 \o/ I already submitted the patches upstream and the pull requests [1,2] have just been merged. - Felix [1] https://github.com/brian-team/brian2/pull/1311 [2] https://github.com/brian-team/brian2/pull/1312 ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Request for help] Making brian reproducible
Hi!
* "Felix C. Stegerman" [2021-06-10 16:55]:
> * Nilesh Patra [2021-06-07 21:16]:
> > * Only _some_ files in the documentation it vendors has stuff (like tags,
> > examples, links) in random order across different builds.
> > By the looks of it, it seems this randomness is due to the way data is
> > being inserted into files with the brian2/sphinxext/generate_examples.py
> > script,
> > but I am having trouble figuring it out beyond this point.
> >
> > My changes are pushed here[1], the failing reprotest CI can be found
> > here[2], and this is the diffoscope[3]
> >
> > [1]: https://salsa.debian.org/med-team/brian/-/blob/make-reproducible
> > [2]: https://salsa.debian.org/med-team/brian/-/jobs/1688958
> > [3]: http://paste.debian.net/1200330/
I also found a bug in brian2/sphinxext/generate_examples.py that's
another source of irreproducibility; here's a patch:
--- a/brian2/sphinxext/generate_examples.py
+++ b/brian2/sphinxext/generate_examples.py
@@ -160,7 +160,7 @@
category_additional_files[relpath].append((file, full_name))
with codecs.open(fname, 'rU', encoding='utf-8') as f:
content = f.read()
-output = file + '\n' + '=' * len(title) + '\n\n'
+output = file + '\n' + '=' * len(file) + '\n\n'
output += '.. code:: none\n\n'
content_lines = ['\t' + l for l in content.split('\n')]
output += '\n'.join(content_lines)
- Felix
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Request for help] Making brian reproducible
Hi! * Nilesh Patra [2021-06-07 21:16]: > * Only _some_ files in the documentation it vendors has stuff (like tags, > examples, links) in random order across different builds. > By the looks of it, it seems this randomness is due to the way data is being > inserted into files with the brian2/sphinxext/generate_examples.py script, > but I am having trouble figuring it out beyond this point. > > My changes are pushed here[1], the failing reprotest CI can be found here[2], > and this is the diffoscope[3] > > [1]: https://salsa.debian.org/med-team/brian/-/blob/make-reproducible > [2]: https://salsa.debian.org/med-team/brian/-/jobs/1688958 > [3]: http://paste.debian.net/1200330/ I've briefly looked at the diffoscope output and the code. One of the problems seems to be that auto_find_examples() from brian2/sphinxext/examplefinder.py loops over the lists "tutorials" and "examples", the order of which depends on the file system. I haven't tested it, but I think this patch would help: --- a/brian2/sphinxext/examplefinder.py +++ b/brian2/sphinxext/examplefinder.py @@ -54,9 +54,9 @@ ''' name = obj.__name__ examples_map = get_examples_map() -examples = the_examples_map[name] +examples = sorted(the_examples_map[name]) tutorials_map = get_tutorials_map() -tutorials = the_tutorials_map[name] +tutorials = sorted(the_tutorials_map[name]) if len(examples+tutorials)==0: return '' txt = 'Tutorials and examples using this' - Felix ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
How can I contribute?
Hi! I'd like to contribute to Reproducible Builds (for Debian). I've read [1] and requested access to [2]; unfortunately, [3] is a broken link. - Felix [1] https://reproducible-builds.org/contribute/ [2] http://salsa.debian.org/reproducible-builds [3] https://reproducible-builds.org/contribute/debian/
RFS: kanjidraw/0.2.3-1 [ITP] -- handwritten kanji recognition library + gui
Hi! I am looking for a sponsor for my package "kanjidraw": * Package name: kanjidraw Version : 0.2.3-1 Upstream Author : f...@obfusk.net * URL : https://github.com/obfusk/kanjidraw * License : AGPL-3.0-or-later, CC-BY-SA-3.0 * Vcs : https://salsa.debian.org/obfusk/kanjidraw Section : python It builds those binary packages: kanjidraw - handwritten kanji recognition - gui python3-kanjidraw - handwritten kanji recognition - library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kanjidraw/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kanjidraw/kanjidraw_0.2.3-1.dsc Changes for the initial release: kanjidraw (0.2.3-1) unstable; urgency=medium . * Initial release. Closes: #988516 Thanks! - Felix signature.asc Description: PGP signature
Bug#988789: diffoscope: .so files are compared using a binary diff in Android APKs
Hi Hans & Chris, * Chris Lamb [2021-05-19 19:04]: > > APKs (Android app files) often contain Linux ELF shared library files, e.g. > > lib/arm64-v8a/libtor.so. These are only compared using a binary diff, but > > they > > should use the shared library comparison. The output looks like: > > It would be great to fix this for you. Could you provide some example > APK files so I can reproducible what you are currently seeing but also > confirm that any changes actually solve your problem? FWIW: I've used diffoscope on quite a few APKs, many of which included .so files, and haven't seen this bug before. I'd be happy to help debug/fix this if someone can provide an example APK. - Felix
Bug#988789: diffoscope: .so files are compared using a binary diff in Android APKs
Hi Hans & Chris, * Chris Lamb [2021-05-19 19:04]: > > APKs (Android app files) often contain Linux ELF shared library files, e.g. > > lib/arm64-v8a/libtor.so. These are only compared using a binary diff, but > > they > > should use the shared library comparison. The output looks like: > > It would be great to fix this for you. Could you provide some example > APK files so I can reproducible what you are currently seeing but also > confirm that any changes actually solve your problem? FWIW: I've used diffoscope on quite a few APKs, many of which included .so files, and haven't seen this bug before. I'd be happy to help debug/fix this if someone can provide an example APK. - Felix ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
request to join the team
Hi! I'd like to join the Debian Python Team :) I develop several Python libraries & tools, which I'd like to package and maintain for Debian, such as: * apksigcopier [1], which has already been sponsored by Holger Levsen. * kanjidraw [2], for which I need a sponsor :) * jiten [3], which I hope to package soon as well. Currently I'm perfectly happy to maintain all of these packages by myself, other than needing a sponsor. But I'm happy to accept help from the team and contribute to other packages when I can. My salsa login: obfusk I have read and accepted https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thanks! - Felix [1] https://mentors.debian.net/package/apksigcopier/ [2] https://mentors.debian.net/package/kanjidraw/ [3] https://github.com/obfusk/jiten signature.asc Description: PGP signature
Bug#988516: ITP: kanjidraw -- handwritten kanji recognition library + gui
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: kanjidraw Version : 0.2.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/kanjidraw * License : AGPLv3+ (code) + CC-BY-SA-3.0 (data) Programming Lang: Python Description : handwritten kanji recognition library + gui kanjidraw is a simple Python library + GUI for matching (the strokes of a) handwritten kanji against its database. You can use the GUI to draw and subsequently select a kanji from the list of probable matches, which will then be copied to the clipboard. The database is based on KanjiVG and the algorithms are based on the Kanji draw Android app. I both develop and use kanjidraw. It's also a dependency for Jiten Japanese Dictionary [1], which I also want to package for Debian soon. I've already packaged it for Debian [2], but I need a sponsor :) I'll upload a source package to mentors.debian.net soon. - Felix [1] https://github.com/obfusk/jiten [2] https://salsa.debian.org/obfusk/kanjidraw/-/tree/debian/sid
Bug#988516: ITP: kanjidraw -- handwritten kanji recognition library + gui
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-devel@lists.debian.org, f...@obfusk.net * Package name: kanjidraw Version : 0.2.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/kanjidraw * License : AGPLv3+ (code) + CC-BY-SA-3.0 (data) Programming Lang: Python Description : handwritten kanji recognition library + gui kanjidraw is a simple Python library + GUI for matching (the strokes of a) handwritten kanji against its database. You can use the GUI to draw and subsequently select a kanji from the list of probable matches, which will then be copied to the clipboard. The database is based on KanjiVG and the algorithms are based on the Kanji draw Android app. I both develop and use kanjidraw. It's also a dependency for Jiten Japanese Dictionary [1], which I also want to package for Debian soon. I've already packaged it for Debian [2], but I need a sponsor :) I'll upload a source package to mentors.debian.net soon. - Felix [1] https://github.com/obfusk/jiten [2] https://salsa.debian.org/obfusk/kanjidraw/-/tree/debian/sid
Bug#988516: ITP: kanjidraw -- handwritten kanji recognition library + gui
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: kanjidraw Version : 0.2.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/kanjidraw * License : AGPLv3+ (code) + CC-BY-SA-3.0 (data) Programming Lang: Python Description : handwritten kanji recognition library + gui kanjidraw is a simple Python library + GUI for matching (the strokes of a) handwritten kanji against its database. You can use the GUI to draw and subsequently select a kanji from the list of probable matches, which will then be copied to the clipboard. The database is based on KanjiVG and the algorithms are based on the Kanji draw Android app. I both develop and use kanjidraw. It's also a dependency for Jiten Japanese Dictionary [1], which I also want to package for Debian soon. I've already packaged it for Debian [2], but I need a sponsor :) I'll upload a source package to mentors.debian.net soon. - Felix [1] https://github.com/obfusk/jiten [2] https://salsa.debian.org/obfusk/kanjidraw/-/tree/debian/sid
[issue29708] support reproducible Python builds
Felix C. Stegerman added the comment: Hi! I've been working on reproducible builds for python-for-android [1,2,3]. Current issues with .pyc files are: * .pyc files differ depending on whether Python was compiled w/ liblzma-dev installed or not; * many .pyc files include build paths; * some .pyc files include paths to system utilities, like `/bin/mkdir` or `/usr/bin/install`, which can differ between systems (e.g. on Debian w/ merged /usr). [1] https://github.com/kivy/python-for-android/pull/2390 [2] https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002132.html [3] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002207.html -- ___ Python tracker <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Change by Felix C. Stegerman : -- nosy: +obfusk ___ Python tracker <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: verifying reproducible APKs: apksigcopier
Hi! I just released v0.5.0 of apksigcopier, which is the same code that has now also been merged into fdroidserver master as a vendored library. I've also uploaded a Debian source package to mentors.debian.net, which is now awaiting Holger's sponsorship. - Felix
[issue2824] zipfile to handle duplicate files in archive
Change by Felix C. Stegerman : -- nosy: +obfusk ___ Python tracker <https://bugs.python.org/issue2824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Bug#986719: fdroidserver: should not depend on (python3-)vagrant
Package: fdroidserver Version: 2.0.1-1 Severity: normal X-Debbugs-Cc: f...@obfusk.net Hi! Currently, fdroidserver Depends: on python3-vagrant which in turn Depends: on vagrant itself. Since fdroidserver has many use cases that don't require vagrant, I think it would be better to downgrade that to a Recommends: or Suggests: Thanks. - Felix
Re: verifying reproducible APKs: apksigcopier
Hi Torsten, * Torsten Grote [2021-03-31 16:58]: > On Sunday, 28 March 2021 22:02:33 -03 Felix C. Stegerman wrote: > > apksigcopier [2], a tool to copy APK signatures > > from a signed APK to an unsigned one. > > What kind of signatures does the tool support (couldn't find > this in the README)? v1, v2 and v3? Correct. I've added this information to the README :) - Felix
Bug#986179: ITP: apksigcopier -- copy/extract/patch apk signatures
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-devel@lists.debian.org, f...@obfusk.net * Package name: apksigcopier Version : 0.3.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/apksigcopier * License : GPLv3+ Programming Lang: Python Description : copy/extract/patch apk signatures apksigcopier is a tool for copying APK signatures from a signed APK to an unsigned one (in order to verify reproducible builds). Its command-line tool offers three operations: * copy signatures directly from a signed to an unsigned APK * extract signatures from a signed APK to a directory * patch previously extracted signatures onto an unsigned APK The F-Droid reproducible builds & verification effort recently led [1] to the development of apksigcopier. I've started packaging it for Debian [2] and I have an offer from Holger Levsen to sponsor my uploads [3]. - Felix [1] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002214.html [2] https://salsa.debian.org/obfusk/apksigcopier/-/commits/debian/sid [3] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002215.html
Bug#986179: ITP: apksigcopier -- copy/extract/patch apk signatures
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: apksigcopier Version : 0.3.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/apksigcopier * License : GPLv3+ Programming Lang: Python Description : copy/extract/patch apk signatures apksigcopier is a tool for copying APK signatures from a signed APK to an unsigned one (in order to verify reproducible builds). Its command-line tool offers three operations: * copy signatures directly from a signed to an unsigned APK * extract signatures from a signed APK to a directory * patch previously extracted signatures onto an unsigned APK The F-Droid reproducible builds & verification effort recently led [1] to the development of apksigcopier. I've started packaging it for Debian [2] and I have an offer from Holger Levsen to sponsor my uploads [3]. - Felix [1] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002214.html [2] https://salsa.debian.org/obfusk/apksigcopier/-/commits/debian/sid [3] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002215.html
Bug#986179: ITP: apksigcopier -- copy/extract/patch apk signatures
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" X-Debbugs-Cc: debian-de...@lists.debian.org, f...@obfusk.net * Package name: apksigcopier Version : 0.3.0 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/apksigcopier * License : GPLv3+ Programming Lang: Python Description : copy/extract/patch apk signatures apksigcopier is a tool for copying APK signatures from a signed APK to an unsigned one (in order to verify reproducible builds). Its command-line tool offers three operations: * copy signatures directly from a signed to an unsigned APK * extract signatures from a signed APK to a directory * patch previously extracted signatures onto an unsigned APK The F-Droid reproducible builds & verification effort recently led [1] to the development of apksigcopier. I've started packaging it for Debian [2] and I have an offer from Holger Levsen to sponsor my uploads [3]. - Felix [1] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002214.html [2] https://salsa.debian.org/obfusk/apksigcopier/-/commits/debian/sid [3] https://lists.reproducible-builds.org/pipermail/rb-general/2021-March/002215.html
verifying reproducible APKs: apksigcopier
Hi! The F-Droid reproducible builds & verification effort recently led [1] to the development of apksigcopier [2], a tool to copy APK signatures from a signed APK to an unsigned one. ( I've started packaging it for Debian [3] and intend to file an ITP soon, but since I'm not a Debian developer -- yet, though I'd like to become one -- I could use some help with that. ) - Felix [1] https://gitlab.com/fdroid/fdroidserver/-/merge_requests/802 [2] https://github.com/obfusk/apksigcopier [3] https://salsa.debian.org/obfusk/apksigcopier/-/commits/debian/sid
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Felix C. Stegerman added the comment: > The __getattr__ hack is not needed. You can reset the flags in a different, > more straight forward way As mentioned, ZipFile._open_to_write() will modify the ZipInfo's .external_attr when it is set to 0. > I just found another specific example in _open_to_write(). 0 is a valid > value for zinfo.external_attr. But this code always forces 0 to something > else: > > if not zinfo.external_attr: > zinfo.external_attr = 0o600 << 16 # permissions: ?rw--- Your alternative doesn't seem to take that subsequent modification into account. -- ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Felix C. Stegerman added the comment: > external_attr == 0 may cause issues with permissions. That may be true in some scenarios, but not being able to set it to 0 means you can't create identical files to those produced by other tools -- like those used to generate APKs -- which do in fact set it to 0. -- ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Felix C. Stegerman : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Felix C. Stegerman : -- components: +Library (Lib) ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Felix C. Stegerman : -- components: -IO, Library (Lib) versions: -Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Felix C. Stegerman added the comment: I've closed the PR for now. Using a carefully crafted ZipInfo object doesn't work because ZipFile modifies its .external_attr when set to 0. Using something like this quickly hacked together ZipInfo subclass does work: class ZeroedZipInfo(zipfile.ZipInfo): def __init__(self, zinfo): for k in self.__slots__: setattr(self, k, getattr(zinfo, k)) def __getattribute__(self, name): if name == "date_time": return (1980,0,0,0,0,0) if name == "external_attr": return 0 return object.__getattribute__(self, name) ... myzipfile.writestr(ZeroedZipInfo(info), data) -- components: +IO type: enhancement -> versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Felix C. Stegerman added the comment: I've created a draft PR; RFC :) Also: * setting the date to (1980,0,0,0,0,0) already works; * the main issue seems to be that external_attr cannot be 0 atm. -- ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Felix C. Stegerman : -- keywords: +patch pull_requests: +23737 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24979 ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Felix C. Stegerman : -- nosy: +obfusk ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: reproducible .pyc files (& python-for-android)
* "Bernhard M. Wiedemann" [2021-01-04 12:48]: > This is not a timestamp issue, though. If those are varying, they are in > the header (first 12 bytes) of the .pyc. > > > │ 00f0: 6d5a 0d62 6469 7374 5f77 696e 696e 7374 mZ.bdist_wininst > │ -0100: 5a05 6368 6563 6b5a 0675 706c 6f61 644e Z.checkZ.uploadN > │ +0100: da05 6368 6563 6b5a 0675 706c 6f61 644e ..checkZ.uploadN > > > I have seen this before and remember something about python string > reference counters being dumped into these pickle files and that varied > from ordering, so that > py_compile py1.py py2.py > produced different results than > py_compile py2.py py1.py > > One way to get reproducible results is to delete and recreate all .pyc > files with > find -type f -a -name "*.py" -print0 | > sort -z | > xargs -0 $python_binary -m py_compile > > > Maybe related: creating .pyc files on i586 and x86_64 (with identical > toolchain) always produced different results for me. I was finally able to reproduce this on another machine. This particular difference is caused by whether the system has liblzma-dev installed or not (when Python is built). - Felix
Bug#984926: chromium: doesn't seem to build with libvpx 1.7.0
Package: chromium Version: 89.0.4389.82-1 Severity: normal X-Debbugs-Cc: f...@obfusk.net Hi! It looks like the latest version doesn't build with libvpx 1.7.0. So far I've only tried building it on Ubuntu [1], but I assume buster has the same problem. - Felix [1] https://launchpadlibrarian.net/527195725/buildlog_ubuntu-focal-amd64.chromium_89.0.4389.82-1ppa~focal1_BUILDING.txt.gz
Bug#981010: rxvt-unicode: urxvt segfaults at exit
Hi, I can reproduce this after a "xrdb -load /dev/null". However, I only seem to be able to reproduce it when I start urxvt via an i3 keybinding. If I start it via dmenu or by running "urxvt" from another terminal, I don't see a segfault in the logs. - Felix
Bug#982546: additional information
* "Felix C. Stegerman" [2021-02-11 18:09]:
> I forgot to mention that I first tried removing the
>
> handle->id_product == SCM_SPR532
>
> check in ccid_vendor_specific_setup(), but that didn't work.
Which makes sense since SCM_SPR532 and SCM_SPR332 apparently have the
same product id.
I've attached an improved patch.
- Felix
--- gnupg2-2.2.27.orig/scd/ccid-driver.c
+++ gnupg2-2.2.27/scd/ccid-driver.c
@@ -1304,10 +1304,20 @@
{
if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
{
+ libusb_clear_halt (handle->idev, handle->ep_intr);
+}
+ return 0;
+}
+
+
+static int
+ccid_vendor_specific_transceive_setup (ccid_driver_t handle)
+{
+ if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
+{
DEBUGOUT ("sending escape sequence to switch to a case 1 APDU\n");
send_escape_cmd (handle, (const unsigned char*)"\x80\x02\x00", 3,
NULL, 0, NULL);
- libusb_clear_halt (handle->idev, handle->ep_intr);
}
return 0;
}
@@ -3583,6 +3593,8 @@
if (pininfo->fixedlen < 0 || pininfo->fixedlen >= 16)
return CCID_DRIVER_ERR_NOT_SUPPORTED;
+ ccid_vendor_specific_transceive_setup (handle);
+
msg = send_buffer;
msg[0] = cherry_mode? 0x89 : PC_to_RDR_Secure;
msg[5] = 0; /* slot */
Bug#982546: additional information
I forgot to mention that I first tried removing the handle->id_product == SCM_SPR532 check in ccid_vendor_specific_setup(), but that didn't work. - Felix
Bug#982546: patch file
It seems reportbug failed to include the patch file, so here it is.
- Felix
--- gnupg2-2.2.27.orig/scd/ccid-driver.c
+++ gnupg2-2.2.27/scd/ccid-driver.c
@@ -3584,6 +3584,16 @@ ccid_transceive_secure (ccid_driver_t ha
return CCID_DRIVER_ERR_NOT_SUPPORTED;
msg = send_buffer;
+
+ if (handle->id_vendor == VENDOR_SCM)
+{
+ DEBUGOUT ("sending escape sequence to switch to a case 1 APDU\n");
+ rc = send_escape_cmd (handle, (const unsigned char*)"\x80\x02\x00", 3,
+NULL, 0, NULL);
+ if (rc)
+return rc;
+}
+
msg[0] = cherry_mode? 0x89 : PC_to_RDR_Secure;
msg[5] = 0; /* slot */
msg[6] = seqno = handle->seqno++;
Bug#982546: scdaemon: SCM SPR332 smartcard reader support broken
Package: scdaemon Version: 2.2.27-1 Severity: important Tags: patch upstream X-Debbugs-Cc: f...@obfusk.net Hi! After upgrading gnupg from 2.2.20-1 to 2.2.27-1 my smartcard reader -- a SCM SPR332 -- is broken. Specifically: * I'm using the reader's keypad to enter my PIN. * The first time I need to enter my PIN, everything works fine. * Subsequent times result in a "verify CHVx failed: Invalid value". The cause seems to be upstream commit [1]. I've attached a patch that partially reverts that commit, which fixes the problem for me. I intend to report this upstream as soon as my bug tracker account is approved. - Felix [1] https://dev.gnupg.org/rG11d8d1e0505645f7d14bcc1c01d17a566e033705
Re: reproducible .pyc files (& python-for-android)
Hi Frederik, * Frederik Rietdijk [2021-01-04 14:48]: > Recently I spent some time again as well on making the Python interpreters > in Nixpkgs build reproducibly. The following Nix expression results in > deterministic builds of the 3.x interpreters we have. Search for > `determinis` and you will see the changes we do to get there. Maybe it's of > help to you. > > https://github.com/NixOS/nixpkgs/blob/f19ad43d674e5bbaa70a000f65031ab09a32a338/pkgs/development/interpreters/python/cpython/default.nix Thanks for the link! I don't really see anything significantly different to what I'm doing though. The issue I had w/ .pyc files was probably caused by something specific to the GitHub Actions Ubuntu image. I'm still kind of curious as to what that is, but I don't think it's currently worth investigating since everything works as expected using a Debian buster container/VM. - Felix
Re: reproducible .pyc files (& python-for-android)
Hi Bernhard (& Chris), * "Bernhard M. Wiedemann" [2021-01-04 12:48]: > Am 04.01.21 um 11:23 schrieb Chris Lamb: > >> p4a compiles those with "hostpython -OO -m compileall -b -f" (where > >> hostpython is the cross-compiled Python for the target -- arm64-v8a or > >> armeabi-v7a -- which is thus definitely the same version on both > >> machines). > > > > As I understand it, recent versions Python can use SOURCE_DATE_EPOCH > > in its internal py_compile routine to ensure that .pyc files are > > reproducible. > > This is not a timestamp issue, though. If those are varying, they are in > the header (first 12 bytes) of the .pyc. Indeed. I should perhaps have mentioned that I am indeed setting SOURCE_DATE_EPOCH (though that is noted in the PR I [1] linked). For reference: the Python version is 3.9.1. > │ 00f0: 6d5a 0d62 6469 7374 5f77 696e 696e 7374 mZ.bdist_wininst > │ -0100: 5a05 6368 6563 6b5a 0675 706c 6f61 644e Z.checkZ.uploadN > │ +0100: da05 6368 6563 6b5a 0675 706c 6f61 644e ..checkZ.uploadN > > I have seen this before and remember something about python string > reference counters being dumped into these pickle files and that varied > from ordering, so that > py_compile py1.py py2.py > produced different results than > py_compile py2.py py1.py That's interesting. But p4a is running "hostpython -OO -m compileall -b -f $DIRECTORY" -- and compileall walks the directory tree in sorted order -- so I don't think that's the problem here. I have currently sidestepped the issue by using a Debian buster docker container (with usrmerge installed) in GitHub Actions (instead of the default Ubuntu image). I now get identical .apks there and on a local buster VM (with the same build path) \o/ If anyone is interested in the modifications I had to make to p4a to get it to build reproducibly: see the PR [1]. It also has comments on what does and does not (yet) work. Thanks. - Felix [1] https://github.com/kivy/python-for-android/pull/2390 P.S. @Chris as a longtime Debian sid user I would also consider that my 'home' distribution :)
Bug#973848: hardware acceleration
Hi! I can confirm that adding --use-gl=desktop to /etc/chromium.d/default-flags makes hardware acceleration work (again) with chromium 87.0.4280.88-0.3 on unstable (on two systems with integrated intel graphics), according to chrome://gpu. NB: to get accelerated video decoding I had to also add --enable-accelerated-video-decode (but this is not a regression AFAIK, since it was not available at all -- at least not by default or using that option -- before). - Felix
Bug#973848: hardware acceleration
Hi! I can confirm that adding --use-gl=desktop to /etc/chromium.d/default-flags makes hardware acceleration work (again) with chromium 87.0.4280.88-0.3 on unstable (on two systems with integrated intel graphics), according to chrome://gpu. NB: to get accelerated video decoding I had to also add --enable-accelerated-video-decode (but this is not a regression AFAIK, since it was not available at all -- at least not by default or using that option -- before). - Felix
Bug#977052: rlwrap: prompt disappears w/ readline 8.1 (fixed upstream)
Package: rlwrap Version: 0.43-1+b2 Severity: important Tags: patch upstream X-Debbugs-Cc: f...@obfusk.net Hi! Bug report, analysis & fix: https://github.com/hanslub42/rlwrap/issues/108 - Felix
Bug#974669: bug analysis
Hi!
I've looked into this:
* readline 8.1 enables bracketed-paste by default;
* when bracketed-paste is enabled, rl_deprep_terminal() prints
BRACK_PASTE_FINI ("\033[?2004l\r") to rl_outstream;
* this moves the cursor to the beginning of the line (instead of the
position after the prompt), which causes the rlwrap prompt to be
overwritten during rl_redisplay().
* thus, adding "set enable-bracketed-paste off" to my ~/.inputrc fixes
the problem;
* THB I'm not entirely sure whether this is a bug in readline or in
rlwrap, so I'll report it to both upstream projects.
- Felix
Bug#974669: regression: prompt disappears in rlwrap
Package: libreadline8
Version: 8.1~rc2-2
Severity: normal
With libreadline8=8.0-4 from testing:
$ rlwrap -C test python3 -c 'while True: print("you said", input(">>> "))'
>>> foo
you said foo
>>> bar
you said bar
>>> ^D
With libreadline8=8.1~rc2-2 from unstable:
$ rlwrap -C test python3 -c 'while True: print("you said", input(">>> "))'
foo
you said foo
bar
you said bar
>>>
The ">>> " prompt is initially shown each time, but then disappears
from the output afterwards. If I input "baz" next, I get:
foo
you said foo
bar
you said bar
baz
you said baz
>>>
- Felix
[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values
Felix C. Stegerman added the comment: > specified_attributes = True is also set in xml.dom.expatbuilder. That's good to know and should perhaps be addressed as well. > Should not it be set to true in the C implementation of ElementTree? That would break existing code. Including mine. I also think the current behaviour of the C implementation makes a lot more sense, especially as there is currently no way to request the alternative. I think using specified_attributes=False as the default behaviour for both implementations is the best solution. But I certainly would not oppose adding e.g. a keyword argument to override the default behaviour for those who would prefer the alternative. -- ___ Python tracker <https://bugs.python.org/issue42151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values
Change by Felix C. Stegerman : -- keywords: +patch pull_requests: +21901 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22987 ___ Python tracker <https://bugs.python.org/issue42151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values
New submission from Felix C. Stegerman : I originally reported this as a bug in PyPy, but it turns out that CPython's C implementation (_elementtree) behaves differently than the pure Python version (b/c it sets specified_attributes = 1). PyPy issue with example code: https://foss.heptapod.net/pypy/pypy/-/issues/ -- components: Library (Lib) messages: 379637 nosy: obfusk priority: normal severity: normal status: open title: Pure Python xml.etree.ElementTree is missing default attribute values type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Bug#911777: iptables: also breaks ufw
Package: iptables
Version: 1.8.1-1
Followup-For: Bug #911777
Dear Maintainer,
The iptables upgrade from 1.6.2-1.1 to 1.8.1-1 also breaks uwf (since
that also looks for ip{,6}tables in /sbin).
I've managed to get it working again for now by:
* creating symlinks to /usr/sbin/ip{,6}tables in /sbin;
* and switching to ip{,6}tables-legacy using update-alternatives
I'm not sure why I had to switch to -legacy as well; could be because
it was using existing chains. If I have more time to investigate I
could maybe try switching back to -nft and rebooting.
- Felix
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Versions of packages iptables depends on:
ii libc62.27-6
ii libip4tc01.8.1-1
ii libip6tc01.8.1-1
ii libiptc0 1.8.1-1
ii libmnl0 1.0.4-2
ii libnetfilter-conntrack3 1.0.7-1
ii libnfnetlink01.0.1-3+b1
ii libnftnl71.1.1-1
ii libxtables12 1.8.1-1
Bug#908871: cups: completed jobs stay in queue
Thank you for the quick reply, Brian. * Brian Potkin [2018-09-16 13:50]: > Thank you for your report, Felix. > > On Sat 15 Sep 2018 at 13:20:57 +0200, Felix C. Stegerman wrote: > > > Package: cups > > Version: 2.2.8-5 > > Severity: normal > > > > Dear Maintainer, > > > > Wondering why my printer didn't seem to want to print anymore, I > > noticed that completed print jobs stay in the queue, preventing any > > subsequent jobs from printing (unless I lprm the completed job). > > > > Tried with lpr, lp and printing from chromium. Same results. > > > > Since I don't print very often, I don't know exactly when this change > > occurred, but everything was working fine about a month ago AFAIK. > > > > Printer: HP LaserJet p2015n Series, hpcups 3.17.1 (via JetDirect). > > > > Happy to help debug this if you let me know what I can try. > > My quick tests show gstoraster is failing. There is a new ghostscript > package now in unstable. Upgrade. How do you go on? > > Regards, > > Brian. That does indeed seem to fix the problem. Thanks! - Felix
Bug#908871: cups: completed jobs stay in queue
Package: cups Version: 2.2.8-5 Severity: normal Dear Maintainer, Wondering why my printer didn't seem to want to print anymore, I noticed that completed print jobs stay in the queue, preventing any subsequent jobs from printing (unless I lprm the completed job). Tried with lpr, lp and printing from chromium. Same results. Since I don't print very often, I don't know exactly when this change occurred, but everything was working fine about a month ago AFAIK. Printer: HP LaserJet p2015n Series, hpcups 3.17.1 (via JetDirect). Happy to help debug this if you let me know what I can try. Thanks. - Felix -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.2.8-5 ii cups-common2.2.8-5 ii cups-core-drivers 2.2.8-5 ii cups-daemon2.2.8-5 ii cups-filters 1.21.2-1 ii cups-ppdc 2.2.8-5 ii cups-server-common 2.2.8-5 ii debconf [debconf-2.0] 1.5.69 ii ghostscript9.22~dfsg-3 ii libavahi-client3 0.7-4 ii libavahi-common3 0.7-4 ii libc-bin 2.27-6 ii libc6 2.27-6 ii libcups2 2.2.8-5 ii libcupscgi12.2.8-5 ii libcupsimage2 2.2.8-5 ii libcupsmime1 2.2.8-5 ii libcupsppdc1 2.2.8-5 ii libgcc11:8.2.0-6 ii libstdc++6 8.2.0-6 ii libusb-1.0-0 2:1.0.22-2 ii poppler-utils 0.63.0-2 ii procps 2:3.3.15-2 Versions of packages cups recommends: ii avahi-daemon 0.7-4 ii colord 1.4.3-3 ii cups-filters [ghostscript-cups] 1.21.2-1 ii printer-driver-gutenprint5.2.13-2+b1 Versions of packages cups suggests: ii cups-bsd 2.2.8-5 pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20180604-1 ii hplip 3.17.10+repack0-5 ii printer-driver-hpcups 3.17.10+repack0-5 ii smbclient 2:4.8.5+dfsg-1 ii udev 239-9 -- debconf information excluded
Bug#908871: cups: completed jobs stay in queue
Package: cups Version: 2.2.8-5 Severity: normal Dear Maintainer, Wondering why my printer didn't seem to want to print anymore, I noticed that completed print jobs stay in the queue, preventing any subsequent jobs from printing (unless I lprm the completed job). Tried with lpr, lp and printing from chromium. Same results. Since I don't print very often, I don't know exactly when this change occurred, but everything was working fine about a month ago AFAIK. Printer: HP LaserJet p2015n Series, hpcups 3.17.1 (via JetDirect). Happy to help debug this if you let me know what I can try. Thanks. - Felix -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.2.8-5 ii cups-common2.2.8-5 ii cups-core-drivers 2.2.8-5 ii cups-daemon2.2.8-5 ii cups-filters 1.21.2-1 ii cups-ppdc 2.2.8-5 ii cups-server-common 2.2.8-5 ii debconf [debconf-2.0] 1.5.69 ii ghostscript9.22~dfsg-3 ii libavahi-client3 0.7-4 ii libavahi-common3 0.7-4 ii libc-bin 2.27-6 ii libc6 2.27-6 ii libcups2 2.2.8-5 ii libcupscgi12.2.8-5 ii libcupsimage2 2.2.8-5 ii libcupsmime1 2.2.8-5 ii libcupsppdc1 2.2.8-5 ii libgcc11:8.2.0-6 ii libstdc++6 8.2.0-6 ii libusb-1.0-0 2:1.0.22-2 ii poppler-utils 0.63.0-2 ii procps 2:3.3.15-2 Versions of packages cups recommends: ii avahi-daemon 0.7-4 ii colord 1.4.3-3 ii cups-filters [ghostscript-cups] 1.21.2-1 ii printer-driver-gutenprint5.2.13-2+b1 Versions of packages cups suggests: ii cups-bsd 2.2.8-5 pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20180604-1 ii hplip 3.17.10+repack0-5 ii printer-driver-hpcups 3.17.10+repack0-5 ii smbclient 2:4.8.5+dfsg-1 ii udev 239-9 -- debconf information excluded
Bug#907705: ITP: mmm -- minimalistic media manager
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" * Package name: mmm Version : 0.4.1 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/m * License : GPLv3+ Programming Lang: Python Description : minimalistic media manager m keeps track of which files you've played (or are still playing) and thus allows you to easily continue playing the next file (using vlc or mpv). I'm the upstream author and I use it a lot myself (instead of kodi); some of my friends do as well. As a Debian user I wanted to be able to install it as a Debian package, so I turned it into a native Debian package. It builds (reproducibly) using dpkg-buildpackage. I'm hoping to eventually become a Debian Developer/Maintainer, but for now I'd need a sponsor to get this into Debian. Thanks. - Felix
Bug#907705: ITP: mmm -- minimalistic media manager
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" * Package name: mmm Version : 0.4.1 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/m * License : GPLv3+ Programming Lang: Python Description : minimalistic media manager m keeps track of which files you've played (or are still playing) and thus allows you to easily continue playing the next file (using vlc or mpv). I'm the upstream author and I use it a lot myself (instead of kodi); some of my friends do as well. As a Debian user I wanted to be able to install it as a Debian package, so I turned it into a native Debian package. It builds (reproducibly) using dpkg-buildpackage. I'm hoping to eventually become a Debian Developer/Maintainer, but for now I'd need a sponsor to get this into Debian. Thanks. - Felix
Bug#907705: ITP: mmm -- minimalistic media manager
Package: wnpp Severity: wishlist Owner: "Felix C. Stegerman" * Package name: mmm Version : 0.4.1 Upstream Author : Felix C. Stegerman * URL : https://github.com/obfusk/m * License : GPLv3+ Programming Lang: Python Description : minimalistic media manager m keeps track of which files you've played (or are still playing) and thus allows you to easily continue playing the next file (using vlc or mpv). I'm the upstream author and I use it a lot myself (instead of kodi); some of my friends do as well. As a Debian user I wanted to be able to install it as a Debian package, so I turned it into a native Debian package. It builds (reproducibly) using dpkg-buildpackage. I'm hoping to eventually become a Debian Developer/Maintainer, but for now I'd need a sponsor to get this into Debian. Thanks. - Felix
Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot
Package: src:linux Version: 4.17.8-1 Followup-For: Bug #904441 Dear Maintainer, Same issue here; 4.16.0-2-amd64 works fine; ahci.mobile_lpm_policy=1 does not help. $ cat /sys/bus/scsi/devices/0\:0\:0\:0/model ST9500325ASG $ cat /sys/bus/scsi/devices/0\:0\:0\:0/rev APM1 Happy to help debug this. Not sure where to start though. Thanks. - Felix -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Apple Inc. product_name: MacBookPro8,1 product_version: 1.0 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.17.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-1 ii linux-base 4.5 Versions of packages linux-image-4.17.0-1-amd64 recommends: ii apparmor 2.13-4 ii firmware-linux-free 3.4 ii irqbalance 1.3.0-0.1+b1 Versions of packages linux-image-4.17.0-1-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.03+dfsg1-2 ii grub-efi-amd64 2.02+dfsg1-4 pn linux-doc-4.17 Versions of packages linux-image-4.17.0-1-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot
Package: src:linux Version: 4.17.8-1 Followup-For: Bug #904441 Dear Maintainer, Same issue here; 4.16.0-2-amd64 works fine; ahci.mobile_lpm_policy=1 does not help. $ cat /sys/bus/scsi/devices/0\:0\:0\:0/model ST9500325ASG $ cat /sys/bus/scsi/devices/0\:0\:0\:0/rev APM1 Happy to help debug this. Not sure where to start though. Thanks. - Felix -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Apple Inc. product_name: MacBookPro8,1 product_version: 1.0 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.17.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-1 ii linux-base 4.5 Versions of packages linux-image-4.17.0-1-amd64 recommends: ii apparmor 2.13-4 ii firmware-linux-free 3.4 ii irqbalance 1.3.0-0.1+b1 Versions of packages linux-image-4.17.0-1-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.03+dfsg1-2 ii grub-efi-amd64 2.02+dfsg1-4 pn linux-doc-4.17 Versions of packages linux-image-4.17.0-1-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
[Touch-packages] [Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
I'd appreciate some help fixing this since these computers are now not getting automatic security updates. And since it's a pretty standard Ubuntu Desktop installation, I'd be surprised if these were the only onese affected. Unfortunately it's a little hard to debug this since it seems to happen during boot and I don't currently have (physical) access to these computers. Happy to help figure this out though. I could patch the script to also log `ps aux` somewhere to figure out what's running at the same time, but unfortunately I don't have easy access to these computers right now; so if someone can reproduce this or has an idea what the problem (or a workaround/fix) might be I'd appreciate it. - Felix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked Status in apt package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: New Bug description: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
I'd appreciate some help fixing this since these computers are now not getting automatic security updates. And since it's a pretty standard Ubuntu Desktop installation, I'd be surprised if these were the only onese affected. Unfortunately it's a little hard to debug this since it seems to happen during boot and I don't currently have (physical) access to these computers. Happy to help figure this out though. I could patch the script to also log `ps aux` somewhere to figure out what's running at the same time, but unfortunately I don't have easy access to these computers right now; so if someone can reproduce this or has an idea what the problem (or a workaround/fix) might be I'd appreciate it. - Felix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked Status in apt package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: New Bug description: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
Thanks for the info. I seem to have missed that. Any idea what else might be running? Or a workaround/fix? These are pretty standard Ubuntu Desktop machines. And everything worked fine when I installed them last year. I doubt it's a strange configuration on my part. - Felix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1771135] Re: unattended upgrades always fail b/c dpkg status database is always locked
Thanks for the info. I seem to have missed that. Any idea what else might be running? Or a workaround/fix? These are pretty standard Ubuntu Desktop machines. And everything worked fine when I installed them last year. I doubt it's a strange configuration on my part. - Felix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked Status in apt package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: New Bug description: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1771135] [NEW] unattended upgrades always fail b/c dpkg status database is always locked
Public bug reported: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New ** Also affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked Status in apt package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: New Bug description: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 1771135] [NEW] unattended upgrades always fail b/c dpkg status database is always locked
Public bug reported: Hi, (Filing this bug against apt since that contains the systemd timers and cron job to start unattended-upgrades). I'm using unattended-upgrades on several computers. On the one that is on most of the time, updates work as expected. On the ones that are off most of the time, updates are never installed because there is always a "dpkg: error: dpkg status database is locked by another process". Running `unattended-upgrade -d` by hand or using aptitude works fine. I suspect that because these computers are off most of the time, the systemd timers for both apt-daily and apt-daily-upgrade are always run at the same time during boot and resulting in the dpkg database being locked for apt-daily-upgrade. I will try disabling the systemd timers and using the cron job instead to see if that fixes the problem. FYI I also noticed that the cron job will only run when the system is on A/C power, whereas the systemd timers do not seem to have any such check. Thanks. - Felix ubuntu version: 16.04.4 LTS apt version: 1.2.26 unattended-upgrades version: 0.90ubuntu0.9 ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New ** Also affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771135 Title: unattended upgrades always fail b/c dpkg status database is always locked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1771135/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Bug#897407: scribus: pdf/ps import fails with ghostscript error: DELAYBIND deprecated
Package: scribus Version: 1.4.6+dfsg-4+b1 Severity: normal Dear Maintainer, Importing PDF files in scribus fails w/ ghostscript complaining that the "DELAYBIND command has been deprecated". Similar to bug #880650 it seems. I've tried to run the gs command scribus uses by hand w/ the -dREALLYDELAYBIND option as suggested by the ghostscript error message, but then I get a different error. Looking at the changelog it seems that the DELAYBIND command was removed from ghostscript in version 9.22 but has since been re-added in version 9.23, so an updated version of ghostscript would probably fix this. Thanks. - Felix -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Versions of packages scribus depends on: ii ghostscript 9.22~dfsg-2.1 ii libc62.27-3 ii libcairo21.15.10-3 ii libcups2 2.2.7-3 ii libfontconfig1 2.13.0-4 ii libfreetype6 2.8.1-2 ii libgcc1 1:8-20180425-1 ii libhyphen0 2.8.8-5 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-1 ii libpodofo0.9.5 0.9.5-9 ii libpython2.7 2.7.15~rc1-1 ii libqt4-network 4:4.8.7+dfsg-15 ii libqt4-xml 4:4.8.7+dfsg-15 ii libqtcore4 4:4.8.7+dfsg-15 ii libqtgui44:4.8.7+dfsg-15 ii libstdc++6 8-20180425-1 ii libtiff5 4.0.9-5 ii libxml2 2.9.4+dfsg1-6.1 ii python-tk2.7.15~rc1-1 ii scribus-data 1.4.6+dfsg-4 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages scribus recommends: ii cups-bsd2.2.7-3 ii fonts-dejavu2.37-1 ii fonts-liberation1:1.07.4-5 ii gsfonts-x11 0.25 ii hyphen-de [hyphen-hyphenation-patterns] 1:6.0.3-3 ii hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-5 ii icc-profiles-free 2.0.1+dfsg-1 ii xfonts-scalable 1:1.0.3-1.1 Versions of packages scribus suggests: pn icc-profiles pn scribus-doc pn scribus-template ii texlive-latex-recommended 2018.20180416-1 -- no debconf information
Bug#893974: apparmor: loads /etc/apparmor.d/*.dpkg-remove
Package: apparmor Version: 2.12-4 Severity: normal Dear Maintainer, I noticed that my openntpd service stopped working after apparmor was enabled in sid by default. I finally traced the problem to a remaining /etc/apparmor.d/usr.sbin.ntpd.dpkg-remove without 'x' permissions for /usr/sbin/ntpd. It did not immediately occur to me that whilst the /etc/apparmor.d/usr.sbin.ntpd config seemed fine, it was being overruled by an old .dpkg-remove. Not sure what the best way to fix this is, but it seems to me that apparmor should probably not load any *.dpkg-remove. I've filed a bug report against openntpd as well for leaving this file behind when it should have been removed automatically (I believe). Thanks. - Felix -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.66 ii libc6 2.27-2 ii lsb-base 9.20170808 ii python33.6.4-1 apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-profiles-extra pn apparmor-utils -- debconf information excluded
Bug#893973: openntpd: broke w/ apparmor b/c remaining /etc/apparmor.d/usr.sbin.ntpd.dpkg-remove
Package: openntpd Version: 1:6.2p3-1 Severity: normal Dear Maintainer, I noticed that my openntpd service stopped working after apparmor was enabled in sid by default. I finally traced the problem to a remaining /etc/apparmor.d/usr.sbin.ntpd.dpkg-remove without 'x' permissions for /usr/sbin/ntpd. Whilst the /etc/apparmor.d/usr.sbin.ntpd config seemed fine, it was being overruled by an old .dpkg-remove, which -- if I understand the use of such files correctly -- should have been removed automatically. Thanks. - Felix -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openntpd depends on: ii adduser 3.117 ii libc6 2.27-2 ii lsb-base 9.20170808 ii netbase 5.4 openntpd recommends no packages. Versions of packages openntpd suggests: ii apparmor 2.12-4 -- Configuration Files: /etc/default/openntpd changed [not included] -- no debconf information
[Aptitude-devel] Bug#888275: aptitude: (leaves) world-writable (!) aptitude-download- dirs in /tmp
Package: aptitude Version: 0.8.10-6 Severity: normal Dear Maintainer, I just found some aptitude-download---- directories in /tmp. Presumably from some recent failed `aptitude changelog` invocations. The directories are empty. I may have ^Cd aptitude because it seemed to hang, which might explain why it did not clean up after itself. It would be nice if it did. But this is definately a minor issue. I'm a little worried about the fact that the directories all have mode 0777. Could this result in a security issue? Either way it does not seem like the correct mode for these temporary directories. Thanks. - Felix -- Package-specific info: Terminal: screen-256color-bce $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.10 Compiler: g++ 7.2.0 Compiled against: apt version 5.0.2 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20171125 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7ffdb8fd1000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f2cd2042000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f2cd1e12000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f2cd1be8000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f2cd19e1000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f2cd16e9000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f2cd13de000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f2cd11c6000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f2cd0fad000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f2cd0da9000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f2cd099e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2cd078) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f2cd0401000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2cd00b6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f2ccfe9f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2ccfae9000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f2ccf8d2000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2ccf6b8000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f2ccf4a8000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2ccf282000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f2ccf07) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f2ccee52000) /lib64/ld-linux-x86-64.so.2 (0x7f2cd2a0e000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2ccec4e000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2ccea46000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f2cce841000) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common0.8.10-6 ii libapt-pkg5.0 1.6~alpha7 ii libboost-filesystem1.62.0 1.62.0+dfsg-5 ii libboost-iostreams1.62.0 1.62.0+dfsg-5 ii libboost-system1.62.0 1.62.0+dfsg-5 ii libc6 2.26-5 ii libcwidget3v5 0.5.17-7 ii libgcc11:7.2.0-20 ii libncursesw5 6.0+20171125-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.22.0-1 ii libstdc++6 7.2.0-20 ii libtinfo5 6.0+20171125-1 ii libxapian301.4.5-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-12 ii sensible-utils 0.0.11 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags ii tasksel 3.42 -- no debconf information ___ Aptitude-devel mailing list Aptitude-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
Bug#888275: aptitude: (leaves) world-writable (!) aptitude-download- dirs in /tmp
Package: aptitude Version: 0.8.10-6 Severity: normal Dear Maintainer, I just found some aptitude-download---- directories in /tmp. Presumably from some recent failed `aptitude changelog` invocations. The directories are empty. I may have ^Cd aptitude because it seemed to hang, which might explain why it did not clean up after itself. It would be nice if it did. But this is definately a minor issue. I'm a little worried about the fact that the directories all have mode 0777. Could this result in a security issue? Either way it does not seem like the correct mode for these temporary directories. Thanks. - Felix -- Package-specific info: Terminal: screen-256color-bce $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.10 Compiler: g++ 7.2.0 Compiled against: apt version 5.0.2 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20171125 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7ffdb8fd1000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f2cd2042000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f2cd1e12000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f2cd1be8000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f2cd19e1000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f2cd16e9000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f2cd13de000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f2cd11c6000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f2cd0fad000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f2cd0da9000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f2cd099e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2cd078) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f2cd0401000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2cd00b6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f2ccfe9f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2ccfae9000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f2ccf8d2000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2ccf6b8000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f2ccf4a8000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2ccf282000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f2ccf07) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f2ccee52000) /lib64/ld-linux-x86-64.so.2 (0x7f2cd2a0e000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2ccec4e000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2ccea46000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f2cce841000) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common0.8.10-6 ii libapt-pkg5.0 1.6~alpha7 ii libboost-filesystem1.62.0 1.62.0+dfsg-5 ii libboost-iostreams1.62.0 1.62.0+dfsg-5 ii libboost-system1.62.0 1.62.0+dfsg-5 ii libc6 2.26-5 ii libcwidget3v5 0.5.17-7 ii libgcc11:7.2.0-20 ii libncursesw5 6.0+20171125-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.22.0-1 ii libstdc++6 7.2.0-20 ii libtinfo5 6.0+20171125-1 ii libxapian301.4.5-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-12 ii sensible-utils 0.0.11 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags ii tasksel 3.42 -- no debconf information
Bug#884649: twine: trying to use testpypi w/ --repository-url results in upload to regular pypi
Package: twine Version: 1.8.1-2 Severity: important Dear Maintainer, Trying to upload a package to TestPyPI [1]: $ twine upload --repository-url https://test.pypi.org/legacy/ dist/* results in twine uploading it to the *regular* PyPI. There's a bug in the --repository-url handling, which is fixed upstream [2]. For now, using: $ twine upload --repository pypitest dist/* works. It'd be nice to get the upstream fix though. Someone might accidentally upload a package to PyPI instead of TestPyPI if they use the same credentials for both. Thanks. - Felix [1] https://packaging.python.org/guides/using-testpypi/ [2] https://github.com/pypa/twine/commit/7ddbaf40951ae49a1e686b0a3456bf84e93ea004 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages twine depends on: ii python33.6.4~rc1-2 ii python3-clint 0.5.1-1 ii python3-pkg-resources 38.2.4-2 ii python3-pkginfo1.2.1-1 ii python3-requests 2.18.1-1 ii python3-requests-toolbelt 0.8.0-1 ii python3-setuptools 38.2.4-2 twine recommends no packages. twine suggests no packages. -- debconf-show failed
Bug#880378: rhythmbox: adding file containing pipe sign or colon to iPod results in database/filesystem mismatch
Package: rhythmbox Version: 3.4.2-1 Severity: normal Dear Maintainer, I just added some new music to my iPod using rhythmbox (as usual), however several files could not be played. Investigating, I found that: 07-ANGER|ANGER.mp3 was renamed as 07-ANGER_ANGER.mp3 on the iPod's file system, and 02-TRAGEDY:ETERNITY.mp3 as 02-TRAGEDY_ETERNITY.mp3 However, rhythmbox showed the iPod database referenced these files as 07-ANGER|ANGER.mp3 and 02-TRAGEDY;ETERNITY.mp3 respectively. No wonder they could not be played. I have several files containing `:' or `|' characters in my music collection, all of which are on my iPod as well - synced earlier using rhythmbox - and AFAIK they all play just fine. This suggests that this bug is relatively new. I'd be happy to assist in helping fix this bug (as soon as I have a bit of time) if necessary. Thanks. - Felix P.S. my apologies if this bug should have been filed against libgpod instead. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), LANGUAGE= (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rhythmbox depends on: ii dbus1.11.22-1 ii gstreamer1.0-plugins-base 1.12.3-1 ii gstreamer1.0-plugins-good 1.12.3-1 ii gstreamer1.0-x 1.12.3-1 ii libc6 2.24-17 ii libglib2.0-02.54.2-1 ii libgstreamer-plugins-base1.0-0 1.12.3-1 ii libgstreamer1.0-0 1.12.3-1 ii libgtk-3-0 3.22.24-3 ii libpeas-1.0-0 1.22.0-1+b1 ii librhythmbox-core10 3.4.2-1 ii libx11-62:1.6.4-3 ii media-player-info 23-1 ii rhythmbox-data 3.4.2-1 Versions of packages rhythmbox recommends: ii avahi-daemon 0.7-3 ii awesome [notification-daemon] 4.2-2 ii dunst [notification-daemon]1.2.0-2 ii gnome-flashback [notification-daemon] 3.26.0-2 ii gnome-shell [notification-daemon] 3.26.1-3 ii gstreamer1.0-plugins-ugly 1.12.3-1 ii gstreamer1.0-pulseaudio1.12.3-1 ii gvfs-backends 1.34.1-1 ii notification-daemon3.20.0-1+b1 ii rhythmbox-plugins 3.4.2-1 ii yelp 3.26.0-1 Versions of packages rhythmbox suggests: pn gnome-codec-install ii gnome-control-center 1:3.26.1-2 ii gstreamer1.0-plugins-bad 1.12.3-2 ii rhythmbox-plugin-cdrecorder 3.4.2-1 -- no debconf information
[android-developers] Setup Emulator in Android Studio for Android 4.4W
Hello Guys, I want to develop an Android Wear App for Sony Smartwatch 3, which has Android 4.4W installed. However, I am not able to setup the emulator in Android Studio for Android 4.4W, because there is no system image available in the SDK Manager. There are no errors in the console/log, the system images are just not shown in the SDK manager for Android 4.4W (API level 20). What can I do? Best Regards Felix -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/175aa550-d63a-4435-aa39-2f19b68ffe4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Bug-tar] I can't unpack my Teamspeak
Hello, i can't unpack my teamspeak3-server_linuk_amd64-3.0.13.6.tar.bz2 Error: tar (child): cannot run bzip2: No such file or directory tar (child): trying lbzip2 tar (child): lbzip2: Cannot exec: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now My Command: tar xfv teamspeak3-server_linuk_amd64-3.0.13.6.tar.bz2 Please Help
Bug#839757: ipython3: fails to start w/ non-utf8 locale if history contains utf8 byte
Package: ipython3
Version: 2.4.1-1
Severity: normal
Dear Maintainer,
I suddenly get this:
$ LC_ALL=C ipython3
Traceback (most recent call last):
File "/usr/bin/ipython3", line 5, in
start_ipython()
File "/usr/lib/python3/dist-packages/IPython/__init__.py", line 120, in
start_ipython
return launch_new_instance(argv=argv, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/config/application.py", line
564, in launch_instance
app.initialize(argv)
File "", line 2, in initialize
File "/usr/lib/python3/dist-packages/IPython/config/application.py", line 92,
in catch_config_error
return method(app, *args, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 332, in
initialize
self.init_shell()
File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 348, in
init_shell
ipython_dir=self.ipython_dir, user_ns=self.user_ns)
File "/usr/lib/python3/dist-packages/IPython/config/configurable.py", line
354, in instance
inst = cls(*args, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/terminal/interactiveshell.py",
line 328, in __init__
**kwargs
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
483, in __init__
self.init_readline()
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
1884, in init_readline
self.refill_readline_hist()
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
1903, in refill_readline_hist
stdin_encoding))
UnicodeEncodeError: 'locale' codec can't encode character '\xe3' in position 1:
Invalid or incomplete multibyte or wide character
If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-...@scipy.org
You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.
Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
c.Application.verbose_crash=True
$ LC_ALL=C.UTF-8 ipython3 # now it works
Python 3.5.2+ (default, Sep 22 2016, 12:18:14)
...
$ LC_ALL=C ipython # works fine
Python 2.7.12+ (default, Sep 1 2016, 20:27:38)
...
$ mv .ipython{,_}
$ LC_ALL=C ipython3 # w/o history it works
Python 3.5.2+ (default, Sep 22 2016, 12:18:14)
...
$ python3 -c "import IPython; print(IPython.sys_info())"
{'commit_hash': 'af17558',
'commit_source': 'installation',
'default_encoding': 'ISO-8859-1',
'ipython_path': '/usr/lib/python3/dist-packages/IPython',
'ipython_version': '2.4.1',
'os_name': 'posix',
'platform': 'Linux-4.7.0-1-amd64-x86_64-with-debian-stretch-sid',
'sys_executable': '/usr/bin/python3',
'sys_platform': 'linux',
'sys_version': '3.5.2+ (default, Sep 22 2016, 12:18:14) \n'
'[GCC 6.2.0 20160914]'}
I decided against reporting it upsteam myself seeing as how the
version in Debian seems to be rather old.
- Felix
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ipython3 depends on:
ii python3-decorator 4.0.6-1
ii python3-pkg-resources 28.0.0-1
ii python3-simplegeneric 0.8.1-1
pn python3:any
ipython3 recommends no packages.
Versions of packages ipython3 suggests:
pn ipython3-notebook
pn ipython3-qtconsole
pn python3-zmq
-- no debconf information
[Python-modules-team] Bug#839757: ipython3: fails to start w/ non-utf8 locale if history contains utf8 byte
Package: ipython3
Version: 2.4.1-1
Severity: normal
Dear Maintainer,
I suddenly get this:
$ LC_ALL=C ipython3
Traceback (most recent call last):
File "/usr/bin/ipython3", line 5, in
start_ipython()
File "/usr/lib/python3/dist-packages/IPython/__init__.py", line 120, in
start_ipython
return launch_new_instance(argv=argv, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/config/application.py", line
564, in launch_instance
app.initialize(argv)
File "", line 2, in initialize
File "/usr/lib/python3/dist-packages/IPython/config/application.py", line 92,
in catch_config_error
return method(app, *args, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 332, in
initialize
self.init_shell()
File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 348, in
init_shell
ipython_dir=self.ipython_dir, user_ns=self.user_ns)
File "/usr/lib/python3/dist-packages/IPython/config/configurable.py", line
354, in instance
inst = cls(*args, **kwargs)
File "/usr/lib/python3/dist-packages/IPython/terminal/interactiveshell.py",
line 328, in __init__
**kwargs
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
483, in __init__
self.init_readline()
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
1884, in init_readline
self.refill_readline_hist()
File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line
1903, in refill_readline_hist
stdin_encoding))
UnicodeEncodeError: 'locale' codec can't encode character '\xe3' in position 1:
Invalid or incomplete multibyte or wide character
If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-...@scipy.org
You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.
Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
c.Application.verbose_crash=True
$ LC_ALL=C.UTF-8 ipython3 # now it works
Python 3.5.2+ (default, Sep 22 2016, 12:18:14)
...
$ LC_ALL=C ipython # works fine
Python 2.7.12+ (default, Sep 1 2016, 20:27:38)
...
$ mv .ipython{,_}
$ LC_ALL=C ipython3 # w/o history it works
Python 3.5.2+ (default, Sep 22 2016, 12:18:14)
...
$ python3 -c "import IPython; print(IPython.sys_info())"
{'commit_hash': 'af17558',
'commit_source': 'installation',
'default_encoding': 'ISO-8859-1',
'ipython_path': '/usr/lib/python3/dist-packages/IPython',
'ipython_version': '2.4.1',
'os_name': 'posix',
'platform': 'Linux-4.7.0-1-amd64-x86_64-with-debian-stretch-sid',
'sys_executable': '/usr/bin/python3',
'sys_platform': 'linux',
'sys_version': '3.5.2+ (default, Sep 22 2016, 12:18:14) \n'
'[GCC 6.2.0 20160914]'}
I decided against reporting it upsteam myself seeing as how the
version in Debian seems to be rather old.
- Felix
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ipython3 depends on:
ii python3-decorator 4.0.6-1
ii python3-pkg-resources 28.0.0-1
ii python3-simplegeneric 0.8.1-1
pn python3:any
ipython3 recommends no packages.
Versions of packages ipython3 suggests:
pn ipython3-notebook
pn ipython3-qtconsole
pn python3-zmq
-- no debconf information
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
Bug#827618: similar bug w/ linux-image-4.7.0-1-amd64{,-unsigned}
Hi, This time I replaced linux-image-4.7.0-1-amd64 w/ linux-image-4.7.0-1-amd64-unsigned. Then I ran: $ sudo aptitude purge ~c ... Purging configuration files for linux-image-4.7.0-1-amd64 (4.7.2-1+s1) ... ... rmdir: failed to remove '/lib/modules/4.7.0-1-amd64': Directory not empty ... Not only did this cause dpkg to fail, it also removed modules.alias etc. So replacing the signed kernel package with the unsigned one still causes some problems. - Felix signature.asc Description: PGP signature
Bug#827618: similar bug w/ linux-image-4.7.0-1-amd64{,-unsigned}
Hi, This time I replaced linux-image-4.7.0-1-amd64 w/ linux-image-4.7.0-1-amd64-unsigned. Then I ran: $ sudo aptitude purge ~c ... Purging configuration files for linux-image-4.7.0-1-amd64 (4.7.2-1+s1) ... ... rmdir: failed to remove '/lib/modules/4.7.0-1-amd64': Directory not empty ... Not only did this cause dpkg to fail, it also removed modules.alias etc. So replacing the signed kernel package with the unsigned one still causes some problems. - Felix signature.asc Description: PGP signature
Bug#827618: linux-image-4.6.0-1-amd64-signed: replacing w/ non-signed breaks things
Package: linux-image-4.6.0-1-amd64-signed Version: 4.6.1-1 Severity: important Dear Maintainer, Since I saw that the non-signed kernel had been updated -- and did not see any need for a signed kernel atm -- I decided to replace it. This caused some trouble... # replaces linux-image-4.6.0-1-amd64-signed $ sudo aptitude install linux-image-4.6.0-1-amd64 ... $ sudo aptitude purge ~c ... Removing linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... Purging configuration files for linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': Directory not empty dpkg: error processing package linux-image-4.6.0-1-amd64-signed (--purge): ... $ ls /lib/modules/* /lib/modules/4.6.0-1-amd64: build kernel modules.builtin modules.order source $ sudo aptitude purge linux-image-4.6.0-1-amd64 ... Purging configuration files for linux-image-4.6.0-1-amd64 (4.6.2-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': Directory not empty dpkg: error processing package linux-image-4.6.0-1-amd64 (--purge): ... $ ls /lib/modules/* /lib/modules/4.6.0-1-amd64: build source $ sudo aptitude purge linux-headers-4.6.0-1-amd64 ... $ sudo aptitude purge ~c ... Purging configuration files for linux-image-4.6.0-1-amd64 (4.6.2-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': No such file or directory dpkg: error processing package linux-image-4.6.0-1-amd64 (--purge): ... Purging configuration files for linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': No such file or directory dpkg: error processing package linux-image-4.6.0-1-amd64-signed (--purge): ... # seems OK after this: $ sudo mkdir /lib/modules/4.6.0-1-amd64 $ sudo aptitude purge linux-image-4.6.0-1-amd64-signed $ sudo mkdir /lib/modules/4.6.0-1-amd64 $ sudo aptitude purge linux-image-4.6.0-1-amd64 $ sudo aptitude install linux-image-amd64 linux-image-4.6.0-1-amd64 linux-headers-amd64 - Felix -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#827618: linux-image-4.6.0-1-amd64-signed: replacing w/ non-signed breaks things
Package: linux-image-4.6.0-1-amd64-signed Version: 4.6.1-1 Severity: important Dear Maintainer, Since I saw that the non-signed kernel had been updated -- and did not see any need for a signed kernel atm -- I decided to replace it. This caused some trouble... # replaces linux-image-4.6.0-1-amd64-signed $ sudo aptitude install linux-image-4.6.0-1-amd64 ... $ sudo aptitude purge ~c ... Removing linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... Purging configuration files for linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': Directory not empty dpkg: error processing package linux-image-4.6.0-1-amd64-signed (--purge): ... $ ls /lib/modules/* /lib/modules/4.6.0-1-amd64: build kernel modules.builtin modules.order source $ sudo aptitude purge linux-image-4.6.0-1-amd64 ... Purging configuration files for linux-image-4.6.0-1-amd64 (4.6.2-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': Directory not empty dpkg: error processing package linux-image-4.6.0-1-amd64 (--purge): ... $ ls /lib/modules/* /lib/modules/4.6.0-1-amd64: build source $ sudo aptitude purge linux-headers-4.6.0-1-amd64 ... $ sudo aptitude purge ~c ... Purging configuration files for linux-image-4.6.0-1-amd64 (4.6.2-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': No such file or directory dpkg: error processing package linux-image-4.6.0-1-amd64 (--purge): ... Purging configuration files for linux-image-4.6.0-1-amd64-signed (4.6.1-1) ... rmdir: failed to remove '/lib/modules/4.6.0-1-amd64': No such file or directory dpkg: error processing package linux-image-4.6.0-1-amd64-signed (--purge): ... # seems OK after this: $ sudo mkdir /lib/modules/4.6.0-1-amd64 $ sudo aptitude purge linux-image-4.6.0-1-amd64-signed $ sudo mkdir /lib/modules/4.6.0-1-amd64 $ sudo aptitude purge linux-image-4.6.0-1-amd64 $ sudo aptitude install linux-image-amd64 linux-image-4.6.0-1-amd64 linux-headers-amd64 - Felix -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#823356: linux-image-4.5.0-2-amd64: system freezes (HDD I/O seems impossible, load keeps climbing) after suspend
Package: src:linux Version: 4.5.2-1 Severity: important Dear Maintainer, Since today, every time I suspend my laptop and re-awake it: * the load keeps climbing * I can still interact to some extent with running programs, but it seems HDD I/O has become impossible (`pwd` works, `ls` freezes the entire shell); can start some new commands, but many things freeze; can stop some programs, but some freeze when I try to * htop shows no out-of-control processes or such * powertop shows: - Intel and Cirrus codecs using 100% (`modprobe -r snd_hda_intel snd_hda_codec_cirrus` before or after suspend fixes this); seems like a result of the underlying problem instead of the cause - ~200 events/sec for blk_delay_work * `systemctl poweroff` fails w/ connection timeout * the only option availble to me is to turn off the power and reboot I've had this problem before (at least the symptoms, I did not look at powertop at the time), probably only twice over the past few months, but never consistently like now. Booting kernel 4.5.1-1 does not change anything. I have another laptop (different make & model) which had the intermittent version (again based on symptoms only) more frequently, but apparently only if I had (dis)connected the AC power whilst it was sleeping; never (dis)connecting AC power has so far made the problem disappear, and that laptop does not experience this problem now either. Both laptops are running sid (equally up-to-date, mostly the same packages). I don't have a lot of time, but would be happy to do what I can to help debug this (as not being able to use suspend is quite bothersome). - Felix P.S. I removed some information automatically added to the bugreport that I considered probably unimportant and possibly bad for my privacy. If you really need this info, I'd be happy to provide it directly, not publicly via the BTS. -- Package-specific info: ** Version: Linux version 4.5.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.3.1 20160424 (Debian 5.3.1-16) ) #1 SMP Debian 4.5.2-1 (2016-04-28) ** Command line: BOOT_IMAGE=/vmlinuz-4.5.0-2-amd64 root=/dev/mapper/root ro ** Tainted: OE (12288) * Out-of-tree module has been loaded. * Unsigned module has been loaded (currently expected). ** Model information sys_vendor: Apple Inc. product_name: MacBookPro8,1 ** Loaded modules: fuse(E) pci_stub(E) vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc(E) bnep(E) nls_utf8(E) nls_cp437(E) vfat(E) fat(E) btusb(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) uvcvideo(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_core(E) videodev(E) bcm5974(E) media(E) arc4(E) b43(E) mac80211(E) cfg80211(E) ssb(E) rfkill(E) rng_core(E) pcmcia(E) pcmcia_core(E) joydev(E) iTCO_wdt(E) iTCO_vendor_support(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) snd_hda_codec_hdmi(E) evdev(E) kvm_intel(E) snd_hda_codec_cirrus(E) snd_hda_codec_generic(E) kvm(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) irqbypass(E) i915(E) snd_hwdep(E) applesmc(E) snd_pcm(E) input_polldev(E) snd_timer(E) efi_pstore(E) snd(E) soundcore(E) drm_kms_helper(E) efivars(E) apple_gmux(E) i2c_i801(E) pcspkr(E) bcma(E) sg(E) apple_bl(E) acpi_als(E) kfifo_buf(E) sbs(E) battery(E) sbshc(E) drm(E) industrialio(E) lpc_ich(E) mfd_core(E) video(E) ac(E) shpchp(E) i2c_algo_bit(E) mei_me(E) mei(E) button(E) ip6t_REJECT(E) nf_reject_ipv6(E) nf_log_ipv6(E) tpm_tis(E) tpm(E) processor(E) xt_hl(E) ip6t_rt(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ipt_REJECT(E) nf_reject_ipv4(E) nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) xt_tcpudp(E) xt_addrtype(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) xt_conntrack(E) ip6table_filter(E) ip6_tables(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_nat_ftp(E) loop(E) nf_nat(E) nf_conntrack_ftp(E) nf_conntrack(E) iptable_filter(E) parport_pc(E) ip_tables(E) ppdev(E) x_tables(E) lp(E) parport(E) efivarfs(E) autofs4(E) ext4(E) ecb(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) algif_skcipher(E) af_alg(E) hid_generic(E) hid_apple(E) dm_crypt(E) dm_mod(E) hid_appleir(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) sd_mod(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) ahci(E) libahci(E) firewire_ohci(E) aesni_intel(E) libata(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) scsi_mod(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) sdhci_pci(E) tg3(E) firewire_core(E) ptp(E) sdhci(E) crc_itu_t(E) pps_core(E) libphy(E) mmc_core(E) usbcore(E) usb_common(E) fjes(E) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages
Bug#823356: linux-image-4.5.0-2-amd64: system freezes (HDD I/O seems impossible, load keeps climbing) after suspend
Package: src:linux Version: 4.5.2-1 Severity: important Dear Maintainer, Since today, every time I suspend my laptop and re-awake it: * the load keeps climbing * I can still interact to some extent with running programs, but it seems HDD I/O has become impossible (`pwd` works, `ls` freezes the entire shell); can start some new commands, but many things freeze; can stop some programs, but some freeze when I try to * htop shows no out-of-control processes or such * powertop shows: - Intel and Cirrus codecs using 100% (`modprobe -r snd_hda_intel snd_hda_codec_cirrus` before or after suspend fixes this); seems like a result of the underlying problem instead of the cause - ~200 events/sec for blk_delay_work * `systemctl poweroff` fails w/ connection timeout * the only option availble to me is to turn off the power and reboot I've had this problem before (at least the symptoms, I did not look at powertop at the time), probably only twice over the past few months, but never consistently like now. Booting kernel 4.5.1-1 does not change anything. I have another laptop (different make & model) which had the intermittent version (again based on symptoms only) more frequently, but apparently only if I had (dis)connected the AC power whilst it was sleeping; never (dis)connecting AC power has so far made the problem disappear, and that laptop does not experience this problem now either. Both laptops are running sid (equally up-to-date, mostly the same packages). I don't have a lot of time, but would be happy to do what I can to help debug this (as not being able to use suspend is quite bothersome). - Felix P.S. I removed some information automatically added to the bugreport that I considered probably unimportant and possibly bad for my privacy. If you really need this info, I'd be happy to provide it directly, not publicly via the BTS. -- Package-specific info: ** Version: Linux version 4.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 20160424 (Debian 5.3.1-16) ) #1 SMP Debian 4.5.2-1 (2016-04-28) ** Command line: BOOT_IMAGE=/vmlinuz-4.5.0-2-amd64 root=/dev/mapper/root ro ** Tainted: OE (12288) * Out-of-tree module has been loaded. * Unsigned module has been loaded (currently expected). ** Model information sys_vendor: Apple Inc. product_name: MacBookPro8,1 ** Loaded modules: fuse(E) pci_stub(E) vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc(E) bnep(E) nls_utf8(E) nls_cp437(E) vfat(E) fat(E) btusb(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) uvcvideo(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_core(E) videodev(E) bcm5974(E) media(E) arc4(E) b43(E) mac80211(E) cfg80211(E) ssb(E) rfkill(E) rng_core(E) pcmcia(E) pcmcia_core(E) joydev(E) iTCO_wdt(E) iTCO_vendor_support(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) snd_hda_codec_hdmi(E) evdev(E) kvm_intel(E) snd_hda_codec_cirrus(E) snd_hda_codec_generic(E) kvm(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) irqbypass(E) i915(E) snd_hwdep(E) applesmc(E) snd_pcm(E) input_polldev(E) snd_timer(E) efi_pstore(E) snd(E) soundcore(E) drm_kms_helper(E) efivars(E) apple_gmux(E) i2c_i801(E) pcspkr(E) bcma(E) sg(E) apple_bl(E) acpi_als(E) kfifo_buf(E) sbs(E) battery(E) sbshc(E) drm(E) industrialio(E) lpc_ich(E) mfd_core(E) video(E) ac(E) shpchp(E) i2c_algo_bit(E) mei_me(E) mei(E) button(E) ip6t_REJECT(E) nf_reject_ipv6(E) nf_log_ipv6(E) tpm_tis(E) tpm(E) processor(E) xt_hl(E) ip6t_rt(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ipt_REJECT(E) nf_reject_ipv4(E) nf_log_ipv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) xt_tcpudp(E) xt_addrtype(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) xt_conntrack(E) ip6table_filter(E) ip6_tables(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_nat_ftp(E) loop(E) nf_nat(E) nf_conntrack_ftp(E) nf_conntrack(E) iptable_filter(E) parport_pc(E) ip_tables(E) ppdev(E) x_tables(E) lp(E) parport(E) efivarfs(E) autofs4(E) ext4(E) ecb(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) algif_skcipher(E) af_alg(E) hid_generic(E) hid_apple(E) dm_crypt(E) dm_mod(E) hid_appleir(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) sd_mod(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) ahci(E) libahci(E) firewire_ohci(E) aesni_intel(E) libata(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) scsi_mod(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) sdhci_pci(E) tg3(E) firewire_core(E) ptp(E) sdhci(E) crc_itu_t(E) pps_core(E) libphy(E) mmc_core(E) usbcore(E) usb_common(E) fjes(E) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages
Bug#815014: python3.5-venv: uninstallable (if python-pip-whl is installed; b/c dependency on python-setuptools-whl)
Package: python3.5-venv
Version: 3.5.1-5
Severity: important
Dear Maintainer,
It seems that python3.5-venv is currently uninstallable if python-pip
is installed.
$ aptitude -s install python3.5-venv
The following NEW packages will be installed:
python-setuptools-whl{a} python3.5-venv
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 165 kB of archives. After unpacking 651 kB will be used.
The following packages have unmet dependencies:
python-pip-whl : Breaks: python-setuptools-whl (< 20.1) but 20.0-2 is to be
installed.
...
- Felix
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#795009: i3: crashes after suspend when using only external monitor
Package: i3 Version: 4.10.3-1 Severity: normal Dear Maintainer, I've connected an external monitor to my laptop and use `xrandr --output HDMI1 --primary --auto --output LVDS1 --off` to only use the external monitor and not the laptop screen. I use `i3lock systemctl suspend` to lock and suspend. Until recently this worked just fine. Now, when I wake my laptop from suspend, my i3 session has crashed and I'm back at my display manager. Relevant lines from ~/.xsession-errors: i3: No usable outputs available. Exiting due to signal. i3lock: X11 connection broke, did your server terminate? i3 also crashes when I disconnect the external monitor (and the laptop screen is disabled). To confirm that it really seems to be i3 that's at fault: openbox works fine. For now, I'm re-enabling the external monitor before suspend and re-disabling it again afterwards as a workaround. But of course it'd be preferable if i3 did not crash. Please let me know if there's anything I can do to help. Thanks. - Felix -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages i3 depends on: ii i3-wm 4.10.3-1 Versions of packages i3 recommends: ii dunst 1.1.0-2 ii i3lock 2.7-1 ii i3status2.9-2 ii suckless-tools 40-1 i3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: SparkR parallelize not found with 1.4.1?
Thanks! It's good to know --- Original Message --- From: Eskilson,Aleksander alek.eskil...@cerner.com Sent: June 25, 2015 5:57 AM To: Felix C felixcheun...@hotmail.com, user@spark.apache.org Subject: Re: SparkR parallelize not found with 1.4.1? Hi there, Parallelize is part of the RDD API which was made private for Spark v. 1.4.0. Some functions in the RDD API were considered too low-level to expose, so only most of the DataFrame API is currently public. The original rationale for this decision can be found on the issue's JIRA [1]. The devs are still considering which parts of the RDD API, if any, should be made public for later releases. If you have some use case that you feel is most easily addressed by the functions currently private in the RDD API, go ahead and let the dev mailing list know. Alek [1] -- https://issues.apache.org/jira/browse/SPARK-7230 On 6/25/15, 12:24 AM, Felix C felixcheun...@hotmail.com wrote: Hi, It must be something very straightforward... Not working: parallelize(sc) Error: could not find function parallelize Working: df - createDataFrame(sqlContext, localDF) What did I miss? Thanks ?B�CB� ?�?[��X��ܚX�K??K[XZ[?�?\�\�][��X��ܚX�P?�?\�˘\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[� ?�??K[XZ[?�?\�\�Z?[???�?\�˘\?X�?K�ܙ�B�B CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. B�CB�� [��X��ܚX�KK[XZ[� \�\�][��X��ܚX�P �\�˘\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\�Z[ �\�˘\X�K�ܙ�B�B - To unsubscribe, e-mail: user-unsubscr...@spark.apache.org For additional commands, e-mail: user-h...@spark.apache.org
SparkR parallelize not found with 1.4.1?
Hi, It must be something very straightforward... Not working: parallelize(sc) Error: could not find function parallelize Working: df - createDataFrame(sqlContext, localDF) What did I miss? Thanks
Bug#786440: (no subject)
* Barry Warsaw ba...@debian.org [2015-05-26 23:45]: @Felix: Actually the pip_util.diff is only relevant for bug #758787. I've tested what will be pip 1.5.6-6 with that patch and it isn't relevant for bug #786440 afaict. You're absolutely right. I intentionally CC'd this bug because it's another bug related to an outdated pip, but I should have been clear about the problems being unrelated otherwise. I'm inclined not to fix this for the 1.5.6 series, and just concentrate on getting (now) pip 7 into Debian. That would be great of course. Thanks! - Felix signature.asc Description: Digital signature
