Bug#747070: ITP: apt-venv -- apt virtual environment
Package: wnpp Severity: wishlist Owner: Leo Iannacone * Package name: apt-venv Version : 0.1.0 Upstream Author : Leo Iannacone * URL : https://github.com/LeoIannacone/apt-venv * License : GPL-3 Programming Lang: Python Description : apt virtual environment apt-venv creates a sort of virtual environment in the user home directory and forces apt to run under some custom option. . A simple use case is collect information about packages in different Debian and Ubuntu release without surfing the web, just using calling apt-cache through the virtual environment. -- 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/20140505100304.20651.59209.reportbug@home
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
Hi, Cameron Norman: > I understand just fine how it is packaged. It is packaged in a way that > pushes components down other's throats and tells users to simply disable > them if they are not necessary. So? The standard case is that they're either not really optional, or they passively sit around, consuming disk space and perhaps an open socket but no other resources. In the first case, you can create a package that disables logind / replaces sytemd-nspawn with a link to /bin/false very easily. This will take MUCH less work than it'd take to split up systemd even more, add a bunch of redundant dependencies to whatever, and fix the inevitable bugs that'll be introduced by this. The second case is a no-brainer. Many packages in Debian consist of more than one binary, of which you need at most one (if that). Do you really want to mass-file a bug against all of these _and_ the packages depending on them, or are you picking on systemd for non-technical reasons here? Sorry, but I suspect the latter. -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#747083: ITP: xcape -- use a modifier key as another key
Package: wnpp Severity: wishlist Owner: KAction * Package name: xcape Version : 1.1 Upstream Author : Albin Olsson * URL : https://github.com/alols/xcape * License : GPL Programming Lang: C Description : use a modifier key as another key xcape allows you to use a modifier key as another key when pressed and released on its own. Note that it is slightly slower than pressing the original key, because the pressed event does not occur until the key is released. The default behaviour is to generate the Escape key when Left Control is pressed and released on its own. (If you don't understand why anybody would want this, I'm guessing that Vim is not your favourite text editor ;) This package is currently the only maintained of its kind, as far as I know. I am using it around year, no problems occured. -- 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/20140505134131.8272.5156.report...@malgrandeta.kaction.name
Re: Point 1 of Social Contract
Le 04/05/2014 23:15, Jonathan Dowland a écrit : > On Sun, May 04, 2014 at 01:59:09PM +0200, Solal wrote: >> I think we shouldn't support proprietary software creaters > > Who's 'we'? "We" in the official list of Debian developers means... The Debian developers. -- 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/53679cde.3080...@me.com
Re: Bug#735134: perl: rename(1) is ancient
On Sun, Feb 02, 2014 at 03:12:32PM +, Dominic Hargreaves wrote: > [CCing debian-devel to get feedback on a de facto 'standard' tool]. > > On Sat, Jan 18, 2014 at 03:34:29PM +, Dominic Hargreaves wrote: > > On Tue, Jan 14, 2014 at 12:59:04PM -0800, Don Armstrong wrote: > > > On Tue, 14 Jan 2014, Niko Tyni wrote: > > > > > I suggest something like > > > > > > > > - package libfile-rename-perl > > > > - make it supply a better /usr/bin/rename with the alternatives system > > > > libfile-rename-perl is now on its way to NEW. > > > > > > - make the old one from the perl package issue warnings, Recommend > > > > libfile-rename-perl for one release cycle > > > > > > I don't know if this is actually necessary. We could just have perl > > > depend on libfile-rename-perl once we remove debian/rename. Or just keep > > > rename as it is currently. But I'm OK with either option so long as > > > /usr/bin/rename keeps the same syntax. > > > > I think removing the rename from the Debian package is the best long-term > > option, otherwise we still end up carrying dead code around. The question > > of whether we carry around a Depends long-term rather depends on whether > > users generally consider rename a fundamental part of the perl package. > > It's certainly become quite a basic tools that I expect to see on Debian > > systems, but others may disagree. The alternative, of course, is for > > libfile-rename-perl to just be Standard, without any actual long-term > > dependencies. > > So to summarise: for many years the perl package has provided > /usr/bin/rename, a stanalone utility implemented in perl. The issue is we > don't want to provide the utility from the perl package any more because > it's been added locally inside debian/ and is not being maintained. A > maintained version is available as a separate package, libfile-rename-perl. > > The proposals on the table are: > > 1) Have perl Depend on libfile-rename-perl (and therefore have the >latter become Priority: standard) > 2) Make libfile-rename-perl be Standard, to match perl, without adding >any dependencies. > 3) Have perl Recommend libfile-rename-perl for one release cycle and then >drop it >- optionally with a warning being emitted by the built-in script > 4) 2) + 3) combined. > > Option 1 would imply that the utility is fundamentally a part of > using perl, which since it's a standalone command line program which > happens to be written in perl, seems wrong. > > Option 2 is my preferred option because it seems like the 'least surprise' > option. 4) can be considered a mostly-harmless enhancement to that, > although adding warnings could be irritating or harmful in some > circumstances. Based on all the comments, I am proceeding to: 1) Make 'rename' (as it has now been renamed, from libfile-rename-perl) Priority: standard 2) Add a Recommends on rename to the perl package for a transitional period 3) Submit a new lintian check for things which use rename or prename in build scripts, advising of changes needed. 4) Wait until vitually all packages have been fixed and then remove prename from the perl package Cheers, Dominic. -- 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/20140505145105.gz23...@urchin.earth.li
Re: Point 1 of Social Contract
> …and firmware. +1 -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/2973237.mVVJe0ZZT7@hal9000
Re: Point 1 of Social Contract
No +1 because proprietary firmware is unethical too. Le 05/05/2014 17:28, Salvo Tomaselli a écrit : >> …and firmware. > +1 > -- 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/5367ae79.5060...@me.com
Re: Bug#747070: ITP: apt-venv -- apt virtual environment
On 5 May 2014 11:03, Leo Iannacone wrote: > Package: wnpp > Severity: wishlist > Owner: Leo Iannacone > > * Package name: apt-venv > Version : 0.1.0 > Upstream Author : Leo Iannacone > * URL : https://github.com/LeoIannacone/apt-venv > * License : GPL-3 > Programming Lang: Python > Description : apt virtual environment > > apt-venv creates a sort of virtual environment in the user > home directory and forces apt to run under some custom option. > . > A simple use case is collect information about packages > in different Debian and Ubuntu release without surfing the web, > just using calling apt-cache through the virtual environment. How is it different from "chdist" utility from the devscripts package that allows apt-cache lookups and more? http://manpages.ubuntu.com/manpages/trusty/en/man1/chdist.1.html -- Regards, Dimitri. -- 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/CANBHLUgYqhCEVc_pMW_k_NeudRMWRXZ8u5CCq_YdebCf67c=u...@mail.gmail.com
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
previously on this list Matthias Urlichs contributed: > The second case is a no-brainer. Many packages in Debian consist of more > than one binary, of which you need at most one (if that). Do you really > want to mass-file a bug against all of these _and_ the packages depending > on them, or are you picking on systemd for non-technical reasons here? > > Sorry, but I suspect the latter. Why did I expect any reasonable and balanced discussion! I suspect but haven't mentioned that I expect the reasons for bundling these components together to be on highly questionable grounds. Something like avahi-daemon can be easily understood as what it is needed for and whilst I would like to remove it I can simply disable the service without any consideration as I know I have no use for it even if I use cups meaning an increases in security without any functionality loss for our users. Things like coreutils are used but not resident. With systemd-services knowing what it is doing is more important and being able to avoid complex resident code with minimal sacrifice should be possible. You could easily argue that just logind does far more in one binary than it should for reasonable system management never mind it being bundled with other especially potentially widely used functions like systemd-localed. After a quick look at the script I guess aptdaemon only needs localed. I guess there is no unlaborious way to see which programs depend on a particular binary of a given package? GDM can be easily avoided or uninstalled for example if you have no need for logind and perhaps there are alternatives for any others but the current situation means you have to cut out more or investigate far more than you should have to. And Yes KDE dependencies being so coarse grained do really annoy me but atleast KDE doesn't run by default. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- 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/63894.49700...@smtp115.mail.ir2.yahoo.com
Re: gnutls28 transition
Dimitri John Ledkov wrote... > Should we start transition to gnutls28 by default, for all packages > that are compatible? Given the fact libgnutls26 has issues like #708174 and cannot handle SHA-512 signed certificates as issued by CACert¹: Yes, please let's get rid of that old stuff whereever possible and as soon as possible. Christoph ¹ http://danielpocock.com/double-whammy-for-cacert.org-users came a few hours too late, I had to re-compile openldap using openssl. -- 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/1399307...@msgid.manchmal.in-ulm.de
Re: Point 1 of Social Contract
In data lunedì 5 maggio 2014 17:30:01, Solal ha scritto: > No +1 because proprietary firmware is unethical too. So don't install it and don't tell me what should I think. Cheers -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/29774854.XCGqkiTW20@hal9000
Re: Bug#747070: ITP: apt-venv -- apt virtual environment
On 5 May 2014 17:58, Dimitri John Ledkov wrote: > How is it different from "chdist" utility from the devscripts package > that allows apt-cache lookups and more? > > http://manpages.ubuntu.com/manpages/trusty/en/man1/chdist.1.html I did not know "chdist", but .. after a quick look I can say "apt-venv" has a different approach and goal. It has been developed to provide user with a full virtual environment, where you can run any command/script you want. If fact, it launches a new `bash` session with a custom APT_CONFIG environment variable, which forces apt to use a different sources.list. Perhaps, chdist may be patched to get this behavior... Anyway, I don't know perl. Best, Leo. -- Ubuntu Member - http://launchpad.net/~l3on Home Page - http://leoiannacone.com GPG Key Id - 0xD282FC25 -- 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/CACzqv1cVVUofeU=QnvFmfG=EvC99-8ZM3TxYS3MtDu1-WE0=0...@mail.gmail.com
Re: Point 1 of Social Contract
On 05/05/2014 05:30 PM, Solal wrote: > No +1 because proprietary firmware is unethical too. hmm, have you read the post you are replying to and what the "+1" was referring to? and please do stop top-posting... fgmards IOhannes PS: am i just feeding the troll? signature.asc Description: OpenPGP digital signature
Re: Point 1 of Social Contract
* "IOhannes m zmölnig (Debian/GNU)" , 2014-05-05, 18:58: PS: am i just feeding the troll? Yes. -- Jakub Wilk -- 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/20140505181320.ga5...@jwilk.net
Re: A question about patches for upstream
On Sun, May 04, 2014 at 05:36:53PM +0200, Jonas Smedegaard wrote: > I cannot imagine *any* example of a bug reported reported according to > guidelines being a waste of time. > > Can you provide examples of that kind of response? I remember it happening only once, and it was quite a while ago. I can't remember for which package it was, so I can't find a link. I'm happy to see that there is consensus anyway that forwarding bugs upstream is the task of the maintainer. Which means that if the maintainer is unable to do that, the response "please forward this upstream" should be interpreted (and perhaps more clearly written) as "sorry I don't have time, this is how you can try to make things happen yourself". Obviously, if the reporter wants to actively help solving the issue, sending it upstream him/herself is a good idea, and it is good for the maintainer to suggest this when it seems appropriate. Thanks, Bas -- 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/20140505185648.gl10...@fmf.nl
Re: A question about patches for upstream
previously on this list Bas Wijnen contributed: > Which means that if the maintainer is unable to do that, the response "please > forward this upstream" should be interpreted (and perhaps more clearly > written) > as "sorry I don't have time, this is how you can try to make things happen > yourself". Perhaps at the same time the minimum could be a debian dev anonymous email address that is used to simply send a link to the bug report to the upstream mailing list if they have one. It is not always easy for a user to find the right place/list/having to register possibly a second time etc.. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- 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/553432.30578...@smtp104.mail.ir2.yahoo.com
Module from /etc/modules-load.d/modules.conf not loaded after systemd upgrade
Hi all, my development system running unstable failed to start X server after an dist-upgrade two days ago. After a bit of investigation I found out that the radeon module is not loaded at bootup anymore. To get the graphical login back, the following commands as root were needed: # modprobe radeon # systemctl restart kdm Why radeon is not loaded at boot anymore is a mystery to me. All other modules from /etc/modules (symlinked as /etc/modules-load.d/modules.conf) are active after bootup. Having no idea of systemd so far, I looked up a few manpages. This quote from the manpage systemd-modules-load.service(8) caught my attention: systemd-modules-load.service is an early-boot service that loads kernel modules from static configuration. So my guess was that with systemd the modules listed in /etc/modules must be available from the initial ramdisk. To verify if this is the case, I added the radeon module to the initial ramdisk: # echo radeon >> /etc/initramfs-tools/modules # update-initramfs -u This change actually fixed the problem for me: After reboot the X server starts just fine and I get my graphical login back. But looking at the other modules in /etc/modules these actually get loaded even though they are not included in my initrd (except for the loop.ko module). Can anybody give me a hint what is going on here? This could be a upgrade problem for jessie as I am sure there are many systems out there that still load some modules by means of /etc/modules-load.d. Greetings, Torsten
Re: Point 1 of Social Contract
"IOhannes m zmölnig (Debian/GNU)" writes: ... > and please do stop top-posting... s/top-// pgpuflwoBqD8u.pgp Description: PGP signature
Re: Module from /etc/modules-load.d/modules.conf not loaded after systemd upgrade
On Tue, 2014-05-06 at 00:08 +0200, Torsten Landschoff wrote: > Hi all, > > my development system running unstable failed to start X server after > an dist-upgrade two days ago. > > After a bit of investigation I found out that the radeon module is not > loaded at bootup anymore. To get the graphical login back, the > following commands as root were needed: > # modprobe radeon > # systemctl restart kdm > Why radeon is not loaded at boot anymore is a mystery to me. All other > modules from /etc/modules (symlinked > as /etc/modules-load.d/modules.conf) are active after bootup. [...] radeon is normally auto-loaded by udev based on seeing a PCI device with a matching device ID. You should not need to add its name to any configuration file. I don't understand why you would put it in /etc/modules in the first place. Perhaps you have blacklisted radeon (for udev auto-loading) in some other module configuration file? Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
Hello, On Mon, May 5, 2014 at 3:29 AM, Matthias Urlichs wrote: > Hi, > > [snip] > > The second case is a no-brainer. Many packages in Debian consist of more > than one binary, of which you need at most one (if that). Do you really > want to mass-file a bug against all of these _and_ the packages depending > on them, or are you picking on systemd for non-technical reasons here? > > Sorry, but I suspect the latter. Please do not assume bad faith; I hold none. Best wishes, -- Cameron -- 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/CALZWFRLBb=fzCkmvzxURubQ0V2+bWQLbPcWifzFPak=96fx...@mail.gmail.com
Re: A question about patches for upstream
Le Mon, May 05, 2014 at 08:56:48PM +0200, Bas Wijnen a écrit : > > I'm happy to see that there is consensus anyway that forwarding bugs upstream > is the task of the maintainer. Hi all, being a package maintainer, I am always uncomfortable when I have the impression that I am considered like a human patch-pushing machine that extends the impact of mass-scale patch producers. Luckily it is not happening often, but please let's take a point of view that is less patch-centric and more human-centric. When the first mass rebuilds with GCC and porting issues came to Debian, I was very impressed. Years later it became a routine and I sometimes feel that I am pressed by a machine. There is not much apparent coordination with the other distributions (not our derivatives) that also conduce such large screens. Especially for the GCC updates, it sometimes happens that if I do nothing, Fedora will do the same screen, send patches Upstream and I will only have to package a new upstream release as usual. Why don't we start to share the workload ? It seems to be a race condition with a lot of duplicated work. Not to mention when Upstream himself follows the evolution of the toolchain. Can't we have a GCC foundation that takes care of this ? I will be happy to donate regularly. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140506010552.gb18...@falafel.plessy.net
Re: Bug#747070: ITP: apt-venv -- apt virtual environment
On Tue, May 6, 2014 at 12:57 AM, Leo Iannacone wrote: > It has been developed to provide user with a full virtual environment, > where you can run any command/script you want. > If fact, it launches a new `bash` session with a custom APT_CONFIG > environment variable, which forces apt to use a different > sources.list. chdist also sets APT_CONFIG, it doesn't however run bash but it would be trivial to add that. Some more similar things: http://modules.sourceforge.net/ (sets PATH/PYTHONPATH etc) https://packages.debian.org/sid/proot (fake chroot using ptrace) -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6Hzje+=earcbdz7nldgtsaiusedjqx3tbo8at6mifq...@mail.gmail.com
Re: Point 1 of Social Contract
Solal dijo [Mon, May 05, 2014 at 04:14:54PM +0200]: > >> I think we shouldn't support proprietary software creaters > > > > Who's 'we'? > > "We" in the official list of Debian developers means... The Debian > developers. So... Who are you? We¹ would like to know. ¹ "We" in the context of a mail with no further information means "three of my sock puppets and me". -- 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/20140506013050.ga77...@gwolf.org
Re: A question about patches for upstream
On Mon, May 5, 2014 at 6:05 PM, Charles Plessy wrote: > Le Mon, May 05, 2014 at 08:56:48PM +0200, Bas Wijnen a écrit : >> >> I'm happy to see that there is consensus anyway that forwarding bugs upstream >> is the task of the maintainer. > > Hi all, > > being a package maintainer, I am always uncomfortable when I have the > impression that I am considered like a human patch-pushing machine that > extends > the impact of mass-scale patch producers. Luckily it is not happening often, > but please let's take a point of view that is less patch-centric and more > human-centric. I am sorry if this was mentioned earlier in the conversation, but are you talking about a specific package here? Best, -- Cameron -- 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/CALZWFRLyGSHXfaA_mYdxCsV7cx7npnJtm=+bkdha7vfh9af...@mail.gmail.com
Re: Gerrit patch review, and gating (was: Call for help from KDE Team)
On 05/02/2014 06:17 PM, David Goodenough wrote: > On Friday 02 May 2014 11:32:41 Maximiliano Curia wrote: >> ¡Hola Paul! >> >> El 2014-05-02 a las 08:40 +0800, Paul Wise escribió: >>> On Fri, May 2, 2014 at 2:19 AM, Maximiliano Curia wrote: For quite a while now the KDE team has been severely understaffed. We maintain a lot of packages, with many different kinds of bugs, but we don't have enough people to do all the work that needs to be done. We have tools that help us automate the update to new upstream releases, but that's just the tip of the iceberg of our work and so we are writing to invite more people to get involved in the team and help us get KDE software in Debian into better shape.> >>> Have you invited the Kubuntu team to join you? I'll send a mail to the >>> other derivatives I can find that use KDE. >> >> We've invited the Kubuntu team to merge their efforts with ours and use the >> same packaging vcs. The answer was positive, although the migration is a bit >> too far in the future. They sort of agree that they could migrate from >> launchpad bzr to git.debian.org, but as they are a larger group they >> separate junior and senior developers, requiring a review for each junior >> commit, for which they have a workflow and systems in place that won't be >> directly usable in git.debian.org. so the idea is to keep in sync most of >> our work, and see if we can figure out a way to merge it. >> >> Which translates to some overhead and a larger TODO list than an immediate >> help, but sure, once certain threshold in time invested is reached, both >> Debian and Ubuntu could benefit from it. >> >> Happy hacking, > Sounds like a job for Gerrit. Currently not fully packages for Debian > but I understand there is work being done one it. There is a github > project at https://github.com/dnaeon/gerrit-debian which builds debs. > > David Someone starting a Debian package is a good idea, though IMO, it'd be nicer if gerrit could be properly packaged in Sid / Testing. Does anyone want to work on that? The above Debian package doesn't seem good after a quick look (for example, it build-depends on java6-runtime-headless which isn't in Sid anymore, depends on git-core instead of git, copyright file isn't right, etc.). If hands are raising for packaging gerrit and the necessary tools for building a gate, then I'd be happy to work on that as well (though I feel like I've got enough work with the packaging of OpenStack already, so my time would be unfortunately limited...). I've seen that the DSA are currently building an OpenStack cloud (using the new Icehouse packages). I'm not sure what will be its use, or what's the current plan, though it'd be a super nice idea to use it to setup Gerrit and some kinds of gating process (piuparts & adequate comes to mind of course). This could be for example used for spawning VMs to do some checkings of each git commit on Alioth, with Gerrit as a tool for a patch review process. 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/536850eb.70...@debian.org
