date:20130401

On Sun, 31 Mar 2013 17:45:15 -0500
Dirk Eddelbuettel e...@debian.org wrote:

 On 1 April 2013 at 00:16, Josselin Mouette wrote:
 | I don’t understand how you can say it “worked before”.
 | Let’s say you backport a R package from wheezy to squeeze (something we
 | tried recently at work). The new R will install without a dependency
 | problem, and… all modules will stop working.
 | 
 |  Testing is fine, but within unstable the transition has to be done.
 | 
 | Testing is not fine. The new R version could migrate to testing without
 
 Not if we blocked it. That's what I was trying to suggest.

So you are relying on the release process to provide the block?

Having the new version in unstable is much more likely to cause
problems with backports as other packages will change to match the new
API and then need those changes undone to be backportable.

 r-base_3.0.0~20130330 is one day old, there should be a new r-base_3.0.0-1 
 come
 April 3. 

... or an epoch could be used to put unstable back to what is in
testing and 3.0.0 could go into experimental, introducing the maximum
version limitation and API versioning at the same time.

 | There are reasons why other interpreters have complex dependency
 | schemes: previously to avoid that. Not only your reverse dependencies
 | should only depend on the *sufficient* version of R (in this case,
 | certainly not the R version used to compile the package, which will lead
 | to transition blockades to testing), but they should stop installing
 | when the version of R becomes incompatible, and so far nothing
 | guarantees that.
 | 
 | Perl has a perlapi-X.Y virtual package to avoid that.
 | Python generates python ( X.Y) dependencies to avoid that.
 | There are tons of similar schemes used across the Debian archive to
 | avoid such problems, from virtual packages, through autogenerated
 | dependencies, to package renames.
 | 
 | It’s OK if you don’t know the best way to do that for your package. This
 
 We did not need for the previous 15 years that R has been part of Debian. 

How many R transitions have been done during a release freeze?

How many at this perilously late stage of a release freeze?

A lot of things can be done early in a release freeze and only cause a
slight delay, if any. It is simply not possible to handle API changes
in unstable at this stage of a release without *directly* delaying that
release. The discussion of the rebuild request alone has required the
attention of people from the FTP team, wanna-build team, release team
and other DD's actively working on the release.

Just because it hasn't caused a big discussion before doesn't mean that
it wasn't a problem, just that it wasn't a big enough problem for lots
of people to get involved.

 If
 the release team strongly insists that I ought to add this, I can.  It has
 not been needed before.
 
 And Perl is an odd example as there are multiple APIs / versions used in
 parallel. We don't usually do that with R.

Unstable now has a different API and version to testing, yes?

Testing has a different API to stable (squeeze)? (I'm not sure)

Wheezy will definitely have a different API to Jessie, so backporters
will clearly need this kind of API version support.

Looks like multiple APIs / versions are inevitable, block or no block.

If multiple APIs / versions are never going to happen, then the API
version support can be avoided. If there is any situation (i.e. as now)
where multiple versions are desirable from your perspective (clearly not
desirable from the release perspective, right now) then your own
requirements mandate a change.

Personally, I agree with Josselin - R looks like it needs precisely the
same kind of API version limits as python or perl. Packages built for
the old API must not allow installation of a version of the interpreter
which breaks the API required by those packages until those packages
have been rebuilt and have a dependency suitable for the new API.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgphRKULOC8qq.pgp
Description: PGP signature

Re: [Debian-uk] dak-roulette activated

2013-04-01 Thread Roger Gammans

On Mon, 2013-04-01 at 01:05 -0700, Steve Langasek wrote:
 On Mon, Apr 01, 2013 at 01:07:32AM +0100, Jonathan Wiltshire wrote:
  The residents of #debian-uk are pleased to announce that, in conjunction 
  with
  our friendly FTP masters, dak-roulette has just been activated in cron on
  ftp-master.debian.org targetting unstable and no particular maintainer.
 
  I enclose the documentation for your reference.
 
 This seems to be a misnomer.  The documentation makes it clear that it's
 based on Russian roulette, not on roulette the casino game;

That's a minor issue, are we sure the case when it shoots itself has
been fully tested? 

-- 
Roger Gammans rgamm...@gammascience.co.uk


--
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/1364804964.3203.0.ca...@agatha.computer-surgery.co.uk

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Samuel Thibault

Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
 Distributions that make latest
 software available are necessary for free software development.

Again, that's one of the things experimental is for.

Samuel


-- 
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/20130401094710.gx17...@type.youpi.perso.aquilenet.fr

missing libgl1-mesa-dri in upgrades




I've found that some default packages in Gnome are broken if
libgl1-mesa-dri is not installed

libgl1-mesa-dri is only installed on upgrade if the package xorg is
present in squeeze, but that is not always the case according to popcon:

http://qa.debian.org/popcon.php?package=xorg

   xserver-xorg 75034

   xorg 64738


So 1 in 7 upgrades will potentially find things that just don't work in
the desktop (things that did work in squeeze), and they have to go to a
terminal to start investigating what is wrong (which is OK for some of
us, but should be avoided)

While I've filed a bug against empathy (that is where I observed the
problem), I suspect other packages are impacted and the issue may need
to be fixed at some other level.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704257


-- 
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/51595a90.5060...@pocock.com.au

Re: [Debian-uk] dak-roulette activated

On Mon, 01 Apr 2013 21:29:24 +1300
Roger Gammans rgamm...@gammascience.co.uk wrote:

 On Mon, 2013-04-01 at 01:05 -0700, Steve Langasek wrote:
  On Mon, Apr 01, 2013 at 01:07:32AM +0100, Jonathan Wiltshire wrote:
   The residents of #debian-uk are pleased to announce that, in conjunction 
   with
   our friendly FTP masters, dak-roulette has just been activated in cron on
   ftp-master.debian.org targetting unstable and no particular maintainer.
  
   I enclose the documentation for your reference.
  
  This seems to be a misnomer.  The documentation makes it clear that it's
  based on Russian roulette, not on roulette the casino game;
 
 That's a minor issue, are we sure the case when it shoots itself has
 been fully tested? 

That's easy, this isn't a package, so cannot be removed by dak.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpcfA8DI6zcW.pgp
Description: PGP signature

Re: [Debian-uk] dak-roulette activated

2013-04-01 Thread Kartik Mistry

On Mon, Apr 1, 2013 at 3:40 PM, Neil Williams codeh...@debian.org wrote:
 That's a minor issue, are we sure the case when it shoots itself has
 been fully tested?

 That's easy, this isn't a package, so cannot be removed by dak.

Can be packaged. Who owns ITP of it? :)

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


-- 
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/CAPDygeyYjv=BBer5YkuRo=w-g08d2cdwatpiab3111tessn...@mail.gmail.com

Re: dak-roulette activated

2013-04-01 Thread Christian PERRIER

Quoting Ansgar Burchardt (ans...@debian.org):
 Scott Kitterman deb...@kitterman.com writes:
  Excellent.  What's the interval on the cron runs?  If we get lucky, this 
  could 
  get us to a release really soon.
 
 While britney still removes packages from testing that are no longer in
 unstable, it only does so when this doesn't make (other) packages in
 testing uninstallable.

There could be a --recursive option implemented so that revese
dependencies are also removed. I'm pondering a wishlist bug report for this.



signature.asc
Description: Digital signature

Re: [Debian-uk] dak-roulette activated

2013-04-01 Thread Paul Martin

On Mon, Apr 01, 2013 at 01:05:06AM -0700, Steve Langasek wrote:
 On Mon, Apr 01, 2013 at 01:07:32AM +0100, Jonathan Wiltshire wrote:
  The residents of #debian-uk are pleased to announce that, in conjunction 
  with
  our friendly FTP masters, dak-roulette has just been activated in cron on
  ftp-master.debian.org targetting unstable and no particular maintainer.
 
  I enclose the documentation for your reference.
 
 This seems to be a misnomer.  The documentation makes it clear that it's
 based on Russian roulette, not on roulette the casino game; dak-roulette
 is as a result misleading, we should find a better name for this.
 
 How about dak-svidanya?

More to the point, this far into freeze such packages should only ever
be uploaded to the existential repository.

-- 
Paul Martin p...@debian.org


signature.asc
Description: Digital signature

Re: dak-roulette activated

2013-04-01 Thread Enrico Zini

On Sun, Mar 31, 2013 at 07:15:39PM -0600, Gunnar Wolf wrote:

 In order to get the release timing for Debian to fit in just one CD
 under such construction, I suggest you take the average size of
 packages and multiply it by the space we need to save. Then we can run
 a contest similar to Christian Perrier's bug #x0.

There could be an alternative way to look at the problem: if we shoot at
random in the archive, larger packages should be easier to hit.

dak-roulette should have an option to weight hit probability according
to package size. That'll make it much faster to converge to fit into one
CD again, and provide a good incentive for people to spend time
optimizing their packages to make them appropriately inconspicuous.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.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/20130401103318.ga27...@enricozini.org

Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Andrey Rahmatullin

On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
  Thanks for trading the R release cycle with Debian's and for
  delaying the release. The harm has already been done, so somebody
  should probably go and create a transition tracker for it?
 
 Rather than accept the harm, surely the release team could simply roll
 back the upload in some manner?
Only by uploading older versions with bumped version numbers, and that
still will cause testing and unstable to have different binaries.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Uoti Urpala

Samuel Thibault wrote:
 Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
  Distributions that make latest
  software available are necessary for free software development.
 
 Again, that's one of the things experimental is for.

It is not. You can't reasonably install things from experimental rather
than unstable by default, nor is there a flag for this really should be
in unstable if not for badly managed release which would allow
autoinstalling those packages. Consider the GDB example I mentioned
earlier; GDB 4.5 should be installed by default for users of unstable,
rather than expecting them to notice that their system has become too
outdated, investigate it and find out which package to manually update.
It is unreasonable to tell the users and upstreams that Debian is going
to keep users on a known inferior version by default for a long time,
just in case more testing is needed to discover problems in the release
version (often in addition to multiple already discovered problems that
Debian is intentionally leaving for users to suffer from, as the most
natural way to fix them would be to update to a newer upstream version).

Also, many things don't get separately packaged in experimental, like
GDB 4.5 isn't (I don't know whether this particular case is due to
release or maintainer otherwise not keeping it up to date, but there are
lots of extra issues due to release, and most of them are unlikely to be
because of maintainer being too busy with other release work).




-- 
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/1364816331.1928.103.camel@glyph.nonexistent.invalid

[OT] Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Charles Plessy

Hi all,

while this thread may have the outcome of having Debian's R packages following
a similar convention as with the perl-api package (why not, it does not seem to
cost much), I hope that it is fairly clear for everyone that it will not change
how we release or how we use experimental: this part of the thread is chatting,
not focusing on getting something achieved.

So please, let's use debian-devel for real attempts at developing Debian, not
for chatting, however interseting it may be to those who do not mind reading
long threads.

Cheers,

-- 
Charles Plessy
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: http://lists.debian.org/20130401120708.ge5...@falafel.plessy.net

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 17:42:29 +0600
Andrey Rahmatullin w...@wrar.name wrote:

 On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
   Thanks for trading the R release cycle with Debian's and for
   delaying the release. The harm has already been done, so somebody
   should probably go and create a transition tracker for it?
  
  Rather than accept the harm, surely the release team could simply roll
  back the upload in some manner?
 Only by uploading older versions with bumped version numbers, and that
 still will cause testing and unstable to have different binaries.

That is why we have epochs - an epoch is ignored for the purposes of
the binary packages, see zlib1g and other packages using epochs. The
existing tools have sane support for epochs, exactly to avoid these
problems.

http://packages.debian.org/sid/zlib1g
1:1.2.7.dfsg-13

http://ftp.uk.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb

dpkg -l | grep ':'

The version currently in wheezy could be re-uploaded with a single
change to the changelog to start using an epoch and using the version
string currently in wheezy for the post-epoch string of the new version.

If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of
1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible
with 1.2.3-1 already in wheezy.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpvkRP8x0Dof.pgp
Description: PGP signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Wouter Verhelst

On 01-04-13 13:38, Uoti Urpala wrote:
 Samuel Thibault wrote:
 Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
 Distributions that make latest
 software available are necessary for free software development.

 Again, that's one of the things experimental is for.
 
 It is not. You can't reasonably install things from experimental rather
 than unstable by default,

Of course you can. Just add a file to /etc/apt/preferences.d that says

Package: *
Pin: release a=experimental
Pin-Priority: 500

and packages will be pulled from experimental by default. Whether you'd
want that is a different matter, of course.

 nor is there a flag for this really should be
 in unstable if not for badly managed release which would allow
 autoinstalling those packages. Consider the GDB example I mentioned
 earlier; GDB 4.5 should be installed by default for users of unstable,
 rather than expecting them to notice that their system has become too
 outdated, investigate it and find out which package to manually update.
 It is unreasonable to tell the users and upstreams that Debian is going
 to keep users on a known inferior version by default for a long time,

No, that is not unreasonable. It is unreasonable to expect Debian will
see the latest and greatest of everything at any given time. That is not
our way. That's not to say that distributions which do such a thing are
useless, or that their developers are idiots. They just have a different
focus.

You'll also see that once the freeze is over, newer versions will be
uploaded, and this problem will be gone.

-- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.


-- 
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/51597b8c.40...@uter.be

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Neil McGovern

On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
 It is not. You can't reasonably install things from experimental rather
 than unstable by default, nor is there a flag for this really should be
 in unstable if not for badly managed release

I'm getting rather annoyed by this accusations of a badly managed
release, and the continual diatrade from yourself blaming me and the
rest of the release team.

 It is unreasonable to tell the users and upstreams that Debian is
 going to keep users on a known inferior version by default for a long
 time, just in case more testing is needed to discover problems in the
 release version (often in addition to multiple already discovered
 problems that Debian is intentionally leaving for users to suffer
 from, as the most natural way to fix them would be to update to a
 newer upstream version).
 

You may consider it most natural, the rest of the project values
stability and not introducing untested new features. Perhaps you may
feel more at home in a different distribution which aligns with your
priorities more.

As it happens, I'm currently canvassing a release weekend when everyone
who needs to do work on the day can make it. Messages such as the above
do not help in any way, shape or form.

Neil


-- 
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/20130401120313.gm7...@halon.org.uk

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

Hi,

On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote:
 Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
  Distributions that make latest
  software available are necessary for free software development.
 
 Again, that's one of the things experimental is for.

Which does not work either with a (almost) non-processed NEW. New software
might need packaging changed and/or new libraries etc

Regards,

Rene


--
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/20130401122658.gb31...@rene-engelhard.de

Re: missing libgl1-mesa-dri in upgrades

2013-04-01 Thread John Paul Adrian Glaubitz


On 04/01/2013 11:59 AM, Daniel Pocock wrote:


I've found that some default packages in Gnome are broken if
libgl1-mesa-dri is not installed

(...)

While I've filed a bug against empathy (that is where I observed the
problem), I suspect other packages are impacted and the issue may need
to be fixed at some other level.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704257


Empathy itself does not required GL libraries to be installed:

glaubitz@znote-t60o:~$ objdump -p `which empathy` |grep NEEDED
  NEEDED   libenchant.so.1
  NEEDED   libcheese-gtk.so.21
  NEEDED   libebook-1.2.so.13
  NEEDED   libgeoclue.so.0
  NEEDED   libgeocode-glib.so.0
  NEEDED   libnm-glib.so.4
  NEEDED   libgudev-1.0.so.0
  NEEDED   libm.so.6
  NEEDED   libdbus-glib-1.so.2
  NEEDED   libfolks-telepathy.so.25
  NEEDED   libfolks.so.25
  NEEDED   libgee.so.2
  NEEDED   libgnome-keyring.so.0
  NEEDED   libgnutls.so.26
  NEEDED   libgstreamer-0.10.so.0
  NEEDED   libgthread-2.0.so.0
  NEEDED   libtelepathy-logger.so.2
  NEEDED   libtelepathy-glib.so.0
  NEEDED   libxml2.so.2
  NEEDED   libcanberra-gtk3.so.0
  NEEDED   libcanberra.so.0
  NEEDED   libnotify.so.4
  NEEDED   libwebkitgtk-3.0.so.0
  NEEDED   libchamplain-gtk-0.12.so.0
  NEEDED   libclutter-gtk-1.0.so.0
  NEEDED   libgtk-3.so.0
  NEEDED   libchamplain-0.12.so.0
  NEEDED   libclutter-1.0.so.0
  NEEDED   libgdk-3.so.0
  NEEDED   libX11.so.6
  NEEDED   libgio-2.0.so.0
  NEEDED   libgdk_pixbuf-2.0.so.0
  NEEDED   libpango-1.0.so.0
  NEEDED   libgobject-2.0.so.0
  NEEDED   libglib-2.0.so.0
  NEEDED   libpthread.so.0
  NEEDED   libc.so.6
glaubitz@znote-t60o:~$

However, Empathy depends on Clutter which itself requires an OpenGL 
implementation:


glaubitz@znote-t60o:~$ objdump -p 
/usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 |grep NEEDED

  NEEDED   libm.so.6
  NEEDED   libatk-1.0.so.0
  NEEDED   libcogl-pango.so.0
  NEEDED   libcogl.so.9
  NEEDED   libjson-glib-1.0.so.0
  NEEDED   libgio-2.0.so.0
  NEEDED   libgdk-3.so.0
  NEEDED   libpangocairo-1.0.so.0
  NEEDED   libgdk_pixbuf-2.0.so.0
  NEEDED   libcairo-gobject.so.2
  NEEDED   libcairo.so.2
  NEEDED   libX11.so.6
  NEEDED   libXext.so.6
  NEEDED   libXdamage.so.1
  NEEDED   libXfixes.so.3
  NEEDED   libXcomposite.so.1
  NEEDED   libXi.so.6
  NEEDED   libpangoft2-1.0.so.0
  NEEDED   libpango-1.0.so.0
  NEEDED   libfreetype.so.6
  NEEDED   libfontconfig.so.1
  NEEDED   libgobject-2.0.so.0
  NEEDED   libgthread-2.0.so.0
  NEEDED   libgmodule-2.0.so.0
  NEEDED   librt.so.1
  NEEDED   libglib-2.0.so.0
  NEEDED   libpthread.so.0
  NEEDED   libc.so.6
glaubitz@znote-t60o:~$

Checking the depends of libclutter-1.0-0:

glaubitz@znote-t60o:~$ apt-cache depends libclutter-1.0-0 |head
libclutter-1.0-0
  Depends: libatk1.0-0
  Depends: libc6
  Depends: libcairo-gobject2
  Depends: libcairo2
  Depends: libcogl-pango0
  Depends: libcogl9
  Depends: libfontconfig1
  Depends: libfreetype6
  Depends: libgdk-pixbuf2.0-0
glaubitz@znote-t60o:~$

where you see a dependency on libcogl9 which in turn depends on MESA:

glaubitz@znote-t60o:~$ apt-cache depends libcogl9 |head
libcogl9
  Depends: libc6
  Depends: libgdk-pixbuf2.0-0
  Depends: libglib2.0-0
  Depends: libx11-6
  Depends: libxcomposite1
  Depends: libxdamage1
  Depends: libxext6
  Depends: libxfixes3
  Depends: libgl1-mesa-glx
glaubitz@znote-t60o:~$

So, whatever you do, don't mess around with Empathy. The bug, if any, is 
not in Empathy but any of its dependencies. I'd have a look at Clutter.


Also, have you tried running Empathy on a non-compositing window manager 
when libgl1-mesa-dri is not installed?


Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51597f74.6000...@physik.fu-berlin.de

Re: Splitting the devscripts package

2013-04-01 Thread Benjamin Drung

Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings:
 On Sat, 2013-03-30 at 22:49 +0100, Benjamin Drung wrote:
  Hi,
  
  devscripts ships a bunch of scripts to make the life of a Debian Package
  maintainer easier. Not every script in there is Debian packaging
  specific. Some of them are used on other non-Debian-based distributions.
  I was contacted [1] and asked if we could split the Debian packaging
  specific scripts from the rest.
  
  I like to keep only Debian packaging specific scripts in devscripts (see
  the list below). Where should we put the non Debian packaging specific
  scripts? Should we create a neutral project or are there other projects
  in which these scripts fit?
 
 There is no reason why Debian couldn't continue to be upstream for
 these, but hosting on freedesktop.org might make them more visible to
 other distributions.
 
 [...]
  Debian packaging specific scripts
  =
 [...]
 
 These might usefully be further divided into truly Debian-specific and
 dpkg/apt-specific, at least in binary packages.

What would this additional split give us as advantage? Are there
distributions that use dpkg/apt, but are not Debian derivatives?

-- 
Benjamin Drung
Debian  Ubuntu Developer


-- 
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/1364820113.3258.1.camel@deep-thought

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 14:26:58 +0200
Rene Engelhard r...@debian.org wrote:

 Hi,
 
 On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote:
  Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
   Distributions that make latest
   software available are necessary for free software development.
  
  Again, that's one of the things experimental is for.
 
 Which does not work either with a (almost) non-processed NEW. New software
 might need packaging changed and/or new libraries etc

... and those uploads go into experimental as well. What's wrong with that?

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpD1ZKeE6cUt.pgp
Description: PGP signature

Re: Splitting the devscripts package

2013-04-01 Thread Benjamin Drung

Am Sonntag, den 31.03.2013, 09:24 +0100 schrieb Lars Wirzenius:
 On Sat, Mar 30, 2013 at 10:49:18PM +0100, Benjamin Drung wrote:
  I like to keep only Debian packaging specific scripts in devscripts (see
  the list below). Where should we put the non Debian packaging specific
  scripts? Should we create a neutral project or are there other projects
  in which these scripts fit?
  
  Non Debian packaging specific scripts
  =
  
  annotate-output [2]
  archpath
  checkbashisms [2]
  licensecheck [2]
  manpage-alert [2]
  namecheck
  suspicious-source
  svnpath
 
 You could ask Joey Hess if they would fit into the moreutils package.

Thanks for this suggestion. annotate-output would fit perfectly into
moreutils, but I doubt that this applies for the other scripts. I filed
bug #704456 for including annotate-output.

-- 
Benjamin Drung
Debian  Ubuntu Developer


-- 
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/1364820872.3258.4.camel@deep-thought

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote:
 ... and those uploads go into experimental as well. What's wrong with that?

That non-processed NEW for packages which in turn is needed for other
packages to go to experimental for getting them tested blocks those packages
from being able to be uploaded/tested?

If the time then comes when this all works out itself either the package
gets delayed or it gets uploaded to unstable quite (it can be tested
in experimental for those who use/want it) untested.

(Or the packages itself being blocked, but that example was just uploaded
on Thursday just before easter, so I understand it not being processed yet.

Regards,

Rene


-- 
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/20130401125914.gc31...@rene-engelhard.de

Re: Splitting the devscripts package

2013-04-01 Thread Benjamin Drung

Am Sonntag, den 31.03.2013, 12:12 -0400 schrieb Michael Gilbert:
 On Sun, Mar 31, 2013 at 11:56 AM, Wookey wrote:
  +++ Benjamin Drung [2013-03-30 22:49 +0100]:
  Hi,
 
  devscripts ships a bunch of scripts to make the life of a Debian Package
  maintainer easier. Not every script in there is Debian packaging
  specific. Some of them are used on other non-Debian-based distributions.
 
  Whilst considering what scripts are where, there are some scripts in
  ubuntu-dev-tools which are not ubuntu-specific, and moving those
  somewhere more general (i.e. into devscripts) would be useful too.
  (I'm thinking particularly of mk-sbuild, but there are no doubt
  others).
 
 reverse-depends is quite useful.

We had a move of not ubuntu-specific script from ubuntu-dev-tools 0.124
to devscripts 2.11.0 two years ago. These scripts were add-patch,
edit-patch, suspicious-source, what-patch, and wrap-and-sort. Maybe it's
time to do it again.

We have Launchpad bug #846420 to move not Ubuntu packaging-specific
scripts out of ubuntu-dev-tools. The list currenlty looks like this:

mk-sbuild (should move into sbuild; Debian bug #613903)
pbuilder-dist (should move into pbuilder)
check-symbols (blocked by LP: #184906)
pull-debian-source (should work without Launchpad)
merge-changelog
reverse-depends

Is this list sensible? Is there something missing?

-- 
Benjamin Drung
Debian  Ubuntu Developer


-- 
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/1364821905.3258.10.camel@deep-thought

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 14:59:14 +0200
Rene Engelhard r...@debian.org wrote:

 On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote:
  ... and those uploads go into experimental as well. What's wrong with that?
 
 That non-processed NEW for packages which in turn is needed for other
 packages to go to experimental for getting them tested blocks those packages
 from being able to be uploaded/tested?

NEW processing happens whether the new package is meant for unstable or
experimental. Whether the package is in unstable or experimental does
not change how that package gets tested. It can affect how that package
affects the release.

Having packages in experimental does not block the ability to test or
upload other packages which depend on functionality in those new
versions - you just need an appropriate setup, maybe a chroot.

Even if you think there are a few days between the time taken to process
NEW for experimental vs NEW for unstable, I've seen no evidence of that
and it's not as if a few days are really going to matter. (If it's that
critical, find a webhost running Debian and install reprepro.)

 If the time then comes when this all works out itself either the package
 gets delayed or it gets uploaded to unstable quite (it can be tested
 in experimental for those who use/want it) untested.

Compared to going into unstable completely untested directly from
incoming? Packages don't go into testing directly from experimental,
freeze or no freeze.

Experimental packages get more testing than unstable, simply because
the package has to go through unstable after the release anyway. At
least the version you want tested is in the archive and it has no
bearing on the release.

During a release, maintainers need to take extra steps to not get in
the way of the release:

$ dch -D experimental -i the 'No RC bugs to fix' upload.

Secondary to that, maintainers may also need to run debootstrap and
manually tweak the apt config to pull in experimental as already
described here by others.

What's so hard about that with the R packages?

We are trying to release, that means that *everyone* has some extra
work to do either directly to help or at the absolute minimum to not get
in the way of those who are helping.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpO6qIjDxKSJ.pgp
Description: PGP signature

Re: dak-roulette activated

2013-04-01 Thread Thomas Goirand

On 04/01/2013 08:37 AM, Scott Kitterman wrote:
 Excellent.  What's the interval on the cron runs?  If we get lucky, this 
 could 
 get us to a release really soon.

 Scott K
My understanding is that such cron is set to run once a year,
at the same date as today... :)

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/51598c63.5050...@debian.org

Re: dak-roulette activated

2013-04-01 Thread Tollef Fog Heen

]] Enrico Zini 

 On Sun, Mar 31, 2013 at 07:15:39PM -0600, Gunnar Wolf wrote:
 
  In order to get the release timing for Debian to fit in just one CD
  under such construction, I suggest you take the average size of
  packages and multiply it by the space we need to save. Then we can run
  a contest similar to Christian Perrier's bug #x0.
 
 There could be an alternative way to look at the problem: if we shoot at
 random in the archive, larger packages should be easier to hit.

More popular packages might also be easier to hit, since there are more
copies of them floating around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m21uau8jd4@rahvafeir.err.no

Re: dak-roulette activated

2013-04-01 Thread Scott Kitterman

On Monday, April 01, 2013 09:32:19 PM Thomas Goirand wrote:
 On 04/01/2013 08:37 AM, Scott Kitterman wrote:
  Excellent.  What's the interval on the cron runs?  If we get lucky, this
  could get us to a release really soon.
  
  Scott K
 
 My understanding is that such cron is set to run once a year,
 at the same date as today... :)

Surely not.  That won't help much.  Probably the release team's fault.

Scott K


-- 
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/1891440.douZz24bDG@scott-latitude-e6320

Re: Splitting the devscripts package

2013-04-01 Thread David Kalnischkies

On Mon, Apr 1, 2013 at 2:41 PM, Benjamin Drung bdr...@debian.org wrote:
Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings:
On Sat, 2013-03-30 at 22:49 +0100, Benjamin Drung wrote:
Hi,

devscripts ships a bunch of scripts to make the life of a Debian Package
maintainer easier. Not every script in there is Debian packaging
specific. Some of them are used on other non-Debian-based distributions.
I was contacted [1] and asked if we could split the Debian packaging
specific scripts from the rest.

I like to keep only Debian packaging specific scripts in devscripts (see
the list below). Where should we put the non Debian packaging specific
scripts? Should we create a neutral project or are there other projects
in which these scripts fit?

There is no reason why Debian couldn't continue to be upstream for
these, but hosting on freedesktop.org might make them more visible to
other distributions.

[...]
Debian packaging specific scripts
=
[...]

These might usefully be further divided into truly Debian-specific and
dpkg/apt-specific, at least in binary packages.

What would this additional split give us as advantage? Are there
distributions that use dpkg/apt, but are not Debian derivatives?

There is apt-rpm which is a pre-0.6 apt fork used by some distributions
as their only supported package manager (the later according to wikipedia).
[version 0.6 marked the introduction of apt-secure … on Christmas 2003]

I have neither looked at the distributions nor at the scripts, so I have
no idea how (un)useful they will be and/or if they even work on apt 0.6.
I am just saying that APT presence is not limited to Debian derivatives …

Best regards

David Kalnischkies

--
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/CAAZ6_fAvAc72z==4j=tokann6tvrgs9bmsgczj-hnq5y8xf...@mail.gmail.com

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
 NEW processing happens whether the new package is meant for unstable or
 experimental. Whether the package is in unstable or experimental does

True.

 not change how that package gets tested. It can affect how that package
 affects the release.

Yes, also true.

 Having packages in experimental does not block the ability to test or
 upload other packages which depend on functionality in those new
 versions - you just need an appropriate setup, maybe a chroot.

Wrong. When I upload something which depends on a package which
isn't available this is uninstallable - useless.

And testing is not only local machine but testing in experimental.
(see above.) By *real usage*. (There have already been
upgrade bugs found by people using my packages in experimental)

 Even if you think there are a few days between the time taken to process
 NEW for experimental vs NEW for unstable, I've seen no evidence of that
 and it's not as if a few days are really going to matter. (If it's that
 critical, find a webhost running Debian and install reprepro.)

A few days? There's stuff there *for months*?

And yes, I do people.debian.org. That's not the same as experimental.
(E.g. builds on the majority of architectures will be untested.
People will not look there, etc.)

 What's so hard about that with the R packages?

Read and think again, please.

I am not caring about R and I am not defeinibg Direk. In contrast,
he should have known that he shouldn't upload.

I am telling about the general case.

That your simple toy packages are not affected by this because they don't
have as much r-deps as e.g. libreoffice. fine. But that doesn't make
the problem go non-existant.

Regards,

Rene


-- 
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/20130401134644.ge31...@rene-engelhard.de

Re: Splitting the devscripts package

2013-04-01 Thread Guillem Jover

On Mon, 2013-04-01 at 14:41:53 +0200, Benjamin Drung wrote:
 Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings:
  There is no reason why Debian couldn't continue to be upstream for
  these, but hosting on freedesktop.org might make them more visible to
  other distributions.
  
  [...]
   Debian packaging specific scripts
   =
  [...]
  
  These might usefully be further divided into truly Debian-specific and
  dpkg/apt-specific, at least in binary packages.
 
 What would this additional split give us as advantage? Are there
 distributions that use dpkg/apt, but are not Debian derivatives?

What David has said about apt applies to dpkg too. I know of at least
Mac OS X, iOS and Solaris distributions not based on Debian, dpkg also
has been used on say HP-UX systems. And there's of course non-Debian
based GNU/Linux systems like UHU-Linux (AFAIUI).

(If people know of others I'd be interested to hear to be able to
track dpkg downstreams: https://wiki.debian.org/Teams/Dpkg/Downstream.)

Thanks,
Guillem


-- 
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/20130401142652.ga20...@gaara.hadrons.org

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 15:46:44 +0200
Rene Engelhard r...@debian.org wrote:

 On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
  Having packages in experimental does not block the ability to test or
  upload other packages which depend on functionality in those new
  versions - you just need an appropriate setup, maybe a chroot.
 
 Wrong. When I upload something which depends on a package which
 isn't available this is uninstallable - useless.

It is installable from experimental if the local setup is correct. It's
only a change to apt sources and preferences, in a chroot if necessary.
How trivial do you want it?

All uploads not destined for wheezy go into experimental, all packages
in unstable and experimental are available for builds within
experimental. New stuff which would break things in unstable goes into
experimental. What's so hard about that?

It's not as if you're trying to mix Debian and Ubuntu using MultiArch
across three architectures to try and debug assembly code for a new
architecture for which there is currently no hardware... just for
example.

  Even if you think there are a few days between the time taken to process
  NEW for experimental vs NEW for unstable, I've seen no evidence of that
  and it's not as if a few days are really going to matter. (If it's that
  critical, find a webhost running Debian and install reprepro.)
 
 A few days? There's stuff there *for months*?

That's not my experience and hasn't been for a few years now. There
again, the FTP team are busy with the release too. Live with it or
find some way to help that team. Why should that excuse interrupting
the release team and making things *worse*?

  What's so hard about that with the R packages?
 
 Read and think again, please.

So there's nothing different in how R packages need to do this, so
there's no problem.
 
 I am not caring about R and I am not defeinibg Direk. In contrast,
 he should have known that he shouldn't upload.
 
 I am telling about the general case.
 
 That your simple toy packages are not affected by this because they don't
 have as much r-deps as e.g. libreoffice. fine. But that doesn't make
 the problem go non-existant.

I've worked on quite a few packages with this method over the years,
some core stuff like curl, cairo, ldap, cups, etc. and then there's all
the cross-build, multiarch stuff which is often dealing with toolchains
and low level libraries. Don't lecture me about rdeps and dismiss the
advice of your peers as the ramblings of fly-by-night maintainers of
toy packages. Everything related to R is a toy project to me, why
should your toy project interfere with my development time?

We're in the late stages of a release, that *requires* changes in how
your R packages are handled.

It requires some effort: yes
It requires a little thought: yes
It requires that you think about teams other than your own: YES!
It works: yes
It disturbs your workflow: yes - don't expect apologies for that.

Deal with it and don't expect everyone else to pick up the mess when
you can't be bothered to think of those working on the release or in
other teams who are also desperately trying to hold things together in
the hope that the release will happen *real soon* now and make our
lives easier too.

There are more people involved in this than your pet R project and
more than just the release team and the FTP team. Most of us are
quietly doing the right thing and using experimental or external
repositories but we're still getting the work done. Please, stop
getting in the way! It really isn't hard.

Just upload the epoch version to unstable to match testing, 1:3.0.0 to
experimental and move on. We've all wasted enough time on this already.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpGeao5XT9A8.pgp
Description: PGP signature

Community Outreach to other communities

2013-04-01 Thread Paul Tagliamonte

Ay yo, what up fellow ninjas,


Few days ago, I was smashin' some beers with the bro-skis[1] and we
were trying to figure out why there are so few bros in Debian.


We need to start a real Debian brobalization effort. I know it'll be
hard with all of us working bro-bono, but hopefully with some new
brocedures, we can avoid trouble and still appear to be a
brofessional organization.


This new broffensive will be a team-effort, and hopefully we can use
this to end the broppression in Debian.


I've attached a patch for apt to help us be more inclusive to this
critical market.


Outie 5000,
  taggs


[1]: http://people.debian.org/~paultag/uploads/dbl.jpg

-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag
diff -Nru apt-0.9.7.8/cmdline/apt-get.cc apt-0.9.7.8+nmu1/cmdline/apt-get.cc
--- apt-0.9.7.8/cmdline/apt-get.cc	2013-03-01 05:51:21.0 -0500
+++ apt-0.9.7.8+nmu1/cmdline/apt-get.cc	2013-03-24 17:37:21.0 -0400
@@ -3344,13 +3344,16 @@
 bool DoMoo(CommandLine CmdL)
 {
cout  
-   (__) \n
-   (oo) \n
- /--\\/ \n
-/ |||   \n 
-   *  /\\---/\\ \n
-  ~~   ~~   \n
-  \Have you mooed today?\...\n;
+_ _\n
+   (_\\___( \\,\n
+ )___   _  have you smashed some milk today?\n
+/( (_)-(_)/\n
+ ,-' \\_\n
+   //(  ',__,'  \\  (' ')\n
+  //  )  ''\n
+  '' ; \\ .--.  ,/\n
+ | )',_,'( ;\n
+ ||| ''' '||\n;
 			
return true;
 }
diff -Nru apt-0.9.7.8/debian/changelog apt-0.9.7.8+nmu1/debian/changelog
--- apt-0.9.7.8/debian/changelog	2013-03-14 03:14:09.0 -0400
+++ apt-0.9.7.8+nmu1/debian/changelog	2013-03-24 17:37:05.0 -0400
@@ -1,3 +1,10 @@
+apt (0.9.7.8+nmu1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Smashing down on some apt.
+
+ -- Paul Tagliamonte paul...@debian.org  Sun, 24 Mar 2013 17:36:58 -0400
+
 apt (0.9.7.8) unstable; urgency=criticial
 
   * SECURITY UPDATE: InRelease verification bypass


signature.asc
Description: Digital signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote:
 It is installable from experimental if the local setup is correct. It's
 only a change to apt sources and preferences, in a chroot if necessary.

This Debian. It is uninstallable there. And people (NOT ME!) can't install
it. Which is the point.

Or it even cannot be built.

It defeats the purpose of experimental when someone who want to use a package
from there need to go looking up some place where he can get the depencencies
from.

This is a RC bug the same way as it was in unstable or anywhere else.


 How trivial do you want it?

How much do you want to go against Debians policies?

  A few days? There's stuff there *for months*?
 
 That's not my experience and hasn't been for a few years now. There
 again, the FTP team are busy with the release too. Live with it or

Obviously you didn't even dare to look. I was not making this up:
http://ftp-master.debian.org/new.html

  I am not caring about R and I am not defeinibg Direk. In contrast,
^
  he should have known that he shouldn't upload.
^^
  
  I am telling about the general case.


 I've worked on quite a few packages with this method over the years,
 some core stuff like curl, cairo, ldap, cups, etc. and then there's all
 the cross-build, multiarch stuff which is often dealing with toolchains
 and low level libraries. Don't lecture me about rdeps and dismiss the

So you uploaded non-bbuildab le, non-installable packages to experimental?
Oh my.

For your own repoitories you were right, but this is about Debian
and it's distro.

 advice of your peers as the ramblings of fly-by-night maintainers of
 toy packages. Everything related to R is a toy project to me, why
 should your toy project interfere with my development time?
 
 We're in the late stages of a release, that *requires* changes in how
 your R packages are handled.
[..,]
 Just upload the epoch version to unstable to match testing, 1:3.0.0 to
 experimental and move on. We've all wasted enough time on this already.

Obviously you can't read (or you don't want to, which this is more
probable) but I am not talking abouut R but the general case.
I highlighted it above again for you.

Rgards,

Rene


-- 
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/20130401144226.gg31...@rene-engelhard.de

Re: Splitting the devscripts package

2013-04-01 Thread Ben Hutchings

On Mon, 2013-04-01 at 14:41 +0200, Benjamin Drung wrote:
 Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings:
  On Sat, 2013-03-30 at 22:49 +0100, Benjamin Drung wrote:
   Hi,
   
   devscripts ships a bunch of scripts to make the life of a Debian Package
   maintainer easier. Not every script in there is Debian packaging
   specific. Some of them are used on other non-Debian-based distributions.
   I was contacted [1] and asked if we could split the Debian packaging
   specific scripts from the rest.
   
   I like to keep only Debian packaging specific scripts in devscripts (see
   the list below). Where should we put the non Debian packaging specific
   scripts? Should we create a neutral project or are there other projects
   in which these scripts fit?
  
  There is no reason why Debian couldn't continue to be upstream for
  these, but hosting on freedesktop.org might make them more visible to
  other distributions.
  
  [...]
   Debian packaging specific scripts
   =
  [...]
  
  These might usefully be further divided into truly Debian-specific and
  dpkg/apt-specific, at least in binary packages.
 
 What would this additional split give us as advantage? Are there
 distributions that use dpkg/apt, but are not Debian derivatives?

Apparently there are, but aside from that: should a 'bts' command on
$DERIVATIVE interact with the Debian bug-tracking system, or the
$DERIVATIVE bug-tracking system?

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


signature.asc
Description: This is a digitally signed message part

Re: Community Outreach to other communities

2013-04-01 Thread Arno Töll

On 01.04.2013 16:41, Paul Tagliamonte wrote:
 diff -Nru apt-0.9.7.8/debian/changelog apt-0.9.7.8+nmu1/debian/changelog
 --- apt-0.9.7.8/debian/changelog  2013-03-14 03:14:09.0 -0400
 +++ apt-0.9.7.8+nmu1/debian/changelog 2013-03-24 17:37:05.0 -0400
 @@ -1,3 +1,10 @@
 +apt (0.9.7.8+nmu1) UNRELEASED; urgency=low
 ^

You missed something, didn't you? Otherwise, your patch looks fine!

Maybe you want to CC deity@l.d.o next time though when you plan to NMU
their package. :

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 15:36:35 +0100
Neil Williams codeh...@debian.org wrote:

 On Mon, 1 Apr 2013 15:46:44 +0200
 Rene Engelhard r...@debian.org wrote:

Apologies Rene, got you mixed up with Dirk re the R packages.

The bit about the epoch and the upload was intended for the R
maintainers.

  On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
  
  It is installable from experimental if the local setup is correct. It's
  only a change to apt sources and preferences, in a chroot if necessary.
  How trivial do you want it?
  
  All uploads not destined for wheezy go into experimental, all packages
  in unstable and experimental are available for builds within
  experimental. New stuff which would break things in unstable goes into
  experimental. What's so hard about that?

  I am telling about the general case.
  
  That your simple toy packages are not affected by this because they don't
  have as much r-deps as e.g. libreoffice. fine. But that doesn't make
  the problem go non-existant.

It may require a little preparation, yes, but it clearly does work.

 I've worked on quite a few packages with this method over the years,
 some core stuff like curl, cairo, ldap, cups, etc. and then there's all
 the cross-build, multiarch stuff which is often dealing with toolchains
 and low level libraries. Don't lecture me about rdeps and dismiss the
 advice of your peers as the ramblings of fly-by-night maintainers of
 toy packages.

I'm going to stop here before I dig myself an even bigger hole...

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpaEPNz8fGSR.pgp
Description: PGP signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Uoti Urpala

Neil McGovern wrote:
 On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
  It is unreasonable to tell the users and upstreams that Debian is
  going to keep users on a known inferior version by default for a long
  time, just in case more testing is needed to discover problems in the
  release version (often in addition to multiple already discovered
  problems that Debian is intentionally leaving for users to suffer
  from, as the most natural way to fix them would be to update to a
  newer upstream version).
  
 
 You may consider it most natural, the rest of the project values
 stability and not introducing untested new features.

I think you misunderstood that as saying I wanted to change packages in
stable; the above was from the perspective of unstable (the natural way
to fix known issues in unstable would be to upload a new upstream
version). I do not believe there is any project-wide consensus to avoid
newer versions in unstable.

 Perhaps you may
 feel more at home in a different distribution which aligns with your
 priorities more.

I think unstable works reasonably well outside release problems (there
are sometimes issues with new enough packages not being available, but I
think those are mostly due to activity of individual maintainers, not
project priorities). And I don't believe it to be a shared view of all
Debian maintainers that only stable releases matter, and users of
unstable are only tools to use to polish stable. Nor do I believe that
all other users of unstable are only trying to help create stable
releases for others to use, intentionally sacrificing their own
experience to do so. And whatever distro I personally choose, as
upstream of packaged software I certainly do not approve of Debian
leaving its upstable users at a known inferior version during long
release freezes.


-- 
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/1364827693.1928.122.camel@glyph.nonexistent.invalid

NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Luca Falavigna

[ This is just my personal point of view, not necessarily the one of the
FTP Team ]

2013/4/1 Rene Engelhard r...@debian.org
 Even if you think there are a few days between the time taken to process
 NEW for experimental vs NEW for unstable, I've seen no evidence of that
 and it's not as if a few days are really going to matter. (If it's that
 critical, find a webhost running Debian and install reprepro.)

 A few days? There's stuff there *for months*?

True. But most of the packages that currently are on top of the NEW queue
would have introduced transitions if FTP Team blindly had accepted them,
and we agreed with Release Team to keep them in the queue to avoid
potential breakages, given that at the time we just entered the Wheezy
freeze. We sent emails to maintainers to inform them about the reasons
behind the delay, and we offered to accept packages targeted to
experimental instead. I think this is a good approach. Some other packages
are stuck in the queue pending an answer from their maintainers about some
concerns FTP Team raised. There's little FTP Team can do other than wait
for actions from maintainers.

Since July 1st (first day of Wheezy freeze), we have the following figures:
* 2085 NEW packages received (7.694 per day)
* 1379 were accepted (5.089 per day)
* 213 were rejected (0.786 per day)
* 130 generated comments from FTP Team (0.480 per day)

During the freeze, the number of NEW packages received dropped by a half if
compared to the average during active development (about 14,85 packages
each day), so the number of actions by the FTP Team (about 13.5 accepts,
1.2 rejects, 0.5 comments each day). The above figures are normal during
freezes, both maintainers and FTP Team members are focused on other tasks
(releasing Wheezy is, of course, one of them!). Maintainers upload packages
more often than FTP Team is willing to process them (about 1,8 packages
every day), that explains the recent NEW queue growth.

Just for the record, FTP Team managed to keep the NEW queue around ten
packages for more than one year and a half, average processing time was
less than two days. Also, FTP Team processed almost two hundred packages
just before the freeze to give maintainers a chance to make their packages
into Wheezy (and most of them did!).

On the other hand, FTP Team is willing to fast-track NEW packages anytime,
if needed. Asking for a pacakge acceptance in #debian-ftp is always worth
it, and rarely these requests are not taken into consideration (as it
happened for some gcc/clang packages, or GNOME ones). If you need actions
from FTP Team, feel free to talk to us and we will be happy to help you.

Cheers,
Luca

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Mon, 1 Apr 2013 16:42:26 +0200
Rene Engelhard r...@debian.org wrote:

 On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote:
  It is installable from experimental if the local setup is correct. It's
  only a change to apt sources and preferences, in a chroot if necessary.
 
 This Debian. It is uninstallable there. And people (NOT ME!) can't install
 it. Which is the point.

Packages in experimental are installable for anyone using Debian, with
the appropriate tweaks to apt config.

Chroots and adapted apt config are perfectly acceptable for Debian -
it's the established method of using experimental.

 Or it even cannot be built.

Packages in experimental can be built trivially when the chroots used
are also tweaked to see experimental.
 
 It defeats the purpose of experimental when someone who want to use a package
 from there need to go looking up some place where he can get the depencencies
 from.

True but it can be useful in intermediate stages. However, I was only
talking about uploading outside Debian as the last resort, not the
recommended fix and certainly not making packages in experimental
depend on external repos, that's the wrong way around.

 How much do you want to go against Debians policies?

You're misunderstanding what I was trying to get at. Experimental is a
suitable target for this work and when combined with unstable, it needs
to be self-contained - correct. 

If a package in experimental needs a dependency, then that dependency
upload also goes into experimental.

The benefit is that if that goes wrong and the packages are
uninstallable then first, that can be fixed in experimental and second,
the RC bug does not affect the release (or other teams).

  I've worked on quite a few packages with this method over the years,
  some core stuff like curl, cairo, ldap, cups, etc. and then there's all
  the cross-build, multiarch stuff which is often dealing with toolchains
  and low level libraries. Don't lecture me about rdeps and dismiss the
 
 So you uploaded non-bbuildab le, non-installable packages to experimental?
 Oh my.

No. Those I upload to personal reprepro instances, if at all.

We're at cross-purposes here - I'm not advising uploading unfinished or
interim/broken packages to experimental. However, merely using
experimental for uploads during a freeze in no way makes an otherwise
correct package uninstallable or FTBFS. r-deps are just a bit of extra
work but that is *not* insurmountable.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgptgIfTlch86.pgp
Description: PGP signature

Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

Hi,

On Mon, Apr 01, 2013 at 05:06:03PM +0200, Luca Falavigna wrote:
True. But most of the packages that currently are on top of the NEW queue
would have introduced transitions if FTP Team blindly had accepted them,
and we agreed with Release Team to keep them in the queue to avoid
potential breakages, given that at the time we just entered the Wheezy
freeze. We sent emails to maintainers to inform them about the reasons

True for unstable, not for experimental, Because stuff uploading to experimental
can cause a transition if uploaded to unstable, yes - for *jessie*.
Of course if mallicous or careless maintainers uploaded to unstable.. *shrugs*

behind the delay, and we offered to accept packages targeted to
experimental instead. I think this is a good approach. Some other packages
are stuck in the queue pending an answer from their maintainers about some
concerns FTP Team raised. There's little FTP Team can do other than wait
for actions from maintainers.

I understand that, *if* comments were needed. But that's not the case always.

Some were stuck there and gor rejedted after 2 months. That specific
exmple was needed to make a transition which *will* happen in jessie
_less painless_.

And this isn't a explanation for *completely new*, (and thus no r-deps,
thus no transition) packages.

(And no, I didn't get a comment.)

On the other hand, FTP Team is willing to fast-track NEW packages anytime,
if needed. Asking for a pacakge acceptance in #debian-ftp is always worth
it, and rarely these requests are not taken into consideration (as it
happened for some gcc/clang packages, or GNOME ones). If you need actions
from FTP Team, feel free to talk to us and we will be happy to help you.
Cheers,

I know, and afaicr I went this way (or /query ansgar), too and I am very
grateful for that.

It's more cumbersome than it needs to be, though.

Regards,

Rene


-- 
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/20130401153057.gh31...@rene-engelhard.de

Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Michael Biebl

Am 01.04.2013 17:06, schrieb Luca Falavigna:
 [ This is just my personal point of view, not necessarily the one of the
 FTP Team ]

Luca, I think you and the FTP team are doing an awesome job! Even during
freezes. If you don't believe me, just have a look at the amount of
packages that were quickly accepted for preparing GNOME 3.8 in experimental.

Michael

/ who is very happy how NEW works nowadays.

-- 
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: Community Outreach to other communities

2013-04-01 Thread Paul Tagliamonte

On Mon, Apr 01, 2013 at 04:46:09PM +0200, A-dawg Tröllski wrote:
 On 01.04.2013 16:41, Paul Tagliamonte wrote:
  diff -Nru apt-0.9.7.8/debian/changelog apt-0.9.7.8+nmu1/debian/changelog
  --- apt-0.9.7.8/debian/changelog2013-03-14 03:14:09.0 -0400
  +++ apt-0.9.7.8+nmu1/debian/changelog   2013-03-24 17:37:05.0 
  -0400
  @@ -1,3 +1,10 @@
  +apt (0.9.7.8+nmu1) UNRELEASED; urgency=low
  ^
 
 You missed something, didn't you? Otherwise, your patch looks fine!

I was planning on rewriting it in Node.js or Ruby later. We should use
the languages that other bros can contribute it.

 
 Maybe you want to CC deity@l.d.o next time though when you plan to NMU
 their package. :
 
 -- 
 with kind regards,
 A-dawg Tröllski
 IRC: daemonkeeper on Freenode/OFTC
 GnuPG Key-ID: 0x9D80F36D
 

-- 
 .''`.  Paul Tagliamonte paul...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Neil McGovern

On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote:
 Neil McGovern wrote:
  On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
   It is unreasonable to tell the users and upstreams that Debian is
   going to keep users on a known inferior version by default for a long
   time, just in case more testing is needed to discover problems in the
   release version (often in addition to multiple already discovered
   problems that Debian is intentionally leaving for users to suffer
   from, as the most natural way to fix them would be to update to a
   newer upstream version).
   
  
  You may consider it most natural, the rest of the project values
  stability and not introducing untested new features.
 
 I think you misunderstood that as saying I wanted to change packages in
 stable; the above was from the perspective of unstable (the natural way
 to fix known issues in unstable would be to upload a new upstream
 version). I do not believe there is any project-wide consensus to avoid
 newer versions in unstable.
 

http://wiki.debian.org/DebianStability. Also see dev-ref 3.1. And the
huge amount of discussion that lead to
http://wiki.debian.org/ReleaseProposals in 2005.

As for consensus, have a read over this thread to see if there's anyone
supporting your views.

  Perhaps you may
  feel more at home in a different distribution which aligns with your
  priorities more.
 
 I think unstable works reasonably well outside release problems (there
 are sometimes issues with new enough packages not being available, but I
 think those are mostly due to activity of individual maintainers, not
 project priorities).
 And I don't believe it to be a shared view of all Debian maintainers
 that only stable releases matter, and users of unstable are only tools
 to use to polish stable.
 Nor do I believe that all other users of unstable are only trying to
 help create stable releases for others to use, intentionally
 sacrificing their own experience to do so.
 And whatever distro I personally choose, as upstream of packaged
 software I certainly do not approve of Debian leaving its upstable
 users at a known inferior version during long release freezes.
 

Wow.

I would have liked to find a source in dev-ref or something which
pointed out explicitly the commitment to releases. But I can't because
we've been doing releases for NEARLY 20 YEARS.

You seem to believe that unstable is more important than stable
releases. I do not. One of us is in the wrong project.

Neil


-- 
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/20130401154519.gn7...@halon.org.uk

Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Luca Falavigna

2013/4/1 Rene Engelhard r...@debian.org:
True for unstable, not for experimental, Because stuff uploading to
experimental
can cause a transition if uploaded to unstable, yes - for *jessie*.

Most of the packages introducing new transitions were accepted, if
targeted experimental. A lot are still in the queue, though. The
rationale will follow shortly.

Of course if mallicous or careless maintainers uploaded to unstable.. *shrugs*

True, and currently it's not possible to block those. But TTBOMK, only
a very few cases happened, and fortunately it was not to crack the
game.

I understand that, *if* comments were needed. But that's not the case always.

Some were stuck there and gor rejedted after 2 months. That specific
exmple was needed to make a transition which *will* happen in jessie
_less painless_.

Comments and rejects are issued during package review. Most of the
packages are accepted without remarks, some of them have a longer
path. I know the frustration of waiting for two months or more, and
then having your package rejected for just a few comments, but that is
why the NEW queue is in place, and maintainers sometimes have to face
a try again.

And this isn't a explanation for *completely new*, (and thus no r-deps,
thus no transition) packages.

(And no, I didn't get a comment.)

As I outlined in my previous message, we're in a phase in which we
receive more packages than we're able to process, due to internal
factors (our team is made of five members, while active developers are
about five hundred), or external (some of us have been busy elsewhere,
rationales are better explained in other mailinglists). binary-NEW
packages are usually processed first due to dak sorting, and the NEW
queue is not generally processed as FIFO, so it can happen a package
is processed way later even if it has been uploaded earlier.

On the other hand, FTP Team is willing to fast-track NEW packages anytime,

I know, and afaicr I went this way (or /query ansgar), too and I am very
grateful for that.

It's more cumbersome than it needs to be, though.

In a perfect world there wouldn't be any need for a NEW queue at all.
But we have to face with the reality.
We try to do our best to improve things where we can. From the FTP
Team side, we always try to be quick and helpful with our fellow
developers, and are happy to hear about suggestions how to improve
further. On the other hand, please bear with us a little more when
packages are not processed so quickly. FTP Team is not just pressing a
button.

Cheers,
Luca

--
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/cadk7b0pspid5gdpbkikuha4skidaa8zy5esbme7wny5iflu...@mail.gmail.com

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Michael Banck

Hi,

On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
 On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote:
 You seem to believe that unstable is more important than stable
 releases. I do not. One of us is in the wrong project.

That's easy to answer:  It must be you, because Uoti Urpala does not
appear to be a DD or DM, AFAICT.



Michael


-- 
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/20130401162512.ge23...@nighthawk.chemicalconnection.dyndns.org

Physical page zeroing on allocation

2013-04-01 Thread Viacheslav Fedorov

Hey guys,

I was wondering, when allocating an anonymous physical page on a Page
Fault, why does kernel have to fill it with zeroes?
I understand it has something to do with security.
But let's say I trust my environment. Then why when I disable zeroing of
the allocated pages, the applications crash in libc?
One would think that libc is debugged well and does not use uninitialized
variables?

I appreciate your comments!

Re: Physical page zeroing on allocation

2013-04-01 Thread Samuel Thibault

Viacheslav Fedorov, le Mon 01 Apr 2013 11:11:44 -0500, a écrit :
 I was wondering, when allocating an anonymous physical page on a Page Fault,
 why does kernel have to fill it with zeroes?
 I understand it has something to do with security.
 But let's say I trust my environment. Then why when I disable zeroing of the
 allocated pages, the applications crash in libc?

See man mmap. Anonymous memory is explicitly documented as being set to
0.

Samuel


-- 
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/20130401163113.gf17...@type.youpi.perso.aquilenet.fr

Re: Physical page zeroing on allocation

2013-04-01 Thread Timo Juhani Lindfors

Viacheslav Fedorov nih...@frtk.ru writes:
 But let's say I trust my environment. Then why when I disable zeroing of
 the allocated pages, the applications crash in libc?

How did you disable it?


-- 
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/848v52us29@sauna.l.org

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Don Armstrong

On Sun, 31 Mar 2013, Dirk Eddelbuettel wrote:
 It really does not add much as well already have a, say, Dependds:
 r-base-core (= 3.0.0~20130327) so we are really just trading one
 for the other as far as I can tell.

The difference is that you can do the following:

r-base-core Provides: r-base-api-3

and all cran depends on r-base-api-3.

When the API changes incompatibly, and an entire rebuild is required,
you change the api, so that r-base-core now Provides r-base-api-4.
 
Now, all cran packages have to be upgraded in lockstep with R, and you
cannot have R packages installed which are incompatible with the R
interpreter.

The version number attached to the API only increments when the API
changes incompatibly. If the API changes in a complex way, you could
also conceivably provide multiple versions of the API in the base
package.


Don Armstrong

-- 
Tell me something interesting about yourself.
Lie if you have to.
 -- hugh macleod http://www.gapingvoid.com/archives/batch20.php

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20130401165451.gy4...@rzlab.ucr.edu

Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Wookey

+++ Luca Falavigna [2013-04-01 17:06 +0200]:
Since July 1st (first day of Wheezy freeze), we have the following
figures:
* 2085 NEW packages received (7.694 per day)
* 1379 were accepted (5.089 per day)
* 213 were rejected (0.786 per day)
* 130 generated comments from FTP Team (0.480 per day)

Wow you guys are busy. I had no idea we generated new packages at such
a rate, even in freeze time.

During the freeze, the number of NEW packages received dropped by a half
if compared to the average during active development (about 14,85 packages
each day), so the number of actions by the FTP Team (about�13.5 accepts,
1.2 rejects, 0.5 comments each day). 

Just for the record, FTP Team managed to keep the NEW queue around ten
packages for more than one year and a half, average processing time was
less than two days. 

Yes, and that excellent record was certainly appreciated by me. You
(the FTP team as a whole) probably don't get told often enough so:
'Thanks for doing a somewhat dull job very well'. 

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/20130401165819.gu2...@stoneboat.aleph1.co.uk

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Scott Kitterman

On Monday, April 01, 2013 09:54:51 AM Don Armstrong wrote:
 On Sun, 31 Mar 2013, Dirk Eddelbuettel wrote:
  It really does not add much as well already have a, say, Dependds:
  r-base-core (= 3.0.0~20130327) so we are really just trading one
  for the other as far as I can tell.
 
 The difference is that you can do the following:
 
 r-base-core Provides: r-base-api-3
 
 and all cran depends on r-base-api-3.
 
 When the API changes incompatibly, and an entire rebuild is required,
 you change the api, so that r-base-core now Provides r-base-api-4.
 
 Now, all cran packages have to be upgraded in lockstep with R, and you
 cannot have R packages installed which are incompatible with the R
 interpreter.
 
 The version number attached to the API only increments when the API
 changes incompatibly. If the API changes in a complex way, you could
 also conceivably provide multiple versions of the API in the base
 package.

In sip4 with dh_sip (and sh_sip3 for python3) we do the latter and it seems to 
work pretty well.

Scott K


-- 
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/5361950.gE0dvWKiiu@scott-latitude-e6320

Re: Community Outreach to other communities

2013-04-01 Thread David Kalnischkies

Hi bro Paul,

thanks for your valuable contribution to fix the longstanding bug #271810
while outreaching to bro's at the same time!

On Mon, Apr 1, 2013 at 4:41 PM, Paul Tagliamonte paul...@debian.org wrote:
I've attached a patch for apt to help us be more inclusive to this
critical market.

Contrary to bro Arno I have to reject the patch in its current form though:
1. It opens a security back^Wfrontdoor: Given that cow has no
forehead everything could enter her head without verification.
I don't think we should be THAT open-minded …
2. The glasses seem to be an embedded copy as they are loosely
coupled with the head without requiring physical attachment to the
ears which is not possible with the glasses I have here, so these
must be a locally modified version. Alternatively I would look into
changing to a bronocle… äh, I meant monocle of course.
3. As with other cow suggestions: License? Source?
And very important: How old is the cow? (It's a nude art after all)
4. As Arno suggested, contact us at de...@lists.debian.org –
otherwise your NMU looks more like a NBU (non-bro upload)

As a sidenote:
I love that a cow is chosen to represent the bro movement even though some
will be offended (not because of the gender or because she is missing a leg,
those dipshits are not bros, I mean the BBQ-bros)!

Thanks again bro and best regards

David Kalnischkies on behalf of the APT bros

--
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/caaz6_fa_nhii99w97ung5qy8nc20t48wfhlcic6afevdodt...@mail.gmail.com

Re: Community Outreach to other communities

2013-04-01 Thread Paul Tagliamonte

On Mon, Apr 01, 2013 at 08:05:32PM +0200, David Kalnischkies wrote:
Hi bro Paul,

Sup!

thanks for your valuable contribution to fix the longstanding bug #271810
while outreaching to bro's at the same time!

Totally rad, brobot! Stoked to do it!

On Mon, Apr 1, 2013 at 4:41 PM, Paul Tagliamonte paul...@debian.org wrote:
I've attached a patch for apt to help us be more inclusive to this
critical market.

We need to broexist with the air-heads, of course.

2. The glasses seem to be an embedded copy as they are loosely
coupled with the head without requiring physical attachment to the
ears which is not possible with the glasses I have here, so these
must be a locally modified version. Alternatively I would look into
changing to a bronocle… äh, I meant monocle of course.

Perhaps we can find someone broficient enough to brollaborate with the
APT team on fixing this severe issue.

3. As with other cow suggestions: License? Source?

http://mediagoblin.com/u/cwebber/m/brogrammer-cow/

Made by real bro, cwebber under CC0 terms (as he's just informed me)

And very important: How old is the cow? (It's a nude art after all)

14:29 paroneayea paultag: all I will say is that our agency asserts
that all cows depicted are at legal and appropriate milk-producing age.

4. As Arno suggested, contact us at de...@lists.debian.org –
otherwise your NMU looks more like a NBU (non-bro upload)

I'll bring this to the broligarchy's attention next time - I was
brocrastinating a little, and forgot when I wrote the mail.

Thanks again bro and best regards

David Kalnischkies on behalf of the APT bros

--
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/caaz6_fa_nhii99w97ung5qy8nc20t48wfhlcic6afevdodt...@mail.gmail.com

Peace, brah!
T

--
.''`. Paul Tagliamonte paul...@debian.org
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag

signature.asc
Description: Digital signature

Bug#704482: general: file copy over kde gui or cp to an usb devices (tried fat/ext3) is showen as finshed while it's still copying

2013-04-01 Thread Manuel Schmidt

Package: general
Severity: critical
Tags: patch
Justification: causes serious data loss

Tried to copy files over usb to an usb stick (fat32) , before the files
correctly fineshed copying the progress bar ist fineshed / the bash prompt is
back.
This Problem you can just see if you larger files which are not copied
instantly.
The usb-devices are auto mounted by kde / gnome.

lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 2109:0811
Bus 004 Device 002: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for
Bluetooth
Bus 002 Device 006: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya
Technology Corp.) 64MB QDI U2 DISK

fat device
fdisk
/dev/sdc1   *1144 7831551 3915204c  W95 FAT32 (LBA)

dmesg
[ 4476.345808] usb 2-1.2: new high-speed USB device number 6 using xhci_hcd
[ 4476.417725] usb 2-1.2: New USB device found, idVendor=090c, idProduct=1000
[ 4476.417730] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 4476.417732] usb 2-1.2: Product: Flash Disk
[ 4476.417734] usb 2-1.2: Manufacturer: USB
[ 4476.417736] usb 2-1.2: SerialNumber: FBH180313345
[ 4476.417861] usb 2-1.2: ep 0x81 - rounding interval to 128 microframes, ep
desc says 255 microframes
[ 4476.417865] usb 2-1.2: ep 0x2 - rounding interval to 128 microframes, ep
desc says 255 microframes
[ 4476.427350] scsi17 : usb-storage 2-1.2:1.0
[ 4477.640842] scsi 17:0:0:0: Direct-Access USB  Flash Disk   1100
PQ: 0 ANSI: 4
[ 4477.641302] sd 17:0:0:0: Attached scsi generic sg4 type 0
[ 4477.642301] sd 17:0:0:0: [sdc] 7831552 512-byte logical blocks: (4.00
GB/3.73 GiB)
[ 4477.642754] sd 17:0:0:0: [sdc] Write Protect is off
[ 4477.642758] sd 17:0:0:0: [sdc] Mode Sense: 43 00 00 00
[ 4477.643135] sd 17:0:0:0: [sdc] No Caching mode page present
[ 4477.643138] sd 17:0:0:0: [sdc] Assuming drive cache: write through
[ 4477.644910] sd 17:0:0:0: [sdc] No Caching mode page present
[ 4477.644915] sd 17:0:0:0: [sdc] Assuming drive cache: write through
[ 4477.645648]  sdc: sdc1
[ 4477.647633] sd 17:0:0:0: [sdc] No Caching mode page present
[ 4477.647639] sd 17:0:0:0: [sdc] Assuming drive cache: write through
[ 4477.647642] sd 17:0:0:0: [sdc] Attached SCSI removable disk



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20130401185238.5333.11722.reportbug@krodeb.infinitydream.local

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Andreas Tille

On Mon, Apr 01, 2013 at 12:16:23AM +0200, Josselin Mouette wrote:
 
 Not only your reverse dependencies
 should only depend on the *sufficient* version of R (in this case,
 certainly not the R version used to compile the package, which will lead
 to transition blockades to testing), but they should stop installing
 when the version of R becomes incompatible, and so far nothing
 guarantees that.

The bug report #659163 that suggested ${R:Depends} originally was different
for exactly this reason[1].

Kind regards

Andreas.

[1] http://bugs.debian.org/659163#75

-- 
http://fam-tille.de


-- 
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/20130401195602.gc6...@an3as.eu

Re: missing libgl1-mesa-dri in upgrades



On 01/04/13 14:37, John Paul Adrian Glaubitz wrote:
 On 04/01/2013 11:59 AM, Daniel Pocock wrote:

 I've found that some default packages in Gnome are broken if
 libgl1-mesa-dri is not installed

 (...)

 While I've filed a bug against empathy (that is where I observed the
 problem), I suspect other packages are impacted and the issue may need
 to be fixed at some other level.
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704257
 
 Empathy itself does not required GL libraries to be installed:
 

Agreed - that's why I suggested that this bug probably needs to be
assigned elsewhere, but only after understanding how this dependency
should be brought in during upgrade.

 
 However, Empathy depends on Clutter which itself requires an OpenGL
 implementation:
 ...
 Checking the depends of libclutter-1.0-0:
 
 glaubitz@znote-t60o:~$ apt-cache depends libclutter-1.0-0 |head
 libclutter-1.0-0
   Depends: libatk1.0-0
   Depends: libc6
   Depends: libcairo-gobject2
   Depends: libcairo2
   Depends: libcogl-pango0
   Depends: libcogl9
   Depends: libfontconfig1
   Depends: libfreetype6
   Depends: libgdk-pixbuf2.0-0
 glaubitz@znote-t60o:~$
 
 where you see a dependency on libcogl9 which in turn depends on MESA:
 
 glaubitz@znote-t60o:~$ apt-cache depends libcogl9 |head
 libcogl9
 ...
   Depends: libgl1-mesa-glx

Agreed, but that doesn't complete the picture, as libgl1-mesa-glx
doesn't depend on libgl1-mesa-dri:

$ apt-cache depends libgl1-mesa-glx
  ...
Recommends: libgl1-mesa-dri


 So, whatever you do, don't mess around with Empathy. The bug, if any, is
 not in Empathy but any of its dependencies. I'd have a look at Clutter.

Either empathy or libclutter probably need to generate a popup error
window in this situation, if the error only appears in a console then it
will leave users with a bad impression of any impacted binary.
Generating such an error is independent of making sure the dependency is
present.

Here are the actual errors:

(empathy:30909): Clutter-CRITICAL **: Unable to initialize Clutter:
Failed to connected to any renderer:
XServer appears to lack required GLX support

(empathy:30909): empathy-CRITICAL **: main: assertion `gtk_clutter_init
(argc, argv) == CLUTTER_INIT_SUCCESS' failed

and this is from /var/log/Xorg.0.log:

[246718.377] (EE) AIGLX error: dlopen of
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so failed
(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so: cannot open shared object
file: No such file or directory)
[246718.377] (EE) AIGLX: reverting to software rendering
[246718.378] (EE) AIGLX error: dlopen of
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed
(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: cannot open shared object
file: No such file or directory)
[246718.378] (EE) GLX: could not load software renderer

I also discovered some older complaints about the empathy/clutter/mesa
relationship, this was is grave and was only closed recently:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619636

 Also, have you tried running Empathy on a non-compositing window manager
 when libgl1-mesa-dri is not installed?
 

I'm happy to try that, can you propose which window manager I should
try?  I know fvwm quite well and don't mind installing that.


-- 
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/5159e718.6040...@pocock.com.au

Bug#704482: #704482 general: file copy over kde gui or cp to an usb devices (tried fat/ext3) is showen as finshed while it's still copying

2013-04-01 Thread Timo Juhani Lindfors

package general
severity 704482 wishlist
tags 704482 -patch
reassign 704482 konqueror
thanks

For cp this is not a bug, you are supposed to umount the filesystem
before you remove the usb device. Nothing in man cp guarantees that
the file has been copied to the disk when the command exits.

For konqueror this is also not a critical bug, you are supposed to use
safely remove drive or equivalent before removing the usb
device. However, I think it would be nice to have a progress bar that
would show the actual data transfer. I'm thus changing this to a
wishlist bug against konqueror. Feel free to close if you don't think
this is realistic.

You marked the bug with patch but I don't see any patch, I assume this
was an error.


-- 
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/844nfquinj@sauna.l.org

Processed (with 1 errors): #704482 general: file copy over kde gui or cp to an usb devices (tried fat/ext3) is showen as finshed while it's still copying

2013-04-01 Thread Debian Bug Tracking System

Processing commands for cont...@bugs.debian.org:

 package general
Limiting to bugs with field 'package' containing at least one of 'general'
Limit currently set to 'package':'general'

 severity 704482 wishlist
Bug #704482 [general] general: file copy over kde gui or cp to an usb devices 
(tried fat/ext3) is showen as finshed while it's still copying
Severity set to 'wishlist' from 'critical'
 tags 704482 -patch
Bug #704482 [general] general: file copy over kde gui or cp to an usb devices 
(tried fat/ext3) is showen as finshed while it's still copying
Removed tag(s) patch.
 reassign 704482 konqueror
Bug #704482 [general] general: file copy over kde gui or cp to an usb devices 
(tried fat/ext3) is showen as finshed while it's still copying
Bug reassigned from package 'general' to 'konqueror'.
package: konqueror' does not match at least one of general
Failed to clear fixed versions and reopen on 704482: limit failed for bugs: 
704482.

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
704482: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704482
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.136484635926027.transcr...@bugs.debian.org

Re: missing libgl1-mesa-dri in upgrades

2013-04-01 Thread John Paul Adrian Glaubitz


On 04/01/2013 09:59 PM, Daniel Pocock wrote:

Agreed, but that doesn't complete the picture, as libgl1-mesa-glx
doesn't depend on libgl1-mesa-dri:

$ apt-cache depends libgl1-mesa-glx
   ...
 Recommends: libgl1-mesa-dri



Well, Recommends are installed by default, aren't they? However, I'm 
not sure why it shouldn't be depending on either libgl1-mesa-dri or 
libgl1-mesa-swx11 here. I mean, MESA doesn't work without either of 
these, does it?



Either empathy or libclutter probably need to generate a popup error
window in this situation, if the error only appears in a console then it
will leave users with a bad impression of any impacted binary.
Generating such an error is independent of making sure the dependency is
present.


No, I don't think there should be a popup. Someone should just fix the 
dependencies.



Also, have you tried running Empathy on a non-compositing window manager
when libgl1-mesa-dri is not installed?



I'm happy to try that, can you propose which window manager I should
try?  I know fvwm quite well and don't mind installing that.


Yeah, fvwm doesn't really do any compositing :).

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/5159e845.9070...@physik.fu-berlin.de

role of unstable in releasing Debian (Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Eugene V. Lyubimkin

Hello,

[ some quotes reordered ]

2013-04-01 16:45, Neil McGovern:
 As for consensus, have a read over this thread to see if there's anyone
 supporting your views.

Well, if you resort to this argument, here I am, supporting some part of
those views. Not supporting the rude tone though.

 http://wiki.debian.org/DebianStability.

I did not sign that. Also, I'd rename it to
'EverythingExceptStableReleasesIsUnimportant'. This is IMO not the same
as 'stability', more on that under.

 Also see dev-ref 3.1.

That is mostly fine, the questionable point there is 'most users will
only benefit from your packages when they are released as part of the
next stable release'. And we advertise our great testing/unstable
branches, the point would be even more questionable.

 And the huge amount of discussion that lead to
 http://wiki.debian.org/ReleaseProposals in 2005.

Nice link, thanks. Do I understand correctly, there were 30
models/changes proposed there but nothing of them was tried or voted or
considered for adoption? In other words, the deliberate choice of
Release Team so far is
http://wiki.debian.org/JustIgnoreAndContinueAsAlways [1]?

One very interesting proposal there,
http://wiki.debian.org/SubProjectPerStabilityLevel, lists It might be
hard to find people who actually WANT to work on the stable/testing
teams as one of disadvantages. If it's false, we might try to seriously
consider implementing it as practically disadvantage-free [2]. If it's
true, I don't understand how only stable matters for us can be true.


 You seem to believe that unstable is more important than stable
 releases. I do not. One of us is in the wrong project.

I do consider, from certain point and for the software of certain [6]
categories, working on unstable more important than working on stable.
Working on unstable now will benefit wheezy+1, wheezy+2, wheezy+3, ...,
wheezy+inf, unstable/experimental, developers, prospective contributors,
upstreams. Working on stable [5] will benefit, limitedly [3], wheezy and
upstreams. 

On stability. I, particularly, would not measure Debian quality in a
number of open RC bugs in the coming stable release. If Debian is
released once in 10 years with 0 RC bugs, most of users will go away. If
Debian is released with only 100 carefully selected RC-free packages,
most of users will go away. The package which crashes and misbehaves
here and there (100 normal bugs, 10 important ones) is [4] IMHO less
useful than the one which works more or less fine but always knowingly
crashes on armel (1 RC bug). Documentation, feature sets, translations,
friendliness with mortal bug reporters -- lack of any of those will have
an influence but hardly ever filed as RC bug. The current system doesn't
take many things into account.

I also do think that the Release Team tries to do a good job but The
Process doesn't scale and should be eventually replaced. As well as that
part of release guidelines which currently just counts relevant RC bugs.



[1] empty but nice page linked from http://wiki.debian.org/ReleaseProposals

[2] the second mentioned disadvantage is Stable might be permenently 1-2
years out of date instead of being new once every four years., and as
of moment of writing stable is permanently 1-3 years out of date.

[3] because:
- not much can be done, limited set of changes are accepted and many
  bugs are not fixable by strangers;
- fixing issues in other packages -- more risky;
- often porting bugfixes from already released upstream point releases
  -- zero benefit to upstream/non-Debian users, less tested changes.

[4] if there is no viable alternatives

[5] as opposed to freely working on unstable

[6] but quite broad

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer


-- 
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/20130401205054.GA14204@debian-w500.Elisa

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

2013-04-01 Thread Vincent Danjean

Le 01/04/2013 00:39, Dirk Eddelbuettel a écrit :
 I didn't mean to create extra work.  We had two such transitions for R before
 in the last five years, and they just worked. 

No. I suffer from partial upgrade and solved it by upgrading all
installed r related packages. The dependency system should have done
it for me, as for perl or python or ...
  I should have opened a bug for this, but I did not take the time
to do it, thinking that this was probably a transitional bug that
would be solved as this is done with all other major interpreters.

  Looking quickly at the description of the problem, I also think
that r-base-core providing a virtual package such as r-abi-3.0
and all modules depending on this virtual package would solve
future such upgrades.
  But you will also need a (long) list of Breaks: in r-base-core 3.0.0
in order to solve the current problem with partial upgrades.
Or you can create a r-base-core-3 (or any other name) package that would
Conflicts *and* Replaces r-base-core in order to be sure to forbid all
previous r modules (even not official ones for examples).

  Regards,
Vincent

PS: I also think that, in any cases, all of this should have been
delayed or done in experimental.

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/5159f729.1030...@free.fr

Re: role of unstable in releasing Debian (Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)

2013-04-01 Thread Russ Allbery

While I realize that it's very hard to put off discussions when they're
raised in interesting-looking threads, this case in particular is one
where it's quite helpful socially to pick the right time to have this
discussion.

Absolutely nothing is going to change the release process for wheezy at
this point.  There will be some time before any possible freeze for
jessie, during which we can and should have this conversation.  Everyone
is on edge and tired at this point (as we always are) during the release
process, so during this very tail end of the release, particularly given
the tone of some of the earlier messages, this debate is quite likely to
make people defensive and annoyed.  Not only is that bad for everyone (we
should have fun working on Debian), but it also makes it much more likely
that any proposals for changes will be rejected.  No one is going to be in
an accepting mood right now.

In other words, this is a great conversation to have starting a couple of
weeks after the release when everything has calmed down and we're all
feeling euphoric and therefore optimistic and excited.  :)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/87y5d2j6l5@windlord.stanford.edu

Re: missing libgl1-mesa-dri in upgrades



On 01/04/13 22:04, John Paul Adrian Glaubitz wrote:
 On 04/01/2013 09:59 PM, Daniel Pocock wrote:
 Agreed, but that doesn't complete the picture, as libgl1-mesa-glx
 doesn't depend on libgl1-mesa-dri:

 $ apt-cache depends libgl1-mesa-glx
...
  Recommends: libgl1-mesa-dri

 
 Well, Recommends are installed by default, aren't they? However, I'm

Not during upgrade or dist-upgrade operations.  This is specifically an
upgrading issue.  From man apt-get:

  upgrade:
 ...  under no circumstances are currently installed packages removed,
or packages not already installed retrieved and installed.

dist-upgrade:
... intelligently handles changing dependencies with new versions of
packages

From that, it's not clear how dist-upgrade should handle Recommends, but
my dpkg.log shows that no attempt was made to install libgl1-mesa-dri
automatically.

 not sure why it shouldn't be depending on either libgl1-mesa-dri or
 libgl1-mesa-swx11 here. I mean, MESA doesn't work without either of
 these, does it?

I'm not sure - other parts of the desktop are working, but I haven't
tested so many things yet.  I'm not sure which components depend on MESA.

 Either empathy or libclutter probably need to generate a popup error
 window in this situation, if the error only appears in a console then it
 will leave users with a bad impression of any impacted binary.
 Generating such an error is independent of making sure the dependency is
 present.
 
 No, I don't think there should be a popup. Someone should just fix the
 dependencies.

Actually, empathy's error is from an assert(), a recent discussion on
debian-devel found that assert() is not loved universally loved.  There
are various errors from empathy that appear in the same way, and they
should probably all be presented in a popup.

 Also, have you tried running Empathy on a non-compositing window manager
 when libgl1-mesa-dri is not installed?


 I'm happy to try that, can you propose which window manager I should
 try?  I know fvwm quite well and don't mind installing that.
 
 Yeah, fvwm doesn't really do any compositing :).

I'll share the results after I try it



-- 
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/5159f937.30...@pocock.com.au

Re: missing libgl1-mesa-dri in upgrades

2013-04-01 Thread Josselin Mouette

Le lundi 01 avril 2013 à 22:04 +0200, John Paul Adrian Glaubitz a
écrit : 
  $ apt-cache depends libgl1-mesa-glx
 ...
   Recommends: libgl1-mesa-dri
 
 
 Well, Recommends are installed by default, aren't they? However, I'm 
 not sure why it shouldn't be depending on either libgl1-mesa-dri or 
 libgl1-mesa-swx11 here. I mean, MESA doesn't work without either of 
 these, does it?

It should work with indirect GLX if the server supports it, in which
case you don’t need either of the two. I guess this is the reason for
Recommends instead of Depends.

OTOH the metapackage xorg correctly depends on libgl1-mesa-dri. I’m not
sure what can be done to make things better.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1364857476.27982.24.camel@tomoyo

Re: missing libgl1-mesa-dri in upgrades



On 02/04/13 01:04, Josselin Mouette wrote:
 Le lundi 01 avril 2013 à 22:04 +0200, John Paul Adrian Glaubitz a
 écrit : 
 $ apt-cache depends libgl1-mesa-glx
...
  Recommends: libgl1-mesa-dri


 Well, Recommends are installed by default, aren't they? However, I'm 
 not sure why it shouldn't be depending on either libgl1-mesa-dri or 
 libgl1-mesa-swx11 here. I mean, MESA doesn't work without either of 
 these, does it?
 
 It should work with indirect GLX if the server supports it, in which
 case you don’t need either of the two. I guess this is the reason for
 Recommends instead of Depends.

In my case, it is not working that way - the problem is 100% repeatable
if I just dpkg --purge libgl1-mesa-dri

I am happy to test it in some other way to see if there is a reason why
the indirect GLX doesn't work, but I would need some suggestions what to
check.

 OTOH the metapackage xorg correctly depends on libgl1-mesa-dri. I’m not
 sure what can be done to make things better.
 

That is correct - but according to popcon, 1 in 7 users of xserver-xorg
don't have the package xorg, so when they upgrade, they won't get the
dependency that way.




-- 
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/515a1376.1020...@pocock.com.au

Bug#704502: ITP: pdf.js -- web standards-based platform for parsing and rendering PDFs

2013-04-01 Thread David Prévot

Package: wnpp
Severity: wishlist
Owner: David Prévot taf...@debian.org

* Package name: pdf.js
  Version : 0.7.423
  Upstream Author : Andreas Gal g...@mozilla.com
* URL : http://mozilla.github.com/pdf.js/
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : web standards-based platform for parsing and rendering PDFs

pdf.js is an HTML5 technology experiment that explores building a
faithful and efficient Portable Document Format (PDF) renderer without
native code assistance.



The purpose would be to provide it, via a libjs-pdf package, in order to
be used as a third party in other packages like owncloud. As such, I
intend to maintain it under the Debian Javascript umbrella, or, by
default, under the ownCloud one.

Regards

David


signature.asc
Description: Digital signature

Accepted live-boot 4.0~a10-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:20:50 +0200
Source: live-boot
Binary: live-boot live-boot-doc live-boot-initramfs-tools
Architecture: source all
Version: 4.0~a10-1
Distribution: experimental
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-boot  - Live System Boot Scripts
 live-boot-doc - Live System Boot Scripts (documentation)
 live-boot-initramfs-tools - Live System Boot Scripts (initramfs-tools backend)
Changes: 
 live-boot (4.0~a10-1) experimental; urgency=low
 .
   [ Daniel Baumann ]
   * Debranding package for derivatives.
 .
   [ Evgeni Golov ]
   * Fixing condition for setting rootfs_dest_backing.
 .
   [ Michael Stummvoll ]
   * Simplifying if statement in is_live_system function.
   * Fixing a bug with multiple files in is_live_path after the last
 commit.
   * Using is_live_path() in mount_images_in_directory() to avoid redundant
 logic.
Checksums-Sha1: 
 5f7181ec83ef67bc078d661178ea57c641e1e63d 1396 live-boot_4.0~a10-1.dsc
 7a8cbe9433f690c5a56b3d149944368a3c2aae8d 58304 live-boot_4.0~a10.orig.tar.xz
 75f3e3b6652a5dd11fd6af2a59b840c457899f1e 22964 
live-boot_4.0~a10-1.debian.tar.xz
 b183e28e30de0e2c3cebd6468679bcb99e1bf26d 49042 live-boot_4.0~a10-1_all.deb
 0d998e3a87b46aaeacf36c5d1dc84eb5ddd80b3a 52196 live-boot-doc_4.0~a10-1_all.deb
 36b6d32fcc3ff4fe84dc3b90f2c316f1161083c0 27120 
live-boot-initramfs-tools_4.0~a10-1_all.deb
Checksums-Sha256: 
 847071e2346ed49f197b4403b1857f57200a9c3b1b7174e3ed6727dce9b99ebd 1396 
live-boot_4.0~a10-1.dsc
 be98d6f2daff8834403ff75da95089a6682acf69310704018083093ad10adb31 58304 
live-boot_4.0~a10.orig.tar.xz
 a31cfbc1e8a5ba3a997418388872136f0ec50eef38a3478847cf3ae02a1b2026 22964 
live-boot_4.0~a10-1.debian.tar.xz
 1113dfd3378a4e1d1834fe0711131fa315f9c29ef59685e6cad40105f0ac0785 49042 
live-boot_4.0~a10-1_all.deb
 ff566c0f17f98086c67c8037cca740e827ebc2eb7c4cda42f5b52b9cc795123b 52196 
live-boot-doc_4.0~a10-1_all.deb
 9754c89c5288bd1e9027653510e57b98b016a5d58e1f482ec61f871b2e883cca 27120 
live-boot-initramfs-tools_4.0~a10-1_all.deb
Files: 
 077f806cc187654673aad80d0668460a 1396 misc optional live-boot_4.0~a10-1.dsc
 4b595cb92f11809e94d98c490f66a29f 58304 misc optional 
live-boot_4.0~a10.orig.tar.xz
 f33e96d2f7b74e5131f035548a60c84f 22964 misc optional 
live-boot_4.0~a10-1.debian.tar.xz
 74d837249d2e6fc49dcc9da9c4e420c5 49042 misc optional 
live-boot_4.0~a10-1_all.deb
 03b6a7f57ff6309e51ac217c4552f478 52196 doc optional 
live-boot-doc_4.0~a10-1_all.deb
 c07f8ffebdf974c4ed82b72ea537f4c5 27120 misc optional 
live-boot-initramfs-tools_4.0~a10-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZJ9AACgkQ+C5cwEsrK5761ACeI7IfrCN1mXjsmZfeB04Nkd/v
OQgAnjz4WRdsLfwe/R8z12q4JyvWQw54
=2waE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umyik-0008km...@franck.debian.org

Accepted live-build 4.0~a16-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:25:04 +0200
Source: live-build
Binary: live-build live-build-cgi
Architecture: source all
Version: 4.0~a16-1
Distribution: experimental
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-build - Live System Build Scripts
 live-build-cgi - Live System Build Scripts (CGI frontend)
Closes: 697793 702537
Changes: 
 live-build (4.0~a16-1) experimental; urgency=low
 .
   [ Daniel Baumann ]
   * Correcting typo directory when dereferencing syslinux symlinks when
 building chrooted, thanks to Luigi Capriotti l.caprio...@xbmc.org.
   * Debranding package for derivatives.
   * Using dpkg-divert in chroot_upstart script to handle upgrades of
 upstart during the build (Closes: #702537).
   * Using dpkg-divert for other diversions too to handle upgrades of the
 diverted stuff during build.
   * Adding generic live-build handle in chroot_dpkg for other live
 packages to act upon.
   * Updating fallback help message in live-build pseudo-command.
   * Simplyfing live-build pseudo-command.
   * Correcting grammer error in live-build description.
   * Improving comment in lb about embedded live-build within config tree.
   * Removing old docs.
   * Adding set -e in example auto scripts.
   * Setting memtest default to none.
   * Using ntfs-3g to mount ntfs partitions.
   * Adding check for ntfs-3g on the host system, precluding the initial
 ntfs binary filesystem support (Closes: #697793).
   * Dropping dedicated backports mirror handling, not needed anymore with
 the move of backports.d.o into ftp.d.o.
   * Dropping dedicated updates (formerly volatile) mirror handling, not
 needed anymore.
   * Renaming config/control to config/image.
   * Removing dedicated emdebian mode, this can entirely be handled with
 different defaults.
 .
   [ Michael Stummvoll ]
   * Fixing missing quotes for tr commands to avoid unwanted expansions.
 .
   [ Richard Nelson ]
   * Converting l-b-cgi frontend to process forms with post.
 .
   [ Daniel Baumann ]
   * Replacing strings in all syslinux config files, not just certain
 hardcoded ones.
   * Cleaning up installer file locations for progress-linux.
   * Aborting early in chroot_package-lists if no package list is found.
   * Stripping out comments in package lists.
   * Unifying append options in binary_syslinux when processing
 configuration files.
Checksums-Sha1: 
 f5d0e9718117267449b278acd282af5527fd448d 1342 live-build_4.0~a16-1.dsc
 ca9dba7ff3debf32a516a1a78733f11d2b8bccf6 146932 live-build_4.0~a16.orig.tar.xz
 0a9eff07906bbbfcb8c73529f327970f0f924a14 53032 
live-build_4.0~a16-1.debian.tar.xz
 f4d22158d0ffcd989f6dc9c93dd76b87a01d8338 213512 live-build_4.0~a16-1_all.deb
 16b3af52f62ce4e3dcca4e017b8ae442c58559ba 66286 live-build-cgi_4.0~a16-1_all.deb
Checksums-Sha256: 
 7545af5524a568f4e333b1903dddcf280eced620c6d74258861184edda3b5860 1342 
live-build_4.0~a16-1.dsc
 66693bef925d6b3e1ccfd01af81b70827d0f3d04220d6262e3238ab3b9e25591 146932 
live-build_4.0~a16.orig.tar.xz
 7ce300b37ebc1d5f6f17ee3ded76d30e79fb762a3e27f1e354f63bdc7ceb11af 53032 
live-build_4.0~a16-1.debian.tar.xz
 b15d2b1786eb6a0c9106a1465f92fd37db5d954eabc4470e8a496cb0c0af8c28 213512 
live-build_4.0~a16-1_all.deb
 bcdd3f41c8f99563418810eb7c1106bead939c076b034ae3d2aca9b281743aad 66286 
live-build-cgi_4.0~a16-1_all.deb
Files: 
 2039fbe3c739f577fd57766b0984f9f6 1342 misc optional live-build_4.0~a16-1.dsc
 ea546336bd6afc8555c6d8b96fc21c1a 146932 misc optional 
live-build_4.0~a16.orig.tar.xz
 dba6cd37790c3f940312b31832989456 53032 misc optional 
live-build_4.0~a16-1.debian.tar.xz
 d4e2a15c6536419416f97f3eedaf0855 213512 misc optional 
live-build_4.0~a16-1_all.deb
 0c93516dabfb156b5eac543f5f0a7e0a 66286 misc optional 
live-build-cgi_4.0~a16-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZKWYACgkQ+C5cwEsrK56AygCffYpu3dYTjo4E8aI+yA78ywcm
xlsAoNjkqr36URuCyc5+TXH0pRJHJ4Nn
=BegD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umywm-0003i2...@franck.debian.org

Accepted live-config 4.0~a19-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:32:26 +0200
Source: live-config
Binary: live-config live-config-doc live-config-systemd live-config-sysvinit 
live-config-upstart
Architecture: source all
Version: 4.0~a19-1
Distribution: experimental
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-config - Live System Configuration Scripts
 live-config-doc - Live System Configuration Scripts (documentation)
 live-config-systemd - Live System Configuration Scripts (systemd backend)
 live-config-sysvinit - Live System Configuration Scripts (sysvinit backend)
 live-config-upstart - Live System Configuration Scripts (upstart backend)
Closes: 703108 703972
Changes: 
 live-config (4.0~a19-1) experimental; urgency=low
 .
   [ Daniel Baumann ]
   * Debranding package for derivatives.
   * Correcting spelling typo in noroot variable name, thanks to Chris
 Malton chr...@cmalton.me.uk (Closes: #703108).
 .
   [ Jun Nogata ]
   * Updating gnome-screensaver locking for gnome3 (Closes: #703972).
Checksums-Sha1: 
 dffe4ec18c2758ebd62f0fda0ebdefd691281d62 1567 live-config_4.0~a19-1.dsc
 1b6b1a3aa6de853129889ccd2762b2b75533f8f1 64076 live-config_4.0~a19.orig.tar.xz
 2fa99e089819e5a0387236387719a71d2df265a0 14232 
live-config_4.0~a19-1.debian.tar.xz
 0f3052acfb1366d76d0172b8c2fe6274a2bf68bd 27812 live-config_4.0~a19-1_all.deb
 ac3c8128de5a4aa08092a78ca77869c0aa716974 51772 
live-config-doc_4.0~a19-1_all.deb
 250c2821e87a79c8afc6e93c53f0fc3b7622f1f9 15396 
live-config-systemd_4.0~a19-1_all.deb
 bb5c9085940d8bc20206133522dd1a7b1d05efc1 16566 
live-config-sysvinit_4.0~a19-1_all.deb
 de7d583284c204afecb37dfa05e01e4c725eaddc 16196 
live-config-upstart_4.0~a19-1_all.deb
Checksums-Sha256: 
 4ed1e4cb644e6803aa68623519f51e673844713f29cdee6184c257e77e0f9d78 1567 
live-config_4.0~a19-1.dsc
 1bd427c8a52b087d8fd0a9e3799479af6f903ef96c0a861c2f318d53e697456c 64076 
live-config_4.0~a19.orig.tar.xz
 98d4bfb6f9e481e81d4cd46b7aeef325b8c34c2dd6baa0c23b4a95eff9c2d398 14232 
live-config_4.0~a19-1.debian.tar.xz
 6718d31cff80e84ee660306c5cbc4d7371b6fa8c1b0ce4454137e51b9263ae7c 27812 
live-config_4.0~a19-1_all.deb
 3dd3f0cf1b1cf494bcb4ee864eaad7ed42f074d9e6bafa87a434f7769028aee8 51772 
live-config-doc_4.0~a19-1_all.deb
 6e1ebe3f271f77b9e323a6c7a8ad452d1e98a95bb93d0524b0c1889d43dc9a2e 15396 
live-config-systemd_4.0~a19-1_all.deb
 0f16f56d24b9e8acf5547075281d8d45858207f181bf765efb649ee21beb9d08 16566 
live-config-sysvinit_4.0~a19-1_all.deb
 e5162b47acb083d350839875e50519798c3ddfb6efdf3d80e0c29f6820ae9536 16196 
live-config-upstart_4.0~a19-1_all.deb
Files: 
 3572be025a351b75b983559664618f26 1567 misc optional live-config_4.0~a19-1.dsc
 53a273c6a2f66284197801d8525f023e 64076 misc optional 
live-config_4.0~a19.orig.tar.xz
 2d9ab61f3beadcb8c6d03bedf883f04c 14232 misc optional 
live-config_4.0~a19-1.debian.tar.xz
 794924bd862b9ab974e60a5fa37d98e7 27812 misc optional 
live-config_4.0~a19-1_all.deb
 12913acb3f852a2896b073c677d463b4 51772 doc optional 
live-config-doc_4.0~a19-1_all.deb
 438da2ddbeda59c92dac1c23f38a52ee 15396 misc optional 
live-config-systemd_4.0~a19-1_all.deb
 e7a90a906218e0de0061d18294ca391b 16566 misc optional 
live-config-sysvinit_4.0~a19-1_all.deb
 d96499549a948560c9a6e683771092c6 16196 misc optional 
live-config-upstart_4.0~a19-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZKswACgkQ+C5cwEsrK55bBACg23QaQPxgM5dQstK55LquVKkF
ZwgAni3VW25ART1pyzXEnANGaypefZRk
=BbGy
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umywv-0003rm...@franck.debian.org

Accepted live-debconfig 4.0~a21-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:37:43 +0200
Source: live-debconfig
Binary: live-debconfig live-debconfig-doc
Architecture: source all
Version: 4.0~a21-1
Distribution: unstable
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-debconfig - Live System Configuration Scripts
 live-debconfig-doc - Live System Configuration Scripts (documentation)
Changes: 
 live-debconfig (4.0~a21-1) unstable; urgency=low
 .
   * Debranding package for derivatives.
Checksums-Sha1: 
 ec8d1f3428f08e6b4f971d0c8b218f0c1ef365b6 1391 live-debconfig_4.0~a21-1.dsc
 f6f4ed500d1649d93625d9259ad441f8532cad25 35000 
live-debconfig_4.0~a21.orig.tar.xz
 7cf6cf2f32e6491bf15987759e37dad8317fe1d9 4952 
live-debconfig_4.0~a21-1.debian.tar.xz
 7a4303731fbedd4f024a2831717a51875c8f0740 16884 live-debconfig_4.0~a21-1_all.deb
 98705ea14a9e103a43a2002d13881c4d09c3a5c8 28764 
live-debconfig-doc_4.0~a21-1_all.deb
Checksums-Sha256: 
 12b9db5e4c515d88f6e3ebee5687c0e929afce59688fc3214ec892d06ee46bd5 1391 
live-debconfig_4.0~a21-1.dsc
 cb93767b892d0e09e481dd0244407706bc5be80686d22a6e2e602627d43a2c6c 35000 
live-debconfig_4.0~a21.orig.tar.xz
 65c9ec031afeb8e0eae393fe42e29bcf1b981a2f802f4c70daa56220ec5883be 4952 
live-debconfig_4.0~a21-1.debian.tar.xz
 f137275bf5b0eafeaa999a02b11a7d53b56d35883de13d3b685ff76a4f2cd832 16884 
live-debconfig_4.0~a21-1_all.deb
 74767c3be1fbe05235af98adb3cbffd4a6a3f0ea5a70b7c2dd0e957f42454ff8 28764 
live-debconfig-doc_4.0~a21-1_all.deb
Files: 
 f00273e7644ccac0b9d8efef571d7c2a 1391 misc optional 
live-debconfig_4.0~a21-1.dsc
 942590e586e17ef726c28ee39c330372 35000 misc optional 
live-debconfig_4.0~a21.orig.tar.xz
 985c0de216b9003990d293545978d5dc 4952 misc optional 
live-debconfig_4.0~a21-1.debian.tar.xz
 205463649498ce9ad5458c6a7f3f7531 16884 misc optional 
live-debconfig_4.0~a21-1_all.deb
 f9e8ad920192f3e6a5e410218822fec5 28764 doc optional 
live-debconfig-doc_4.0~a21-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZK6YACgkQ+C5cwEsrK54onACgggd2zAhJEuRWXFRU/IyFmOLQ
gIAAoL9at3B8vj3OFnT/i5BnLG5R6Gy/
=HIOv
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umyx0-0003w5...@franck.debian.org

Accepted gup 0.5.14 (source i386)

2013-04-01 Thread Marco d'Itri

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 07:36:31 +0200
Source: gup
Binary: gup
Architecture: source i386
Version: 0.5.14
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri m...@linux.it
Changed-By: Marco d'Itri m...@linux.it
Description: 
 gup- let a remote site change their newsgroups subscription
Closes: 668769
Changes: 
 gup (0.5.14) unstable; urgency=low
 .
   * Really delete the generated files on purge in postrm, not prerm.
 (Closes: #668769)
   * Fixed minus vs. hyphen occurences in gup(8).
   * Packaging updated to modern standards.
Checksums-Sha1: 
 2348fba40cf704edfc15bc24b4e21092e683de20 716 gup_0.5.14.dsc
 05dde8834a995d769426addf0b917eef0dd446bf 30384 gup_0.5.14.tar.xz
 37bf99242bc0cd3b130aa196256e0e46d5effc1e 26496 gup_0.5.14_i386.deb
Checksums-Sha256: 
 92d672d965eeeba93d00860bb47f09b250e588056c8b6fadf6b372307f1ada80 716 
gup_0.5.14.dsc
 6a45f7d87901bad52aecb0f06b27512ed929b6afc3ae11394e1adb5fd4a6c5ae 30384 
gup_0.5.14.tar.xz
 0c66eed7428f8c11004e1b076690e8a487ce00482ebd60ca1fae266948e76eb5 26496 
gup_0.5.14_i386.deb
Files: 
 86e57c25dcccfafc0413561e986a 716 news extra gup_0.5.14.dsc
 67bcac17be91bc09570989aaa5942ade 30384 news extra gup_0.5.14.tar.xz
 6ab821f7aa4b65b0f2e28d69d03f7b08 26496 news extra gup_0.5.14_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZLT0ACgkQFGfw2OHuP7HrUgCgj1QLER5xXLe58KmlyjPCtGcp
ac8AoKaDT9RdR5UbhaqQPn1FUmaSJ+Ou
=UlEH
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umylv-00072e...@franck.debian.org

Accepted live-tools 4.0~a12-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:44:24 +0200
Source: live-tools
Binary: live-tools
Architecture: source all
Version: 4.0~a12-1
Distribution: experimental
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-tools - Live System Support Scripts
Changes: 
 live-tools (4.0~a12-1) experimental; urgency=low
 .
   * Debranding package for derivatives.
   * Detect being run in a live system being built on a live system by
 looking for the /.live-build handle provided by live-build in live-
 update-initramfs.
Checksums-Sha1: 
 51fa6a13360aa6027e76d88f0395d182bf722f91 1286 live-tools_4.0~a12-1.dsc
 41806a70e1a9be3f7a3cb0605c5fc7ac5edd824d 27036 live-tools_4.0~a12.orig.tar.xz
 46d46d665fc63f351fde5762eaac4d3da83ca7eb 5520 
live-tools_4.0~a12-1.debian.tar.xz
 509c30a8d49d8530e3cc95bf0ba36496dd092875 27894 live-tools_4.0~a12-1_all.deb
Checksums-Sha256: 
 6b79c0b7179966f75cac8be111ea9606aa61a673529fccce8b52e71c072d93f3 1286 
live-tools_4.0~a12-1.dsc
 3ba1e8e8ec54082d689b2da4be3c4699b42a08de9105e5f906f9e67fa5989fcb 27036 
live-tools_4.0~a12.orig.tar.xz
 8de140723e0f66e4f20e7e2683a131789a36b2d66df0fa31b32f525f59ae64c3 5520 
live-tools_4.0~a12-1.debian.tar.xz
 45406b0294d57823c758ef932188cbb951d7cfb0c6d97487a4fbe083eb8308d8 27894 
live-tools_4.0~a12-1_all.deb
Files: 
 83cfb6325ecff09e2490bd0408576c99 1286 misc optional live-tools_4.0~a12-1.dsc
 c2de3ef11f77c3bea3c99a9a5ea5365d 27036 misc optional 
live-tools_4.0~a12.orig.tar.xz
 6c498bbef669d4b5e3dd90e9dccec168 5520 misc optional 
live-tools_4.0~a12-1.debian.tar.xz
 c787bedd2c17bf2312da470515f3a0b1 27894 misc optional 
live-tools_4.0~a12-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZL38ACgkQ+C5cwEsrK57kEwCgyW8E44G133geqtjqSsxx65Lw
L8QAoJ+NNP71gHBEHJkXdgIGquO5sZXj
=wKeE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umym5-0007bs...@franck.debian.org

Accepted cacti 0.8.8a+dfsg-4 (source all)

2013-04-01 Thread Paul Gevers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 01 Apr 2013 08:03:11 +0200
Source: cacti
Binary: cacti
Architecture: source all
Version: 0.8.8a+dfsg-4
Distribution: unstable
Urgency: low
Maintainer: Cacti Maintainer pkg-cacti-ma...@lists.alioth.debian.org
Changed-By: Paul Gevers elb...@debian.org
Description: 
 cacti  - web interface for graphing of monitoring systems
Closes: 702690
Changes: 
 cacti (0.8.8a+dfsg-4) unstable; urgency=low
 .
   * Improve jquery tree patch to show trees multilevel (Closes: #702690)
Checksums-Sha1: 
 49fc58a3a17f2e9517ec3bf51b4496b7bc957b1e 1655 cacti_0.8.8a+dfsg-4.dsc
 977f6c8dc2c631d7f34617be01b7f77851d0a69e 104289 
cacti_0.8.8a+dfsg-4.debian.tar.gz
 49dd4081056d1b9a77a28f637eeb6b91112463f4 2140694 cacti_0.8.8a+dfsg-4_all.deb
Checksums-Sha256: 
 03cb53d0eb0ec7c61967f7e0ef7fcfe617d77f2bec50f62f7b39396fd514f292 1655 
cacti_0.8.8a+dfsg-4.dsc
 6086c47be42cfb61b606c1d8ea0bdab9f5bb774afcbe9b13ffba45b20e202971 104289 
cacti_0.8.8a+dfsg-4.debian.tar.gz
 7c4df0ef6e6d60d5b9b140680c2166f99cd97afcd2940bc500398cca13a76bce 2140694 
cacti_0.8.8a+dfsg-4_all.deb
Files: 
 7ada7fa6425f5684a39d9fbc7ece0020 1655 web extra cacti_0.8.8a+dfsg-4.dsc
 627716c4e1521348ffd9398ca7312aa7 104289 web extra 
cacti_0.8.8a+dfsg-4.debian.tar.gz
 4c430afcb3d02b1a122d3e08919f9a41 2140694 web extra cacti_0.8.8a+dfsg-4_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJRWTVsAAoJEJxcmesFvXUKgHIIAMYvS9k9E7EiYqZukZEE0ele
7KWCgbzayjmOje193NvJKIXd62Hn4g6y5Ehj69dwblX4/D12EfbfBjf9ISzqm7Xl
eL+aksRXSHD+vHb+tC+Hq4hAuDG1L3B1LaD58M6I1dT3XnAotLIhTP13qy14hB3x
vrJLpPNCgG1R6sFQ9NO4clg6Elb+b8brcpew9DNyOCCo13MTH5X3FJXxZMT2RPi4
9r9De8eRK/W263ktOFUIvBy5fbpuk5q0dgk6E02tWI5wG7SAhSBm+NYJ9NYuJ1+L
D5aUV/CLs98G7uareSXTzXYzMb/mk9zJeFkjL10+yG949HxvUaoMYwVYXabl7ks=
=4v83
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umzej-0005tt...@franck.debian.org

Accepted herold 6.1.0-1 (source all)

2013-04-01 Thread Mathieu Malaterre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 10:01:31 +0200
Source: herold
Binary: herold
Architecture: source all
Version: 6.1.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian XML/SGML Group debian-xml-sgml-p...@lists.alioth.debian.org
Changed-By: Mathieu Malaterre ma...@debian.org
Description: 
 herold - HTML to DocBook XML conversion
Closes: 697525 698421
Changes: 
 herold (6.1.0-1) unstable; urgency=low
 .
   * New upstream. Closes: #697525, #698421
   * Refresh patch
Checksums-Sha1: 
 d1412183adbd5423af558fa4a6ff85a9d9015ee5 2129 herold_6.1.0-1.dsc
 9466b6bb15e9f5165f8fb32943c5174a794b6243 217678 herold_6.1.0.orig.tar.gz
 e425ad5b2f773fc971e9304f9292bd6f612da983 11034 herold_6.1.0-1.debian.tar.gz
 b82d157f891249f4c5e4bc3667e5d3d0fc7a2569 474082 herold_6.1.0-1_all.deb
Checksums-Sha256: 
 c6160fc5885aef28156b489889eb5745dc295a6d14eab944ee7ed63f0cb4f2cd 2129 
herold_6.1.0-1.dsc
 3256e0450fab4dce24911511baad35ac4cd82179719922e55043dbb3b3cd517a 217678 
herold_6.1.0.orig.tar.gz
 1404dd48dd11162ff9449d4ae69c55d356a53aa3a46ceee04fcd37c95f787c95 11034 
herold_6.1.0-1.debian.tar.gz
 691d0f55b9a608ebb9812d57d4fb0e0edd1b5970eaee7b1d26077b1c4f8dd2a0 474082 
herold_6.1.0-1_all.deb
Files: 
 e0a42c59c5d2bea2198ad1e3b413156d 2129 java optional herold_6.1.0-1.dsc
 051a170a86e69791f25a4502d2e671eb 217678 java optional herold_6.1.0.orig.tar.gz
 531c226c9546e94609174f2ef3a3ee0f 11034 java optional 
herold_6.1.0-1.debian.tar.gz
 d6de48541ad5124cb558712eb444116f 474082 java optional herold_6.1.0-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJRWUGaAAoJEAFx4YKK4JNFz9gQAIRtVXRNcKUjfYdUWMrMoF+Q
koUJZF7G4UR3HAuQUiu76xIy1MJhziftzbrI7a5YdJSHq8FKzCRofH3IJUsnbTE6
SdlxiFCK8OXG112SBJMUOPdl896mcJOztM/NKizpPOW1BwJD/51Hr6aCTqNSZj29
tQ04eVBc11n2CMg6Z6E5ceOAeS8QYXpX1uaUYMe8Ww+vEVYmyQsXMJ07HfOzs3fX
KdrLNa+Bg5nH7u907Si5lrVoL6ciB+gtIifIGHCJfiITt06nCT6rzyo4IqMRJBuy
8NJQhzcfm0yG5qKUtAh37kErqKGLldW9NLGXnjozcgS5bF4ztyQXjTQTMZ3OLesH
wb2Vbv9CizH67QEtat42z0P9smk2ErUggtOYTGPOVU3SMCmaabK6tnhj5QUmDMuZ
CDRmC5CAZAj4ojw/ByKjI6tziDEb9rey1ogdJqJPtBqWto66/qKy6HBW6rBGDx+Q
3l36VI5WXdgK5lP4nzmvxfwGwO2/LeCdRW669dPT+3MHyxLiZeYPCg1S26uAwN6O
gtJ+cXq9kg8IHPeQG2UOUmXMB6x1s0Vz27N1Gfib1d4kZC2cNwfl4q5+2RuEG/K7
KtXlzTfYYpwGJYO2gafVBrWjNI7W8uGNpgh3ATnQ6KGNJt1GI7u0GaOvK2PUudqB
7Rg1KfcnamyByAS/icO5
=QtZ/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umaot-0006lj...@franck.debian.org

Accepted jpegoptim 1.3.0-1 (source amd64)

2013-04-01 Thread Mathieu Malaterre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 09:53:17 +0200
Source: jpegoptim
Binary: jpegoptim
Architecture: source amd64
Version: 1.3.0-1
Distribution: unstable
Urgency: low
Maintainer: Mathieu Malaterre ma...@debian.org
Changed-By: Mathieu Malaterre ma...@debian.org
Description: 
 jpegoptim  - utility to optimize jpeg files
Changes: 
 jpegoptim (1.3.0-1) unstable; urgency=low
 .
   * New upstream 1.3.0. Optimize progressive JPEGs
Checksums-Sha1: 
 41d25ccfbde7d0965eba549d994c81bdcd935a7d 1896 jpegoptim_1.3.0-1.dsc
 02bf879a6c2a960e51a9e2b45c6eb342b2363783 92515 jpegoptim_1.3.0.orig.tar.gz
 995f60ea4b0395f20380c21c7035dd4192257aa0 2350 jpegoptim_1.3.0-1.debian.tar.gz
 ddc9781c94cb11fb73d9e0babbaf5e4de4d8532e 16446 jpegoptim_1.3.0-1_amd64.deb
Checksums-Sha256: 
 7de474acd7590991bac72ba1738e48b1e3a8b2d73f4e9315eebf5782c709b2e6 1896 
jpegoptim_1.3.0-1.dsc
 ee07cab6ee6fb438d82785258a86da7c101e28817d24f2d0f0ded7efc55bafc4 92515 
jpegoptim_1.3.0.orig.tar.gz
 5d3bb410c7e407f2901b68dac08939b6fd0f5ee1770a18cbd16e7a5403368afb 2350 
jpegoptim_1.3.0-1.debian.tar.gz
 efbeeb43949367364e432a0454ce69b1cfa1e97d6e54a6e7e1879b17211c40ac 16446 
jpegoptim_1.3.0-1_amd64.deb
Files: 
 82ec93ef421afcc8400bedb6f6d9f73a 1896 graphics optional jpegoptim_1.3.0-1.dsc
 508bf9f129d557abfa14b09b174a5216 92515 graphics optional 
jpegoptim_1.3.0.orig.tar.gz
 87e6856a7fd7058bfae446b1aa6582aa 2350 graphics optional 
jpegoptim_1.3.0-1.debian.tar.gz
 56e453ddd6880d0c1b000acf35d4bdf0 16446 graphics optional 
jpegoptim_1.3.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJRWT1NAAoJEAFx4YKK4JNFdzcP+wax4KvPyoXFe+XFqxtf74/x
jxfE/rFLGGzMJdRdfUd3qbFWr9XeWT8dFPuMulYokBFvD35LFilfEDKumR84soPg
WEJwAoeYc3txSlQwtscOjR9HZgR03WsJSHOA5hP4jiD5Fe/ySf0GG2zHEucSuz7t
tljaTeSAfsycOp1L2VvZv7Spg6Wl4MGR80qnEyYfsioS6yQa/2gE6iWKzH2e1Q4d
Cqo+VjhpZ73UM01y4mSr+y6nInntq1WiKmtsM+2MVV0mPqdmiagncd7A7TUK7xZP
5zfSusvFqvTQXgRfLF0W8im/KoT8Oh4/9kCkHrZA/UFcWU18YJkSqhxWnm3/BrFY
jwAlRhluoIFrXQ53jZ1wf9jdsKYvkAMpSjfG2ubQBcBortwFVEf3fcGJgZxGYCAt
ba6Mj7DGaHT+Hh6ZEVB6DqKzeLoAHLzjEH4K4RAmZAix2PGXiazRggvoKzUUnndh
heHk4oQtutDoQ+lvtjDEM1cJdwW2dwLgTGsCodTtyBB12rQx9com8lGJXVI3DDDf
mvaFSAiIq91Ch5ruGLM19lXULl734i028mdobXeuyuJToWbdOHnV68i2k//zZFUX
OGlgLd732UTH5AiL85anyMO9iPR3UYimWIe6iBJlBC09AmtysqFnWx82EsX0Nq23
uO+2/wGUd9QhytBLMWhP
=VRUm
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umaoy-0006ou...@franck.debian.org

Accepted live-images 4.0~a11-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 08:40:02 +0200
Source: live-images
Binary: live-image-all live-image-gnome-desktop live-image-kde-desktop 
live-image-lxde-desktop live-image-rescue live-image-standard 
live-image-xfce-desktop
Architecture: source all
Version: 4.0~a11-1
Distribution: unstable
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-image-all - live-build configurations (metapackage)
 live-image-gnome-desktop - live-build configuration for the GNOME desktop live 
images
 live-image-kde-desktop - live-build configuration for the KDE live images
 live-image-lxde-desktop - live-build configuration for the LXDE desktop live 
images
 live-image-rescue - live-build configuration for the rescue live images
 live-image-standard - live-build configuration for the standard live images
 live-image-xfce-desktop - live-build configuration for the Xfce desktop live 
images
Closes: 703179
Changes: 
 live-images (4.0~a11-1) unstable; urgency=low
 .
   [ Daniel Baumann ]
   * Debranding package for derivatives.
   * Adding script used to build pre-built wheezy image sets.
   * Building non-free set with KMS disabled for radeon and nouveau for the
 time being to workaround boot errors caused by missing integration
 with the binary-only drivers (Closes: #703179).
   * Adding examples to automatic syntax checking in toplevel makefile.
   * Intending lb config options for easier diffing.
   * Handling source enabled/disabled trigger from within auto/config
 rather than from the build script.
 .
   [ Ben Armstrong ]
   * Adding sudo to installer list to ensure post-install cleanup doesn't
 remove it.
Checksums-Sha1: 
 adde9257624585f7754dc9d12aba54f3421b361b 1700 live-images_4.0~a11-1.dsc
 cd35f07e0795341d79fb9d442b0efab004446007 26412 live-images_4.0~a11.orig.tar.xz
 184e4063740baca0120cf2d926d64636ec20b3dc 3856 
live-images_4.0~a11-1.debian.tar.xz
 36e006ba5c53dc143a3900e2cabe34ddbad30ddd 6046 live-image-all_4.0~a11-1_all.deb
 5fdd66d9ddc890c32f6e1bb0a4d6a4a6aa58efe9 10580 
live-image-gnome-desktop_4.0~a11-1_all.deb
 f84e46d59e8bbd66030a0267a7ef61bfa0e85e00 10540 
live-image-kde-desktop_4.0~a11-1_all.deb
 4fe479e64c8b1c91375e7f798a900d421f11f624 10564 
live-image-lxde-desktop_4.0~a11-1_all.deb
 25f3adeed4d49a6bf98d7dfd7de62eb4cb67c4c6 12208 
live-image-rescue_4.0~a11-1_all.deb
 05087992d6e1cf3eacaea9cba2350cc8380dabe0 10020 
live-image-standard_4.0~a11-1_all.deb
 79c4f2b1b65acef157d3723d94eb980b53388699 10550 
live-image-xfce-desktop_4.0~a11-1_all.deb
Checksums-Sha256: 
 989dbd99e442b1def836547455ed1dc8400c8d15fa321715b8c4793cd93f05b1 1700 
live-images_4.0~a11-1.dsc
 bd61fe9acec966cddfff26c01f236eb9bc38614a43fdbefa27cdfc22ab933785 26412 
live-images_4.0~a11.orig.tar.xz
 b133cda94ec1b5d0fd731654d94eab9a9b3150fb576af376a2b22031b4a75154 3856 
live-images_4.0~a11-1.debian.tar.xz
 41422cf21e187d5f08786d72cbdaf53e75fa33a1e045a8679a67ede2d536f39b 6046 
live-image-all_4.0~a11-1_all.deb
 e38082ee8b47a53444f2e1443415ba686031915774800057b8bcc37597a05487 10580 
live-image-gnome-desktop_4.0~a11-1_all.deb
 f2085ef13f565270bf3006714116cabc3ebac735128f2b39ad21f5dd0d96cf8f 10540 
live-image-kde-desktop_4.0~a11-1_all.deb
 886b77a6f0f2d73bd5c608886d6da27eb143c1d78334c0bbfbf0cdbc708b7fa6 10564 
live-image-lxde-desktop_4.0~a11-1_all.deb
 d6266d1a67a49d9359196690019494ace5472c7729489fb44f2057ec0195 12208 
live-image-rescue_4.0~a11-1_all.deb
 f52b6520b9e1414fa8901e6a6fb1afb7e79ba447e68a64f19e86aa52061f32c9 10020 
live-image-standard_4.0~a11-1_all.deb
 6a1fb7fb3c264856ffc708ae3670dd0a3cdb2735f21f8189b03ea816f96a3c8c 10550 
live-image-xfce-desktop_4.0~a11-1_all.deb
Files: 
 36c2f6ec1d0ab3a2d4441448a87b1f2f 1700 misc optional live-images_4.0~a11-1.dsc
 bceda61471e95fc5d797dd7496b601c0 26412 misc optional 
live-images_4.0~a11.orig.tar.xz
 957e536fff9b1cc5dfd408332b0daebe 3856 misc optional 
live-images_4.0~a11-1.debian.tar.xz
 666418c3c587134cf4e74e8370f4196e 6046 metapackages optional 
live-image-all_4.0~a11-1_all.deb
 bcd98455d4c61ab03cac7d17ff240da1 10580 misc optional 
live-image-gnome-desktop_4.0~a11-1_all.deb
 b921e7ce57f259d4acf151799744c37b 10540 misc optional 
live-image-kde-desktop_4.0~a11-1_all.deb
 6f03cb159acc96a97703b3b74008c7be 10564 misc optional 
live-image-lxde-desktop_4.0~a11-1_all.deb
 9fff01eb7df3aba2150587f69fbea55f 12208 misc optional 
live-image-rescue_4.0~a11-1_all.deb
 2952cabba1b51912eefe524e354a5ae6 10020 misc optional 
live-image-standard_4.0~a11-1_all.deb
 baf348b1ce0fa909143fbfabe13cf6a7 10550 misc optional 
live-image-xfce-desktop_4.0~a11-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZRRUACgkQ+C5cwEsrK555aQCfRdHGBQaV4CQMMrCPSaRsz9M0
534AniO5yzu9PUt6qOs10IgmWvhe1e7h
=GE3R
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of

Accepted live-manual 1:4.0~a4-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 09:00:24 +0200
Source: live-manual
Binary: live-manual live-manual-epub live-manual-html live-manual-odf 
live-manual-pdf live-manual-txt
Architecture: source all
Version: 1:4.0~a4-1
Distribution: experimental
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-manual - Live Systems Documentation (metapackage)
 live-manual-epub - Live Systems Documentation (epub)
 live-manual-html - Live Systems Documentation (html)
 live-manual-odf - Live Systems Documentation (odf)
 live-manual-pdf - Live Systems Documentation (pdf)
 live-manual-txt - Live Systems Documentation (txt)
Changes: 
 live-manual (1:4.0~a4-1) experimental; urgency=low
 .
   [ Daniel Baumann ]
   * Debranding package for derivatives.
 .
   [ chals ]
   * Fixing grammar error, order of negative adverb, in netbooting section.
   * Using 'netbooting' instead of 'netboot' as it sounds more natural in
 English.
   * Updating the tftpboot path which still showed currently unused
 directories.
   * Updating server configuration to make it a bit more complete in
 netbooting section.
   * Updating the translated user_basics files from the English one.
   * Updating Catalan translation.
   * Fixing an error in the Catalan translation of user_basics.
   * Using 'mida' instead of 'tamany' in about_project and project_bugs,
 Catalan translation.
   * Translating the word 'font' correctly, Catalan translation.
   * Updating the dates in live-manual files.
   * Revising the use of the prepositions 'per' and 'per a' making changes
 accordingly throughout the manual, Catalan translation.
 .
   [ Ben Armstrong ]
   * Clarifying that licensing statement is optional.
 .
   [ chals ]
   * Updating the dates in live-manual files.
   * Updating project_contributing files from the original English file.
   * Updating Catalan translation of project_contributing.
   * Updating Spanish translation of project_contributing.
   * Updating the dates in live-manual files.
   * Translating the appendix_style-guide into Catalan, reaching 100%
 complete for the first time in that language.
   * Unfuzzying the date in the Catalan translation.
   * Removing comment from the header of the Catalan appendix_style-guide
 po file.
   * Updating dates in live-manual.ssm and .ssm.po files.
   * Updating Spanish translation.
   * Translating the appendix_style-guide into Spanish, 100% complete
 translation.
   * Removing comment on the headers of the appendix_style-guide of the de,
 fr, it, pt_BR and ro language directories.
   * Updating the dates in live-manual.ssm, live-manual.ssm.po and live-
 manual.ssm.pot files.
   * Clarifying that native speakers refers to native speakers of English
 in the appendix_style-guide.
   * Using 'might' where appropriate in the appendix_style-guide to make
 the meaning of the sentences more clear.
   * Fixing typo 'a/an' in user_basics.ssi.
   * Simplifying the 'Bootloader' section.
   * Renaming the 'Bootloader' title to the plural form.
   * Updating translations from the English files.
   * Updating Catalan translation of several files.
   * Updating the Spanish translation of several files.
Checksums-Sha1: 
 f713e14869b1d774088c1af6250d9131091f820e 1787 live-manual_4.0~a4-1.dsc
 5e51110cabf1f1794eb109772f15626f45a7a7d8 335544 live-manual_4.0~a4.orig.tar.xz
 7c50c83a09b672b27a8e7113743f111360d1514d 27716 
live-manual_4.0~a4-1.debian.tar.xz
 bc206213cce8f185561840bd754524194455d0de 31050 live-manual_4.0~a4-1_all.deb
 944f0d2372cf8908b55d5ce71c0e65211b2f82e5 817000 
live-manual-epub_4.0~a4-1_all.deb
 73c686dc4fdc977602f3c3d5fa832a76d60bd5f7 392326 
live-manual-html_4.0~a4-1_all.deb
 f8ce58f09c769a78909f14bb8f8971f344ab5dd5 533816 
live-manual-odf_4.0~a4-1_all.deb
 e67b18936d69216eb39be58395176d99144771ce 11728026 
live-manual-pdf_4.0~a4-1_all.deb
 9669ae9b4fb028a9e5689d7e83ba9fccac81989d 459420 
live-manual-txt_4.0~a4-1_all.deb
Checksums-Sha256: 
 4c262f8cc9c5635865e829991ed5e32adc264a4512c7d0bf559722646581c713 1787 
live-manual_4.0~a4-1.dsc
 fc8a7aabcdbac58c505f03915ee4c415a3a86d8fed5e767bd84789a29286baa7 335544 
live-manual_4.0~a4.orig.tar.xz
 bdd04babce083af41f296a757f0d92139e7eae304c111266771bc36b881f1bbf 27716 
live-manual_4.0~a4-1.debian.tar.xz
 3895d37a39894f083723c67efcc522daac18a27d37ac4594e2ed2b46f219577f 31050 
live-manual_4.0~a4-1_all.deb
 61bd54e76eb58dff6692f64c97ceb069b57392f1aad120ead8bc132b98c9aeea 817000 
live-manual-epub_4.0~a4-1_all.deb
 6c84aebd77c8454d69de37c84f2a27c360889f86e659fc7e026903a2b6fc755c 392326 
live-manual-html_4.0~a4-1_all.deb
 07eb1950073f5961db6b269f5ff18cd46e298ec454df5b3dcef443dc9d77c2ae 533816 
live-manual-odf_4.0~a4-1_all.deb
 319a44ba95bc2771d00f0f0dbed8dac57e912464896ff875f7136468ed98fd0f 11728026 
live-manual-pdf_4.0~a4-1_all.deb

Accepted buildbot 0.8.7p1-1 (source all)

2013-04-01 Thread Andriy Senkovych

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Mar 2013 17:56:25 +0200
Source: buildbot
Binary: buildbot
Architecture: source all
Version: 0.8.7p1-1
Distribution: unstable
Urgency: low
Maintainer: Andriy Senkovych jolly_ro...@itblog.org.ua
Changed-By: Andriy Senkovych jolly_ro...@itblog.org.ua
Description: 
 buildbot   - system to automate the compile/test cycle
Closes: 692451
Changes: 
 buildbot (0.8.7p1-1) unstable; urgency=low
 .
   * New upstream release (Closes: #692451).
   * Update patches.
   * Remove temporary code for fixing permissions.
   * Use /usr/bin/trial to run tests.
   * Run dh clean with no extra arguments.
   * Introduce config for git-buildpackage: debian/gbp.conf.
   * debian/control:
 - prettify Depends
 - bump Standards-Version to 3.9.4.0 (no changes required)
 - specify minimal supported version for python-sqlalchemy
 - add python-dateutil (=1.5) to Depends and Build-Depends (required by
   nightly scheduler).
 - add libaprutil1 to Build-Depends and to Recommends (required by web
   htpasswd auth).
Checksums-Sha1: 
 1b9c436c40d181e548502b75473967cb109a63ce 1412 buildbot_0.8.7p1-1.dsc
 9801e513960cbfbdd05ff3c8309acdde5d0528c1 4580890 buildbot_0.8.7p1.orig.tar.gz
 8150fc82c24944b2b8d87a3fb033c86574c11170 7646 buildbot_0.8.7p1-1.debian.tar.gz
 9d3c6cc2b2f4d26ac1a14e230ceddbcd476ff0c0 2513054 buildbot_0.8.7p1-1_all.deb
Checksums-Sha256: 
 d335a6849c816469e8033bf894a71ece536211f1c1f7f4c85b6d9490d5f9df2c 1412 
buildbot_0.8.7p1-1.dsc
 32ae706c60673b6939e7a1cafa136dd2ff2832ca8e2fe410a4cf911950309a88 4580890 
buildbot_0.8.7p1.orig.tar.gz
 c84505a1dbdc4620884a83fe4c7d9d5456c6d039253154201c92cf0d14966b8e 7646 
buildbot_0.8.7p1-1.debian.tar.gz
 f1d7f0f6ac64f3caf6e0807464a0f2328ace61756c22e30252f8e52ddcf13741 2513054 
buildbot_0.8.7p1-1_all.deb
Files: 
 4f497f9900e3203241b7011b6e0b57af 1412 devel optional buildbot_0.8.7p1-1.dsc
 b36658577892071c4f2f068d8db7197f 4580890 devel optional 
buildbot_0.8.7p1.orig.tar.gz
 d0a4cc632025e12ebfaa88cc400a4dd6 7646 devel optional 
buildbot_0.8.7p1-1.debian.tar.gz
 6793b242848ab21a14e22a5e5973dcf7 2513054 devel optional 
buildbot_0.8.7p1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZS3gACgkQStlRaw+TLJxldwCeMkdRxiXVqoTZ9fZOZM1/+Z0w
Kb8An1qAPjTnh4lb5+HJSfGpsnWEDzqC
=JkuA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umadq-0001ov...@franck.debian.org

Accepted buildbot-slave 0.8.7p1-1 (source all)

2013-04-01 Thread Andriy Senkovych

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 18 Mar 2013 13:01:55 +0200
Source: buildbot-slave
Binary: buildbot-slave
Architecture: source all
Version: 0.8.7p1-1
Distribution: experimental
Urgency: low
Maintainer: Andriy Senkovych jolly_ro...@itblog.org.ua
Changed-By: Andriy Senkovych jolly_ro...@itblog.org.ua
Description: 
 buildbot-slave - system to automate the compile/test cycle
Changes: 
 buildbot-slave (0.8.7p1-1) experimental; urgency=low
 .
   * New upstream release
   * Enable unit testing during build.
   * Introduce config for git-buildpackage: debian/gbp.conf.
   * debian/gbp.conf: use master branch as primary debian branch
   * Add python-twisted-core and python-mock to build-depends to run unit tests
   * debian/control:
 - prettify Depends
 - bump Standards-Version to 3.9.4.0 (no changes required)
Checksums-Sha1: 
 cf80e2987ee63bffcaa65702efbb6990cba0b100 1247 buildbot-slave_0.8.7p1-1.dsc
 e8488225e79a45ace4573b3dce0ddb7e679ed200 103684 
buildbot-slave_0.8.7p1.orig.tar.gz
 bb08a06662fe36291d2ff499364d8897f0d18fd7 5913 
buildbot-slave_0.8.7p1-1.debian.tar.gz
 a0cf218ce5967ecce47fb78d69b928f61e3ef2ca 101900 
buildbot-slave_0.8.7p1-1_all.deb
Checksums-Sha256: 
 cf45e37e5cc914d81a55ec665a9b54c54d95cde3f4ed873f432005154c867631 1247 
buildbot-slave_0.8.7p1-1.dsc
 bc540ac3a60f3c66ff84ba99e8532b37c4a57888ddee7820fef9ca721791579a 103684 
buildbot-slave_0.8.7p1.orig.tar.gz
 ef521d98b1d5f8871a1e7610ee42a39447d676ba2013ae15c6c1e7d238455650 5913 
buildbot-slave_0.8.7p1-1.debian.tar.gz
 f00f3716c100a01887575db68e6cd645ef90a275de1d5251f22e92c98b1385b4 101900 
buildbot-slave_0.8.7p1-1_all.deb
Files: 
 1e6691207c670b8364d4c991db3155d3 1247 devel optional 
buildbot-slave_0.8.7p1-1.dsc
 15fa87eb2c3c1b33644e226557dd81ef 103684 devel optional 
buildbot-slave_0.8.7p1.orig.tar.gz
 ae2a4818ee7fa8f620635da4e5f93593 5913 devel optional 
buildbot-slave_0.8.7p1-1.debian.tar.gz
 ff9a42d1d7819824305bc795f4bcc206 101900 devel optional 
buildbot-slave_0.8.7p1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZS6UACgkQStlRaw+TLJw5CQCfSHGY4/EYO7PEVs93Re6PosZJ
07YAnjBfkc3kfK3mb+zqZtPaAfEgi1we
=/r/j
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umadv-0001rv...@franck.debian.org

Accepted file 1:5.11-3 (source amd64)

2013-04-01 Thread Luk Claes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 10:20:18 +0200
Source: file
Binary: file libmagic1 libmagic-dev python-magic
Architecture: source amd64
Version: 1:5.11-3
Distribution: unstable
Urgency: low
Maintainer: Luk Claes l...@debian.org
Changed-By: Luk Claes l...@debian.org
Description: 
 file   - Determines file type using magic numbers
 libmagic-dev - File type determination library using magic numbers 
(developmen
 libmagic1  - File type determination library using magic numbers
 python-magic - File type determination library using magic numbers (Python 
bin
Closes: 704326
Changes: 
 file (1:5.11-3) unstable; urgency=low
 .
   * Taking over maintainership (Closes: 704326).
   * Updating Standards-Version (no changes).
   * Do not ship python-magic-dbg as it is currently empty.
Checksums-Sha1: 
 819cb7729cbd8cfa2bda738cf99b5219073eeb15 1856 file_5.11-3.dsc
 865a69d0407376d43b62f6819afaea5e4a6aff81 24184 file_5.11-3.debian.tar.xz
 5212c77e4b1c8af0fb26d0d3078be48abf4a0030 51978 file_5.11-3_amd64.deb
 6528c39f1dc1653d60e1be5546ea6d7113bca775 202126 libmagic1_5.11-3_amd64.deb
 02ca5afc22aea1a91d2c7a1e04e84c0259d2a2c6 91776 libmagic-dev_5.11-3_amd64.deb
 7a8e568b6ff66c24ceec173fc59d11dc39f7436d 38482 python-magic_5.11-3_amd64.deb
Checksums-Sha256: 
 244f1ccdfa952e5fcc1775a05dae02fa7472a291b19810cb9b4cf11dde78750f 1856 
file_5.11-3.dsc
 ae2087deedd956bc76c0590ac1aaa631d70eb7f99404b6f2bffa60a69ad10389 24184 
file_5.11-3.debian.tar.xz
 935fff7c5577cccf0b1bffee24659211d1d9f38e7bc1445db85fe0109b1d371d 51978 
file_5.11-3_amd64.deb
 bbfc03d711a968ba6316bb27500c7344aa007d25188b6796746b19b16b5a75ef 202126 
libmagic1_5.11-3_amd64.deb
 b84d808067dbe978fe326b126b00019288184c41600d5a669cd20e5dc488a4d0 91776 
libmagic-dev_5.11-3_amd64.deb
 8aadef04973146d0577926bd178e903631e19ca67a4e885c042068d0e02c9227 38482 
python-magic_5.11-3_amd64.deb
Files: 
 2ee4848addfd03f2bcfbcd5496d65f26 1856 utils standard file_5.11-3.dsc
 ad95c6c256a97010196e11a3dfa19c37 24184 utils standard file_5.11-3.debian.tar.xz
 c1bbbedfcd09742062b3f75405487752 51978 utils standard file_5.11-3_amd64.deb
 1bedaa11ea63b8bdc86df6708aa784b0 202126 libs standard 
libmagic1_5.11-3_amd64.deb
 e2119076aa07cc6ce98c6760f4328c6e 91776 libdevel optional 
libmagic-dev_5.11-3_amd64.deb
 c0e22f25bfb934859cc55ee293cf6f19 38482 python extra 
python-magic_5.11-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRWUwzAAoJECEnNxubsjBiCZYP/j/lBuZvr7GNcKuh3P6WNVQ3
Un5NudHuxDLFqpV9MCxXDR5nkYxepG+1pKGPcJM6mqsKET8BexJ8TKfS7ttldKXb
E/enTFwJZae2A10TJkZwwMrYTohk1i8+MPUL478Pzzlj8wfr2RWT2x3VXO79cdGZ
4XqNiYCGSvdCZFpVst5xdqu9IZv2j2/SwO6WevQFko+LxGuHEx7YqZyXKF+9BE6z
U7ddk3KizCMFiTafBLMEzA5qI/9b2BGwU4Q64PQHKfmp1WKYTc7+nfDQFYG6m6nX
cbwX9RA2vakYQspcQN9HZ29wuKT1kwo/EINyA3rZHSD+A1wM9o7XhSRo9h2kyN+e
3TS9st9Hxx2/pozSlfr5sauFzUUc5C0l2uCfIXm3ZH50v/f1EejtEb08+MPtVtLs
EiSxKSo0LSOW1WIjtfpxgbTFxgqfhDTBMFPaGOxSp6EXrGLii/foy2o5IWvrfznF
uY4ow/lCkT1F4SSAKH+oFmTsS6Hu0uag+hUWF+M42Vgfl2NIvgVzWWu0s+MseEJJ
d4YHI6rbXLhBSqP5DDFYx0nmexk7i6OYdC7B5jMxYLB+S5cCCvnX5nxLn4dKoLuL
9rtgVmRA6RCAB0i2ZF1R9TZ2W32vmeAQ5EMl+Ac7dWK4qSFhb9BPxOmR99Qsq1Vs
WHl2HKbfwv0GEytg90Ph
=Dkpc
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umadd-0001zw...@franck.debian.org

Accepted mummy 1.0.3-2 (source amd64 all)

2013-04-01 Thread Mathieu Malaterre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 09:33:20 +0200
Source: mummy
Binary: mummy libkitware-mummy-runtime1.0-cil mummy-doc
Architecture: source amd64 all
Version: 1.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Mathieu Malaterre ma...@debian.org
Description: 
 libkitware-mummy-runtime1.0-cil - Mummy CLI bindings
 mummy  - command line executable that generates C# wrappers from gccxml ou
 mummy-doc  - mummy class reference documentation
Closes: 703332
Changes: 
 mummy (1.0.3-2) unstable; urgency=low
 .
   * Fix ABI version. Closes: #703332
 + debian/libkitware-mummy-runtime1.0-cil.cligacpolicy
Checksums-Sha1: 
 ad638382fb1b7d7f8843162fa9382fc6e82de42a 2204 mummy_1.0.3-2.dsc
 df2d54fa1a4fa78006f56f14f5c31b40e158e6e2 7733 mummy_1.0.3-2.debian.tar.gz
 afc0be9ba2c2b885b805ed6074ec791f86d8130e 315668 mummy_1.0.3-2_amd64.deb
 3afb737e3e11c31319efc965d39d7fdde79c3cb6 28236 
libkitware-mummy-runtime1.0-cil_1.0.3-2_amd64.deb
 8aff6eb586860321b87d65f944025331e3161d37 970244 mummy-doc_1.0.3-2_all.deb
Checksums-Sha256: 
 ad3c59d6b3d25c5ed3028961fb9c012090c1b9bb99eb21478031c3b9c8283c73 2204 
mummy_1.0.3-2.dsc
 99b989c5e2239a921ae2b1d641c1c7f7f21ebe87b9e0d649dd447469377621da 7733 
mummy_1.0.3-2.debian.tar.gz
 a5f94a4026fc4244c8392fc586211ad7175174f4c72ec4ae956f74bbe7684901 315668 
mummy_1.0.3-2_amd64.deb
 5631e07d580212741afbefb5ccc1dcce572fe347a515483e24a429cf90deeb8f 28236 
libkitware-mummy-runtime1.0-cil_1.0.3-2_amd64.deb
 f0cde94d6f89979ae849a33d0b66cb1c14a183a2559a567193d7de378da7e11c 970244 
mummy-doc_1.0.3-2_all.deb
Files: 
 c6f68db96b97663b82d94309ffab5d6a 2204 devel extra mummy_1.0.3-2.dsc
 eb782295b0c5f50bc4c710fa5d1d8fab 7733 devel extra mummy_1.0.3-2.debian.tar.gz
 0b6b2fe13945c0c916c4a3bc9a477401 315668 devel extra mummy_1.0.3-2_amd64.deb
 2e551a8d54042b0d81e24bfabfea864d 28236 cli-mono extra 
libkitware-mummy-runtime1.0-cil_1.0.3-2_amd64.deb
 0fee1124007d3818c437b9fe0613c247 970244 doc extra mummy-doc_1.0.3-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJRWUomAAoJEAFx4YKK4JNFesQP/itDJJkwCBIGsEFtcl50WaSq
XnaLNGcXddN/nGNqnJhPdKRgPhdu6lsMGUQXZL3HJUGjIHMW4R25S8FShbz/b5Pf
Vo1IzQRaps//C1hvcSB85T9pj65oXU4K70jUUJjjrItbpKPaRIR7V4c17xZI0ygq
reIUjucX9hMfLMbX1H8BTVw5V77GIEKADbnC0Q/Uz2Rp8YZypt8vgUEqTza3evHU
iriU4vsdtqTHuzhtulM0BkLXG94cNS8Z9wZuezybb/CGO9f6U65HYcdr0WVJG78G
o4rmVgk8snFc2ndeJb/lbOzgmeHDd/0w0AzUBODp+FMlFMd69qLLqH/1E1/LKBgp
+lBFEHGjbo/tQmAs+utGuud3XWH/DDbY0v3WpMtRbA05+ueWN+SzFviwDdwhmnP/
SzkY1J1kvRnFNJQhyHN7MV9CaevpQwvUqVd+OZKDKXgau6bZ9nAd+rUrWEHj+Gt+
z5b9TkM/rbSuVjcnp85vCEOJbs/HN8+aYBH/ezmA9e6GWUW8bQreQ248LYDWVBI1
bISA52+4RR3UK5vskgt0wAzlvb/06CAqDviGSqLs93hZkqMR+PEtWGRhbubaz532
qGQVVo+KIedX8ox8kJudMa9e7h2uMneJaU1f1OmmEozbR6joFd24ssxk1BarVT5g
R+LZXSf1CHaSl8ZNShOg
=19sy
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umb6o-0005gj...@franck.debian.org

Accepted dosage 1.15-1 (source all)

2013-04-01 Thread Bastian Kleineidam

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 25 Mar 2013 19:52:49 +0100
Source: dosage
Binary: dosage
Architecture: source all
Version: 1.15-1
Distribution: unstable
Urgency: low
Maintainer: Bastian Kleineidam cal...@debian.org
Changed-By: Bastian Kleineidam cal...@debian.org
Description: 
 dosage - comic strip downloader and archiver
Changes: 
 dosage (1.15-1) unstable; urgency=low
 .
   * New upstream release.
Checksums-Sha1: 
 1584a6368bc0e9e2841e475d3ef62fb02b67bf4c 1062 dosage_1.15-1.dsc
 f3216ac6a0c44ed83d912cbc74e455743acf968d 369357 dosage_1.15.orig.tar.gz
 8c318c81c136cb3bdc739e06f6aebe54dd5aea1b 3982 dosage_1.15-1.debian.tar.gz
 672dffccc50a321ed2ddc86c09c700b0ba1641d5 232468 dosage_1.15-1_all.deb
Checksums-Sha256: 
 168cb5f8d58479bd9969c02558ef98d9dc12ceb419bbd6b1182317273984c699 1062 
dosage_1.15-1.dsc
 66f0c8d318856a003b00af93e3f9e1d20d5949e4b83fb2dc7a93f26849913487 369357 
dosage_1.15.orig.tar.gz
 f7a28d30291bded41449f0679735b365dbb4ba13a6e79b5540feb99c9070db19 3982 
dosage_1.15-1.debian.tar.gz
 92c509652e82a84cb9086fdbc5b5aec2cde07f3df4774a5ca7ed966972c570b4 232468 
dosage_1.15-1_all.deb
Files: 
 3b8ee49c865bfc96667535418b1eed0b 1062 net optional dosage_1.15-1.dsc
 413b74f8a625e08c9863a902d9102747 369357 net optional dosage_1.15.orig.tar.gz
 2e49301793b524cb107cb31f578668df 3982 net optional dosage_1.15-1.debian.tar.gz
 be8b36a209c3cab6b7ed1c740cd1bc1c 232468 net optional dosage_1.15-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZWIkACgkQeBwlBDLsbz6c1QCcDs3TOcMn6qeYlkammb1a0Zgz
eOEAn2bkbrZ5K81yGa/+TBjqt08TvO0H
=z8rk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umba6-0001pn...@franck.debian.org

Accepted krb5-auth-dialog 3.8.0-1 (source i386)

2013-04-01 Thread Guido Günther

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 10:21:01 +0200
Source: krb5-auth-dialog
Binary: krb5-auth-dialog
Architecture: source i386
Version: 3.8.0-1
Distribution: experimental
Urgency: low
Maintainer: Guido Günther a...@sigxcpu.org
Changed-By: Guido Günther a...@sigxcpu.org
Description: 
 krb5-auth-dialog - tray applet for reauthenticating kerberos tickets
Changes: 
 krb5-auth-dialog (3.8.0-1) experimental; urgency=low
 .
   * [4ed0c59] Allow for xz upstream tarballs
   * [6c66f3c] New upstream version 3.8.0
   * [e045c1c] Use GSettings instead of GConf
Checksums-Sha1: 
 5f8d4567fb83377b61ebb550941bce5e6332fd65 1563 krb5-auth-dialog_3.8.0-1.dsc
 eb00a1bfd28881057f703c189567e103fe55fe03 530116 
krb5-auth-dialog_3.8.0.orig.tar.xz
 4f68664bf67834e0bcb1ae7ff60f7cd612ab40ae 5714 
krb5-auth-dialog_3.8.0-1.debian.tar.gz
 43142e0d42209faf86e7b4c27632639f0fd56b2c 268328 
krb5-auth-dialog_3.8.0-1_i386.deb
Checksums-Sha256: 
 05d7f0e71876b6721bce4df868246203b0ec5b13a3ee5ffb22a6622fe10a260e 1563 
krb5-auth-dialog_3.8.0-1.dsc
 3446b38caa61b39660ac73be1cc25a63366936384c36e8d1fad5962af8cb3edf 530116 
krb5-auth-dialog_3.8.0.orig.tar.xz
 4d67aaa920a79d1a4d6af70d29b967c668012e659e90f6e1824025851d465152 5714 
krb5-auth-dialog_3.8.0-1.debian.tar.gz
 bdcad936e76d2b6ddfb92ea4ed8c0485680f715f82cf297e718aa3212a175f64 268328 
krb5-auth-dialog_3.8.0-1_i386.deb
Files: 
 4040e2fa1cb4dc7f2fc4764e29864488 1563 gnome optional 
krb5-auth-dialog_3.8.0-1.dsc
 5f158123eeb10905db2ffae425d7a4b1 530116 gnome optional 
krb5-auth-dialog_3.8.0.orig.tar.xz
 192d09facd4b897e07b44bf962331186 5714 gnome optional 
krb5-auth-dialog_3.8.0-1.debian.tar.gz
 89130fe808071d0eaacc4dd038dc10c4 268328 gnome optional 
krb5-auth-dialog_3.8.0-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iD8DBQFRWVkRn88szT8+ZCYRAol0AJ9bYm3bSHeUj/PZhbEUlIxcFp/mWQCcDSxy
KTSaEYwuLjugDs0SEbicV2s=
=AcT5
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umbah-0001w8...@franck.debian.org

Accepted harfbuzz 0.9.14-1 (source i386)

2013-04-01 Thread Ahmed El-Mahmoudy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 30 Mar 2013 22:17:31 +0200
Source: harfbuzz
Binary: libharfbuzz0 libharfbuzz-dev libharfbuzz-bin
Architecture: source i386
Version: 0.9.14-1
Distribution: experimental
Urgency: low
Maintainer: أحمد المحمودي (Ahmed El-Mahmoudy) aelmahmo...@sabily.org
Changed-By: أحمد المحمودي (Ahmed El-Mahmoudy) aelmahmo...@sabily.org
Description: 
 libharfbuzz-bin - OpenType text shaping engine (utility)
 libharfbuzz-dev - Development files for OpenType text shaping engine
 libharfbuzz0 - OpenType text shaping engine
Changes: 
 harfbuzz (0.9.14-1) experimental; urgency=low
 .
   * New upstream release.
Checksums-Sha1: 
 e06a8c5909230959b6057f9448462f9e81652bd5 1467 harfbuzz_0.9.14-1.dsc
 e12eb5a494453909deb7ec57700fa667c02332da 900959 harfbuzz_0.9.14.orig.tar.bz2
 5354c3f52afbb36c05acc1eee0e74bfcfd69ee59 4140 harfbuzz_0.9.14-1.debian.tar.gz
 8297cd734d9d9e125d1e73cfbdd3b7758d42157c 529440 libharfbuzz0_0.9.14-1_i386.deb
 648982e7ed03912d9dbbf2a3bf26a89cf72db1fe 272470 
libharfbuzz-dev_0.9.14-1_i386.deb
 44ce2e0d3abe6f20caeb76f46b35ec6ef95c4107 289972 
libharfbuzz-bin_0.9.14-1_i386.deb
Checksums-Sha256: 
 f7cbc0c4c1245701f426124e3e36361106c51989b7819c759c4a775cc687e363 1467 
harfbuzz_0.9.14-1.dsc
 d07c0ffdbbbfdfbb6c65e73fe9c76466e87dbf04b094cbd0abf5fd7d571a4004 900959 
harfbuzz_0.9.14.orig.tar.bz2
 129fd246b64acb33ea9674ee7c2c7204f40a2b0db6485e75ca5e21fcfdc928fc 4140 
harfbuzz_0.9.14-1.debian.tar.gz
 f91177676ba9792d2befa1cf1925e1ad250a6a80460f177bc33cbdab72149b13 529440 
libharfbuzz0_0.9.14-1_i386.deb
 09ff640e827ab46249af4c556c49b56b8a7bc448edf70e3ddcf966ab78a1410c 272470 
libharfbuzz-dev_0.9.14-1_i386.deb
 4185c325e5f0145b4940da3cf1a29c81973baf4b6f6e13192a240729d5790e1f 289972 
libharfbuzz-bin_0.9.14-1_i386.deb
Files: 
 ae706e516dbf5487bb40f63258fe0c2d 1467 libs optional harfbuzz_0.9.14-1.dsc
 7e1990b79060e98e2d31f677a0ac9eed 900959 libs optional 
harfbuzz_0.9.14.orig.tar.bz2
 88b1bbfeaead8e23e3853caca4a24067 4140 libs optional 
harfbuzz_0.9.14-1.debian.tar.gz
 08f400a1fb4fb6c213eac1877e0717ca 529440 libs optional 
libharfbuzz0_0.9.14-1_i386.deb
 891bde1e1bedc6484043b8a155fd7b1e 272470 libdevel optional 
libharfbuzz-dev_0.9.14-1_i386.deb
 91592a400b2d2b45a0b56df49d7d0b90 289972 utils optional 
libharfbuzz-bin_0.9.14-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZYVwACgkQhTV17EoIsv6KbwCguSKTWQ3JR1QDHrWQovOxXZCQ
q08An2rVZ8RI2te+XVae8heSw379T4XY
=uPor
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umc2x-0004ly...@franck.debian.org

Accepted memtester 4.3.0-3 (source amd64)

2013-04-01 Thread GCS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 11:56:19 +0200
Source: memtester
Binary: memtester
Architecture: source amd64
Version: 4.3.0-3
Distribution: unstable
Urgency: low
Maintainer: Laszlo Boszormenyi (GCS) g...@debian.hu
Changed-By: Laszlo Boszormenyi (GCS) g...@debian.hu
Description: 
 memtester  - Utility for testing the memory subsystem
Closes: 704327
Changes: 
 memtester (4.3.0-3) unstable; urgency=low
 .
   * New maintainer (closes: #704327).
 .
   [ Bart Martens ba...@debian.org ]
   * Add watch file.
Checksums-Sha1: 
 88ab7f66729fb15643d23b1c43be8e7658f25f58 1081 memtester_4.3.0-3.dsc
 a8a71401ea0178d303c64c866c10e9052db288aa 3256 memtester_4.3.0-3.debian.tar.xz
 6e8b4048321c118dd8c4366ad500eecbaf08f28f 18808 memtester_4.3.0-3_amd64.deb
Checksums-Sha256: 
 af6bdf1954a49821504b5840a3691e62a805dec1b982f9b57840816fb78f739d 1081 
memtester_4.3.0-3.dsc
 e4b7e1708f8915d8fe0b18a86d6dc8289b4e7bfc4742a88c1ef200996bf8a6ff 3256 
memtester_4.3.0-3.debian.tar.xz
 36262a78c9d0020b3fa432fb5f23a79cdcedaa583c648b6f1704d4bd1d69f182 18808 
memtester_4.3.0-3_amd64.deb
Files: 
 8917c2c83026804f412eef76e592c973 1081 utils optional memtester_4.3.0-3.dsc
 1f33b3215d2eaa745448d88a123cbe7f 3256 utils optional 
memtester_4.3.0-3.debian.tar.xz
 f7344d110863c9068c2b986f9add1221 18808 utils optional 
memtester_4.3.0-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZX14ACgkQMDatjqUaT92LtACgnHkX7WnYtqEtWChkN0nzsRxu
+KcAoIE1LDMZ/G0BSF8+Vq2rRfq4UlRj
=rdEl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umc2c-0004ui...@franck.debian.org

Accepted haskell-cryptohash 0.8.4-1 (source all amd64)

2013-04-01 Thread Joachim Breitner

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 13:10:40 +0200
Source: haskell-cryptohash
Binary: libghc-cryptohash-dev libghc-cryptohash-prof libghc-cryptohash-doc
Architecture: source all amd64
Version: 0.8.4-1
Distribution: experimental
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Joachim Breitner nome...@debian.org
Description: 
 libghc-cryptohash-dev - collection of crypto hashes, fast, pure and practical
 libghc-cryptohash-doc - collection of crypto hashes, fast, pure and practical; 
documentat
 libghc-cryptohash-prof - collection of crypto hashes, fast, pure and 
practical; profiling
Closes: 704452
Changes: 
 haskell-cryptohash (0.8.4-1) experimental; urgency=low
 .
   * New upstream release (Closes: #704452)
Checksums-Sha1: 
 78e4773a192e195534891f3f4b37e13559b04c8f 1992 haskell-cryptohash_0.8.4-1.dsc
 aa22b82a9adbf714331454b064174f98ee723a96 64666 
haskell-cryptohash_0.8.4.orig.tar.gz
 cd48043f16c9d5915b4a957a947ebb211fa9df16 2684 
haskell-cryptohash_0.8.4-1.debian.tar.gz
 3588bbf8dcc72d17e749b90c04a1ea5680de0706 100354 
libghc-cryptohash-doc_0.8.4-1_all.deb
 cff2aa5e5994dc1f65ff6fb2952e208ad2ae0e2c 333158 
libghc-cryptohash-dev_0.8.4-1_amd64.deb
 2351e73a32c3d954328282cd85f2ed13b7e5d419 308654 
libghc-cryptohash-prof_0.8.4-1_amd64.deb
Checksums-Sha256: 
 f60455739d2e645beecd612ca3f68d46ca9861093fdfe0b99cac7ea25b96b1ae 1992 
haskell-cryptohash_0.8.4-1.dsc
 b63ae45c3fc8e8a0bc346f143bad0668c7751e32f430a187f4f3eeccfa55a840 64666 
haskell-cryptohash_0.8.4.orig.tar.gz
 f98f1ec28dfbb771ab93cc33ba1f533c77a7e15dd1dd6e9e306bec6e89d0f80f 2684 
haskell-cryptohash_0.8.4-1.debian.tar.gz
 13d1d3b19f2acedb495486590712b8f32d93c70904c68c8866e47f556ca7b36f 100354 
libghc-cryptohash-doc_0.8.4-1_all.deb
 4f3d31152547111cec1b6e1f54bf86d6fa4b247aed126de131dd4ed23d0ca31c 333158 
libghc-cryptohash-dev_0.8.4-1_amd64.deb
 46e5bae411e6e404d9c12eb7e714e85b02165be23c2af2dcbeb164cecbf80f6d 308654 
libghc-cryptohash-prof_0.8.4-1_amd64.deb
Files: 
 e4a9aff78ba9179fcd2581c02fb77fac 1992 haskell extra 
haskell-cryptohash_0.8.4-1.dsc
 4459e4e7de79192f2e305c67af46bb51 64666 haskell extra 
haskell-cryptohash_0.8.4.orig.tar.gz
 05dcdce5614dab1960bb71abec5feea7 2684 haskell extra 
haskell-cryptohash_0.8.4-1.debian.tar.gz
 20cd964307844eafd8a1e24a988d92e8 100354 doc extra 
libghc-cryptohash-doc_0.8.4-1_all.deb
 adc535b10aa98169657020972f5677eb 333158 haskell extra 
libghc-cryptohash-dev_0.8.4-1_amd64.deb
 ce1f37ffd5a0776313d09cf0de592089 308654 haskell extra 
libghc-cryptohash-prof_0.8.4-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZbFQACgkQ9ijrk0dDIGwQLgCeJ8fCaTUWvZI+YYClFkqMq+fJ
+hYAoIacgytv8BZ8ifbSxqOWaw7zhRDo
=m7oc
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umcyy-0004nd...@franck.debian.org

Accepted pcsc-perl 1.4.13-1 (source amd64)

2013-04-01 Thread Ludovic Rousseau

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 01 Apr 2013 12:44:59 +0200
Source: pcsc-perl
Binary: libpcsc-perl
Architecture: source amd64
Version: 1.4.13-1
Distribution: unstable
Urgency: low
Maintainer: Ludovic Rousseau rouss...@debian.org
Changed-By: Ludovic Rousseau rouss...@debian.org
Description: 
 libpcsc-perl - Perl interface to the PC/SC smart card library
Changes: 
 pcsc-perl (1.4.13-1) unstable; urgency=low
 .
   * New upstream release
   * debian/control: Standards-Version: 3.9.1 - 3.9.4. No change needed.
   * debian/compat: 7 - 9. Get automatic hardening of compiled code.
   * debian/copyright: refer to a specific version of GPL
Checksums-Sha1: 
 eefb41223a763c4fb8babba112a444994d5fa950 1308 pcsc-perl_1.4.13-1.dsc
 2a3895953d5734cacd589b96a8a7890200da84d1 43170 pcsc-perl_1.4.13.orig.tar.gz
 eec2fbb2d236eed4eacffbc511da505dd0b2303c 3581 pcsc-perl_1.4.13-1.debian.tar.gz
 e6c90faa065978a23a1b6c3ee0a8309ae703b131 57152 libpcsc-perl_1.4.13-1_amd64.deb
Checksums-Sha256: 
 10afad876f032216e93af41416d9c62a7bb0a1d64a9d5d41239d83d276e94783 1308 
pcsc-perl_1.4.13-1.dsc
 1006e1f699559f7bab963fa6e19ab0342dfc85daa8e1cf791f5d324adc96cd98 43170 
pcsc-perl_1.4.13.orig.tar.gz
 03593d84948b0f87e5185323a20db5d9bda8705cc8011733707be8508a2f6c7e 3581 
pcsc-perl_1.4.13-1.debian.tar.gz
 66770a1f7b3497255299636ca4b86f0494ba274c45bdbe7590222d273bcf07bd 57152 
libpcsc-perl_1.4.13-1_amd64.deb
Files: 
 0aa13c8dd520dcf37c003ba17b3ab1df 1308 perl optional pcsc-perl_1.4.13-1.dsc
 29af997b997956faee270e0885bb0dbf 43170 perl optional 
pcsc-perl_1.4.13.orig.tar.gz
 a4f00d86ed2be57998297a4c7859221e 3581 perl optional 
pcsc-perl_1.4.13-1.debian.tar.gz
 6e4c439c666e5d633f2e2215af54292b 57152 perl optional 
libpcsc-perl_1.4.13-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFZcDcACgkQP0qKj+B/HPmRiQCfbNtLxkZzygPyOen3uXA7lpxi
+JAAn2oLfjChMS8Vb3SUOuyYVOra+vR2
=v83z
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umdew-00089b...@franck.debian.org

Accepted gtksourceview3 3.8.0-1 (source all i386)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 29 Mar 2013 21:07:50 +0100
Source: gtksourceview3
Binary: libgtksourceview-3.0-1 libgtksourceview-3.0-common 
libgtksourceview-3.0-dev libgtksourceview-3.0-doc gir1.2-gtksource-3.0
Architecture: source all i386
Version: 3.8.0-1
Distribution: experimental
Urgency: low
Maintainer: Debian GNOME Maintainers 
pkg-gnome-maintain...@lists.alioth.debian.org
Changed-By: Emilio Pozuelo Monfort po...@debian.org
Description: 
 gir1.2-gtksource-3.0 - gir files for the GTK+ syntax highlighting widget
 libgtksourceview-3.0-1 - shared libraries for the GTK+ syntax highlighting 
widget
 libgtksourceview-3.0-common - common files for the GTK+ syntax highlighting 
widget
 libgtksourceview-3.0-dev - development files for the GTK+ syntax highlighting 
widget
 libgtksourceview-3.0-doc - documentation for the GTK+ syntax highlighting 
widget
Changes: 
 gtksourceview3 (3.8.0-1) experimental; urgency=low
 .
   [ Andreas Henriksson ]
   * New upstream release (v3.7.92).
   * Bump required versions of build-dependencies according to configure.ac:
 - libgtk-3-dev bumped from (= 3.3.8) to (= 3.7.12)
 - libglib2.0-dev bumped from (= 2.28.0) to (= 2.34.0)
   * Update libgtksourceview-3.0-0.symbols with many symbols dropped!
 - no matches found by codesearch.debian.net and apparently these
   where meant to be private and never was available in headers.
   * New upstream release (v3.8.0)
   * Rename package for new so-name.
 .
   [ Emilio Pozuelo Monfort ]
   * debian/control.in,
 debian/rules:
 + Loosen libgtksourceview-3.0-1 dependency on the -common package
   to allow for different versions of the library to be installed
   simultaneously.
Checksums-Sha1: 
 61ed2df56e46ad4a811dfc8a7bb8dac475395fa3 2138 gtksourceview3_3.8.0-1.dsc
 6f268f63ec9f2a7ee769f3ceacd875fc4e92179b 1260676 
gtksourceview3_3.8.0.orig.tar.xz
 394150aee7cfa938d7270c59b9ebeba8d0ac8f7d 13706 
gtksourceview3_3.8.0-1.debian.tar.gz
 a4c238ea923bc964d1d1f99aeea3045a20d5c518 677814 
libgtksourceview-3.0-common_3.8.0-1_all.deb
 781e3aa241c4f81c4be1c75d6e3d3d0520f8b9cc 213210 
libgtksourceview-3.0-doc_3.8.0-1_all.deb
 cb6bc4e8f3e2aac7de683e86abc65d5a3e5d49fe 276314 
libgtksourceview-3.0-1_3.8.0-1_i386.deb
 96f9a3f4578dfeae6183ed918a2d4ecf166a294a 333486 
libgtksourceview-3.0-dev_3.8.0-1_i386.deb
 cb1b68d915e51510b0ebab50c4f56a35757138db 143676 
gir1.2-gtksource-3.0_3.8.0-1_i386.deb
Checksums-Sha256: 
 824af16e278913f6e055d57fa6900232aae000823dd30c301e3599667f7606a8 2138 
gtksourceview3_3.8.0-1.dsc
 5a995f3f2c188f52f75fe8117a690f53e25b2c6fe2a39103b269acdbb70061b8 1260676 
gtksourceview3_3.8.0.orig.tar.xz
 824d08d29b7ab0e60bdc30db39d0394d2f153771b796003329534789eeca6b3e 13706 
gtksourceview3_3.8.0-1.debian.tar.gz
 905c706490bcc21afff62b57af54973c3aa05305f719449c37f9775ffa7b5d9c 677814 
libgtksourceview-3.0-common_3.8.0-1_all.deb
 1f84c74fb53c1613a40fc6a91d8aec952f7d0e1dba1cfed89e00e92a78e2ad24 213210 
libgtksourceview-3.0-doc_3.8.0-1_all.deb
 15b8fee6e0cbee4b118b2ecb31d31c5f0925a684f633d8dcb1cc53187dfe8a84 276314 
libgtksourceview-3.0-1_3.8.0-1_i386.deb
 628d6fffa7ef4c21d52c3da203387337eab28ba4a56ccf46fc31fb6bf6aaefb6 333486 
libgtksourceview-3.0-dev_3.8.0-1_i386.deb
 fd2590f39633a320fd3101391a74aeba38514fe411204105af630fadc65af1f0 143676 
gir1.2-gtksource-3.0_3.8.0-1_i386.deb
Files: 
 8a41e2d466475175d5dbc20205d10684 2138 libs optional gtksourceview3_3.8.0-1.dsc
 b4d72cf0998a8ba4f08a8cd2c96b7844 1260676 libs optional 
gtksourceview3_3.8.0.orig.tar.xz
 a9c6dfdac0cb4633b56dbabb27f47f13 13706 libs optional 
gtksourceview3_3.8.0-1.debian.tar.gz
 818ef5f15a593cb1c3476f957b570c67 677814 libs optional 
libgtksourceview-3.0-common_3.8.0-1_all.deb
 3db79f243cdfe4891d292174f25ab23b 213210 doc optional 
libgtksourceview-3.0-doc_3.8.0-1_all.deb
 c8d1561e989ae92493909e5b52e161ff 276314 libs optional 
libgtksourceview-3.0-1_3.8.0-1_i386.deb
 c8b42b1a13c6d97c8ce4b26a99689731 333486 libdevel optional 
libgtksourceview-3.0-dev_3.8.0-1_i386.deb
 8d7464fa3a956272f581e9bd101cbc5b 143676 introspection optional 
gir1.2-gtksource-3.0_3.8.0-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFWDVYACgkQhTV17EoIsv7SaQCfe1r4lm1WgczrvM44urzQNQIb
3ygAoIU0PQ0j2bbtim7sKxbK24PnPZIF
=wHUZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umdpa-0003nm...@franck.debian.org

Accepted devhelp 3.8.0-1 (source all i386)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 28 Mar 2013 12:38:17 +0100
Source: devhelp
Binary: libdevhelp-3-2 libdevhelp-dev devhelp devhelp-common
Architecture: source all i386
Version: 3.8.0-1
Distribution: experimental
Urgency: low
Maintainer: Debian GNOME Maintainers 
pkg-gnome-maintain...@lists.alioth.debian.org
Changed-By: Emilio Pozuelo Monfort po...@debian.org
Description: 
 devhelp- GNOME developers help program
 devhelp-common - Common files for devhelp and its library
 libdevhelp-3-2 - Library providing documentation browser functionality
 libdevhelp-dev - Library providing documentation browser functionality 
(developmen
Changes: 
 devhelp (3.8.0-1) experimental; urgency=low
 .
   [ Thomas Bechtold ]
   * New upstream release.
   * soname bump according to configure.ac
   * debian/libdevhelp-3-2.symbols: Updated symbols.
   * debian/control:
 - Bump libgtk-3-dev Build-Depends to = 3.5.6 according to configure.ac.
 - Bump libglib2.0-dev Build-Depends to = 2.32 according to configure.ac.
   * debian/rules: explicit don't build against webkit2
   * debian/devhelp-common.install:
 - etc is no longer needed
 - install gsettings schema
 - install gconf-to-gsettings convert file
 .
   [ Emilio Pozuelo Monfort ]
   * debian/control.in:
 + Update build dependencies.
Checksums-Sha1: 
 398ae988e1c0eadfa0635dcb75bfcc640676f309 1696 devhelp_3.8.0-1.dsc
 3b070cb841d4abd402acc1bf5224eb94e8a16962 495240 devhelp_3.8.0.orig.tar.xz
 7c4f2209ab6ba8460db934e987f4a4b1820d4eb6 18923 devhelp_3.8.0-1.debian.tar.gz
 9a2757c4116f8347dfe769aa28c38049f9ecf8dc 157966 devhelp-common_3.8.0-1_all.deb
 5c7a10fb9da566f6ed94a8daa7984ba8041c5803 77652 libdevhelp-3-2_3.8.0-1_i386.deb
 20f25d4ba623e65bc525018c2fa6f672ee4e9683 29382 libdevhelp-dev_3.8.0-1_i386.deb
 8285ba8c22dcaaea82cdb1b37af23de4fedd3e71 39934 devhelp_3.8.0-1_i386.deb
Checksums-Sha256: 
 f08f00b87f85348df71ab8039131461d055083fb6b3c1ab33184f0e6472fbd7a 1696 
devhelp_3.8.0-1.dsc
 f8ebd829d96b975069bb70a1fc3b658c3e39505824c8ccb5abd23a6f75589dda 495240 
devhelp_3.8.0.orig.tar.xz
 f775989a15e9677323d45cf280e55ca3cc2004ac69e05ba8f48894a5e12b 18923 
devhelp_3.8.0-1.debian.tar.gz
 765c8d3c929fcf43d11f0d0a7249fa4bf172b9c3d03a98f1600aa2bed15ec9dd 157966 
devhelp-common_3.8.0-1_all.deb
 cecc1bec6176aa6d7458677bb067a7f4ab6b69940c5602cb1515987760533290 77652 
libdevhelp-3-2_3.8.0-1_i386.deb
 1e2be5d306fc6688daf9556ff2b55df06db92b7fe1e72a05086a20388dbb3df6 29382 
libdevhelp-dev_3.8.0-1_i386.deb
 93ef68bac385ee6c5caae5c30078c6236b2e7a272175cdb7ca987b58bd85ca5e 39934 
devhelp_3.8.0-1_i386.deb
Files: 
 eb693fcca97949a479e385eff04b22e5 1696 devel optional devhelp_3.8.0-1.dsc
 e6d8bef5cf698c5d25a0e1c8593a2f63 495240 devel optional 
devhelp_3.8.0.orig.tar.xz
 955a67b388a535a97feb35db69e3b3f6 18923 devel optional 
devhelp_3.8.0-1.debian.tar.gz
 7eda8cd35f740fd8194b9b0bb11f1afc 157966 devel optional 
devhelp-common_3.8.0-1_all.deb
 bc7dc021553db5fc1cc0ce0c4d2369fc 77652 libs optional 
libdevhelp-3-2_3.8.0-1_i386.deb
 a0de19a5e5cd8caef90790748a22cc86 29382 libdevel optional 
libdevhelp-dev_3.8.0-1_i386.deb
 0d47c53ba3f2f7995f25127101dd08bc 39934 devel optional devhelp_3.8.0-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFUNDkACgkQhTV17EoIsv6wDgCfS13xGqToKwI33jwaHqgHx2bS
diMAnRfliHK29iqH1Hh6KRM3YVS+LibR
=UQ0J
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1umdpc-0003o1...@franck.debian.org

Accepted pango1.0 1.32.5-3 (source all i386)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 29 Mar 2013 13:42:58 +0100
Source: pango1.0
Binary: libpango1.0-0 libpango-1.0-0 libpangocairo-1.0-0 libpangoxft-1.0-0 
libpangoft2-1.0-0 libpango1.0-udeb libpango1.0-dev libpango1.0-0-dbg 
libpango1.0-doc gir1.2-pango-1.0
Architecture: source all i386
Version: 1.32.5-3
Distribution: experimental
Urgency: low
Maintainer: Debian GNOME Maintainers 
pkg-gnome-maintain...@lists.alioth.debian.org
Changed-By: Emilio Pozuelo Monfort po...@debian.org
Description: 
 gir1.2-pango-1.0 - Layout and rendering of internationalized text - gir 
bindings
 libpango-1.0-0 - Layout and rendering of internationalized text
 libpango1.0-0 - Layout and rendering of internationalized text
 libpango1.0-0-dbg - Pango library and debugging symbols
 libpango1.0-dev - Development files for the Pango
 libpango1.0-doc - Documentation files for the Pango
 libpango1.0-udeb - Layout and rendering of internationalized text - minimal 
runtime (udeb)
 libpangocairo-1.0-0 - Layout and rendering of internationalized text
 libpangoft2-1.0-0 - Layout and rendering of internationalized text
 libpangoxft-1.0-0 - Layout and rendering of internationalized text
Changes: 
 pango1.0 (1.32.5-3) experimental; urgency=low
 .
   * debian/control.in:
 + Add missing breaks/replaces.
Checksums-Sha1: 
 ac95af66d0484aa6c9e61064ea2d74f85a46236e 2496 pango1.0_1.32.5-3.dsc
 c83d36af26c3edba9b56b2cdf8d71134380ef9d4 29640 pango1.0_1.32.5-3.debian.tar.xz
 227677db6c8a35aea916f5932370a4b0ee224fb7 156510 libpango1.0-0_1.32.5-3_all.deb
 da7723957d8130ee48ebc11dc7b9821e102b1b9a 342056 
libpango1.0-doc_1.32.5-3_all.deb
 a08aa98c5560e58f1be02a84f2b3cdb657680fbb 263468 
libpango-1.0-0_1.32.5-3_i386.deb
 fe9966f7bb9bd1e7ebb04b0e84dbdd1dd9f6aecc 173934 
libpangocairo-1.0-0_1.32.5-3_i386.deb
 fecf559e1f0e28fba27b11e1e06807965a1abfd3 168680 
libpangoxft-1.0-0_1.32.5-3_i386.deb
 b4b1da29decc59bf69240dab0420479ebfed2c6b 186910 
libpangoft2-1.0-0_1.32.5-3_i386.deb
 3605c0f7c1e021afccf4ec7ba6dfd598aa719d6e 143488 
libpango1.0-udeb_1.32.5-3_i386.udeb
 14e36c366439d023b064a8dfecf2105c1ea9f850 413918 
libpango1.0-dev_1.32.5-3_i386.deb
 7a57420f08e6ac9b7abdf522231ae254481c93b2 584958 
libpango1.0-0-dbg_1.32.5-3_i386.deb
 1bde50234803c376ea36f53fb02645ee50c33005 172184 
gir1.2-pango-1.0_1.32.5-3_i386.deb
Checksums-Sha256: 
 bffa104367b46c9c35775f5b5dabcfddf58c1d0610d88f7e4c1b94d57fc9e0e2 2496 
pango1.0_1.32.5-3.dsc
 92f772913f8b454bebed831f59e2102a90a886119ce3bdc995b52b448423af77 29640 
pango1.0_1.32.5-3.debian.tar.xz
 f8309cf578dbbecc406f44183520ffd3208fbdac197dd7ce32564530c00f1d48 156510 
libpango1.0-0_1.32.5-3_all.deb
 ad20605cb5547e1e8848dcc096523394399973b050183d86b1b42df61b28 342056 
libpango1.0-doc_1.32.5-3_all.deb
 fd890b699f02d21a349ca913cce9949a2b79235a70ec904251666d71bdd74eee 263468 
libpango-1.0-0_1.32.5-3_i386.deb
 6e68910072319f97bdb0cd0d9a335cd0335be35b4cef2c904973e50c21e11d08 173934 
libpangocairo-1.0-0_1.32.5-3_i386.deb
 c9cb7daa2ea3bc147dac7246ab7ef162c1adb5bc815923d04c0c85d036f0e99c 168680 
libpangoxft-1.0-0_1.32.5-3_i386.deb
 1d2923b774cbb606740ac41697576f8ab1edaee423f354c4f18cd8f1e416cd33 186910 
libpangoft2-1.0-0_1.32.5-3_i386.deb
 d57a56dc51e829a115d5af46bd4849ba8f9b075aff2b13a5dfbd14c2093249fe 143488 
libpango1.0-udeb_1.32.5-3_i386.udeb
 92f9f0ab3c96e5d4c6ca3f1da47e7335f719cb9ce334016611f44bc5b79d9395 413918 
libpango1.0-dev_1.32.5-3_i386.deb
 cc7bf8affc258d6c152cc7604b170e14d9af532196d7135a7c157ce67a7c2bd6 584958 
libpango1.0-0-dbg_1.32.5-3_i386.deb
 29718b194d2c852588e5935ea3f7f40c874f2d3c24aee9121bedbcbca6ad7222 172184 
gir1.2-pango-1.0_1.32.5-3_i386.deb
Files: 
 2d6001ac599e78761012d7fe847f716b 2496 libs optional pango1.0_1.32.5-3.dsc
 31bed09df968e97604c1b140915087cb 29640 libs optional 
pango1.0_1.32.5-3.debian.tar.xz
 22128e48e1441a9b623f28b84fe4f72b 156510 oldlibs extra 
libpango1.0-0_1.32.5-3_all.deb
 0219083005cf911ae3f083317fda8811 342056 doc optional 
libpango1.0-doc_1.32.5-3_all.deb
 1e8d164c0cd5fe78d51b2b648946cf19 263468 libs optional 
libpango-1.0-0_1.32.5-3_i386.deb
 c83f7dd58651173cb9bc1c5f1376654b 173934 libs optional 
libpangocairo-1.0-0_1.32.5-3_i386.deb
 ee05ecde082ea4c8affcd99f32a2de8f 168680 libs optional 
libpangoxft-1.0-0_1.32.5-3_i386.deb
 7cfbfcfb75128933a64add00bb41911c 186910 libs optional 
libpangoft2-1.0-0_1.32.5-3_i386.deb
 3aa9077fd7c68aeee079403604f1b51c 143488 debian-installer optional 
libpango1.0-udeb_1.32.5-3_i386.udeb
 04abfe28836173c8291309b1b24cb405 413918 libdevel optional 
libpango1.0-dev_1.32.5-3_i386.deb
 7a7113e8cb4df27971326500b8de813b 584958 debug extra 
libpango1.0-0-dbg_1.32.5-3_i386.deb
 d1bf63eee9366b6c446fcad31ae22e87 172184 introspection optional 
gir1.2-pango-1.0_1.32.5-3_i386.deb
Package-Type: udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlFVk/YACgkQhTV17EoIsv5shwCfeFsQ3RswRcGJsoASE+eg1vXA
pb4AoMOfZSjhJTPNJx4Kb/47mnN72m9P
=OT9s
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to

Accepted gnome-terminal 3.8.0.1-1 (source all i386)