Re: Ad-hoc survey of existing Debian git integration tools
Hi Ian, On Thu, Jul 30, 2015 at 03:51:59PM +0100, Ian Jackson wrote: [..snip..] > I don't think the number of git-based workflows is going to decrease. > I'm hoping (betting!) that the proportion of packages whose git > maintainers' git workflows involve strange[1] git trees will go down. > > [1] Strange means any tree which you can't work on, immediately, with > git, without using some special tool on it first. Having patches applied with 3.0(quilt) calls out for sync problems between your git tree and debian/patches/. This can be mitigated with --single-debian-patch --auto-commit but that's not what most people mean when talking about 3.0(quilt) - and it kind of defeats it's purpose. It would IMHO be better to have a true git based format then. Cheers, -- Guido -- 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/2015073107.gb3...@bogon.m.sigxcpu.org
Bug#794211: ITP: libmemory-usage-perl -- Determine actual memory usage of Perl programs
Package: wnpp Owner: intrigeri Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmemory-usage-perl Version : 0.201 Upstream Author : Dave O'Neill * URL : https://metacpan.org/release/Memory-Usage * License : Artistic or GPL-1+ Programming Lang: Perl Description : Determine actual memory usage of Perl programs Memory::Usage measures, from the operating system's perspective, how much memory a Perl program is using at any given time. It can record memory usage at specific times, and report about it afterwards. -- 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/20150731093022.3413C721CA7@localhost
Re: Metapackage dependencies: "Depends" or "Recommends"?
* Neil Williams [150729 03:30]: > I'd still use Depends in the metapackage. e.g. foo-server has lots of > strict dependencies without which is simply won't install or start. > foo-client has less dependencies and a few Recommends because the > client can work for a range of usecases and not everyone needs every > use case. > > For those people who *do* want the assurance that every possible use > case can work, then a foo metapackage would Depend on foo-server and > foo-client and *all* of the Recommends of foo-client, possibly > including even a few of the Suggests of foo-client. For those people, don't change the default Apt::Install-Recommends and you get the desired behavior with metapackages that use Recommends. But those of us who want most, but not all, of a metapackage can still get what we want, too (with either setting of Install-Recommends). If a metapackage uses Depends, the only way to install all but one subpackage from the metapackage is to manually install all the desired subpackages; but then you do not get the auto-installed behavior, so you cannot easily remove the (non-)metapackage. You also do not get the benefits of updates to the contents of the metapackage. No downside to Recommends; no upside to Depends. Think of Recommends as "defaults to Depends, but can easily be overridden by the user at install time". Depends should be used when not installing the package causes functional breakage rather than logical breakage or loss of functionality. Recommends should be used when not installing the package makes sense if the user is willing to put up with reduced functionality. I think much of this debate is caused by users who set Install-Recommends to false, but then want some of the benefits of leaving it at the default of true. I do set Install-Recommends to false, but I understand the trade-off I am making. I mostly use the aptitude curses interface, and I take a little more time to go through the list of Recommended packages to select the ones I want before pressing g a second time. And yes, I do mark those packages as automatically installed. Using Recommends allows the user to choose which side of the trade-off to be on. Using Depends forces the "install everything, no opportunity to spend a few extra seconds to choose what you want" on everybody. ...Marvin -- 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/20150731121623.gk21...@basil.wdw
Re: Ad-hoc survey of existing Debian git integration tools
Guido Günther writes: > Having patches applied with 3.0(quilt) calls out for sync problems > between your git tree and debian/patches/. This can be mitigated with > --single-debian-patch --auto-commit but that's not what most people mean > when talking about 3.0(quilt) - and it kind of defeats it's purpose. I think the problems you are describing arise when the user does _both_ (a) manipulate the patches in debina/patches/ (with maybe quilt) _and_ (b) manipulate the upstream code in git. Does git-buildpackage have a way to take a patches-applied git tree and turn it into a patches-unapplied form ? If so then it might be sensible for gbp users who want to publish a directly-useable git branch to treat the dgit branch as an export format: ie, to explicitly convert to it, and to convert _from_ it where necessary. No doubt the tools could be enhanced to do this. > It would IMHO be better to have a true git based format then. Well, I quite agree, and am not a fan of `3.0 (quilt)'. But dgit is not part of a campaign to eliminate `3.0 (quilt)'. Ian. -- 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/21947.33927.97215.768...@chiark.greenend.org.uk
Re: Ad-hoc survey of existing Debian git integration tools
Ian Jackson writes ("Ad-hoc survey of existing Debian git integration tools"):
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
> provide good guidance for how these tools work with dgit (and perhaps
> send feature requests for those tools, or know what extra features are
> needed in dgit).
FTR, WRT git-dpm, I have filed this wishlist bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794244
"request for manpage git-dpm-dgit(7) or similar"
I would like to make a similar request about git-buildpackage, but I'm
not sure I understand gbp well enough yet.
Ian.
--
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/21947.41612.396037.673...@chiark.greenend.org.uk
Bug#794245: ITP: fonts-monoid -- open source coding font with bitmap-like sharpness
Package: wnpp Severity: wishlist Owner: Vasudev Kamath * Package name: fonts-monoid Version : 0.60 Upstream Author : Andreas Larsen * URL : http://larsenwork.com/monoid/ * License : MIT/OFL 1.1 Programming Lang: font Description : open source coding font with bitmap-like sharpness Monoid is customizatble and optimized for coding with bitmap-like sharpness at 12px/9pt even on low res display. . Monoid is semi-condensed and distinguishable glyphs with short ascenders, descenders, big appertures and supersized operators, punctuation. . It comes with regular, bold, oblique and retina versions with >750 latin, greek, cyrillic, ligature, alternate and Powerline glyphs. I will maintain this package as part of pkg-fonts team. -- 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/20150731163656.31718.79438.report...@rudra.copyninja.info
Bug#794250: ITP: pgcli -- CLI for PostgreSQL with syntax highlighting and completion
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: pgcli Version : 0.18.0 Upstream Author : Amjith Ramanujam * URL : http://pgcli.com/ * License : BSD-3-clause Programming Lang: Python Description : CLI for PostgreSQL with syntax highlighting and completion This is a PostgreSQL client that does auto-completion and syntax highlighting. The CLI is also capable of pretty printing tabular data Reasons for ITP: Usefuly utility for people who like to do their SQL work on the Shell. I intend to maintain this with either sponsorship from PATP or my personal sponsor. -- 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/20150731171957.29633.26292.report...@lhw.ring0.de
Bug#794251: ITP: mycli -- CLI for MySQL/MariaDB with syntax highlighting and completion
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: mycli Version : 1.0.1 Upstream Author : Amjith Ramanujam * URL : http://mycli.net * License : BSD-3-clause Programming Lang: Python Description : CLI for MySQL/MariaDB with syntax highlighting and completion This is a MySQL/Mariadb client that does auto-completion and syntax highlighting. The CLI is also capable of pretty printing tabular data Reasons for ITP: Usefuly utility for people who like to do their SQL work on the Shell. I intend to maintain this with either sponsorship from PATP or my personal sponsor. -- 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/20150731172211.30047.55061.report...@lhw.ring0.de
Bug#794279: ITP: r-bioc-genefilter -- methods for filtering genes from microarray experiments
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-genefilter Version : 1.50.0 Upstream Author : R. Gentleman, V. Carey, W. Huber, F. Hahne * URL : http://bioconductor.org/packages/release/bioc/html/genefilter.html * License : Artistic-2.0 Programming Lang: R Description : methods for filtering genes from microarray experiments This BioConductor module provides methods for filtering genes from microarray experiments. It contains some basic functions for filtering genes. Remark: This BioConductor module will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-genefilter/trunk/ -- 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/20150731202117.19298.56609.report...@mail.an3as.eu
Re: Metapackage dependencies: "Depends" or "Recommends"?
On Thu, 2015-07-30 at 08:57 +0200, David Kalnischkies wrote: > This example makes it quite obvious that your requirements are "keep > a minimal set of packages installed" while the requirement of libapt's > autoremove is "suggest only packages for removal which are completely > safe to remove". If "Suggest only packages for removal which are completely safe to remove" is supposed to be "list all which are completely safe to remove" then it doesn't manage to do that either. It fails given circular references, ie A depends on B depends on C depends on A. I guess it's designed for the "cleanup packages I played with for a short while on my laptop" use case. It does a sort of OK job at that. Only sort of, because when you move across flag days the dregs left libapt leaves behind can get it confused over which packages should removed so the upgrade can proceed. For my servers it's different. The inherent ambiguity of Debian dependency system that libapt tries hide becomes intolerable, meaning I don't want something to just choose between the possibilities on my behalf, I want to be informed so I can see the choices and have my decision explicitly recorded to I can repeat it. Leaving garbage packages (think "garbage" as in garbage collector) lying around on servers that are supposed to be clones left alone to maintain themselves for a while is equally unacceptable. In the end I gave up up on libapt and wrote my own dependency resolver. Fortunately libapt makes that relatively easy because it's API gives you access to all its internal working so you can re-use most of it. signature.asc Description: This is a digitally signed message part
Re: Metapackage dependencies: "Depends" or "Recommends"?
On Sat, 01 Aug 2015 08:55:03 +1000, Russell Stuart wrote: >For my servers it's different. The inherent ambiguity of Debian >dependency system that libapt tries hide becomes intolerable, meaning I >don't want something to just choose between the possibilities on my >behalf, I want to be informed so I can see the choices and have my >decision explicitly recorded to I can repeat it. debfoster? >Leaving garbage >packages (think "garbage" as in garbage collector) lying around on >servers that are supposed to be clones left alone to maintain themselves >for a while is equally unacceptable. Playing with servers that are supposed to be clones, even adminning them with manual ssh interaction will make them lose their clone property in absolutely not ime, turning them into snowflakes[1]. Automated systems are needed for that. And even then, a machine is to be considered a snowflake once a person has been root on them. Greetings Marc [1] all alike, but different -- -- !! 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 -- 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/e1zlqwc-00061d...@swivel.zugschlus.de
