Re: Debtags consolidation
On Wed, Feb 03, 2016 at 08:24:51AM +1000, Paul Wise wrote: > I think removing anonymous debtags will eliminate casual debtagging > from non-technical users. If we can still allow anonymous submissions > after the SSO integration then I would be willing to moderate > anonymous submissions once a week as I do for screenshots. Perhaps the > site could allow any DD moderate any package and any DM to moderate > their packages? I tried anonymous submissions and relying on myself or others do manual review, and all that happened so far is that both others and me have very quickly lost interest, and after reviewers lost interest, debtags stalled. I consider that way tried, and failed. I see value in authenticated users contributing tags directly to the reviewed set, and in changing https://debtags.debian.org/edit/debtags so that the changes that are saved take effect immediately without review. I think that it simplifies both the site codebase (and as a consequence the maintenance worload on it) and the data workflow, and I would consider it a great boon if the workflow became simple enough that others besides me can actually understand it. I consider moving on to non-anonymous tagging only a definite move towards something better than we have now, which is why I do not hesitate to go that way. I am skeptical about the value of having such a low enough barrier of entry to tag submissions that even creating an alioth account would be too much, because I don't think such casual visitors would be motivated to do much more than just click through the AI-suggested tags. I rather make it easy for the package maintainers and other regular debian contributors to regularly go and take good care of things. There can be some value in having anonymous casual visitors submit tags without creating an alioth account first, but I do not see that value as high enough for /me/ to spend the energy to design, code, and maintain an interface, a backend and a workflow for it. I have for years went and implemented all sort of features requests for blue sky ideas of mine and of others, and then ended up with a pile of code and services that I do not have the energy to maintain. I'm done with that, and I'll now just put work into something that I clearly see as a sustainable way forward for me. You are welcome to join as a site comaintainer and design an interface for anonymous tagging and write code for it and commit to maintaining it through future evolutions of the site codebase. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: bugs in bootstrap.debian.net
On 03.02.2016 06:34, Helmut Grohne wrote: Hi Tollef, On Wed, Feb 03, 2016 at 06:10:50AM +0100, Tollef Fog Heen wrote: Those scripts can wrap pkg-config, and pkg-config already knows how to provide user-defined variables, so this sounds like a problem that's solveable. What sounds obvious isn't. The important bit here is which architecture you are building for. pkg-config has an API for this: You invoke it as $DEB_HOST_GNU_TYPE-pkg-config. Those foo-config scripts do not have this API (with rare exceptions). Thus they do not know the host architecture and have no way of correctly invoking pkg-config. Yes, there were proposals checking $DEB_HOST_GNU_TYPE inside foo-config scripts, but this will just break those scripts for those users that are the reason for keeping them. So this doesn't work, but I cannot tell you what works, sorry. In many cases, these files are scripts and don't need to be architecture specific, because they point to paths which are default paths anyway. You can just remove things like @libdir@ and -L@libdir@. And even if the script offers a --libdir or --includedir option you can either remove that option, or lie about it. Matthias
Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)
* Helmut Grohne , 2016-02-03, 06:17: I see that there is now a lintian check for this issue whcih is great, and gives us some idea of how big it is: https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html So that lists 240 packages which are MA:same and also contain an arch-specific foo-config script. The assumption that the tag would only hit MA:same packages is wrong. It hits e.g. libgpg-error-dev, which is correctly not marked MA:same. In defense, this tag is very young and correctly marked with with low confidence. The intention was to check only MA:same and MA:foreign packages (and arch:all packages, but that's a separate tag), but because of a bug MA-less packages are checked too. This will be fixed in the next Lintian release. -- Jakub Wilk
Bug#813574: ITP: libtemplate-stash-autoescaping-perl -- escape automatically in Template-Toolkit
Package: wnpp Severity: wishlist Owner: Julian Maurice * Package name: libtemplate-stash-autoescaping-perl Version : 0.0303 Upstream Author : Shlomi Fish * URL : https://metacpan.org/release/Template-Stash-AutoEscaping * License : Artistic or GPL-1+ Programming Lang: Perl Description : escape automatically in Template-Toolkit Template::Stash::AutoEscaping is a sub class of Template::Stash, automatically escape all HTML strings and avoid XSS vulnerability.
Bug#813577: ITP: ckeditor -- command line builder for CKEditor
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: Dmitry Smirnov Control: block 802738 by -1 Package name: ckbuilder Version: 2.3.0+dfsg Upstream Author: CKSource - Frederico Knabben License: Expat, BSD-2-Clause URL: https://github.com/ckeditor/ckbuilder Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/ckbuilder.git Description: command line builder for CKEditor CKBuilder builds CKEditor from its source code. signature.asc Description: This is a digitally signed message part.
Bug#813374: general: Menus and window popup does not work after recent upgrade
On 02/01/2016 09:01 PM, Vincent Danjean wrote: > It worked well. I was able to move window between the two monitors. > > But, after the last upgrade (see below the upgraded packages), I suffer > several problems after I enabled the external monitor: > - window from iceweasel and icedove opened with a very small size (unless > before where they opened at their last size) [but correctly on the primary > external monitor] > - popup windows from iceweasel and icedove (to ask for password or passphrase > or to ask to restore or not the session) all opened on the laptop monitor in > a small size (wheras the mouse was on the primary monitor) > - more problematic (hence this bug report), menus in iceweasel and icedove do > not draw themselves. The heading is selected but nothing appears below. It > is > also true for menus from their toolbar (ie 'Tags' selector in icedove for > example) > - for emacs, if the window is at a high where the secondary monitor have > pixels, the menu is opened on the left of the secondary monitor! Else, the > menu do not open at all. > - other programs work correctly (at least the 'Applications' menu of XFCE that > I use as VM, menus from Thunar, menus and windows from GIMP, ...) > - for problematic applications (at least Iceweasel, Icedove and Emacs), moving > the window onto the other monitor (without closing it) allows menus to be > correctlt drawn (on the other monitor). When the window is moved again onto > the primary external monitor, the problematic behavior occurs again. > > So, if someone have an idea of what happens, of where (in which softare) is > the bug, or just want additionnal inputs, just say so. For now, this is really > annoying. > > Regards, > Vincent Vincent, This sounds like issues with your window manager, since you mostly complain about issues with window placements and dispositions. Just to be sure, you're using XFCE, right? Cheers, Thomas Goirand (zigo)
Re: [Q] How we set Vcs-* ?
On 02/01/2016 08:38 PM, Andreas Tille wrote: > So why not using such a translation process without a need to change > every single debian/control file. +1 for this idea, +2 (workflow) if you implement it! :) Thomas Goirand (zigo)
Bug#813583: ITP: python-fuelclient -- CLI tool and a Python API wrapper for interacting with Fuel
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-fuelclient Version : 9.0.0~0+2016.02.01.git.7f4bacbed0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/python-fuelclient/ * License : Apache-2.0 Programming Lang: Python Description : CLI tool and a Python API wrapper for interacting with Fuel Fuel is an open source deployment and management tool for OpenStack. Developed as an OpenStack community effort, it provides an intuitive, GUI-driven experience for deployment and management of OpenStack, related community projects and plug-ins. . Fuel brings consumer-grade simplicity to streamline and accelerate the otherwise time-consuming, often complex, and error-prone process of deploying, testing and maintaining various configuration flavors of OpenStack at scale. Unlike other platform-specific deployment or management utilities, Fuel is an upstream OpenStack project that focuses on automating the deployment and testing of OpenStack and a range of third-party options, so it’s not compromised by hard bundling or vendor lock-in. . python-fuelclient provides a CLI tool and a Python API wrapper for interacting with Fuel.
Bug#813591: ITP: baka-mplayer -- A libmpv based media player
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: baka-mplayer Version : 2.0.4 Upstream Author : Daniel Clarke * URL : http://bakamplayer.u8sand.net/ * License : GPL-2 Programming Lang: C++ Description : A libmpv based media player Baka MPlayer is a free and open source, cross-platform, libmpv based multimedia player. Its simple design reflects the idea for an uncluttered and enjoyable environment for watching tv shows. Features: * Gesture seeking. * Smart playlist. * Dim Desktop. * Hardware accelerated playback (vdpau, vaapi, vda). * Youtube playback support (and others). * Multilingual support (we are looking for translators!). * And more...
Bug#813606: general: Lenovo G50-30 freezes running debian 4.3.0-0.bpo.1-amd64; Intel Pentium N3530
Package: general Severity: normal Dear Maintainer, Im using Debian on a Lenovo G50-30 notebook with the 4.3.0-0.bpo.1-amd64 Kernel and Gnome from jessie-stable. After booting everything works, but after about 20 minutes the system freezes completely an nothing works anymore. You have to shut it hown hardly and reboot it. Then it works some time and freezes again. The notebook is running on a Intel Pentium N3530. If it freezes, everything is stopped instantly, like PulseAudio, Bluetooth- or Networkconnection. The problem also exists with Ubuntu, look here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1511019 or https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536327 -- 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 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
bat: 3 different programms and one name
Hi all, after uploading alsa-utils 1.1.0-1 #813473 popped up [0]. It seems that we have /usr/bin/bat and /usr/share/man/man1/bat.1.gz three times in unstable: bacula-console-qt bareos-bat alsa-utils It should be easy to rename ie alsa's bat to bat-alsa but should this be mentioned in a patched manpage as well? How is the correct way to solve this? [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813473 Any hint is appreciated. Thanks in advance -- Do you smell something burning or is it me?
Re: bat: 3 different programms and one name
On Wed, Feb 03, 2016 at 07:54:22PM +0100, Elimar Riesebieter wrote: > It seems that we have /usr/bin/bat and /usr/share/man/man1/bat.1.gz > three times in unstable: > > bacula-console-qt > bareos-bat > alsa-utils > > It should be easy to rename ie alsa's bat to bat-alsa but should > this be mentioned in a patched manpage as well? > > How is the correct way to solve this? The correct way is indeed to rename the binary. Another suggestion is to name it "basic-audio-tester" instead of "bat-alsa". Inform upstream of their conflict with existing programs with the same name, so perhaps they can change it as well. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#813374: general: Menus and window popup does not work after recent upgrade
Le 03/02/2016 12:31, Thomas Goirand a écrit : > Vincent, > > This sounds like issues with your window manager, since you mostly > complain about issues with window placements and dispositions. Just to > be sure, you're using XFCE, right? Yes. But is the WM involved in (the placement of) application menus ? If yes, xfce seems indeed a good target. Regards, Vincent > Cheers, > > Thomas Goirand (zigo) > -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?
Hi! On Tue, 2016-02-02 at 20:23:08 +, Simon McVittie wrote: > On 02/02/16 17:38, Jonathan Dowland wrote: > > I must say that I do not like this proposal. The current situation does > > result > > in under-maintained packages requiring churn, but that's true for many > > aspects > > of them, not least their policy version. It's a good indicator of which > > packages need some attention. > > At the moment, lintian needs changes anyway whenever best-practice > changes. Would it perhaps make sense to do the same transformations in > dak - perhaps data-driven, with some regexes supplied by the Alioth or > lintian maintainers - so that what is published in the Sources file for > consumers is always the currently-preferred form? That was exactly my thought. dak is already applying overrides for Section and Priority, and adding Tag fields, etc, it might as well fix other stuff. > > I think it makes the > > cognitive load of the control file larger. You have to know there are > > special > > rules that exist for some URLs, but not all. Exactly, I've to say I cannot agree more with Jonathan. And that while having to adapt the whole archive for new URL changes is cumbersome, introducing external magic would be worse, because downstreams or casual users will not know what those URLs refer to, and we'll also have to hardcode those magic rules in anything that tries to use those URLs. Thanks, Guillem
Bug#813652: ITP: golang-github-tarm-serial -- Go package for serial port communucation
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: golang-github-tarm-serial Version : 0.0+git20151113 Upstream Author : tarm * URL : https://github.com/tarm/serial * License : BSD-3-clause Programming Lang: go Description : Go package for serial port communucation Go package to allow user to read and write from the serial port as a stream of bytes.
uv: (5)
http://boothtag.com/aletbpn.php Any fool can make a rule, an d any fool will min d it.Roosevelt Cuzman
