Re: python3 reportbug in experimental: call for testing
Hi Sandro, On 14/12/16 00:40, Sandro Tosi wrote: > i intend to upload reportbug 7.x series (python3 only) to unstable > this coming weekend, so it'd be really great if you could give it a > shot from experimental before then -- thanks!! I've been using it (the ncurses interface) since you uploaded it and it's been working fine. Cheers, Emilio
Re: python3 reportbug in experimental: call for testing
2016-12-02 6:00 GMT+08:00 Sandro Tosi : > Hello, > reportbug has been ported to python3 and it landed in experimental. Whenever > you have a chance, please test and report any bugs/broken functionalities > you might find. > > I'm sure there are several parts no longer working, for sure the GTK+ UI is > one (and it is a known issue, given no one is able to maintain it at the > moment). Now that reportbug 6.x is working well and reportbug 7.x is broken with GUI, wouldn't it be better if we just let reportbug 6 enter stretch? I took a try and the error message is broken as well. It suggests that the user should install python-vte (Python 2 version!), which is misleading and useless. Also there is no such a package like "python3-vte". Also, I didn't find a way to start a ncurses frontend. Neither the --help message nor the man page mentioned it. All I have is the fallback to "text" frontend. In short I don't think the current reportbug 7 is suitable for stretch. -- Sincerely, Boyuan Yang
Re: python3 reportbug in experimental: call for testing
On 14/12/16 09:22, Emilio Pozuelo Monfort wrote: > Hi Sandro, > > On 14/12/16 00:40, Sandro Tosi wrote: >> i intend to upload reportbug 7.x series (python3 only) to unstable >> this coming weekend, so it'd be really great if you could give it a >> shot from experimental before then -- thanks!! > > I've been using it (the ncurses interface) since you uploaded it and it's been > working fine. Sorry, I meant the text interface. Emilio
Re: python3 reportbug in experimental: call for testing
On Wed, Dec 14, 2016 at 04:50:52PM +0800, Boyuan Yang wrote: > Also, I didn't find a way to start a ncurses frontend. Neither the > --help message > nor the man page mentioned it. It's called urwid, manpage mentions it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#848120: ITP: python-django-etcd-settings -- config manager for Django apps based on ETCD
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-etcd-settings Version : 0.1.11 Upstream Author : Enrique Paz * URL : https://github.com/kpn-digital/django-etcd-settings * License : Apache-2 Programming Lang: Python Description : config manager for Django apps based on ETCD. This application allows you to extend the Django settings as configured in the settings.py file with: . * Environment dependent values * Values in different config sets, identified by name, which can be selected on a 'per request' basis using the X-DYNAMIC-SETTINGS HTTP header . Both the added configuration values and config sets would live at ETCD, which will be continuously monitored by this library in order to transparently update your app settings upon changes. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlhRFcIRHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WrpKAf/SAJqMKoehHx1c1iH/r1ZVsanzKb8f6eA MxgCw62kyPuvY7buvsYGrvJRLYy0sSUyRlAiLiwjjNSFXmG7jHFo9dmRzoOQ4vkC o7aIkVmQsnFIs5xNJex9Coqwr2zTXtGlaKIT9NDBtMBMEAXdZuNj7ZrzmbH7TNM6 IyiYMi5zGuqtsdRuMkdDmho0ARkAyAI/NZWpqthL1CeVreJVZBq7Vtwm/khKUAiX l1Z11Szk+GB4JAiA5l0lAH2H5jn+g7Wli8JKUH61dJmueq81/oT09juNwBtj5ner ZSpP8SlxNNYXyHqWWdi1FFcSiintMaQA8i1X6d5Uk+FYCz2nJYEx/g== =F6fL -END PGP SIGNATURE-
Bug#848122: ITP: pbcopper -- data structures, algorithms, and utilities for C++ applications
Package: wnpp Severity: wishlist Owner: Debian Med Packaging Team Control: block 847310 by -1 * Package name: pbcopper Version : 0.0.1 Upstream Author : Pacific Biosciences * URL : https://github.com/PacificBiosciences/pbcopper * License : BSD Programming Lang: C++ Description : data structures, algorithms, and utilities for C++ applications pbcopper provides general tools for C++ applications. It is developed for use by applications of the Pacific Biosciences SMRT Analysis suite. This package is a dependency of unanimity. It will be maintained by the Debian Med team.
Re: Re: [RFC] Enabling bindnow by default in dpkg-buildflags
It seems no one cares, there is no movement whatsoever. Why not just go forward and enable it in sid? Others have done and it worked, there has been sufficient testing in Ubuntu. In fact this was even simply enabled in GCC for a short period of time deliberately. I do not see the problem here. Balint stepped up to do a lot of work and now we are stuck. If no one has objections to something that gets the project further why not just do it? This a matter of changing one line and making an upload, no reason to have this pending for months. Thanks
Bug#848127: ITP: fsm -- state machine library
Package: wnpp Owner: Matteo F. Vescovi Severity: wishlist * Package name: fsm Version : 0.2.1 Upstream Author : Thomas Fitzsimmons * URL or Web page : http://elpa.gnu.org/packages/fsm.html * License : GPL-2+ Description : state machine library fsm.el is an exercise in metaprogramming inspired by gen_fsm of Erlang/OTP. It aims to make asynchronous programming in Emacs Lisp easy and fun. By "asynchronous" I mean that long-lasting tasks don't interfer with normal editing. Some people say that it would be nice if Emacs Lisp had threads and/or continuations. They are probably right, but there are few things that can't be made to run in the background using facilities already available: timers, filters and sentinels. As the code can become a bit messy when using such means, with callbacks everywhere and such things, it can be useful to structure the program as a state machine. In this model, a state machine passes between different "states", which are actually only different event handler functions. The state machine receives "events" (from timers, filters, user requests, etc) and reacts to them, possibly entering another state, possibly returning a value. The essential macros/functions are: define-state-machine - create start-FOO function define-state - event handler for each state (required) define-enter-state- called when entering a state (optional) define-fsm- encapsulates the above three (more sugar!) fsm-send - send an event to a state machine fsm-call - send an event and wait for reply fsm.el is similar to but different from Distel: http://fresh.homeunix.net/~luke/distel/> Emacs' tq library is a similar idea. -- Matteo F. Vescovi signature.asc Description: PGP signature
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
Hi All, 2016-12-13 9:29 GMT+01:00 Bálint Réczey : > Hi Guillem, > > 2016-11-27 23:11 GMT+01:00 Bálint Réczey : >> Hi Guillem, >> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover : >>> Hi! >>> >>> This was discussed relatively recently, but it was not entirely clear >>> to me what was the conclusion, if there was any(?), about enabling >>> bindnow by default. >>> >>> And although this got enabled by default in gcc-6 6.2.0-7 when PIE >>> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed >>> out that enabling bindnow in gcc w/o enabling relro too didn't seem to >>> make much sense, but then I didn't notice any rationale for the >>> reversion, instead of say enabling relro too. >> >> GCC enabled bindnow only for architectures which also enabled >> PIE by default, but unlike PIE there were no architecture-specific >> objections against enabling bindnow. >> >> I think talking to Matthias (@Matthias: talking to Guillem) and >> reaching a consensus would be badly needed for the project. >> >>> >>> >>> My mine concern is and has always been that bindnow changes the >>> run-time behavior (instead of the build-time one) and could break >>> things such as dlopen() on shared libraries or plugins and similar. >>> And detecting problems becomes harder, and reverting this change >>> iff we notice that it breaks too much might imply rebuilding an >>> unspecified number of packages. So in a way it feels kind of like >>> a transition? >>> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by >>> default in gcc for a long time, but also relro, stack-protector and >>> fortify. Which would seem to imply this might not break that much? >>> (I'm not sure why we are not enabling all those in gcc in Debian >>> too, but that's probably a different conversation to have if at all.) >> >> Lucas already performed the archive-wide rebuild with bindnow >> enabled by dpkg and we have not observed breakages specific to >> bindnow. IMO this is mostly due to packages already disabling >> bindnow through dpkg-buildflags. >> >> Considering that we are already in the transition freeze I suggest >> going with enabling bindnow for all architectures in dpkg and >> for Stretch+1 the responsibility of setting some hardening flags >> could be transferred to gcc. >> IMO this is not a transition because the change does not affect >> package interdependencies. > > Is there any update on this? > > We are running out of time... I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10 according to current NMU rules. If the Release Team increases the severity of #835146 it can reach unstable earlier. Cheers, Balint >>> >>> So at this point, I guess I still have concerns, but only very mild >>> ones, and would not mind one way or another, but would like input >>> from at least the release team, because I don't feel like possibly >>> deciding on this on my own, even more at this stage of the release. >>> >>> Thanks, >>> Guillem
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
On Wed, Dec 14, 2016 at 02:05:44PM +0100, Bálint Réczey wrote: > I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10 > according to current NMU rules. If the Release Team increases the > severity of #835146 it can reach unstable earlier. Thanks! -- WBR, wRAR signature.asc Description: PGP signature
Re: python3 reportbug in experimental: call for testing
> Now that reportbug 6.x is working well and reportbug 7.x is broken with GUI, > wouldn't it be better if we just let reportbug 6 enter stretch? No. Either someone step up and volunteer to maintain the GTK+ interface, or it will simply die. that's how things evolve > I took a try and the error message is broken as well. It suggests that the > user > should install python-vte (Python 2 version!), which is misleading and > useless. > Also there is no such a package like "python3-vte". i know, but i have no clue (nor time to find out) what the replacement for the VTE objects is in the new introspection/gobject world of GTK -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: python3 reportbug in experimental: call for testing
On Wed, 14 Dec 2016 at 08:50:30 -0500, Sandro Tosi wrote:
> > I took a try and the error message is broken as well. It suggests that the
> > user
> > should install python-vte (Python 2 version!), which is misleading and
> > useless.
> > Also there is no such a package like "python3-vte".
>
> i know, but i have no clue (nor time to find out) what the replacement
> for the VTE objects is in the new introspection/gobject world of GTK
The replacement for python-vte is:
Depends: python3-gi, gir1.2-vte-2.91
import gi
gi.require_version('Vte', '2.91')
from gi.repository import Vte
as used by gdebi, terminator and virt-manager, among others.
The Python API of gi.repository.Vte is auto-generated from its C API, and is
likely to be quite similar to python-vte.
S
Re: python3 reportbug in experimental: call for testing
> The replacement for python-vte is:
>
> Depends: python3-gi, gir1.2-vte-2.91
>
> import gi
> gi.require_version('Vte', '2.91')
> from gi.repository import Vte
Thanks Simon, i'll have a look at it again (but i kinda feel that was
not the only issue with vte or other GTK+ APIs usage, but it's a
start)
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi
Re: python3 reportbug in experimental: call for testing
On Wed, 14 Dec 2016 at 09:21:27 -0500, Sandro Tosi wrote:
> > The replacement for python-vte is:
> >
> > Depends: python3-gi, gir1.2-vte-2.91
> >
> > import gi
> > gi.require_version('Vte', '2.91')
> > from gi.repository import Vte
>
> Thanks Simon, i'll have a look at it again (but i kinda feel that was
> not the only issue with vte or other GTK+ APIs usage, but it's a
> start)
I've sent a patch series to #651590 which worked in at least basic testing
(fixing gaps in pygtkcompat's compatibility shims, and moving towards
using Gtk via g-i directly instead of via pygtkcompat).
S
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: [...asking for armel to be retained...] One way in which the need to keep armel around would be reduced is if we could somehow upgrade from armel machines to armhf ones, without requiring a reinstall. After all, armel has been around longer than armhf has, which means that there may be some machines out in the wild that were installed (and upgraded) when armel existed but armhf did not yet (or at least, was not stable yet). Some of those machines might be armv7 machines that would be perfectly capable of running the armhf port, except that it wasn't around yet when they were first installed, and switching to armhf without reinstalling isn't possible. I once did try to do a similar migration on my Thecus (from arm to armel, rather than armel to armhf), but that failed miserably; and since I hadn't installed the firmware update to be able to access the console so as to figure out what went wrong, that essentially bricked the machine. If there was a supported and tested way to upgrade older armel installations on hardware that actually works with armhf, then those machines wouldn't need to be able to run armel anymore, and part of this problem would go away... -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote: > On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: > [...asking for armel to be retained...] > > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to armhf ones, without > requiring a reinstall. > > After all, armel has been around longer than armhf has, which means that > there may be some machines out in the wild that were installed (and > upgraded) when armel existed but armhf did not yet (or at least, was not > stable yet). Some of those machines might be armv7 machines that would > be perfectly capable of running the armhf port, except that it wasn't > around yet when they were first installed, and switching to armhf > without reinstalling isn't possible. > > I once did try to do a similar migration on my Thecus (from arm to > armel, rather than armel to armhf), but that failed miserably; and since > I hadn't installed the firmware update to be able to access the console > so as to figure out what went wrong, that essentially bricked the > machine. > > If there was a supported and tested way to upgrade older armel > installations on hardware that actually works with armhf, then those > machines wouldn't need to be able to run armel anymore, and part of this > problem would go away... I actually highly doubt there are that many armv7 boxes running armel. armhf was a nice performance improvement and worth the hassle to reinstall if you had such a box in the first place. I think most armel systems are probably armv5, often the marvell chips. Not sure if anyone is running it on Raspberry pi (Original, not 2 or 3) systems or if those all run Rasbian armhf instead. -- Len Sorensen
Re: Auto-detecting -dev package dependences from pkg-config
]] Josh Triplett > Does this seem like a reasonable approach? I think it sounds fine, but please remember that it's pkg-config, not pkgconfig. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#847782: ITP: kdiagram -- library for creating business charts
On domingo, 11 de diciembre de 2016 17:54:09 ART Sebastian Ramacher wrote: > Package: wnpp > Severity: wishlist > Owner: Sebastian Ramacher > > * Package name: kdiagram > Version : 2.6.0 > Upstream Author : Klaralvdalens Datakonsult AB > * URL : https://cgit.kde.org/kdiagram.git > * License : GPL-2+ > Programming Lang: C++ > Description : library for creating business charts > > KD Chart and KD Gantt provide an implementation of the ODF Chart > specification. They utilize the Qt's model-view programming model for easy > integration in Qt based applications. > > If anyone from the Qt/KDE team wants to maintain this package instead, > please feel free to take it. Not that I know of, but you can use kde-extras's repositories if you want. -- Without us [Free Software developers], people would study computer science and programming without ever having seen a real program in its entirety. That's like becoming writers without ever having read a complete book. Matthias Ettrich, founder of the KDE project. http://www.efytimes.com/efytimes/25412/news.htm Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#848175: ITP: python-filelock -- platform independent file locking module
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-filelock Version : 2.0.7 Upstream Author : Benedikt Schmitt * URL : https://github.com/benediktschmitt/py-filelock * License : Public domain Programming Lang: Python Description : platform independent file locking module This package contains a single module, which implements a platform independent file locking mechanism for Python. The lock includes a lock counter and is thread safe. This means, when locking the same lock object twice, it will not block. This is packaged as a dependency of the Rekall memory forensics toolkit.
Re: python3 reportbug in experimental: call for testing
On Wed, Dec 14, 2016 at 11:48 AM, Simon McVittie wrote: > I've sent a patch series to #651590 which worked in at least basic testing > (fixing gaps in pygtkcompat's compatibility shims, and moving towards > using Gtk via g-i directly instead of via pygtkcompat). That's amazing Simon, thanks a ton! I've just uploaded reportbug/7.1.0 to experimental with your patches merged in -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#848198: ITP: fonts-noto-color-emoji -- Color emoji set from Android
Package: wnpp Severity: wishlist Owner: "Ming-ting Yao Wei (魏銘廷)" * Package name: fonts-noto-color-emoji * URL : https://www.google.com/get/noto/help/emoji/ * License : Apache 2.0 Description : Color emoji set from Android Noto color emoji is the emoji font set originated from the Android project. It currently supports Unicode 9.0 specs with emojis for different skin tones and family forms. A Debian user discovered that Jessie includes the fontconfig capable of rendering color emoji, but needs a workaround for a bug fixed in newer fontconfig that is not in Debian main yet: http://stdio.tumblr.com/post/114082931782 Currently this package should be best maintained with the supports from Debian Fonts Task Force.
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to armhf ones, without > requiring a reinstall. There is a script for that here: https://wiki.debian.org/CrossGrading -- bye, pabs https://wiki.debian.org/PaulWise
Bug#848203: ITP: backports.functools-lru-cache -- backport of functools.lru_cache from Python 3.3
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: backports.functools-lru-cache Version : 1.3 Upstream Author : Jason R. Coombs * URL : https://github.com/jaraco/backports.functools_lru_cache * License : MIT Programming Lang: Python Description : backport of functools.lru_cache from Python 3.3 needed by pylint 1.6.4
Bug#848206: ITP: nototools -- Utilities for building and maintaining noto fonts
Package: wnpp Severity: wishlist Owner: "Ming-ting Yao Wei (魏銘廷)" * Package name: nototools Upstream Author : Google Inc. * URL : https://github.com/googlei18n/nototools * License : Apache License 2.0 Programming Lang: Python Description : Utilities for building and maintaining noto fonts This is the utility for Noto contributors to build and maintain Noto fonts, and is required if we need to build fonts-noto-color-emoji from source. After priminary build of Noto Color Emoji I found that due to the old version of fonttools it requires patching and disabling Python 3 support to make it work. As this utility is for building font from source, the "maintaining" function of this package becomes not so important. This package should be best maintained by Debian Fonts Task Force.
