Re: git and quilt
OoO En ce début d'après-midi ensoleillé du samedi 06 février 2010, vers 15:15, Goswin von Brederlow disait : > He wants to KISS. So lets make it even simpler. > - master: patched source > - upstream: upstream source Suppose the following workflow: - upstream version X.Y - master branch based on X.Y - patch Z applied on master branch - upstream branch is updated to (X+1).0 - upstream is merged into master branch and manual intervention is needed because there are conflicts between changes on upstream side and patch Z Now, if upstream want to get patch Z, he can : - get patch Z for version X.Y - get patch between upstream (X+1).0 and master (X+1).0 containing patch Z and other stuff While git allows to keep track of modifications, it is difficult for upstream (or some other people) to review a precise patch. Or maybe you rebase master branch on the upstream one (which would be great to see watch patches are applying to upstream but will lead to difficulties when tracking master branch)? -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) pgpk4diN0Vp0H.pgp Description: PGP signature
Re: git and quilt
Hi Vincent, Vincent Bernat wrote: > Now, if upstream want to get patch Z, he can : > - get patch Z for version X.Y > - get patch between upstream (X+1).0 and master (X+1).0 containing >patch Z and other stuff > Well, in this example there wouldn't be any "other stuff" - you would do the conflict resolution and end up with modified patch Z' which can be extracted easily. > While git allows to keep track of modifications, it is difficult for > upstream (or some other people) to review a precise patch. In the more general sense however, I agree - you could have committed 20 revisions to the master branch while fixing 3 bugs and intermittently working on one experimental feature which isn't finished yet. There is no simple way of separating these looking at the master branch alone. IMHO you still need to have someway to separate the commits into patches or something equivalent. You could use topic branches. You could cherry pick commits from master and combine them into one-commit-per-bugfix onto a different branch. Or, of course, you could cherry pick commits and combine them into quilt patches ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
On Sun, 07 Feb 2010, Vincent Bernat wrote: > While git allows to keep track of modifications, it is difficult for > upstream (or some other people) to review a precise patch. Or maybe you > rebase master branch on the upstream one (which would be great to see > watch patches are applying to upstream but will lead to difficulties > when tracking master branch)? Well, a non-native Debian package would need to use a git workflow that is optimized for downstream maintenance. And that does mean rebases. One should never confuse the optimal *upstream* git workflow, with downstream workflows. Anything that goes "never rebase" is solely for pure upstream use. Downstream, you "fork" from upstream each release, either by merging topic branches (_rebasing_ them if any sort of conflict happens, all merge commits must be perfectly clean ones), or rebasing the debian changes on top of the new upstream and calling that the new 'master' branch. This doesn't mean a lot of branches. You just need "master", and to tag every release so that you can get it back (and even make it a permanent or temporary branch) at any time. And you shouldn't have a mess of a history, either. All patches cleaned up. If this doesn't suit your style of developent, you should have a work repo somewhere, and keep the package repo separate and clean. There are different ways of doing the above, of course. The important details are exactly what you pointed at: it needs to result in clean commits that are easy to locate, and that apply cleanly to the upstream version matching the package's (and not to some past upstream version). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568732: ITP: libwebcam -- The Webcam Library libwebcam is designed to simplify the development of webcam applications
Package: wnpp Severity: wishlist Owner: Paulo * Package name: libwebcam Version : 0.2.0 Upstream Author : Martin Rubli * URL : http://http://www.quickcamteam.net/software/libwebcam * License : (LGPL, GPL) Programming Lang: C Description : The Webcam Library libwebcam is designed to simplify the development of webcam applications The Webcam Library libwebcam is designed to simplify the development of webcam applications, primarily on Linux but with an option to be ported to other platforms, in particular Solaris. It's an easy to use library that shields its users from many of the difficulties and problems of using the V4L2 API directly. It also provides command line tools and a udev script to automate enabling uvc extension controls (logitech: focus, pan/tilt, ...) in cameras that have support for them. Libwebcam provides the following core features: * Enumeration of all cameras available in the system. * Provide detailed information about the detected devices and their controls. * Wrapper for the V4L2 frame format enumeration. * Convenient access to device controls. * Support for configuring the Linux UVC driver's dynamic controls (extension unit controls). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Sat, 06 Feb 2010, Marco d'Itri wrote: > On Feb 06, Henrique de Moraes Holschuh wrote: > > It got renamed to wdt_tco, I think, and it will hard-hang a lot of thinkpads > > if it ever triggers, for example: the SMBIOS can't handle it. > OK, I will blacklist this one. I'd rather we had a watchdog mini policy that boils down to: Watchdog drivers have to default to *at least* N seconds timeout (N can't be too large, some watchdogs have hardware/firmware limits). All watchdog-enabled packages have to default to *at most* N/2 seconds timeout (probably N/3 is better, though). The blacklisting of watchdog drivers would be switched to default options to ensure the "N seconds timeout", or alternatively, we would need to fix it on the kernel tree. I prefer the options, because AFAIK some kernel drivers default to "leave the timeout to whatever was set by the BIOS", and it would be tough to get that policy changed upstream. > > Anyway, if for any reason we load a watchdog driver, AND any of the watchdog > > userspace packages by mistake, we can cause data loss. > root can cause data loss by running rm -rf / by mistake as well, so this > is not a great argument. And if that happens because of any default config or package maintainer script, it is a "critical" bug. At least the watchdog issues would warrant at most "grave" bugs (and personally I would place them at severity "important", since spurious reboots are a normal and expected failure mode of a watchdog system). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
e2fsprogs not esential anymore?
Now that /sbin/fsck is provided by util-linux it should be possible to drop the Essential attribute from the e2fsprogs. How do we do this? e2fsprogs is not needed when the system uses other file systems or does not have its own (e.g. openvz and lxc containers) and removing it would save a few MB. -- ciao, Marco signature.asc Description: Digital signature
Re: e2fsprogs not esential anymore?
Marco d'Itri wrote: > Now that /sbin/fsck is provided by util-linux it should be possible to > drop the Essential attribute from the e2fsprogs. How do we do this? The whole archive needs to be scanned to see if no functionality of e2fsprogs is used without (build) dependency. Dropping the flag itself is just uploading e2fsprogs AFAICS. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: e2fsprogs not esential anymore?
Marco d'Itri wrote: > Now that /sbin/fsck is provided by util-linux it should be possible to > drop the Essential attribute from the e2fsprogs. How do we do this? Does that also mean initscripts will be dropping its dependency on e2fsprogs? Also, what new priority should it get? Debian Installer already ensures e2fsprogs gets installed if ext[234] are used, so from that PoV there's no problem. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: e2fsprogs not esential anymore?
On Sunday 07 February 2010, Frans Pop wrote: > Does that also mean initscripts will be dropping its dependency on > e2fsprogs? Just see it's already been lowered to recommends (I had an older version of initscripts installed). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#474540: e2fsprogs not esential anymore?
On Feb 07, Frans Pop wrote: > > Now that /sbin/fsck is provided by util-linux it should be possible to > > drop the Essential attribute from the e2fsprogs. How do we do this? > Does that also mean initscripts will be dropping its dependency on > e2fsprogs? initscripts in squeeze already only recommends e2fsprogs. > Also, what new priority should it get? I'm not sure, right now my goal is to remove the essential flag in time for squeeze. -- ciao, Marco signature.asc Description: Digital signature
List of possible empty binary packages
Hello, I conducted an analysis to see if there are empty packages in the archive which are not metapackages or transitional ones, and then prepared a dd-list to show affected packages. Some packages have been removed from the original list as it was clearly stated in package descriptions they are empty by purpose, others have been manually removed being false positives. There could be more false positives, feel free to report inaccuracies to have a more precise picture for a potential MBF. Adam C. Powell scotch (U) Michael Ablassmeier libapache-mod-chroot Ivanko B mseide-msegui Christian Bac phpgroupware (U) Sebastien Bacher totem Mirco Bauer mono (U) Olivier Berger phpgroupware Armin Berres kdeartwork (U) kdeedu (U) kdepim (U) Laurent Bigonville libchamplain (U) Fathi Boudra kdeartwork (U) kdeedu (U) kdepim (U) mlt Emmanuel Bouthenot weechat Michael Casadevall kdeartwork (U) Michael Casadevall libxfcegui4 (U) Jesus Climent dspam (U) Julien Cristau libxmu (U) LI Daobing liblunar Debian Citadel Team citadel Debian DSPAM Maintainers dspam Debian GCC Maintainers gcc-4.1 Debian GNOME Maintainers libchamplain (U) totem (U) Debian Haskell Group haskell-hsql-mysql Debian Mono Group mono mono-uia Debian Pkg-e Team e17 Debian Qt/KDE Maintainers kdeartwork kdebindings kdeedu kdepim Debian Request Tracker Group request-tracker3.8 Debian Science Team code-saturne Debian Scientific Computing Team fenics scotch suitesparse-metis Debian X Strike Force libxmu Debian Xfce Maintainers libxfcegui4 Debian Xiph.org Maintainers libfishsound Eric Dorland libp11 Sebastian Dröge mono (U) totem (U) vala (U) John Francesco Ferlito libfishsound (U) Freevo Debian Dream Team freevo Wilfried Goesgens citadel (U) Stephen Gran hdparm Debian QA Group avifile GRUB Maintainers grub2 Christoph Haas dspam (U) Dominic Hargreaves request-tracker3.8 (U) Jacob Helwig request-tracker3.8 (U) Simon Huggins libxfcegui4 (U) Mario Iseli libconfig-inetd-perl IV" scotch (U) Kurt B. Kaiser dspam (U) Dustin Kirkland byobu Matthias Klose gcc-4.1 (U) Ivan Kohler request-tracker3.8 (U) Aurelien Labrosse dspam (U) Sylvestre Ledru code-saturne (U) Georg W. Leonhardt freevo (U) Martin Loschwitz libxfcegui4 (U) Ola Lundqvist dpsyco harden Marc-Andre Lureau vala (U) Jan Lübbe e17 (U) Maintainers of Vala packages vala Jordi Mallach grub2 (U) Torsten Marek kdebindings (U) TSUCHIYA Masatoshi mecab-ipadic mecab-jumandic Patrick Matthäi mlt (U) Alastair McKinstry emoslib A Mennucc1 freevo (U) Michael Meskes citadel (U) kdepim (U) Robert Millan grub2 (U) Loic Minier vala (U) Matthijs Mohlmann dspam (U) Emilio Pozuelo Monfort totem (U) Daniel Rus Morales suitesparse-metis (U) Daigo Moriwaki google-perftools ruby1.9 (U) Josselin Mouette totem (U) Toni Mueller request-tracker3.8 (U) David Nusinow libxmu (U) Lucas Nussbaum ruby1.9 (U) Xavier Oswald e17 (U) David Palacio kdebindings (U) Víctor Pérez Pereira haskell-hsql-mysql (U) Yves-Alexis Perez libxfcegui4 (U) Christophe Prud'homme fenics (U) scotch (U) suitesparse-metis (U) Johannes Ring fenics (U) Emanuele Rocca libxfcegui4 (U) Felipe Sateler csound Daniel Schepler kdeedu (U) Jo Shields mono (U) Sjoerd Simons libchamplain totem (U) Jonas Smedegaard csound (U) Lincoln de Sousa freecraft TANIGUCHI Takaki libmoe Reinhard Tartler byobu (U) Enrico Tassi lua-soap lua-xmlrpc Albin Tonnerre e17 (U) Niko Tyni request-tracker3.8 (U) Modestas Vainius kdepim (U) Modestas Vainius kdeartwork (U) kdebindings (U) kdeedu (U) Sune Vuorela kdeartwork (U) kdebindings (U) kdeedu (U) kdepim (U) Ray Wang mono-uia (U) Rudolf Weber dspam (U) Torsten Werner mseide-msegui (U) Alexander Wirt citadel (U) akira yamada ruby1.9 Felix Zielcke grub2 (U) Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: List of possible empty binary packages
Il giorno Sun, 7 Feb 2010 20:20:08 +0100 Luca Falavigna ha scritto: > I conducted an analysis to see if there are empty packages in the > archive which are not metapackages or transitional ones, and > then prepared a dd-list to show affected packages. To match source packages with affected binaries, you can look at the list I prepared at http://people.debian.org/~dktrkranz/empty_packages Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: List of possible empty binary packages
On Sun, Feb 07, 2010 at 08:20:08PM +0100, Luca Falavigna wrote: > Hello, > > I conducted an analysis to see if there are empty packages in the > archive which are not metapackages or transitional ones, and > then prepared a dd-list to show affected packages. > > Some packages have been removed from the original list as it was > clearly stated in package descriptions they are empty by purpose, > others have been manually removed being false positives. > > There could be more false positives, feel free to report > inaccuracies to have a more precise picture for a potential MBF. > ... > Debian Qt/KDE Maintainers >kdeartwork >kdebindings >kdeedu >kdepim > These are all metapackages. BTW, I wonder why you listed only those from KDE and not for example kdegames that is similar (KDE metapackage installing all the provided apps). Ana -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: List of possible empty binary packages
On Sun, Feb 7, 2010 at 20:20:08 +0100, Luca Falavigna wrote: > Debian X Strike Force >libxmu > debian/rules does: dh_strip -Nlibxmu6 -Nlibxmuu1 dh_strip -plibxmu6 --dbg-package=libxmu6-dbg dh_strip -plibxmuu1 --dbg-package=libxmuu1-dbg and the debug symbols for both libxmu6 and libxmuu1 end up in libxmu6-dbg. Probably because DH_OPTIONS is set to -s, and so the -p is useless. Thanks for the report… Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
Henrique de Moraes Holschuh writes: > Downstream, you "fork" from upstream each release, either by merging > topic branches (_rebasing_ them if any sort of conflict happens, all > merge commits must be perfectly clean ones), or rebasing the debian > changes on top of the new upstream and calling that the new 'master' > branch. With Bazaar, one doesn't need to rebase to achieve this. The ‘loom’ plugin allows for tracking changes against upstream revisions, while *preserving* the history of changes, and generating tidy change sets to feed back upstream (or, in our use case of interest, to use as Quilt patches). http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar> -- \“The restriction of knowledge to an elite group destroys the | `\ spirit of society and leads to its intellectual | _o__)impoverishment.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: List of possible empty binary packages
On 07/02/2010 20:20, Luca Falavigna wrote: > Debian Xfce Maintainers >libxfcegui4 Aha, thought that dh7 tiny.rules would take care of the --dbg-package arg to dh_strip for me. Thanks for noticing, will fix that soon. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature
Re: List of possible empty binary packages
On 07/02/10 21:30, Ana Guerrero wrote: >> Debian Qt/KDE Maintainers >>kdeartwork >>kdebindings >>kdeedu >>kdepim >> > > These are all metapackages. > BTW, I wonder why you listed only those from KDE and not for example > kdegames that is similar (KDE metapackage installing all the provided apps). Those are the source packages. The buggy ones are not those, but others (indi for kdeedu, kdeartwork-theme-window for kdeartwork...). See http://people.debian.org/~dktrkranz/empty_packages to find the affected binary packages. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney wrote: > With Bazaar, one doesn't need to rebase to achieve this. The ‘loom’ > plugin allows for tracking changes against upstream revisions, while > *preserving* the history of changes, and generating tidy change sets to > feed back upstream (or, in our use case of interest, to use as Quilt > patches). As was already mentioned, topgit is not perfect (it basically needs a little polishing, and the history of patch branches gets messy from many merges), but for people who don't want to switch to bzr, it provides essentially the same functionality as bzr loom or (AIUI) hg patch queues. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Removing dpkg conffile backgrounding prompt support
Hi! I'd like to know if people would strongly miss being able to background dpkg on the conffile prompt (‘Z’), instead of starting a new subshell. The latter is the default with most modern frontends (APT based). I personally find the background support annoying and confusing when one is used to expect a subshell. It would also allow to properly fix bug 60329, which I think would be nice. Otherwise I'd like to remove it in the near future. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
