Re: Availability of Debian official cloud images from debian.org

[Chris Fordham]

+1 there. I already brought this up in the mailing list i.e. the ubuntu
distro of images.

On Fri, Mar 15, 2013 at 5:28 PM, Thomas Goirand  wrote:

> Hi,
>
> Multiple times, in the debian-cloud@l.d.o, we've came to the conclusion
> that Debian should be release images of the stable release (and probably
> testing as well) to be run in the cloud. I'm bringing this topic to
> -devel, as I'm convince it is a topic which should be debated with
> everyone in Debian.
>
> There is enough software in Debian itself which can support such images:
> - Openstack
> - Eucalyptus
> - XCP
> - etc.
>
> Currently, we have semi-official images which, thanks to the nice work
> of the people in debian-cl...@lists.debian.org, are uploaded to both AWS
> and Azure. While it's nice that we have these, and while I believe such
> initiatives should be encouraged and generalize to other hosting
> providers, it is now clear that we need a channel to be able to provide
> Debian cloud images.
>
> Please have a look to what they do at Ubuntu:
> https://cloud-images.ubuntu.com/releases/
>
> and more specifically, when you click on one of them:
> https://cloud-images.ubuntu.com/releases/precise/release/
>
> they provide both the images for all Ubuntu releases. Also, please
> notice that there are multiple format available:
> - .ovf, which is an open format
> - disk1.img qcow2 format: can be uploaded to Openstack, or booted
> directly using kvm, and many more
> - .img, +kernel and ramdisk: can be used on EC2, Eucalyptus, or Openstack
>
> Plus there are "links" to EC2 so that you can just launch such
> instances. [in debian.org, we should allow anyone to add information
> about Debian images in any company though, and not focus only on one
> major vendor, otherwise it is anti-competitive]
>
> So, put in simple words: we need something like this. Question is, where
> can this be uploaded? To me, cdimage.debian.org seem to be the natural
> place. Does it make sense to everyone else? Could we, in a near future,
> imagine having these images creation, included in the official release
> build process, together with the CDs, DVDs, etc.?
>
> Cheers,
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/5142bf77.3080...@debian.org
>
>


-- 
*Chris Fordham*
*Cloud Solutions Engineer*
RightScale Inc.
Direct: +61 2 9037 2780
US Callers: +1 805 243 0252
Cell: +61 423 003 417
Skype: chris.fordham.rs
Email: chris.ford...@rightscale.com

Availability of Debian official cloud images from debian.org

[Thomas Goirand]

Hi,

Multiple times, in the debian-cloud@l.d.o, we've came to the conclusion
that Debian should be release images of the stable release (and probably
testing as well) to be run in the cloud. I'm bringing this topic to
-devel, as I'm convince it is a topic which should be debated with
everyone in Debian.

There is enough software in Debian itself which can support such images:
- Openstack
- Eucalyptus
- XCP
- etc.

Currently, we have semi-official images which, thanks to the nice work
of the people in debian-cl...@lists.debian.org, are uploaded to both AWS
and Azure. While it's nice that we have these, and while I believe such
initiatives should be encouraged and generalize to other hosting
providers, it is now clear that we need a channel to be able to provide
Debian cloud images.

Please have a look to what they do at Ubuntu:
https://cloud-images.ubuntu.com/releases/

and more specifically, when you click on one of them:
https://cloud-images.ubuntu.com/releases/precise/release/

they provide both the images for all Ubuntu releases. Also, please
notice that there are multiple format available:
- .ovf, which is an open format
- disk1.img qcow2 format: can be uploaded to Openstack, or booted
directly using kvm, and many more
- .img, +kernel and ramdisk: can be used on EC2, Eucalyptus, or Openstack

Plus there are "links" to EC2 so that you can just launch such
instances. [in debian.org, we should allow anyone to add information
about Debian images in any company though, and not focus only on one
major vendor, otherwise it is anti-competitive]

So, put in simple words: we need something like this. Question is, where
can this be uploaded? To me, cdimage.debian.org seem to be the natural
place. Does it make sense to everyone else? Could we, in a near future,
imagine having these images creation, included in the official release
build process, together with the CDs, DVDs, etc.?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5142bf77.3080...@debian.org

Re: history transparency

[Philip Ashmore]

On 15/03/13 02:19, Dmitrijs Ledkovs wrote:

On 15 March 2013 00:56, Philip Ashmore  wrote:

On 09/02/12 08:58, Paul Wise wrote:


On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote:


I think Debian needs a way to be able to pick a point in history and
obtain
at least the versions + patches of all the source packages that would
have
been installed / available to reproduce the Debian system running on the
users machine at the time they reported the bug.

With more and more source packages becoming available under publicly
accessible version control, what needs to change in Debian to make this
possible?



Nothing, it already exists:

http://snapshot.debian.org/archive/debian/20091229T215155Z/


How do I work out which snapshot I have installed now?
I download from Sid.



Take the checksum of Packages from /var/lib/apt/lists and find a
matching one on snapshots.

Is there a web interface for that, or a script that can do this?


It will be close, but not everything.
A better way is to use apt-clone which will generate a more
comprehensive state tarball.


Is there a micro-version file that stores this information or is it a time
stamp on some file?



How would that help at all? Given that it will never know the set of
packages you have installed, or obsolete packages not-removed,
modified conffiles etc.

I get you, but I'm talking from a pbuilder or similar perspective.
If I run into a problem and a week later it's gone it would be nice to 
be able to tell what packages changed.


Backing up /var/lib/apt/lists would do it but then you would start 
backing it up all over the place, that's why a micro-version number 
would be better, just increment it every time new packages appear in 
snapshots.
It it were in its own file or available from lsb_release or similar then 
even better.



Regards,

Dmitrijs.


Cheers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5142a111.4020...@philipashmore.com

Re: adduser Pre-Depends for qemu-system-common

[Steve Langasek]

On Thu, Mar 14, 2013 at 10:28:23PM +0100, Jakub Wilk wrote:
> * Serge Hallyn , 2013-03-14, 14:58:
> >qemu-system-common installs a udev rules file which sets /dev/kvm
> >group to 'kvm'. Its postinst then adds a kvm group.  However udev
> >reads the new rules file as soon as it sees it, sees that group
> >kvm doesn't exist, and ignores that part of the rule (until
> >reboot, udev restart, or the rule is re-added, of course).

> >To fix this the kvm group should be created during preinst before
> >the udev rules file is unpacked. This requires adding adduser to
> >the Pre-Depends. vorlon warned me that any new pre-depends should
> >be discussed here first, so I'm emailing to ask - is this ok? Is
> >there a better way?

> IIRC, src:sane-backends uses setfacl(1) instead of changing the
> group. Not sure if that counts as "better".

setfacl or chgrp, it still needs to be handled in the udev rules; so
preferably, those udev rules would be the *only* place the device perms need
to be handled, and that means making sure the rules are valid at unpack
time.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: history transparency

[Dmitrijs Ledkovs]

On 15 March 2013 00:56, Philip Ashmore  wrote:
> On 09/02/12 08:58, Paul Wise wrote:
>>
>> On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote:
>>
>>> I think Debian needs a way to be able to pick a point in history and
>>> obtain
>>> at least the versions + patches of all the source packages that would
>>> have
>>> been installed / available to reproduce the Debian system running on the
>>> users machine at the time they reported the bug.
>>>
>>> With more and more source packages becoming available under publicly
>>> accessible version control, what needs to change in Debian to make this
>>> possible?
>>
>>
>> Nothing, it already exists:
>>
>> http://snapshot.debian.org/archive/debian/20091229T215155Z/
>
> How do I work out which snapshot I have installed now?
> I download from Sid.
>

Take the checksum of Packages from /var/lib/apt/lists and find a
matching one on snapshots.
It will be close, but not everything.
A better way is to use apt-clone which will generate a more
comprehensive state tarball.

> Is there a micro-version file that stores this information or is it a time
> stamp on some file?
>

How would that help at all? Given that it will never know the set of
packages you have installed, or obsolete packages not-removed,
modified conffiles etc.

Regards,

Dmitrijs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluhmbhhn+vlxjufhtdffrq3j9z2r9mx4w3phq3cnki6...@mail.gmail.com

Re: history transparency

[Philip Ashmore]

On 09/02/12 08:58, Paul Wise wrote:

On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote:


I think Debian needs a way to be able to pick a point in history and obtain
at least the versions + patches of all the source packages that would have
been installed / available to reproduce the Debian system running on the
users machine at the time they reported the bug.

With more and more source packages becoming available under publicly
accessible version control, what needs to change in Debian to make this
possible?


Nothing, it already exists:

http://snapshot.debian.org/archive/debian/20091229T215155Z/

How do I work out which snapshot I have installed now?
I download from Sid.

Is there a micro-version file that stores this information or is it a 
time stamp on some file?


Regards,
Philip


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514271a5.7010...@philipashmore.com

Work-needing packages report for Mar 15, 2013

[wnpp]

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: 496 (new: 5)
Total number of packages offered up for adoption: 142 (new: 0)
Total number of packages requested help for: 62 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cairo-clock (#702599), orphaned 6 days ago
 Description: analog clock drawn with vector-graphics
 Installations reported by Popcon: 491

   gwhere (#702596), orphaned 6 days ago
 Description: Removable media catalog manager
 Installations reported by Popcon: 115

   libcgi-untaint-perl (#702591), orphaned 6 days ago
 Description: process CGI input parameters
 Installations reported by Popcon: 202

   libcrypt-unixcrypt-perl (#702595), orphaned 6 days ago
 Description: Perl-only implementation of the crypt(3) function
 Installations reported by Popcon: 71

   libpostscript-simple-perl (#702594), orphaned 6 days ago
 Description: generating postscript files
 Installations reported by Popcon: 63

491 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 142 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1137 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 64084

   asymptote (#517342), requested 1476 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4209

   athcool (#278442), requested 3061 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 64

   balsa (#642906), requested 536 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 792

   bastille (#592137), requested 950 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 173

   cardstories (#624100), requested 689 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 8

   chromium-browser (#583826), requested 1019 days ago
 Description: Chromium browser
 Installations reported by Popcon: 12903

   cups (#532097), requested 1377 days ago
 Description: Common UNIX Printing System
 Installations reported by Popcon: 107490

   debtags (#567954), requested 1137 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2488

   doc-central (#566364), requested 1146 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 210

   fbcat (#565156), requested 1156 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 156

   flightgear (#487388), requested 1727 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 804

   freeipmi (#628062), requested 658 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 2289

   gnat-4.4 (#539633), requested 1794 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 2088

   gnat-gps (#496905), requested 1659 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 484

   gnokii (#677750), requested 271 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2192

   gnupg (#660685), requested 388 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 137010

   golang (#668870), requested 333 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 547

   gpa (#663405), requested 369 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 538

   gradle (#683666), requested 224 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 28

   grub2 (#248397), requested 3230 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 128494

   hfsprogs (#557892), requested 1205 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1342

   horde4 (#686007), requested 199 days ag

Re: adduser Pre-Depends for qemu-system-common

[Steve Langasek]

On Thu, Mar 14, 2013 at 10:59:42PM +0100, Michael Biebl wrote:
> On 14.03.2013 22:30, Serge Hallyn wrote:
> > Quoting Michael Biebl (bi...@debian.org):
> >> On 14.03.2013 22:15, Ansgar Burchardt wrote:
> >>> Hi,

> >>> Serge Hallyn  writes:
>  qemu-system-common installs a udev rules file which sets /dev/kvm group
>  to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
>  new rules file as soon as it sees it, sees that group kvm doesn't
>  exist, and ignores that part of the rule (until reboot, udev restart,
>  or the rule is re-added, of course).

> >>> Couldn't postint tell udev explicitly to reload rules after the kvm
> >>> group was added? The init script has a reload action which calls
> >>> udevadm control --reload-rules which might do the right thing.

> >> I'd probably just do an explicit chown/chmod /dev/kvm (given the device
> >> exists) in postinst.

> > That is not sufficient.  If something else does udevadm trigger, udev
> > will re-label /dev/kvm with the old group perms.

> Nothing should run udevadm trigger, at least not without being specific
> to a subsystem. If a package is doing that, it's buggy.

The relevant subsystem for kvm is "misc", which could be triggered by any
number of arbitrary packages.  A solution that happens to work /unless/ some
other package gets installed that uses the same kernel subsystem isn't very
robust.  I think it's important to ensure that, by the time the package is
in state 'installed', the udev db is in a consistent state.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#703075: ITP: ruby-backports -- backports of new features for older versions of Ruby

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 

* Package name: ruby-backports
  Version : 3.1.1
  Upstream Author : Marc-Andre Lafortune
* URL : https://github.com/marcandre/backports
* License : Expat
  Programming Lang: Ruby
  Description : backports of new features for older versions of Ruby

This Ruby library contains essential backports that enable many of the
nice features of Ruby 1.8.7 up to 2.0.0 for earlier versions.

Features are backported with the following limitations:
 - will not break older code,
 - can be implemented in pure Ruby (no C extensions),
 - must pass RubySpec.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: adduser Pre-Depends for qemu-system-common

[Florian Weimer]

* Ansgar Burchardt:

> Couldn't postint tell udev explicitly to reload rules after the kvm
> group was added?

udev does not support this:



(The discussion extends into February 2013.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hakdy4y0@mid.deneb.enyo.de

Re: adduser Pre-Depends for qemu-system-common

[Michael Biebl]

On 14.03.2013 22:30, Serge Hallyn wrote:
> Quoting Michael Biebl (bi...@debian.org):
>> On 14.03.2013 22:15, Ansgar Burchardt wrote:
>>> Hi,
>>>
>>> Serge Hallyn  writes:
 qemu-system-common installs a udev rules file which sets /dev/kvm group
 to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
 new rules file as soon as it sees it, sees that group kvm doesn't
 exist, and ignores that part of the rule (until reboot, udev restart,
 or the rule is re-added, of course).
>>>
>>> Couldn't postint tell udev explicitly to reload rules after the kvm
>>> group was added? The init script has a reload action which calls
>>> udevadm control --reload-rules which might do the right thing.
>>
>> I'd probably just do an explicit chown/chmod /dev/kvm (given the device
>> exists) in postinst.
> 
> That is not sufficient.  If something else does udevadm trigger, udev
> will re-label /dev/kvm with the old group perms.

Nothing should run udevadm trigger, at least not without being specific
to a subsystem. If a package is doing that, it's buggy.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adduser Pre-Depends for qemu-system-common

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> On 14.03.2013 22:15, Ansgar Burchardt wrote:
> > Hi,
> > 
> > Serge Hallyn  writes:
> >> qemu-system-common installs a udev rules file which sets /dev/kvm group
> >> to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
> >> new rules file as soon as it sees it, sees that group kvm doesn't
> >> exist, and ignores that part of the rule (until reboot, udev restart,
> >> or the rule is re-added, of course).
> > 
> > Couldn't postint tell udev explicitly to reload rules after the kvm
> > group was added? The init script has a reload action which calls
> > udevadm control --reload-rules which might do the right thing.
> 
> I'd probably just do an explicit chown/chmod /dev/kvm (given the device
> exists) in postinst.

That is not sufficient.  If something else does udevadm trigger, udev
will re-label /dev/kvm with the old group perms.

-serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130314213030.GA6605@sergelap

Re: adduser Pre-Depends for qemu-system-common

[Wookey]

+++ Serge Hallyn [2013-03-14 14:58 -0500]:
> Hi,
> 
 
> To fix this the kvm group should be created during preinst before the
> udev rules file is unpacked.  This requires adding adduser to the
> Pre-Depends.  vorlon warned me that any new pre-depends should be
> discussed here first, so I'm emailing to ask - is this ok?  Is there
> a better way?

I don't know if there is a better way in this particular case but I do
know that adding users in preinsts does cause problems. Preinsts that
do anything important (which is not dealing with upgrades from
previous packages) cause issues for cross-arch rootfs generation,
where the system has to be booted before preinsts can be run. Mysql,
for example, creates its user in the preinst and this breaks if you
create a foreign-arch rootfs with multistrap containing mysql. I find
it hard to imagine why this necessary, but I assume someone had a good
reason. 

Making sure that the user/group is _also_ created in the postinst if
it's not already been done would make everything work nicely from my
POV. Avoiding doing such things in preinsts at all is good if possible. . 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130314214317.gf20...@stoneboat.aleph1.co.uk

Bug#703068: ITP: ruby-sinatra-contrib -- collection of useful extensions to the Sinatra web framework

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérmy Bobbio 

* Package name: ruby-sinatra-contrib
  Version : 1.3.2
  Upstream Author : Nicolas Sanguinetti, entp.com, Konstantin Haase
* URL : https://github.com/sinatra/sinatra-contrib
* License : Expat
  Programming Lang: Ruby
  Description : collection of useful extensions to the Sinatra web framework

sinatra-contrib is a collection of common extensions to the Sinatra web
framework, semi-officially supported:
 - capture: Let's you capture the content of blocks in templates.
 - config_file: Allows loading configuration from yaml files.
 - content_for: Adds Rails-style content_for helpers to Haml, Erb,
   Erubis and Slim.
 - cookies: A cookies helper for reading and writing cookies.
 - engine_tracking: Adds methods like haml? that allow helper methods
   to check whether they are called from within a template.
 - json: Adds a #json helper method to return JSON documents.
 - link_header: Helpers for generating link HTML tags and
   corresponding Link HTTP headers. Adds link, stylesheet and prefetch helper
   methods.
 - multi_route: Adds ability to define one route block for multiple
   routes and multiple or custom HTTP verbs.
 - namespace: Adds namespace support to Sinatra.
 - respond_with: Choose action and/or template automatically depending
   on the incoming request. Adds helpers respond_to and respond_with.
 - decompile: Recreates path patterns from Sinatra's internal data
   structures (used by other extensions).
 - reloader: Automatically reloads Ruby files on code changes.
 - extension: Mixin for writing your own Sinatra extensions.
 - test_helpers: Helper methods to ease testing your Sinatra
   application. Partly extracted from Sinatra. Testing framework agnostic.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: adduser Pre-Depends for qemu-system-common

[Jakub Wilk]

* Serge Hallyn , 2013-03-14, 14:58:
qemu-system-common installs a udev rules file which sets /dev/kvm group 
to 'kvm'. Its postinst then adds a kvm group.  However udev reads the 
new rules file as soon as it sees it, sees that group kvm doesn't 
exist, and ignores that part of the rule (until reboot, udev restart, 
or the rule is re-added, of course).


To fix this the kvm group should be created during preinst before the 
udev rules file is unpacked. This requires adding adduser to the 
Pre-Depends. vorlon warned me that any new pre-depends should be 
discussed here first, so I'm emailing to ask - is this ok? Is there a 
better way?


IIRC, src:sane-backends uses setfacl(1) instead of changing the group. 
Not sure if that counts as "better".


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130314212823.ga4...@jwilk.net

Re: adduser Pre-Depends for qemu-system-common

[Michael Biebl]

On 14.03.2013 22:15, Ansgar Burchardt wrote:
> Hi,
> 
> Serge Hallyn  writes:
>> qemu-system-common installs a udev rules file which sets /dev/kvm group
>> to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
>> new rules file as soon as it sees it, sees that group kvm doesn't
>> exist, and ignores that part of the rule (until reboot, udev restart,
>> or the rule is re-added, of course).
> 
> Couldn't postint tell udev explicitly to reload rules after the kvm
> group was added? The init script has a reload action which calls
> udevadm control --reload-rules which might do the right thing.

I'd probably just do an explicit chown/chmod /dev/kvm (given the device
exists) in postinst.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adduser Pre-Depends for qemu-system-common

[Ansgar Burchardt]

Hi,

Serge Hallyn  writes:
> qemu-system-common installs a udev rules file which sets /dev/kvm group
> to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
> new rules file as soon as it sees it, sees that group kvm doesn't
> exist, and ignores that part of the rule (until reboot, udev restart,
> or the rule is re-added, of course).

Couldn't postint tell udev explicitly to reload rules after the kvm
group was added? The init script has a reload action which calls
udevadm control --reload-rules which might do the right thing.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9q5vg2n@deep-thought.43-1.org

Re: adduser Pre-Depends for qemu-system-common

[Steve Langasek]

On Thu, Mar 14, 2013 at 02:58:24PM -0500, Serge Hallyn wrote:
> qemu-system-common installs a udev rules file which sets /dev/kvm group
> to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
> new rules file as soon as it sees it, sees that group kvm doesn't
> exist, and ignores that part of the rule (until reboot, udev restart,
> or the rule is re-added, of course).

> To fix this the kvm group should be created during preinst before the
> udev rules file is unpacked.  This requires adding adduser to the
> Pre-Depends.  vorlon warned me that any new pre-depends should be
> discussed here first, so I'm emailing to ask - is this ok?  Is there
> a better way?

FWIW, my own analysis is that this looks fine; qemu-system-common is nothing
approaching a core package, and adduser is already one of the most common
Pre-Dependencies in the archive (32 packages in unstable; the only more
common pre-deps seem to be multiarch-support, and dpkg).  So I think this is
a clear cut legitimate use of a Pre-Depends, but of course this should still
get other eyeballs on it in case I've missed something.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#703065: ITP: libjs-mousetrap -- simple library for handling keyboard shortcuts in Javascript

[Zed Pobre]

Package: wnpp
Severity: wishlist
Owner: Zed Pobre 


* Package name: libjs-mousetrap
  Version : 1.3
  Upstream Author : Craig Campbell
* URL : http://craig.is/killing/mice
* License : Apache
  Programming Lang: Javascript
  Description : simple library for handling keyboard shortcuts in Javascript

 There are no external dependencies, no framework is required
 .
 You are not limited to keydown events
 (You can specify keypress, keydown, or keyup or let Mousetrap choose
 for you).
 .
 You can bind key events directly to special keys such as ? or * without
 having to specify shift+/ or shift+8 which are not consistent across all
 keyboards
 .
 It works with international keyboard layouts
 .
 You can bind Gmail like key sequences in addition to regular keys and
 key combinations
 .
 You can programatically trigger key events with the trigger() method
 .
 It works with the numeric keypad on your keyboard


There is no upstream tarball for this package; it will be built from
the Github repository at https://github.com/ccampbell/mousetrap

The source package is being renamed to mousetrap.js, per instructions
at http://wiki.debian.org/Javascript/Policy


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130314203746.26693.94437.report...@moebius.resonant.org

adduser Pre-Depends for qemu-system-common

[Serge Hallyn]

Hi,

qemu-system-common installs a udev rules file which sets /dev/kvm group
to 'kvm'.  Its postinst then adds a kvm group.  However udev reads the
new rules file as soon as it sees it, sees that group kvm doesn't
exist, and ignores that part of the rule (until reboot, udev restart,
or the rule is re-added, of course).

To fix this the kvm group should be created during preinst before the
udev rules file is unpacked.  This requires adding adduser to the
Pre-Depends.  vorlon warned me that any new pre-depends should be
discussed here first, so I'm emailing to ask - is this ok?  Is there
a better way?

thanks,
-serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130314195824.GA21222@sergelap

Bug#703060: ITP: i7z -- a better reporting tool for i7, i5, i3 CPUs

[Andreas Beckmann]

Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann 

* Package name: i7z
  Version : 0.27.1
  Upstream Author : Abhishek Jaiantilal (abhishek.jaiantilal (@@) colorado.edu) 
* URL : http://code.google.com/p/i7z/
* License : GPL2, GPL3
  Programming Lang: C, Ruby
  Description : a better reporting tool for i7, i5, i3 CPUs

i7z is a tool to report CPU information about TurboBoost, frequencies,
multipliers, ... and a top-like display for the current frequency,
temperature and time spent in the C0/C1/C3/C6/C7 states.

There is also a i7z_rw_registers script that allows toggling Turbo mode
or set multipliers.

It comes wiht a GUI (written in QT), but that has not been updated for
SandyBridge/IviBridge CPUs.

I plan to put the packaging into collab-maint. Or is there a team that
would like to include that package under its umbrella?


Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130314191233.22735.53241.report...@cake.ae.cs.uni-frankfurt.de

Bug#703029: ITP: newsblur -- Social news reader with intelligence

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: newsblur
  Version : 
  Upstream Author : Samuel Clay 
* URL : https://github.com/samuelclay/NewsBlur
* License : MIT
  Programming Lang: Python, jQuery etc.
  Description : A visual feed reader with intelligence

NewsBlur is visual feed reader with following features:

 * Shows the original site.
 * Hides stories you don't want to read based on tags, keywords, authors, etc.
 * Highlights stories you want to read, based on the same criteria.

--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: Digital signature