Re: How shall I report a bug in the .deb packaging itself?
Le mardi 22 décembre 2015, 00:35:25 Robie Basak a écrit : > I had always assumed that this is the risk you take by using autoremove > and thus you need to pay attention to what you autoremove, which is for > example why unattended-upgrades is sensible by not doing it by default. Excepted that unattended-upgrades is changeing this behaviour right now because some users got their /boot filled with many differents kernel images over the time. https://github.com/mvo5/unattended-upgrades/commit/25ff94915a9fc99058839d16761cf029896cbe05 https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093 *) "apt-get autoremove" should always be safe; one can use apt-mark manual to pin pakcages *) "apt-get remove $(deborphan)" is more dangerous; and should be done manually; and then one can also build fake empty packages with equivs to register some -libs or -devel packages as needed by a local application. Greets, Alexandre signature.asc Description: This is a digitally signed message part.
Re: How shall I report a bug in the .deb packaging itself?
On Tue, Dec 22, 2015, at 09:37, Alexandre Detiste wrote: > *) "apt-get remove $(deborphan)" is more dangerous; and should be done > manually; > and then one can also build fake empty packages with equivs to register > some > -libs or -devel packages as needed by a local application. Errr, why? Just use deborphan keep file: --add-keep, -A PKGS.. Never report PKGS. --keep-file, -k FILE Use FILE to get/store info about kept packages. --list-keep, -LList the packages that are never reported. --del-keep, -R PKGS.. Remove PKGS from the "keep" file. --zero-keep, -ZRemove all packages from the "keep" file. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Bug#808727: ITP: python-django-overextends -- reusable app providing circular template inheritance
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-django-overextends Version : 0.4.0 Upstream Author : Stephen McDonald * URL : https://github.com/stephenmcd/django-overextends * License : BSD-2-clause Programming Lang: Python Description : reusable app providing circular template inheritance A Django reusable app providing the overextends template tag, a drop-in replacement for Django's extends tag, which allows you to use circular template inheritance. . The primary use-case for overextends is to simultaneously override and extend templates from other reusable apps, in your own Django project. This is a new dependency for python-django-compressor, needed by Horizon, the OpenStack dashboard.
Re: How shall I report a bug in the .deb packaging itself?
Le mardi 22 décembre 2015, 10:03:15 Ondřej Surý a écrit : > On Tue, Dec 22, 2015, at 09:37, Alexandre Detiste wrote: > > *) "apt-get remove $(deborphan)" is more dangerous; and should be done > > manually; > > and then one can also build fake empty packages with equivs to register > > some > > -libs or -devel packages as needed by a local application. > > Errr, why? Just use deborphan keep file: > > --add-keep, -A PKGS.. Never report PKGS. > --keep-file, -k FILE Use FILE to get/store info about kept > packages. > --list-keep, -LList the packages that are never reported. > --del-keep, -R PKGS.. Remove PKGS from the "keep" file. > --zero-keep, -ZRemove all packages from the "keep" file. I said "can", not "must". There's more than one way to do it (tm). The dummy package has some advantages: - "aptitude why" will give the correct answer, browsing aptitude TUI also - it can be stuffed in a local repository - that fasten duplicating one's setup on an other computer - it's much easier for this dummy package to Depends: on some -libs & -dev than to include a postinst script that modifies /var/lib/deborphan/keep the dummy package can then be expanded and provides some files in /etc/*.d/ PS: deborphan doesn't know about "Enhances:" :-( https://sources.debian.net/src/deborphan/1.7.28.8-0.2/src/pkginfo.c/ Cheers signature.asc Description: This is a digitally signed message part.
Re: AppStream / DEP-11 support now available in the Debian archive
Hi, On Thu, Dec 17, 2015 at 02:24:38AM +0100, Matthias Klumpp wrote: > > Coming from a science background myself, I like this idea very much! :-) > However, we shouldn't add each and every metadata to the AppStream > document, so we would need to go through what the UpstreamMetadata > project offers and see if we can integrate it with AppStream. > The main purpose of AppStream is to provide data to have people decide > if they want to install the software, its secondary purpose is to > contain data which the users might find useful to know when browsing > applications. :-) > I think having a tag or something similar would be > pretty cool - searching in the AppStream data pool for applications > associated with a publication, or just have the publications at hand > when looking atthe application would be awesome! > > Even if there is useful data which we don't include in the AppStream > data, we can probably link it and load it on-demand. I have some ideas > for this for parts of AppStream (like the tag) already, but > haven't worked out the details - so far, this is just early > experimentation to see whether something like that makes sense. > > So, in summary: I'll look at the wiki page to familiarize a bit with > your upstream-metadata project, so I can say something more > meaningful. But I think adding most of the data to the AS metadata > would be a good and viable idea :-) Just to give some additional technical background: The bibliographic data are gathered in UDD in the table bibref. I just noticed that there is some problem with the umegaya importer[1] but I plan to tackle this soon. Once this is done the bibref example which can be seen here: http://blends.debian.net/packages-metadata/ will be updated again. This is actually my test case for the importer success (which has some flaws as discussed in [1]) and just an example what can be currently done with the available data. I guess there is way more possible usage like a debhelper script doing some sensible things with the bibliographic data (but so far not even a definition what would be sensible). Thanks for the AppStream initiative in general which has a big potential also for Blends Andreas. [1] https://lists.debian.org/debian-qa/2015/12/msg00105.html -- http://fam-tille.de
Re: lists.debian.org: New list: debian-metad...@lists.debian.org
On Fri, Dec 18, 2015 at 12:27:24PM +0545, Jonas Smedegaard wrote: > Quoting Iain R. Learmonth (2015-12-18 01:51:31) > > Having a mailing list would greatly help with co-ordination, so please > > hit up the bug with a +1 if this is something you'd like to be > > involved in. > > I wanna be involved, and support creation of list for our work. +1 Andreas. -- http://fam-tille.de
Re: Can I suppress automatic creation of -dbgsym packages?
On Sun, Dec 20, 2015 at 09:11:03PM +, Niels Thykier wrote: > Please have a look at [1]. Though if your reason for disabling them are: > > * Upload speed / personal bandwidth costs. >- Then please consider using "source-only" (or arch:all+source) > uploads, which is unaffected and keeps the dbgsym. I admit I would really like to safe bandwidth - I seem to have missed the source-only upload option. Could you provide a pointer. This would be even cooler than the dbgsym feature. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Can I suppress automatic creation of -dbgsym packages?
On Tue, Dec 22, 2015 at 6:13 PM, Andreas Tille wrote: > I admit I would really like to safe bandwidth - I seem to have missed > the source-only upload option. Could you provide a pointer. This would > be even cooler than the dbgsym feature. ;-) They were on d-d-a last year (arch any) and this year (arch all): https://lists.debian.org/debian-devel-announce/2014/08/msg2.html https://lists.debian.org/debian-devel-announce/2015/08/msg7.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Can I suppress automatic creation of -dbgsym packages?
* Paul Wise , 2015-12-22, 18:19: On Tue, Dec 22, 2015 at 6:13 PM, Andreas Tille wrote: I admit I would really like to safe bandwidth - I seem to have missed the source-only upload option. Could you provide a pointer. This would be even cooler than the dbgsym feature. ;-) They were on d-d-a last year (arch any) and this year (arch all): https://lists.debian.org/debian-devel-announce/2014/08/msg2.html https://lists.debian.org/debian-devel-announce/2015/08/msg7.html Reminder: Every person who was caught not reading d-d-a carefully is obliged to fix 42 RC bugs. -- Jakub Wilk
Re: Can I suppress automatic creation of -dbgsym packages?
Hi Jakub, On Tue, Dec 22, 2015 at 11:25:28AM +0100, Jakub Wilk wrote: > > > >https://lists.debian.org/debian-devel-announce/2014/08/msg2.html > >https://lists.debian.org/debian-devel-announce/2015/08/msg7.html > > Reminder: Every person who was caught not reading d-d-a carefully is obliged > to fix 42 RC bugs. Good idea. Please checkout how many bugs of http://debian-med.alteholz.de/advent/ were recently fixed by me (well it did not become obvious who exatly fixed the bug but I did more than 42 in the last 3 weeks - admittedly not all RC. ;-) Unfortunately we have no power to push this "fix 42 RC bugs" rule - otherwise the RC bug count would probably decrease a lot. Kind regards Andreas. -- http://fam-tille.de
Re: How shall I report a bug in the .deb packaging itself?
On Tue, Dec 22, 2015 at 12:35:25AM +, Robie Basak wrote: > On Mon, Dec 21, 2015 at 03:08:51PM +0100, Julian Andres Klode wrote: > > I'll repeat this one last time for you: If A suggests B, and you > > install B in some way, you may have come to rely on the fact that A is > > extended by B on your system. Automatically removing B could thus > > cause an unexpected loss of functionality. > > I understand your logic here. But doesn't the same logic apply to > Depends? If B depends on A and you install B in some way, then you may > have come to reply on the fact that A is extended by B on your system, > etc. What? A isn't extending B – B needs A to function, that is all. [What you describe is maybe "Enhances", which is a sort-of reverse Suggests (expect that there is no option to install them all by default… I wonder what the point would be to install all iceweasel extensions)]. If you installed B either A was already installed or A was installed by your request for B. Either way A will not be autoremoved (even if it was at some point automatically installed to satisfy a dependency-relation of C on A) as long as B is there (and/or C). A package can only be autoremoved if it is auto-installed and isn't a possible satisfier for a (Pre-)Depends/Recommends/Suggests relation (or-group) of another package which isn't autoremovable. > I had always assumed that this is the risk you take by using autoremove > and thus you need to pay attention to what you autoremove, which is for > example why unattended-upgrades is sensible by not doing it by default. It is not a good idea to perform autoremoves unattended for situations in which you have installed A (gui) depends B (console) depends C (data), but later decide that you don't like A (gui) anymore as you prefer using the console interface (B) directly. apt doesn't know that you ended up using B directly - it still believes it was installing B just for A, so after you removed A it will offer to autoremove B and C. Not the end of the world of course: reinstalling B is easy if it got removed and as long as you don't purge it it will be as it was before. You are in danger of surprising the user through (what the hell happend?!? Where is B?) and it is possible it will occur to the user that B is missing at a very inconvenient time (no internet or simply uninstallable at the moment). Its easy to dismiss this as no real problem, but if you ever experience this first hand your opinion might change. The alternatives might be worse through. > What makes Recommends and Suggests special? They aren't special, that is the point. The only difference between these relations is just if they will be installed by default (Depends, Recommends), if apt allows you to remove it without removing the package which has such a dependency-relation on it (Recommends, Suggests) and if apt is allowed to break such a relation via autoremove (none). There are options to change property one (you can't change it for Depends of course) and three (ditto) and if I remember right e.g. aptitude warns if you do two [something I want do implement for apt some day]. apt tends to be *very* conservative with removes which is a common complain - this thread is an example, the "usual" upgrade-problems if a maintainer decided that a transitional package is probably not needed is another. "Interestingly", if apt eventually decides to remove a package that tends to cause people to complain as well… We are open to ideas to improve apt, but apt is used by many people with very different expectations, so an idea which looks like an obvious no-brainer in your head might not survive contact with reality. After 6 years I think I have enough 'battle' experience to say that even I have still ideas which look good on paper only… and its good that others put a stop to such ideas before those ideas have a chance to hurt me (and I can assure you, I implemented ideas which never should have been and now taunt me by their mere existence). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#808764: ITP: python-csscompressor -- python port of YUI CSS Compressor
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-csscompressor Version : 0.9.4 Upstream Author : Yury Selivanov * URL : https://github.com/sprymix/csscompressor * License : BSD-3-clause Programming Lang: Python Description : python port of YUI CSS Compressor The python-csscompressor package provides an almost exact port of YUI CSS Compressor. It passes all original unittests. This is a new dependency for python-django-compressor, itself needed for Horizon, the OpenStack dashboard. Note that this is needed if we ant the latest commit from django-compressor, which is the only way to get Django 1.9 compatibility.
Bug#808765: ITP: python-rcssmin -- CSS Minifier
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-rcssmin Version : 1.0.6 Upstream Author : n.d. parker * URL : https://github.com/ndparker/rcssmin * License : Apache-2.0 Programming Lang: Python Description : CSS Minifier The minifier is based on the semantics of the YUI compressor, which itself is based on the rule list by Isaac Schlueter. . This module is a re-implementation aiming for speed instead of maximum compression, so it can be used at runtime (rather than during a preprocessing step). RCSSmin does syntactical compression only (removing spaces, comments and possibly semicolons). It does not provide semantic compression (like removing empty blocks, collapsing redundant properties etc). It does, however, support various CSS hacks (by keeping them working as intended). . rcssmin.c is a reimplementation of rcssmin.py in C and improves runtime up to factor 100 or so (depending on the input). docs/BENCHMARKS in the source distribution contains the details. This is a new dependency for python-django-compressor, which is itself one of the runtime dependencies for Horizon, the OpenStack dashboard. This new dependency is needed by the latest commit on django-compressor, which is the only version currently supporting Django 1.9.
Bug#808767: ITP: apt-transport-gs -- APT transport for repositories privately held on GCS
Package: wnpp Severity: wishlist Owner: "Marcin Kulisz (kuLa)" * Package name: apt-transport-gs Upstream Author : Dhaivat Pandit * URL : https://github.com/ceocoder/apt-gcs * License : MIT Programming Lang: go Description : APT transport for repositories privately held on GCS Transport for apt allowing to have private repositories on Google Cloud Storage
Re: Can I suppress automatic creation of -dbgsym packages?
On Tue, 22 Dec 2015 11:38:26 +0100, Andreas Tille wrote: >Unfortunately we have no power to push this "fix 42 RC bugs" rule - >otherwise the RC bug count would probably decrease a lot. If we had the power to push anybody to do anything, Debian would be in a much better shape. Unfortunately, the "we're all volunteers" argument seems to allow all kinds of unfriendlyness and uncaringness. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Known issues with automatic dbgsym packages (Was: Automatic dbgsym packages built by default as of today!)
On Sun, Dec 20, 2015 at 10:35:05AM +, Niels Thykier wrote: > * reprepro rejects upload with automatic debug symbols as it does not >support them yet[1]. (#730572) >- Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs >- Workaround #2: Pass --ignore=surprisingbinary to reprepro if you > can trust all uploaders (and their tools) to behave. I haven't gotten --ignore=surprisingbinary to actually do what it's meant to do, at least with "reprepro processincoming". I get this: + reprepro --ignore=surprisingbinary processincoming default Name 'obnam-dbgsym' of binary 'obnam-dbgsym_1.19.0ci59-1.unstable_amd64.deb' is not listed in Binaries header of 'obnam_1.19.0ci59-1.unstable_amd64.changes'! Name 'obnam-dbgsym' of binary 'obnam-dbgsym_1.19.0ci59-1.unstable_i386.deb' is not listed in Binaries header of 'obnam_1.19.0ci59-1.unstable_i386.changes'! Warning: database 'jessie-ci|main|i386' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'jessie-ci|main|amd64' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'jessie-ci|main|source' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'unstable-ci|main|source' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'wheezy-ci|main|i386' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'wheezy-ci|main|amd64' was modified but no index file was exported. Changes will only be visible after the next 'export'! Warning: database 'wheezy-ci|main|source' was modified but no index file was exported. Changes will only be visible after the next 'export'! There have been errors! I also don't get this message, which you quoted, though I guess it might only happen with "reprepro include": > To ignore use --ignore=surprisingbinary. This is reprepro 4.16.0-1 from jessie (though it seems sid has the same version). Am I doing something otterly stupid? I can get it to work by ignoring that reprepro failed, and then running "reprepro export" afterwards. Suggestions, anyone? -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: Digital signature
Re: Known issues with automatic dbgsym packages (Was: Automatic dbgsym packages built by default as of today!)
* Lars Wirzenius [Tue Dec 22, 2015 at 06:36:55PM +0100]: > On Sun, Dec 20, 2015 at 10:35:05AM +, Niels Thykier wrote: > > * reprepro rejects upload with automatic debug symbols as it does not > >support them yet[1]. (#730572) > >- Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs > >- Workaround #2: Pass --ignore=surprisingbinary to reprepro if you > > can trust all uploaders (and their tools) to behave. > I haven't gotten --ignore=surprisingbinary to actually do what it's > meant to do, at least with "reprepro processincoming". I get this: [...] > > To ignore use --ignore=surprisingbinary. > This is reprepro 4.16.0-1 from jessie (though it seems sid has the > same version). Am I doing something otterly stupid? > I can get it to work by ignoring that reprepro failed, and then > running "reprepro export" afterwards. > Suggestions, anyone? This is #808558. regards, -mika- signature.asc Description: Digital signature
[OT] Re: Can I suppress automatic creation of -dbgsym packages?
On Tue, Dec 22, 2015 at 05:11:07PM +0100, Marc Haber wrote: > On Tue, 22 Dec 2015 11:38:26 +0100, Andreas Tille > wrote: > >Unfortunately we have no power to push this "fix 42 RC bugs" rule - > >otherwise the RC bug count would probably decrease a lot. > > If we had the power to push anybody to do anything, Debian would be in > a much better shape. Even if I've choosen the word "push" in the first place this Debian would be without my contribution (no idea whether it would be better or worse because of this ;-)). > Unfortunately, the "we're all volunteers" > argument seems to allow all kinds of unfriendlyness and uncaringness. I do not see a correlation between volunteers and unfriendlyness. Kind regards Andreas. -- http://fam-tille.de
Bug#808793: test, please ignore
Package: general This is a test of the BTS, please ignore.
Processed: your mail
Processing commands for cont...@bugs.debian.org: > reassign 808793 gparted Bug #808793 [general] test, please ignore Bug reassigned from package 'general' to 'gparted'. Ignoring request to alter found versions of bug #808793 to the same values previously set Ignoring request to alter fixed versions of bug #808793 to the same values previously set > End of message, stopping processing here. Please contact me if you need assistance. -- 808793: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808793 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
