Re: sane chromium default flags - include --enable-remote-extensions
On Fri, 24 Feb 2017 15:14:18 +0100 m...@linux.it (Marco d'Itri) wrote: > > To be honest I've the feeling that we're doing a disservice to our > > users when we release stretch with the current defaults. Putting > I amazed by this decision: this is the kind of thing that makes > people not take Debian seriously. > This behaviour should either be implemented consistently by all > browsers or the default reverted. > Users expect their browser to update the extensions that they have > installed themselves, so the excuse about "unrequested network > connections" looks like just an ideological decision. It's not even about updating: the first version of chromium with this build-time tweak simply disabled all already installed extensions for me so they were not activated when I restarted chromium after that upgrade session -- and hence were not shown in UI etc. What's worse, it's futile to attemt to reinstall them: the settings tab for the extensions works OK, the chromiums "extensions store" (whatever its real name is, I dunno) works OK, just when you try to install an extension, you get some mystical error message having nothing to do with what Debian's build did, and with no hint at what to do next. I possess the necessary google-fu and I'm a programmer after all, so that wasn't too hard for me to find the cause and implement the solution, but for a plain computer user that would be a complete dead-end.
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
Hello,
Adam Borowski, on ven. 24 févr. 2017 15:44:38 +0100, wrote:
> Yeah, it is. There is one problem, though -- even if you install the extra
> docs,
> zgrep -i ubrl `dpkg -L imagemagick-6{.q16,-common,-doc}`
> shows a wee bit too little for my taste.
Indeed, apparently I forgot to add documentation. I have submitted
patch, thanks.
> I wonder about the histogram tool.
Actually I was thinking that it could be part of gnuplot (it has "set
terminal dumb", but it could have a "set terminal braille"), but a very
simple script that emits histograms from basic data makes sense to me
too. I was wondering whether such simple tool already exist, using just
ASCII to produce the histograms, but couldn't find one with a quick
search.
It would probably be useful to make such tool have an optional ASCII
mode. It should also not assume UTF-8 output, but use something like "|
iconv -f utf-8", since chinese people have their own way of encoding
unicode.
Samuel
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
Control: retitle -1 ITP: braillegraph -- simple histogram tool producing text dot-matrix graphs On Sat, Feb 25, 2017 at 02:46:57PM +0100, Samuel Thibault wrote: > Indeed, apparently I forgot to add documentation. I have submitted > patch, thanks. Awesome, thanks! > > I wonder about the histogram tool. > > Actually I was thinking that it could be part of gnuplot (it has "set > terminal dumb", but it could have a "set terminal braille") Alas, it won't work: I see that, while alignment of the graph itself works well, anything but terminals (which force a char-cell grid) fails to give Braille and ASCII characters the same width, despite requesting fixed-width display. You can see how bad it is on https://angband.pl/doc/alluni.txt -- you should get an aligned grid with right edge of every full block forming an even vertical line, yet most blocks fail to align even within themselves. gnuplot relies on being able to place labels within the image, which works for ASCII and maybe Latin/Greek/Cyrillic but, except for most terminals, not for anything else. Too many people use in-browser webmails or GUI clients (a heresy, mutt is the way to go!), or read list archives via WWW. > but a very simple script that emits histograms from basic data makes sense > to me too. I was wondering whether such simple tool already exist, using > just ASCII to produce the histograms, but couldn't find one with a quick > search. That's what we have ITPs for -- thanks for pointing out my image converter is redundant. It looks like no one made a histogram tool using high-resolution Braille yet, thus I'll add some features (like auto-scaling Y axis -- doing it manually is tedious, horizontal mode, etc) and package this part. > It would probably be useful to make such tool have an optional ASCII > mode. Meh, I don't think mail clients, terminals and web browsers without Unicode support deserve much thought. There's a problem in jessie-'s FreeMono where it produces a grayish block for Braille (both legitimate use and our abuse) but since the fix comes a release cycle before this graphing tool, it might be good enough. > It should also not assume UTF-8 output, but use something like "| > iconv -f utf-8", since chinese people have their own way of encoding > unicode. I'm about to raise a thread about dropping ancient locale support in buster, almost no one uses them anymore, GUI stuff hardly pays lip service to non-Unicode, and it seriously burdens i18n efforts. In any case, there wasn't a single bug report filed with such an old Chinese locale since 2012; 2013-2017 stats are: ISO-8859-1 | 736 ISO-8859-15| 187 ISO-8859-2 |46 KOI8-R |39 EUC-JP |14 TIS-620| 2 Unrelated: perhaps some other name than "braillegraph" would be better? The glyphs used belonging to the Braille range is an implementation detail, users probably won't care other than for requiring Unicode. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Bug#856158: ITP: g810-led -- LED configuration tool for Logitech G410/G610/G810/G910 keyboards
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: g810-led Version : 0.1.0 Upstream Author : MatMoul * URL : https://github.com/MatMoul/g810-led * License : GPL-3 Programming Lang: C++ Description : LED configuration tool for Logitech Gx10 keyboards g810-led is a configuration tool for the LEDs on Logitech Gx10 gaming keyboards: G410, G610, G810 and G910. The LEDs can be configured in a variety of ways, depending on the keyboards' capabilities: * pre-defined effects (breathing, colour-cycling, waves) * individual key colours and/or intensities * key group colours and/or intensities
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
Adam Borowski, on sam. 25 févr. 2017 18:24:33 +0100, wrote: > Alas, it won't work: I see that, while alignment of the graph itself works > well, anything but terminals (which force a char-cell grid) fails to give > Braille and ASCII characters the same width, despite requesting fixed-width > display. That's not normal: fixed-width fonts should really have fixed-width for the characters used by gnuplot. > You can see how bad it is on https://angband.pl/doc/alluni.txt -- you should > get an aligned grid with right edge of every full block forming an even > vertical line, yet most blocks fail to align even within themselves. That's expected: some characters have double-width, others have zero-width. But for characters that have single-width, they are really aligned with a proper fixed-width font. > gnuplot relies on being able to place labels within the image, which works > for ASCII and maybe Latin/Greek/Cyrillic but, except for most terminals, not > for anything else. Then gnuplot is missing taking into account the value returned by wcwidth() (0, 1, 2, ...), that's the bug. Samuel
Bug#829076: general: Random freezes but the mouse can still move
Hi John, thank you for coming forward with your problem, but I think a better approach for resolving your issue is to bring it up on IRC, or use the the debian-user mailing list to further debug the issue. Then, if your problem is not solved, but further narrowed down, you can provide better infos and file the bug against the respective package. The IRC channel is #debian on irc.oftc.net, and the mailing list you can find at https://lists.debian.org/debian-user/. See you there! Greetings, Lee
Processed: Re: Bug#829076: general: Random freezes but the mouse can still move
Processing commands for cont...@bugs.debian.org: > severity 829076 normal Bug #829076 [general] general: Random freezes but the mouse can still move Severity set to 'normal' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 829076: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829076 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#856165: ITP: pupnp-1.8 -- Portable SDK for UPnP Devices, version 1.8
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-Cc: debian-devel@lists.debian.org, n...@leverton.org * Package name: pupnp-1.8 Version : 1.8.0 Upstream Author : Intel Corporation, Marcelo Roberto Jimenez * URL : http://pupnp.sourceforge.net/ * License : BSD Programming Lang: C Description : Portable SDK for UPnP Devices, version 1.8 The Portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification - see http://www.upnp.org/ for specifications. Version 1.8 has been a work in progress for many years and makes a number of API changes compared to version 1.6. It's designed to be co-installable with libupnp 1.6. Upstream are planning to continue maintaining the 1.6 branch since it's much more widely used. It's currently only available on GitHub: https://github.com/mrjimenez/pupnp pupnp-1.8 is needed for packaging the active fork of mediatomb which I'm having a look into. This fork solves the current issues facing the mediatomb package which bundles a heavily patched version of libupnp containing a number of security issues. I'm CCing the maintainer for libupnp, although I have a strong feeling he is MIA. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#818705: marked as done (general: multipackage issue)
Your message dated Sat, 25 Feb 2017 20:39:35 +0100 with message-id <106e016a-ce3e-dcbc-0548-9db1dabe0...@rocketjump.eu> and subject line general: multipackage issue has caused the Debian Bug report #818705, regarding general: multipackage issue to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 818705: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818705 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: critical Justification: breaks unrelated software Dear Maintainer, when sshfs is mounted IE: my webserver and I do a package update(updating libreO, so must be removed first) lxdesktop file manager crashes. Im noticing it sometimes generically with the sshfs mount, which remains mounted but apt-get apt-fast and synaptic should not cause this. I do not know what is causing this. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- kthxbye--- End Message ---
Bug#818705: general: multipackage issue
Hi Richard, please ask for support in the Debian IRC channel, which you can reach at #debian on irc.oftc.net. Or the debian-user mailinglist, which is found at https://lists.debian.org/debian-user/. There we'll be able to further debug your issue. See you there! Greetings, Lee
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
On Sat, Feb 25, 2017 at 08:05:32PM +0100, Samuel Thibault wrote: > Adam Borowski, on sam. 25 févr. 2017 18:24:33 +0100, wrote: > > Alas, it won't work: I see that, while alignment of the graph itself works > > well, anything but terminals (which force a char-cell grid) fails to give > > Braille and ASCII characters the same width, despite requesting fixed-width > > display. > > That's not normal: fixed-width fonts should really have fixed-width for > the characters used by gnuplot. "Should have" and "have" are different things. :( > > You can see how bad it is on https://angband.pl/doc/alluni.txt -- you should > > get an aligned grid with right edge of every full block forming an even > > vertical line, yet most blocks fail to align even within themselves. > > That's expected: some characters have double-width, others have > zero-width. My test sheet accounts for that: it includes only wcwidth()==1 and 2 characters (recently updated for unstable's glibc). You can see that most lines include 64 characters, CJK ones have 32, a few lines are mixed. > But for characters that have single-width, they are really > aligned with a proper fixed-width font. Depends on your software. xterm, libvte, pterm, rxvt-unicode get it right, mousepad, firefox, chromium and Microsoft Edge don't. They prefer appearance over accuracy, and when borrowing a glyph from another font, they use the other font's horizontal advance which breaks the fixed width rule. > > gnuplot relies on being able to place labels within the image, which works > > for ASCII and maybe Latin/Greek/Cyrillic but, except for most terminals, not > > for anything else. > > Then gnuplot is missing taking into account the value returned by > wcwidth() (0, 1, 2, ...), that's the bug. I don't know whether gnuplot is doing it correctly, I haven't tested -- but even if it does, the output will be misrendered by browsers. This is not restricted to Braille tricks, same happens if your label includes letters that happen to not be in the recipient's chosen font, and you can't control the latter. Thus, the only safe way to use Braille for drawing is to not mix it with any other character range at all -- or at most, place labels exclusively to the right of a rectangular graph. Even labels at the bottom turned out to be badly shifted. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
Adam Borowski, on sam. 25 févr. 2017 22:31:57 +0100, wrote: > On Sat, Feb 25, 2017 at 08:05:32PM +0100, Samuel Thibault wrote: > > That's expected: some characters have double-width, others have > > zero-width. > > My test sheet accounts for that: it includes only wcwidth()==1 and 2 > characters (recently updated for unstable's glibc). Ah, ok, sorry I didn't actually check :) > > But for characters that have single-width, they are really > > aligned with a proper fixed-width font. > > Depends on your software. xterm, libvte, pterm, rxvt-unicode get it right, > mousepad, firefox, chromium and Microsoft Edge don't. Ok, but would one really look at the output of text-gnuplot in such software? Cases where I happened to use the text-gnuplot were always inside an xterm or such. In other words: it's not because in some odd cases things go wrong that one shouldn't implement the often-used case. > > > gnuplot relies on being able to place labels within the image, which works > > > for ASCII and maybe Latin/Greek/Cyrillic but, except for most terminals, > > > not > > > for anything else. > > > > Then gnuplot is missing taking into account the value returned by > > wcwidth() (0, 1, 2, ...), that's the bug. > > I don't know whether gnuplot is doing it correctly, I haven't tested -- but > even if it does, the output will be misrendered by browsers. But if the output is to be rendered in a browser, one would use a png or svg output :) Samuel
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
On Sat, Feb 25, 2017 at 10:44:12PM +0100, Samuel Thibault wrote: > Adam Borowski, on sam. 25 févr. 2017 22:31:57 +0100, wrote: > > On Sat, Feb 25, 2017 at 08:05:32PM +0100, Samuel Thibault wrote: > > > But for characters that have single-width, they are really > > > aligned with a proper fixed-width font. > > > > Depends on your software. xterm, libvte, pterm, rxvt-unicode get it right, > > mousepad, firefox, chromium and Microsoft Edge don't. > > Ok, but would one really look at the output of text-gnuplot in such > software? Cases where I happened to use the text-gnuplot were always > inside an xterm or such. Well, if you run an _x_term, you can just as well use X forwarding or toss a png/svg over. On the other hand, mailing a graph or putting it in a commit message will meet a variety of clients, many of them in a browser. Alternatively, you can place the image on some random web server, but that's often tedious, and unlikely to stay 10 years from now. > > I don't know whether gnuplot is doing it correctly, I haven't tested -- but > > even if it does, the output will be misrendered by browsers. > > But if the output is to be rendered in a browser, one would use a png or > svg output :) The output is meant to be rendered in a proper $DEITY-fearing mail/usenet client, a rightful text editor[1], less or git's built-in pager. It's just that _some_ heretics read their mail in a buggy GUI client or a web page, view commit messages on github rather than locally, and so on. And in case their web browser is not elinks, we need to avoid bugs. Meow! [1]. Which excludes both emacs and vi, of course! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Bug#856033: ITP: brailleimg -- produce text images and graphs abusing Braille glyphs
Adam Borowski, on sam. 25 févr. 2017 22:31:57 +0100, wrote: > On Sat, Feb 25, 2017 at 08:05:32PM +0100, Samuel Thibault wrote: > > Adam Borowski, on sam. 25 févr. 2017 18:24:33 +0100, wrote: > > > gnuplot relies on being able to place labels within the image, which works > > > for ASCII and maybe Latin/Greek/Cyrillic but, except for most terminals, > > > not > > > for anything else. > > > > Then gnuplot is missing taking into account the value returned by > > wcwidth() (0, 1, 2, ...), that's the bug. > > I don't know whether gnuplot is doing it correctly, I haven't tested Actually it doesn't even properly handle latin1 characters in utf-8 locale. Samuel
Bug#856176: ITP: pweave -- scientific report generator with embedded Python computations
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: pweave Version : 0.25 Upstream Author : Matti Pastell * URL : http://mpastell.com/pweave/ * License : BSD Programming Lang: Python Description : scientific report generator with embedded Python computations Pweave is a scientific report generator and a literate programming tool for Python. Pweave can capture the results and plots from data analysis and works well with NumPy, SciPy and matplotlib. It is able to run Python code from source document and include the results and capture matplotlib plots in the output. This software is a dependency to the future scientific report plugin for the Spyder IDE. The packaging will be be co-maintained the Debian Science Team alongside the spyder source package.
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Package: wnpp Severity: wishlist Owner: Jason Pleau * Package name: polybar Version : 3.0.4 Upstream Author : Michael Carlberg * URL : https://github.com/jaagr/polybar/ * License : MIT/Expat Programming Lang: C++ Description : fast and easy-to-use status bar The main purpose of Polybar is to help users create awesome status bars. It has built-in functionality to display information about the most commonly used services, such as: * Systray icons * Window title * Playback controls and status display for MPD using libmpdclient * ALSA volume controls * Workspace and desktop panel for bspwm and i3 * Workspace module for EWMH compliant window managers * Keyboard layout and indicator status * CPU and memory load indicator * Battery display * Network connection details * Backlight level * Date and time label * Time-based shell script execution * Command output tailing * User-defined menu tree * Inter-process messaging Users can also develop their own modules and/or integrate modules created by others. It can be used a replacement for status bars / panels used in different window managers and desktop environments. I plan to maintain this package in collab-maint on alioth
Re: sane chromium default flags - include --enable-remote-extensions [and 1 more messages]
On Fri, Feb 24, 2017 at 10:05 AM, Ian Jackson wrote: > It seems likely to me that this is a bug, not some kind of > "ideological mistake". You basically nailed it, especially since I don't care either way [0]. People are yelling must have safe defaults on one side. And people are yelling must have unsafe defaults on the other. The negativity from both sides is disheartening. Can't we all just get along [1]? Best wishes, Mike [0]http://bugs.debian.org/856183 [1]http://www.huffingtonpost.com/jenna-brownson/cant-we-all-just-get-alon_3_b_10150704.html
