Uploading python-xstatic-* packages in Debian
Just a quick explanation of what I'm doing with the python-xstatic-* packages here. I've thought about how to do it best for a long time. Upstream for the OpenStack dashboard (otherwise called Horizon) decided (very rightly) that holding embedded copies of javascript files was a bad idea. So they now rely on Python module XStatic-* instead of their embedded copy. Each of these small python modules contain embedded copies of static files, like javascript, .css, or the like. When upstream runs tests using PyPi, it downloads the Python module in a virtualenv, then uses whatever static file(s) comes with the Python module. In Debian, Horizon will depend on python-xstatic-* packages. Most of the time, when the static files are available in Debian, the resulting package do *not* embed a copy (I delete it from the resulting .deb file, depend on the libjs-* corresponding package, and either symlink to the target file or patch the xstatic/pkg/*/__init__.py which is what upstream recommends doing). Note that the XStatic python modules aren't just meta packages, they also offer a mechanism for a Python script to discover where to find a given static file in the system (which really, isn't obvious, as the Debian archive is a bit messy in this regard, especially when dealing with static files that aren't javascript like .css or .less files). As for the licensing, note that each XStatic package follows the upstream licensing of the files it embeds (which IMO, is a very good choice). It is also worth noting that the Debian package version for XStatic modules is following the static file package version. For example, even though upstream released XStatic-JQuery 1.10.2.1, the Debian package version is 1.7.2.0, to match the version number of libjs-jquery. Also, to have no surprise, I sometimes intentionally restricted version numbers. For example: python-xstatic-angular has "Depends: libjs-angularjs (<< 1.2.17), libjs-angularjs (>= 1.2.16)", just to avoid surprises. If one day, it becomes uninstallable, then I will know the python-xstatic package will have to be updated. For some XStatic packages, the embedded static files are not present in Debian. That is the case for example with python-xstatic-hogan, python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the above 3 packages, the upstream source code is part of a much larger project. See for example bootstrap-scss, which comes with a huge Ruby framework. I have no intention to package all of that... As I know very little about packaging of some upstream code (for example, I have never maintained ruby or nodejs packages), and that I don't need them anyway (I only need a few javascript files from them, I will have no use of Ruby or nodejs code), then I decided to *not* package the full upstream package, and leave the embedded copy inside the python-xstatic-* packages. This is until someone needs the full upstream package, at which point I will remove the embedded copy, and point to the relevant files inside the recently uploaded package. Also, for the sake of simplicity, I'm not removing the embedded copy of static files from the XStatic source package (as long as these are DFSG compliant: I had to remove one of them because it contained the .min.js which isn't desirable). If you want to package one of the files which I will embed in python-xstatic-* packages, just let me know, so that we keep only a single copy in Debian. As for other Python packages for which upstream is embedding static file copies, I would recommend you, as a maintainer, to point to the relevant packages in PyPi to upstream, so they can adopt the same technique. My only concern with all of this, is that it will produce a lot of micro-packages. Though I believe the benefits of having a clean system to remove embedded copies and having a clean way to find these files on a Debian system outweighs the added load on our infrastructure. I thought it was best to inform my fellow Debian contributors about what I was doing, so that there's no surprise. Also, I would welcome suggestions if you have any. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ec648d.4010...@debian.org
Bug#758087: ITP: python-xstatic-jasmine -- Jasmine JS XStatic support
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-xstatic-jasmine Version : 1.3.1.1 Upstream Author : Radomir Dopieralski * URL : https://github.com/stackforge/xstatic-jasmine * License : Expat Programming Lang: Python Description : Jasmine JS XStatic support XStatic is a packaging standard to package external (often 3rd party) static files as a Python package, so they are easily usable on all operating systems, with any package management system or even without one. . Many Python projects need to use some specific data files, like javascript, css, java applets, images, etc. Sometimes these files belong to YOUR project (then you may want to package them separately, but you could also just put them into your main package). But in many other cases, those files are maintained by someone else (like jQuery javascript library or even much bigger js libraries or applications) and you definitely do not really want to merge them into your project. So, you want to have static file packages, but you don’t want to get lots of stuff you do not want. Thus, stuff required by XStatic file packages (especially the main, toplevel XStatic package) tries to obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web framework or other stuff you don't want. Maybe there will be optional XStatic extensions for all sorts of stuff, but they won't be required if you just want the files. . By having static files in packages, it is also easier to build virtual envs, support linux/bsd/... distribution package maintainers and even windows installs using the same mechanism. . This package provides Jasmine JS support as a Python module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814072839.4300.2217.report...@buzig.gplhost.com
Re: Uploading python-xstatic-* packages in Debian
On Thu, 14 Aug 2014, Thomas Goirand wrote: > Just a quick explanation of what I'm doing with the python-xstatic-* > packages here. I've thought about how to do it best for a long time. Thanks! I was wondering. > It is also worth noting that the Debian package version for XStatic > modules is following the static file package version. For example, even > though upstream released XStatic-JQuery 1.10.2.1, the Debian package > version is 1.7.2.0, to match the version number of libjs-jquery. Idea here: can’t python-xstatic-jquery just take over libjs-jquery via Provides, so we have one binary package less after this? (Of course, if the Debian JS maintainers agree, and probably will want to (co-)maintain python-xstatic-jquery after this.) Similar for the other ones. That would mean we’d have almost zero cost for the addi‐ tion of python-xstatic-* because they’d just take over the non-xstatic ones and provide the same functionality plus more. > My only concern with all of this, is that it will produce a lot of > micro-packages. Though I believe the benefits of having a clean system > to remove embedded copies and having a clean way to find these files on > a Debian system outweighs the added load on our infrastructure. Right… which is why I suggested the above ;-) As for micro packages in general… I’d say the goal here is to remove code duplication, so packaging things like this is useful, but if there are several micro packages with the same dependencies, they could be grouped into one binary package, for example this was done in src:mediawiki-extensions which produces mediawiki-extensions-base for all those with no additional dependencies, and then several small packages that contain only one or two extensions each, which share some additional dependencies like PHP modules, graphviz, etc. Since we can have versioned Provides soon, I believe this could be used by most of the JS packages. A binary package libjs-jquery-bundle which Provides all the others with versions. This would leave us with the maintainer burden because it has multiple upstreams with different versions. Simply adding the version numbers will not always sort well, either… but I think that the overall load (maintainers + infrastructure + mirrors + users) will be the lowest like that. bye, //mirabilos PS: [OT] A coworker just shared this in our MUC: https://lh3.googleusercontent.com/-bZId5j2jREQ/U-vlysklvCI/CrA/B4JggkVJi38/w426-h284/bd0fb252416206158627fb0b1bff9b4779dca13f.gif -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1408140934140.30...@tglase.lan.tarent.de
Re: let missing-debian-source-format lintian tag be a warning!
On Wed, 2014-07-16 at 09:20:51 +0200, Raphael Hertzog wrote: > On Wed, 16 Jul 2014, Guillem Jover wrote: > > The only reason for that warning right now is to pester people into > > either switching, which they should be doing out of their own > > volition anyway because people think the new formats are really > > superior and help them. Or so that people set it explicitly to 1.0 > > just to shut up the warning, and then we have some kind of stats of > > how many people have been pestered… Which I think is the wrong way > > about trying to get people to switch. > > You see it only from a negative side, sure there are a few people who > consider this message as "pestering them" but it really filled the role > of the missing lintian warning for all people who create source packages > from scratch and/or who take over old packages and use the lintian output > as their todo list. I'll take a long tail of packages that have not switched to new stuff because they are practically unmaintained or because the maintainer didn't yet find the time to switch, than one that is composed of those plus ones from disgruntled or alienated maintainers, any day. Removal of that warning is just a step in trying to heal those “wounds”. > Certainly that without this message the adoption rate of the new formats > would not have been so good as it has been (which despite some of the > critics, is probably one the best adoption rate for such wide scale opt-in > changes in the Debian history). I don't think the adoption rate has been much different in relative terms to any other such change in Debian, and I expect the long tail to linger for a long time. I also think a bigger factor was the very aggressive campaign at the beginning, which at the same time seemed counterproductive as it pushed the wrong buttons for quite some people. > So to sum it up, I'm OK for dropping that message but only if lintian gets > the corresponding tag raised to a warning level and IMO it still makes > sense in the long term for dpkg-source to abort if debian/source/format is > missing, precisely because the historical default no longer matches > Debian's desired default. It does not make sense, because when it comes to source packages, there isn't and never has been a default from dpkg-source or even Debian. dpkg-source builds whatever is provided by the maintainer, and it does not (and cannot as currently designed) perform any format conversion on its own (compared to dpkg-deb f.ex.). There might be a project preferred or recommended format, or packages such as dh-make or debmake might have such default but certainly not in dpkg-source or Debian. Bumping that lintian tag to a warning would be rather inappropriate IMO. Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814082956.ga13...@gaara.hadrons.org
Re: Reverting to GNOME for jessie's default desktop
Can we please keep accessibility for the disabled in mind too? Unless Debian wants to be completely ableist, Gnome and KDE are the only two viable options. I worked in adaptive technology for years training blind users to use JAWS under windows. I think it's great that similar technology now exists in the free software ecosystem. It would be a shame to leave it out based purely on the needs of sighted users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ec7682.40...@speakeasy.net
Filed Bug#758096: tasksel: Allow to select specific packages during installation - just "DE", "Web server", "Mail server" is NOT enough
Just filed the bugreport for tasksel (being inspired by the gnome discussion...) Bug#758096: tasksel: Allow to select specific packages during installation - just "DE", "Web server", "Mail server" is NOT enough http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758096 -- With best regards, Vitaliy Filippov -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/op.xkkrjdgq0ncgu9@vitalif.vhome
Bug#758098: ITP: python-xstatic-jquery-migrate -- JQuery Migrate XStatic support
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-xstatic-jquery-migrate Version : 1.2.1.1 Upstream Author : Radomir Dopieralski * URL : https://github.com/stackforge/xstatic-jquery-migrate * License : Expat Programming Lang: Python, JS Description : JQuery Migrate XStatic support XStatic is a packaging standard to package external (often 3rd party) static files as a Python package, so they are easily usable on all operating systems, with any package management system or even without one. . Many Python projects need to use some specific data files, like javascript, css, java applets, images, etc. Sometimes these files belong to YOUR project (then you may want to package them separately, but you could also just put them into your main package). But in many other cases, those files are maintained by someone else (like jQuery javascript library or even much bigger js libraries or applications) and you definitely do not really want to merge them into your project. So, you want to have static file packages, but you don’t want to get lots of stuff you do not want. Thus, stuff required by XStatic file packages (especially the main, toplevel XStatic package) tries to obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web framework or other stuff you don't want. Maybe there will be optional XStatic extensions for all sorts of stuff, but they won't be required if you just want the files. . By having static files in packages, it is also easier to build virtual envs, support linux/bsd/... distribution package maintainers and even windows installs using the same mechanism. . This package provides JQuery Migrate support as a Python module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814091333.11881.31335.report...@buzig.gplhost.com
Re: Reverting to GNOME for jessie's default desktop
Le jeudi 14 août 2014 à 08:53 +0200, Christian PERRIER a écrit : > > → Will you configure different defaults for different architectures? > > Given the current architecture of tasksel, I think it requires > important changes to the code and nearly nobody contributes to the > code: tasksel is in maintenance only mode with easy to fix bugs being > fixed as well as bugs or fixes required to cope with changes in > installed packages. Since a11y looks like a compelling argument to go back to GNOME by default, I think we must address that point one way or another if we want it to happen. I think there are several ways to do that: * tweak the debian-cd scripts to build GNOME images for Linux architectures and Xfce or MATE images for !linux (I can’t tell how hard it is) * make stripped-down gnome-core/gnome metapackages for !linux, relying on lightdm and gnome-flashback (that I can do) * hackishly make gnome-core/gnome metapackages depend directly on Xfce or MATE for !linux instead of GNOME (same) Overall, a gnome-flashback solution would probably be more featureful, but it is clearly less maintained than e.g. Xfce. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408009711.20025.6.camel@dsp0698014
Re: Filed Bug#758096: tasksel: Allow to select specific packages during installation - just "DE", "Web server", "Mail server" is NOT enough
Hi, On Thu, Aug 14, 2014 at 01:05:27PM +0400, Vitaliy Filippov wrote: > Just filed the bugreport for tasksel (being inspired by the gnome > discussion...) > > Bug#758096: tasksel: Allow to select specific packages during > installation - just "DE", "Web server", "Mail server" is NOT enough Beeing inspired by the recent discussion on Blends list, I'd like to add a pointer to the thread basically starting here: https://lists.debian.org/debian-blends/2014/08/msg4.html Currently we can provide tasksel control files in the following Blends (packages): Debian Edu (edu-tasks) Debian Games (games-tasks) Debian GIS (gis-tasks) Debian Junior (junior-tasks) Debian Med (med-tasks) Debian Science (science-tasks) DebiChem (debichem-tasks) The packages contain a file /usr/share/tasksel/descs/-tasks.desc and the usual stuff in /usr/share/doc/ but nothing else. They are exclusively designed as tasksel input. IMHO it would do a nice service to our users to promote these topics on our installers at the time when tasks will be selected. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814095210.gk26...@an3as.eu
Bug#758104: ITP: python-xstatic-jquery.tablesorter -- JQuery Tablesorter XStatic support
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-xstatic-jquery.tablesorter Version : 2.0.5b Upstream Author : Radomir Dopieralski * URL : https://github.com/stackforge/xstatic-jquery.tablesorter * License : Expat & GPL (dual license) Programming Lang: Python, JS Description : JQuery Tablesorter XStatic support XStatic is a packaging standard to package external (often 3rd party) static files as a Python package, so they are easily usable on all operating systems, with any package management system or even without one. . Many Python projects need to use some specific data files, like javascript, css, java applets, images, etc. Sometimes these files belong to YOUR project (then you may want to package them separately, but you could also just put them into your main package). But in many other cases, those files are maintained by someone else (like jQuery javascript library or even much bigger js libraries or applications) and you definitely do not really want to merge them into your project. So, you want to have static file packages, but you don’t want to get lots of stuff you do not want. Thus, stuff required by XStatic file packages (especially the main, toplevel XStatic package) tries to obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web framework or other stuff you don't want. Maybe there will be optional XStatic extensions for all sorts of stuff, but they won't be required if you just want the files. . By having static files in packages, it is also easier to build virtual envs, support linux/bsd/... distribution package maintainers and even windows installs using the same mechanism. . This package provides JQuery Tablesorter support as a Python module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814095718.13404.62783.report...@buzig.gplhost.com
Re: Uploading python-xstatic-* packages in Debian
On 14 Aug 2014 17:43, "Thorsten Glaser" wrote: > > It is also worth noting that the Debian package version for XStatic > > modules is following the static file package version. For example, even > > though upstream released XStatic-JQuery 1.10.2.1, the Debian package > > version is 1.7.2.0, to match the version number of libjs-jquery. Finding it hard to understand the reasoning here. > Idea here: can’t python-xstatic-jquery just take over libjs-jquery > via Provides, so we have one binary package less after this? (Of > course, if the Debian JS maintainers agree, and probably will want > to (co-)maintain python-xstatic-jquery after this.) Similar for the > other ones. That would mean we’d have almost zero cost for the addi‐ > tion of python-xstatic-* because they’d just take over the non-xstatic > ones and provide the same functionality plus more. In what way will python-xstatic-jquery be better than libjs-jquery? Still trying to understand this. Thanks
Re: dpkg-source to automatically add a Testsuite field
Hi! On Tue, 2014-07-08 at 11:22:57 -0300, Antonio Terceiro wrote: > On Tue, Jul 08, 2014 at 03:06:14AM +0200, Guillem Jover wrote: > > > How will it handle an existing value in that field? In the future, we > > > might have other forms of test suite, thus requiring different items in > > > the Testsuite: field. What happens when there is already > > > > > > Testsuite: foo > > > > > > and dpkg-source detects the presence of debian/tests/control? Will it > > > merge `autopkgtest` into the list, or will it replace the existing > > > value? > > > > Ah indeed, here's the current behavior: > > > > The field is parsed as a comma-separated list of values (as per the > > spec). If the debian/tests/control file is present then the value will > > be added to the list. The values will always get emitted in alphabetical > > order as a comma-separated list, any dupes squashed, so that the output > > is reproducible. Unknown values are emitted untouched. > > > > If the field contains “autopkgtest”, but the debian/tests/control file > > is not present, then a warning will be issued, and the value preserved, > > as in “the maintainer knows better!?”. But maybe it is actually better > > to warn and just trim the “autopkgtest” value? > > > > Does this resolve your concern? > > Absolutely. Good. :) At the end I went for warning and removing the autopkgtest value if the file is missing, as that seemed to make more sense, but we can certainly revisit that if there's advantages in keeping the value. It migth make sense to update the last section describing the field in «doc/README.package-tests.rst», now that this is handled by dpkg-source >= 1.17.11. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814110506.ga11...@gaara.hadrons.org
Bug#758116: tasksel: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
Package: tasksel Version: 3.14.1 Severity: normal Tags: d-i Hi, beeing inspired by bug #758096 (I was asked to separate this topic from the topic of this bug) and the recent discussion on Blends list, I'd like to add a pointer to the thread basically starting here: https://lists.debian.org/debian-blends/2014/08/msg4.html Currently we can provide tasksel control files in the following Blends (packages): Debian Edu (edu-tasks) Debian Games (games-tasks) Debian GIS (gis-tasks) Debian Junior (junior-tasks) Debian Med (med-tasks) Debian Science (science-tasks) DebiChem (debichem-tasks) The packages contain a file /usr/share/tasksel/descs/-tasks.desc and the usual stuff in /usr/share/doc/ but nothing else. They are exclusively designed as tasksel input. IMHO it would do a nice service to our users to promote these topics on our installers at the time when tasks will be selected. Kind regards Andreas. -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tasksel depends on: ii apt 0.9.7.9+deb7u2 ii debconf [debconf-2.0] 1.5.49 ii liblocale-gettext-perl 1.05-7+b1 ii perl-base 5.14.2-21+deb7u1 ii tasksel-data3.14.1 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814112620.2992.16379.report...@mail.an3as.eu
Re: dpkg-source to automatically add a Testsuite field
Hey Guillem, Guillem Jover [2014-08-14 13:05 +0200]: > Good. :) At the end I went for warning and removing the autopkgtest > value if the file is missing, as that seemed to make more sense, but we > can certainly revisit that if there's advantages in keeping the value. Splendid! > It migth make sense to update the last section describing the field > in «doc/README.package-tests.rst», now that this is handled by > dpkg-source >= 1.17.11. Indeed, done in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=859cf134 I also updated https://people.debian.org/~mpitt/autopkgtest/ Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded: > On Wed, 13 Aug 2014 00:30:05 +0200 > Michael Niedermayer wrote: > > > I never understood why people who once where friends > > became mutually so hostile > > You should know that better than anyone else! > > You still claim to be my friend, yet you said and did things > that i have not seen from my enemies, let alone from my friends. > To this day, after 3 years, i still get accused by random people > of thing i supposedly have done against FFmpeg and the spirit > of open source. After 3 years i still have to defend myself against > these baseless attacks! > > If you trully want to mend ways, then you and your fellow FFmpeg > developers should stop this constant spreading of lies, this > defamation campaing against libav and its developers that has > been going on for the last 3 and a half years and show at least > the minimum respect you would show to a stranger you meet on the > street. Until you do this, i see very little chance for a healthy > cooperation. Please refrain from claiming other people are spreading lies, especially with no specific references (and this is not the place where to discuss such things). As for me, I don't consider Libav developers neither friends nor enemies. We reached a point when we got two different projects with different policies, culture, and guidelines. Then you should be aware that the way the Libav fork was created was hostile towards FFmpeg, so you shouldn't be surprised that there was (and still there is) a perceived hostility between the two projects. If you or other Libav or FFmpeg developers want the two projects to collaborate more, this can be discussed, possibly with *specific* proposals, but again, debian-devel is not the right place where to discuss such things. -- FFmpeg = Faithful & Foolish Multipurpose Peaceless Extensive God -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814115807.GG11331@barisone
Re: Uploading python-xstatic-* packages in Debian
Brian May dixit: >In what way will python-xstatic-jquery be better than libjs-jquery? No. What I meant is: | Package: python-xstatic-jquery | Provides: libjs-jquery is better than | Package: python-xstatic-jquery | Depends: libjs-jquery | | Package: libjs-jquery because it’s less packages. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1408141218310.11...@herc.mirbsd.org
Bug#758124: Documenting the Testsuite field in the Policy.
Package: debian-policy Version: 3.9.5 Severity: wishlist Hi Guillem and everybody, thanks for adding direct support for the Testsuite field in Dpkg. Here is a patch to update the Policy accordingly. Do you have comments ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan >From b2679f5e6e871c3316625d231ef88e5858d1b57c Mon Sep 17 00:00:00 2001 From: Charles Plessy Date: Thu, 14 Aug 2014 21:30:47 +0900 Subject: [PATCH] Document the Testsuite field. --- policy.sgml | 20 1 file changed, 20 insertions(+) diff --git a/policy.sgml b/policy.sgml index 6eac491..a8b27e2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2666,6 +2666,7 @@ Package: libc6 Standards-Version (recommended) Homepage Vcs-Browser, Vcs-Git, et al. + Testsuite @@ -2761,6 +2762,7 @@ Package: libc6 Uploaders Homepage Vcs-Browser, Vcs-Git, et al. + Testsuite Dgit Standards-Version (recommended) Build-Depends et al @@ -3863,6 +3865,24 @@ Checksums-Sha256: further details. + + + Testsuite + + + Simple field containing a comma-separated list of values allowing + test execution environments to discover packages which provide + tests. Currently, the only defined value is autopkgtest. + + + + This field is automatically added to Debian source control files by + dpkgfrom version 1.17.11. when + a debian/tests/control file is present in the source + package. This field may also be used in source package control + files if needed in other situations. + + -- 2.0.1
Packaging postinstall handles
Hi, I've created a debian installer for an application with some configuration files. One of those is a udev rule, installed in /lib/udev/rules.d/xx-rule.rules. Others are desktop icons and stuff that go into /usr/share/application. There are two binaries installed, a background process and a main process that should be launched when the background process notices the correct device is plugged in. The background process is placed under /etc/xdg/autostart/ so it launcher at user login. Currently, the installer itself works fine, but there are some elements that I cannot seem to accomplish: 1) automatically reload udev rules after installation. 2) kickstart the background process after installation. I cannot seem to find any examples that would help me resolve this, so any help would be greatly appreciated! Kr, Mathieu
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
2014-08-14 13:58 GMT+02:00 Stefano Sabatini : > On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded: >> On Wed, 13 Aug 2014 00:30:05 +0200 >> Michael Niedermayer wrote: >> >> > I never understood why people who once where friends >> > became mutually so hostile >> >> You should know that better than anyone else! >> >> You still claim to be my friend, yet you said and did things >> that i have not seen from my enemies, let alone from my friends. >> To this day, after 3 years, i still get accused by random people >> of thing i supposedly have done against FFmpeg and the spirit >> of open source. After 3 years i still have to defend myself against >> these baseless attacks! >> >> If you trully want to mend ways, then you and your fellow FFmpeg >> developers should stop this constant spreading of lies, this >> defamation campaing against libav and its developers that has >> been going on for the last 3 and a half years and show at least >> the minimum respect you would show to a stranger you meet on the >> street. Until you do this, i see very little chance for a healthy >> cooperation. > > Please refrain from claiming other people are spreading lies, > especially with no specific references (and this is not the place > where to discuss such things). > > As for me, I don't consider Libav developers neither friends nor > enemies. We reached a point when we got two different projects with > different policies, culture, and guidelines. Then you should be aware > that the way the Libav fork was created was hostile towards FFmpeg, so > you shouldn't be surprised that there was (and still there is) a > perceived hostility between the two projects. If you or other Libav or > FFmpeg developers want the two projects to collaborate more, this can > be discussed, possibly with *specific* proposals, but again, > debian-devel is not the right place where to discuss such things. I have no problem with FFmpeg and Libav developers discussing collaboration on debian-devel especially if they finally sit together and find a way in which they could join efforts after years of working in separation. This would be Legen... ...dary. :-) Cheers, Balint -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak0odpwp7rzzwmpkpwc9txtb2na3zp7bb8t2mdgktiztxfd...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
Why not MATE for all and put a11y into it? Makes more sense for e.g. small computers like those in 3rd World talked before. Enviado de Samsung Mobile Mensaje original De: Josselin Mouette Fecha:14/08/2014 10:48 (GMT+00:00) Para: debian-devel@lists.debian.org Asunto: Re: Reverting to GNOME for jessie's default desktop Le jeudi 14 août 2014 à 08:53 +0200, Christian PERRIER a écrit : > > → Will you configure different defaults for different architectures? > > Given the current architecture of tasksel, I think it requires > important changes to the code and nearly nobody contributes to the > code: tasksel is in maintenance only mode with easy to fix bugs being > fixed as well as bugs or fixes required to cope with changes in > installed packages. Since a11y looks like a compelling argument to go back to GNOME by default, I think we must address that point one way or another if we want it to happen. I think there are several ways to do that: * tweak the debian-cd scripts to build GNOME images for Linux architectures and Xfce or MATE images for !linux (I can’t tell how hard it is) * make stripped-down gnome-core/gnome metapackages for !linux, relying on lightdm and gnome-flashback (that I can do) * hackishly make gnome-core/gnome metapackages depend directly on Xfce or MATE for !linux instead of GNOME (same) Overall, a gnome-flashback solution would probably be more featureful, but it is clearly less maintained than e.g. Xfce. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408009711.20025.6.camel@dsp0698014
Re: Packaging postinstall handles
Le jeudi 14 août 2014 à 15:12 +0200, Mathieu Slabbinck a écrit : > The background process is placed under /etc/xdg/autostart/ so it > launcher at user login. > 1) automatically reload udev rules after installation. This is automatic. You don’t have anything to do. > 2) kickstart the background process after installation. A package should never do anything directly to a running session. As for any rule, there are exceptions such as mechanisms to signal a reload, but even those are workarounds. You should never launch anything in the user session. Once your launcher is installed in /etc/xdg/autostart, the job is done. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408026561.20025.27.camel@dsp0698014
Bug#758135: ITP: python-pymemcache -- comprehensive, fast, pure Python memcached client
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-pymemcache Version : 1.2.4 Upstream Author : Charles Gordon * URL : https://github.com/pinterest/pymemcache * License : Apache-2.0 Programming Lang: Python Description : comprehensive, fast, pure Python memcached client Pymemcache is a comprehensive, fast, pure-Python memcached client. It supports the following features: * Complete implementation of the memcached text protocol. * Configurable timeouts for socket connect and send/recv calls. * Access to the "noreply" flag, which can significantly increase the speed * of writes. * Flexible, simple approach to serialization and deserialization. * The (optional) ability to treat network and memcached errors as cache misses. This is a dependency of python-tooz, which itself is now one of the Python dependencies for OpenStack. Note that, to the contrary of python-memcache, this package works with Python 3. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814145751.8876.48288.report...@buzig.gplhost.com
Re: Uploading python-xstatic-* packages in Debian
On 08/14/2014 03:43 PM, Thorsten Glaser wrote:
> Idea here: can’t python-xstatic-jquery just take over libjs-jquery
> via Provides, so we have one binary package less after this? (Of
> course, if the Debian JS maintainers agree, and probably will want
> to (co-)maintain python-xstatic-jquery after this.) Similar for the
> other ones. That would mean we’d have almost zero cost for the addi‐
> tion of python-xstatic-* because they’d just take over the non-xstatic
> ones and provide the same functionality plus more.
Well, the xstatic packages don't contain the full upstream source, they
mostly contain the javascript file (eg: jquery.js in this case), and
that's it. Upstream for jquery has lots of other stuff included.
What would probably work better would be to add the python library
inside upstream code. But then we have another issue: the Python module
is supposed to be packaged as python-, and the JS libs are
supposed to be packaged as libjs-. So we'd have to break one
or the other convention. I don't think that's desirable to do. We don't
want to break automatic dependency calculation by dh_python{2,3} either.
On 08/14/2014 07:02 PM, Brian May wrote:>
>>> It is also worth noting that the Debian package version for XStatic
>>> modules is following the static file package version. For example,
>>> even though upstream released XStatic-JQuery 1.10.2.1, the Debian
>>> package version is 1.7.2.0, to match the version number of
>>> libjs-jquery.
>
> Finding it hard to understand the reasoning here.
The important bit is that upstream requires version X of
python-xstatic-jquery because it needs version X of jquery. When we have
jquery 1.7.2, then we just add a leading version number for the
python-xstatic-jquery package, and it becomes 1.7.2.0. The XStatic
package itself doesn't contain much but the Python wrapper, so it's not
a big deal (it's very simplistic Python code).
On 08/14/2014 07:02 PM, Brian May wrote:
> In what way will python-xstatic-jquery be better than libjs-jquery?
It's not in any way better, it just adds the Python wrapper layer, so
upstream code can easily find out that jquery is located in
/usr/share/javascript/jquery. As for upstream, they mostly use
virtualenv stuff, downloading from PyPi to run the unit tests, and in
that case, the XStatic package will contain the jquery.js /
jquery.min.js file. So it's transparent for upstream, and provides us
(eg: distribution package maintainers) a way to stop having embedded
static files libraries. In fact, XStatic has been created upstream with
distributions in mind, and I find it very nice of them. It's indeed
solving the problem, even if that's some non-negligible work at first to
do the python-xstatic-* packaging.
For reference, have a look at this, it may be better than all of my
explanations:
https://github.com/stackforge/xstatic-angular/blob/master/xstatic/pkg/angular/__init__.py
In Debian, I just patch VERSION =, and BASE_DIR=. That's in fact what
upstream for XStatic expects me to do! Then on the resulting package, I
just delete the xstatic/pkg/angular/data folder and its content which
contains the embedded Angular javascript files, since I want to use
/usr/share/javascript/angular.js instead.
I hope that's better explanations. If not, ping me again...
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53eccb61.7000...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > Whatever, people can work on their own code happily but the rest of > the world (cf this thread) has to deal with this annoying FFmpeg/libav > madness. Right! Not only a core of a few upstream authors are affected, but also downstream distributions (where we have to deal with numerous build issues), and final users (who may loose the possibility to use some nice software...). If you guys could find a solution to try to work together again, and merge back both projects, that'd be best for everyone. On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > Also ive offered my resignation in the past. > I do still offer to resign from the FFmpeg leader position, if it > resolves this split between FFmpeg and Libav and make everyone work > together again. Why not just take the offer, and move on? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecd562.1070...@debian.org
Re: Uploading python-xstatic-* packages in Debian
On 14/08/14 15:44, Thomas Goirand wrote: > On 08/14/2014 07:02 PM, Brian May wrote: >> In what way will python-xstatic-jquery be better than libjs-jquery? > > It's not in any way better, it just adds the Python wrapper layer, so > upstream code can easily find out that jquery is located in > /usr/share/javascript/jquery. As for upstream, they mostly use > virtualenv stuff, downloading from PyPi to run the unit tests, and in > that case, the XStatic package will contain the jquery.js / > jquery.min.js file. So it's transparent for upstream, and provides us > (eg: distribution package maintainers) a way to stop having embedded > static files libraries. In fact, XStatic has been created upstream with > distributions in mind, and I find it very nice of them. It's indeed > solving the problem, even if that's some non-negligible work at first to > do the python-xstatic-* packaging. I can't help thinking that this is a lot like pkg-config, but runtime instead of compile-time, and specific to Python instead of biased towards C/C++. If the XStatic files are pure metadata (albeit in Python syntax and installed to the PYTHONPATH, because when all you have in some of your target OSs/environments is a Python hammer, everything looks like a nail), wouldn't it make more sense to ask the various Javascript projects' upstreams to ship them? After all, when libwhatever doesn't ship whatever.pc, we don't upload pkg-config-whatever.deb, we file a wishlist bug against libwhatever "please include a .pc file". S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecd812.4070...@debian.org
Bug#758138: ITP: python-tooz -- coordination library for distributed systems
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-tooz Version : 0.3 Upstream Author : Julien Danjou * URL : https://github.com/stackforge/tooz * License : Apache-2.0 Programming Lang: Python Description : coordination library for distributed systems The Tooz project centralizes the most common distributed primitives like group membership protocol, lock service and leader election by providing a coordination API helping developers to build distributed applications. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814155256.10429.26471.report...@buzig.gplhost.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/14/2014 11:27 AM, Thomas Goirand wrote: > On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > >> Also ive offered my resignation in the past. I do still offer to >> resign from the FFmpeg leader position, if it resolves this split >> between FFmpeg and Libav and make everyone work together again. > > Why not just take the offer, and move on? Probably because of the condition he attached to it, which also dates back to the arguments preceding the original split: >> The part i insist on though is that everyone must be able to work >> on their code without people uninvolved in that specific parts >> maintaince or authorship being able to block their work. In other words, as I think I understand it from the discussion back then: people not involved with a particular area of the code can't NACK the work of someone who is working on it, and someone who works on a particular area of the code doesn't have to wait on review of people who aren't involved with that area of the code. Since one of the motivations of the people behind the libav side of the split seems, IIRC, to have been "no code gets in without having been reviewed by someone other than the author", this was apparently deemed an unacceptable condition. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT7Nz0AAoJEASpNY00KDJrGzwP/Rn3aW9i+b8YfDhrkKrP1QfW HhfxOnIzEiGTJZnMWSCyJ/3K2zAmwvqCwTgGi2E04ud92AZdAjdMLzKUyvnblhmV iN56iahO5dfX8J42jXh9C3d+kbKOHYhc1I2DgzNyeNTfOdfc5kQkPEdTwR1Mfbl/ NXyICwnURhvaZaRrwNQQfN7DSRwdB++hi0OExVzyrX4xI5OvWV5TcwKheXykYgGe RrHtdkobACM1p9z5x/fGl5RC5KTQ9/qfP+IrOqfrZ0f8Sp3LvWyOjjliHWuQ0fwh tx9oX6BfgwFqqEZ/FSO0hfdRz1ec37yo/ZpapgMNkRUaXP4jhHRlOmljpE6JiuoH sJne9r1OAXQV5md4bZYjHfXkk9Rw6BXNLVfaHpmdlXZAUqEd6/GTYRLlUNmjvsM1 pySPCT+z+BN2U6RkVeBGDIkW2E2Q/Wwa50MQTcvrJ4Tixa3vC3x84HuNj3ykWuof UnwQD2ktBfQlwEBjC+qVLt5+mSKfAqtJUqm+lULISx9OFdX/f8/7Z+k60cJ+U3Qx q1MsqcAot7oUcibj3a/m9I+wW7LvpzP4Xt/DEwgUx9TDUHTYMv/EDWq1uxl1S25v 1hvawkiabpgYeNw4pXo9Kt/YqpNB9mlq6V1lDi6XqecxcXyy4RCRhpUAtHRxVKAN 6mXiIK5hvhv0R4nedkC1 =Fo9z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecdcf4.1020...@fastmail.fm
Re: Reverting to GNOME for jessie's default desktop
Hi Josselin, here's my take as d-i release guy. That's basically in line with Christian's except for the last answer. I'm also putting -boot@ in Cc so that other d-i members can voice their opinions. Full mail can be found at: https://lists.debian.org/debian-devel/2014/08/msg00432.html Josselin Mouette (2014-08-14): > → Is the installation CD size still relevant? If everything doesn't fit on CD#1 alone, too bad. Definitely not a blocker. See, we released wheezy while CD#1 on i386 (without a net mirror) isn't sufficient to install a whole desktop. We "just" need to stop pretending it does (I stumbled upon at least such a page on www.debian.org lately). For those questioning the usefulness of those images: as a (maybe not so) random debian-cd witness, keeping on building CDs is just a matter of I/O on pettersson.debian.org, so I don't see why we should stop building CD images if some users still find them useful. > → What is the target audience of Debian-installer for the default > image? [ Replying with s/image/desktop/ in mind. ] What Christian says. It seems to me it's quite fair to imagine that so called “power users” are very much able not to pick the default desktop and install their beloved desktop environement or custom window manager instead. > → What is the required level of accessibility? Very high. At the very least we must not regress from a release to another. Xfce is currently a pretty big regression in that area (which explains the wording I used in my Beta 1 announce, pointing to Gnome images instead). > → Will you configure different defaults for different architectures? If we're going to be back for Gnome as a default, we will likely need to handle per-architecture defaults, since Gnome on non-Linux isn't going to be supported (by either Gnome upstream, by Gnome Debian maintainers, or by GNU/kFreeBSD porters, as far as I understand it). If we're ending up implementing what I alluded to in my first reply to this thread (in a nutshell: look at installable task-*-desktop packages, propose a list, defaulting to whatever we prefer), that's likely doable. Mraw, KiBi. signature.asc Description: Digital signature
Re: Uploading python-xstatic-* packages in Debian
Quoting Thomas Goirand (2014-08-14 09:26:05) > Note that the XStatic python modules aren't just meta packages, they > also offer a mechanism for a Python script to discover where to find a > given static file in the system (which really, isn't obvious, as the > Debian archive is a bit messy in this regard, especially when dealing > with static files that aren't javascript like .css or .less files). You are quite welcome to propose tp relevant teams streamlining which could ease your packaging. A cleanup might take time to coordinate, and agreeing on tidying the structure may take time too, but that shouldn't discourage you from initiating that process :-) I recommend to discuss that in those smaller teams rather than here. > For some XStatic packages, the embedded static files are not present > in Debian. That is the case for example with python-xstatic-hogan, > python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the > above 3 packages, the upstream source code is part of a much larger > project. Please don't embed reusable non-Python code into Python-specific packages - then you end up with same problem as you ran into yourself with ruby-bootstrap-sass (see right below). Instead, package (or request others like the Javascript ot Sass team) to package those which you need. > See for example bootstrap-scss, which comes with a huge Ruby > framework. I have no intention to package all of that... I guess you mean ruby-bootstrap-sass - please see bug#739783. > As I know very little about packaging of some upstream code (for > example, I have never maintained ruby or nodejs packages), and that I > don't need them anyway (I only need a few javascript files from them, > I will have no use of Ruby or nodejs code), then I decided to *not* > package the full upstream package, and leave the embedded copy inside > the python-xstatic-* packages. This is until someone needs the full > upstream package, at which point I will remove the embedded copy, and > point to the relevant files inside the recently uploaded package. Please don't postpone proper packaging until others eventually steps up. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Uploading python-xstatic-* packages in Debian
On 08/14/2014 11:38 PM, Simon McVittie wrote: > If the XStatic files are pure metadata (albeit in Python syntax and > installed to the PYTHONPATH, because when all you have in some of your > target OSs/environments is a Python hammer, everything looks like a > nail), wouldn't it make more sense to ask the various Javascript > projects' upstreams to ship them? It will still produce another binary package, so it doesn't solve the problem of avoiding that. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ece5bc.4090...@debian.org
suspension bug
Greetings, I have found a bug and don't know which package to report it on. The bug is that my computer immediately awakes from suspension if certain USB devices are connected. Can anyone point me at the right package? Regards Sven signature.asc Description: PGP signature
Re: suspension bug
On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > Greetings, > > I have found a bug and don't know which package to report it on. > The bug is that my computer immediately awakes from suspension if > certain USB devices are connected. > Can anyone point me at the right package? IIRC there was an option on some BIOS to do exactly that. Check yours in case you didn't already, and good luck :) -- 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.
Re: suspension bug
On 14/08/14 19:23, Sven Bartscher wrote: > I have found a bug and don't know which package to report it on. > The bug is that my computer immediately awakes from suspension if > certain USB devices are connected. > Can anyone point me at the right package? Hey, 1. You wrote about 'devices' so I assume that it happens only with a few specific ones (but more than one) and not with others? 2. Does it happen every time or just form time to time? 3. Did you check your dmesg for any warning or error messages after such a wakeup? Regards, T. signature.asc Description: OpenPGP digital signature
Re: suspension bug
On Thu, 14 Aug 2014 20:13:04 +0200 Tomasz Nitecki wrote: > On 14/08/14 19:23, Sven Bartscher wrote: > > I have found a bug and don't know which package to report it on. > > The bug is that my computer immediately awakes from suspension if > > certain USB devices are connected. > > Can anyone point me at the right package? > > Hey, > > 1. You wrote about 'devices' so I assume that it happens only with a few > specific ones (but more than one) and not with others? Right. The devices are a HBCI card reader and USB receivers for wireless gamepads. But as I noticed just now: They only cause the computer to wake up if they are connected to an additional USB card (which is conect to the mainboard via an internal USB connector). > 2. Does it happen every time or just form time to time? It happens every time these devices are connected to the ports mentioned above. > 3. Did you check your dmesg for any warning or error messages after such > a wakeup? I didn't see anything suspicious. Just the messages about the computer going down, followed by the messages about the computer waking up again. Regards Sven signature.asc Description: PGP signature
Re: suspension bug
On Thu, 14 Aug 2014 14:34:23 -0300 Lisandro Damián Nicanor Pérez Meyer wrote: > On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > > Greetings, > > > > I have found a bug and don't know which package to report it on. > > The bug is that my computer immediately awakes from suspension if > > certain USB devices are connected. > > Can anyone point me at the right package? > > IIRC there was an option on some BIOS to do exactly that. Check yours in case > you didn't already, and good luck :) I checked that. All wake events (that can be configured) are disabled. signature.asc Description: PGP signature
Re: suspension bug
I think it would be good to know if your running stable or testing. and if you are on systemd or not. irc channels on irc.debian.org #debian or #debian-next are very good for 'live support' so that the issue can be dug into. On 14 August 2014 19:45, Sven Bartscher wrote: > On Thu, 14 Aug 2014 14:34:23 -0300 > Lisandro Damián Nicanor Pérez Meyer wrote: > > > On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > > > Greetings, > > > > > > I have found a bug and don't know which package to report it on. > > > The bug is that my computer immediately awakes from suspension if > > > certain USB devices are connected. > > > Can anyone point me at the right package? > > > > IIRC there was an option on some BIOS to do exactly that. Check yours in > case > > you didn't already, and good luck :) > > I checked that. All wake events (that can be configured) are disabled. >
Re: suspension bug
On Thu, 14 Aug 2014 20:00:03 +0100 Anthony F McInerney wrote: > I think it would be good to know if your running stable or testing. and if > you are on systemd or not. > irc channels on irc.debian.org #debian or #debian-next are very good for > 'live support' so that the issue can be dug into. I'm running testing, with systemd. I switched to systemd recently, but the with sysvinit I had the same problem. If you (or anyone else) have further questions, you can find in me in #debian-next (name: Kritzefitz). > On 14 August 2014 19:45, Sven Bartscher > wrote: > > > On Thu, 14 Aug 2014 14:34:23 -0300 > > Lisandro Damián Nicanor Pérez Meyer wrote: > > > > > On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > > > > Greetings, > > > > > > > > I have found a bug and don't know which package to report it on. > > > > The bug is that my computer immediately awakes from suspension if > > > > certain USB devices are connected. > > > > Can anyone point me at the right package? > > > > > > IIRC there was an option on some BIOS to do exactly that. Check yours in > > case > > > you didn't already, and good luck :) > > > > I checked that. All wake events (that can be configured) are disabled. > > signature.asc Description: PGP signature
Re: Reverting to GNOME for jessie's default desktop
Hi, On Thu, 14 Aug 2014, Josselin Mouette wrote: > I think there are several ways to do that: [...] > * make stripped-down gnome-core/gnome metapackages for !linux, > relying on lightdm and gnome-flashback (that I can do) I believe this should be done. It's also in the spirit of providing something useful on those architectures. Having non-installable gnome metapackages is not very friendly to users of those architectures. We could possibly also tweak debian-cd to do something else on non-linux but in general I think it's best if we limit differences across architectures when it can be avoided. Architecture specific documentation may recommend users to use the (non-default) Xfce image if that's the preferred image according to porters. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814161939.gb2...@x230-buxy.home.ouaza.com
Re: suspension bug
On Thu, 14 Aug 2014 19:23:05 +0200 Sven Bartscher wrote: > Greetings, > > I have found a bug and don't know which package to report it on. > The bug is that my computer immediately awakes from suspension if > certain USB devices are connected. > Can anyone point me at the right package? It turned out that my usb-hub had wakeup enabled. Disabling it fixed the problem. Thanks for your time and help. Regards Sven signature.asc Description: PGP signature
Re: Reintroducing FFmpeg to Debian
Stefano Sabatini wrote: > Please refrain from claiming other people are spreading lies, > especially with no specific references (and this is not the place > where to discuss such things). Attila already amended one of the false statement that had been spun around (about the people behind Libav "stealing" infrastructure from whoever), Kieran already amended the claim of avresample being a fork of swresample. The list is quite long and debunking each of the statements could take a lot of time. I'm going to address two historical "misrepresentations": # The change of management Michael Niedermayer managed to get demoted from his leader position by the topmost 18[1] people involved in FFmpeg by the time due his tendency of not following the rules. that after weeks from being voted to stay as leader by 15, 5 explicitly stating their vote was conditioned by his behaviour and 1 definitely against him.[2] His demotion is due to acts in full disregard of the policies in place, even those enforced automatically by the svn hooks. The fact he bullied and belittled volunteers and contributor can be checked by digging the mailing list during the months and the year before the management change and it adds up. # The split The split is mainly due to trademark ownership: He managed to gain back the use of the name from Fabrice Bellard, the trademark owner and the only one controlling the dns, thus the people not agreeing with Michael decided to just use a different name and keep working on the project. The dns started pointing another host, the people owning the previous infrastructure kept owning their boxes as Attila already explained. Now back to the rest of the email and yet another misconception. > As for me, I don't consider Libav developers neither friends nor > enemies. We reached a point when we got two different projects with > different policies, culture, and guidelines. Then you should be aware > that the way the Libav fork was created was hostile towards FFmpeg, so No, Libav as project enforces a set of simple rules and enforces them for everybody, no matter who. The people working on Libav were hostile to Michael Niedermayer attitude to override any rules for himself and use the same rules to hammer whoever confronted him. > you shouldn't be surprised that there was (and still there is) a > perceived hostility between the two projects. If you or other Libav or > FFmpeg developers want the two projects to collaborate more, this can > be discussed, possibly with *specific* proposals, but again, > debian-devel is not the right place where to discuss such things. Personally I have no problems in collaborating with anybody. Although it could be a little difficult collaborating with the person that suggested to fund our burial [3] and I'm quite sure the other one that called us swine back in the time and refused to even say hi to me in person this year when we were at the same booth at LinuxTag. lu [1] http://lwn.net/Articles/423703/ [2] http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/118594 [3] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2011-January/107416.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ed440a.3020...@gentoo.org
Your Payment Code:ST/DPI/829
Official Compensation Letter.rtf Description: Binary data
Processed: unble to re-enable wifi/bt after hardware or software disable
Processing commands for cont...@bugs.debian.org: > tags 756947 - moreinfo Bug #756947 [general] general: unble to re-enable wifi/bt after hardware or software disable Removed tag(s) moreinfo. > reassign 756947 firmware-ipw2x00 Bug #756947 [general] general: unble to re-enable wifi/bt after hardware or software disable Bug reassigned from package 'general' to 'firmware-ipw2x00'. Ignoring request to alter found versions of bug #756947 to the same values previously set Ignoring request to alter fixed versions of bug #756947 to the same values previously set > found 756947 0.36+wheezy.1 Bug #756947 [firmware-ipw2x00] general: unble to re-enable wifi/bt after hardware or software disable Marked as found in versions firmware-nonfree/0.36+wheezy.1. > thanks Stopping processing here. Please contact me if you need assistance. -- 756947: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756947 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.140805934424467.transcr...@bugs.debian.org
Bug#756947: unble to re-enable wifi/bt after hardware or software disable
tags 756947 - moreinfo reassign 756947 firmware-ipw2x00 found 756947 0.36+wheezy.1 thanks Hey, A quick summary of the problem: Alan is using '02:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)' with ipw2200 driver and correctly loaded non-free firmware blob 'ipw2200-bss.fw'. After he disables the wifi radio via hardware button or via network manager he is unable to re-enable it. The only way to fix it is to reset BIOS settings to default configuration (after such a reset wifi is automatically back on). Rfkill is also unable to re-enable wifi but after using 'unblock' option and resetting BIOS the wifi is still disabled (but can be re-enabled by normal means - once). The only suspicious dmesg message is 'ipw2200: Failed to send CARD_DISABLE: Command timed out.' All logs are available in older messages attached to #756947. Regards and thanks, T. signature.asc Description: OpenPGP digital signature
Work-needing packages report for Aug 15, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 587 (new: 1) Total number of packages offered up for adoption: 139 (new: 1) Total number of packages requested help for: 60 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: xbuffy (#757599), orphaned 5 days ago Description: monitor mailboxes and/or newsgroups Installations reported by Popcon: 702 586 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: hg-fast-export (#758114), offered today Installations reported by Popcon: 182 138 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] pgadmin3 (#757770), requested 3 days ago Description: graphical administration tool for PostgreSQL Reverse Depends: pgadmin3 pgadmin3-dbg Installations reported by Popcon: 3878 apt-xapian-index (#567955), requested 1655 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 73634 athcool (#278442), requested 3579 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 46 awstats (#755797), requested 22 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4079 balsa (#642906), requested 1054 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 771 cardstories (#624100), requested 1207 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 8 chromium-browser (#583826), requested 1537 days ago Description: Chromium browser Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 24399 code-saturne (#754477), requested 34 days ago Description: General purpose Computational Fluid Dynamics (CFD) software Reverse Depends: code-saturne Installations reported by Popcon: 168 csv2latex (#746158), requested 109 days ago Description: a CSV to LaTeX file converter Installations reported by Popcon: 150 cups (#532097), requested 1895 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (63 more omitted) Installations reported by Popcon: 134574 debtags (#567954), requested 1655 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2285 fbcat (#565156), requested 1674 days ago Description: framebuffer grabber Installations reported by Popcon: 148 freeipmi (#628062), requested 1176 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted) Installations reported by Popcon: 5336 gnat-gps (#496905), requested 2177 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 515 gnokii (#677750), requested 789 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1586 gnupg (#660685), requested 906 days ago Description: GNU privacy guard - a free PGP replacement Reverse Depends: 0install-core apt arriero bootstrap-base cdebootstrap cdebootstrap-static clamav-unofficial-sigs cloud-utils debian-archive-keyring debian-edu-archive-keyring (54 more omitted) Installations reported by Popcon: 164605 gpa (#663405), requested 887 days ago Description: GNU Privacy Assistant (GPA) Installations reported by Popcon: 573 gradle (#683666), requested 742 days ago Description: Groovy based build system Reverse Depends: gradle libgradl
Bug#758178: general: screen resolution reverts to minimum when not selected by KVM
Package: general Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? I have 3 or 4 debian machines attached to a Zonet KVM3304 4 port KVM switch. I usually keep at least 2 of them on most of the time. Thus only one is selected at any one time. I try to keep separate projects for clients on separate machines. When I select a machine that has not been selected for a while, say 2 hours or longer, the screen resolution has been set to the minimum. It is almost like some process goes out and queries about the display resolution and when the machine is not selected it either does not get an answer or the answer it gets is 600x480. * What exactly did you do (or not do) that was effective (or ineffective)? I went to the System Settings -> Displays to try to reset the resolution. I have done this both with Gnome Classic and the new Gnome. I am rather sure that the problem is somewhere in Gnome, but I have no idea which subsystem. * What was the outcome of this action? In every case, the display goes black and the computer becomes unresponsive. I have to reboot. I have tried this with fresh installs of debian 7.1, 7.2, 7.3, and now 7.6. This makes debian 7 unusable because when I am working on a project, I usually leave multiple GVIM editor sessions open (sometimes a dozen or more sessions) and sometimes for days at a time. * What outcome did you expect instead? This never happened under debian 6 or debian 5 or debian 4. The resolution stays the same no matter how long the machine has been unselected by the KVM. I have had to revert to debian 6 in order to get any work done on any machine that I need to leave on for more than a few hours. Last week I installed openSUSE just to see what it did. I left its machine unselected overnight and when I reselected it, it came back with the screen resolution unchanged. So openSUSE seems to have fixed this bug. *** End of the template - remove these lines *** -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815061315.3847.42292.reportbug@debian7.6
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/14/2014 11:59 PM, The Wanderer wrote: > On 08/14/2014 11:27 AM, Thomas Goirand wrote: > >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > >>> Also ive offered my resignation in the past. I do still offer to >>> resign from the FFmpeg leader position, if it resolves this split >>> between FFmpeg and Libav and make everyone work together again. > >> Why not just take the offer, and move on? > > Probably because of the condition he attached to it, which also dates > back to the arguments preceding the original split: > >>> The part i insist on though is that everyone must be able to work >>> on their code without people uninvolved in that specific parts >>> maintaince or authorship being able to block their work. > > In other words, as I think I understand it from the discussion back > then: people not involved with a particular area of the code can't NACK > the work of someone who is working on it, and someone who works on a > particular area of the code doesn't have to wait on review of people who > aren't involved with that area of the code. > > Since one of the motivations of the people behind the libav side of the > split seems, IIRC, to have been "no code gets in without having been > reviewed by someone other than the author", this was apparently deemed > an unacceptable condition. Hum... Well, to me, what's important is that the code gets peer-reviewed. Setting-up something like gerrit may help, as it can be setup in a way that review becomes mandatory. Then discussing who's core-reviewer and can approve this or that part of the code can be setup within gerrit. This should be discussed, and setup based on technical merit. Having a NACK review is often disappointing. It goes the wrong way if there's only a NACK with no comments on how to improve things, so that the code becomes acceptable. Absolutely everyone should *always* be able to leave comments, be it positive or negative. With Gerrit, it's possible to comment directly in the patch, which helps going in the right direction. Of course, a technical solution will not solve all social issues, but it may improve the workflow and process, and avoid frictions. I hope this helps, Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53edae55.4090...@debian.org
