Re: epoch fix?
On 05/08/2013 06:30 PM, Peter Samuelson wrote: # in unstable Package: bar Build-Depends: libfoo-dev (= 1.5) The 'bar' maintainer intended to require the unstable version of libfoo-dev, but in fact the dependency is satisfied from stable as well. Yeah! And this mistake is very easy to make. I did a similar woopsie recently myself with Breaks / Replaces, (which was quickly solved) even though I quite know what I was doing, simply because I forgot about the epoch. Of course, that made the Breaks / Replaces completely useless. Though, is there a way to fix human brains? I don't think so... Would having the epoch written in the generated file names solve the problem? I don't think so either... 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/518b429e.7030...@debian.org
Re: wheezy postmortem re rc bugfixing
On 2013-05-09 00:48, anarcat wrote: [...] In fact, I am of the opinion that we should relax the requirements that the release team systematically review every diff posted during the freeze, especially if the freeze is going to last almost a year... That always seemed to me to be an insane amount of work. [...] A. FTR, I believe we (i.e. the RT) never wanted or aimed for a freeze taking a year. I can see how your idea might seem attractive for maintainers, you can get that fix in you just missed or upstream has a fix and don't have to cherry-pick from a lot of other changes. That said, for the former, the freeze date was announced a year ahead of time. Yet, there were quite a few maintainers that seemed to be caught by surprised by the freeze. If you add that slush period, I fear maintainers would just be even more relaxed (because I can always fix it during the slush). To be honest, I am not convinced that people are vigilant enough to avoid doing ABI breakages, so a slush upload might end up starting a transition[1]. What I would like to see is a way to reduce the need for changes post freeze. It was my understanding that time-based freeze was intended to do that - by letting you know ahead of time so you could have your things ready (before last minute). The execution of the time-based freeze might have failed. Also, testing did not serving its purpose of always being in (a near-)releasable state[2] with its 500+ RC bugs at the start of the freeze was not ideal (either?). ~Niels [1] During the Wheezy development cycle we did have quite a few uncoordinated library transitions. Combine that with some people's acceptance of huge diffs post-freeze... [2] At least it is my understanding that this is why we (i.e. the RT) wants testing around. Admittedly a lot of people seem to expect it to be a rolling distribution instead. -- 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/518b430e.2030...@thykier.net
Re: DPA instead of PPA
Hi, On Wed, 08 May 2013, Holger Levsen wrote: I actually really like this idea! (Though I suggest Debian Personal Archive.) It's really different from what people know as PPAs. To be fair, Personal is probably not relevant either. I expect many of those repositories to be maintained by teams. DSPA = Debian Special Purpose Archive DSPR = Debian Special Purpose Repository DASP = Debian Archive of Special Packages SPA = Special Package Archive bikeshed \o/ In the end, I don't care of the name as long as we have the feature. :-) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130509063802.gc23...@x230-buxy.home.ouaza.com
Re: Depends: libfoo:foreign ???
On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. Indeed, I believe that should work. ~Niels [1] Though she ignores them in Recommends/Suggests and possibly also in Breaks/Conflicts. -- 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/518b458a.2020...@thykier.net
Re: idea: generalized soft dependencies
Hi,
Without discussing whether adding generalized soft dependencies would be a
good idea or not, let me give you my two cents about the syntax.
Quoting Eugene V. Lyubimkin (2013-05-08 20:51:54)
Soft-Depends: a {90%}, b (= 1.2) {20%}, c (= 4) {99%}, c (= 6) {70%}
Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
Soft-Depends: debdelta {10%,text:to enable automatic delta downloading}
We (myself+wookey) recently proposed a new syntax to tag build dependencies
with build profiles for bootstrapping [1] but it was deemed not to be a good
idea to introduce a new meta character. Instead, it seems that your proposal
can easily be implemented using the unified qualifier proposal that was made by
Ian Jackson in the same thread [2] which does not spend an additional meta
character but extends the architecture qualification syntax:
Soft-Depends: a [minthresh:90], b (= 1.2) [minthresh:20], c (= 4)
[minthresh:99], c (= 6) [minthresh:70]
Soft-Depends: iceweasel [minthresh:50 tag:desktop], curl [minthresh:95
!installed:wget]
I also started a thread to discuss Ian Jackson's proposal on d-dpkg@l.d.o [3]
where Raphael Hertzog gave a use case [4] for this syntax similar to the one
which you address here.
cheers, josch
[1] http://lists.debian.org/20130115181840.GA16417@hoothoot
[2] http://lists.debian.org/20726.45081.38709.233...@chiark.greenend.org.uk
[3] http://lists.debian.org/20130419194252.17205.76995@hoothoot
[4] http://lists.debian.org/20130421194955.gb2...@x230-buxy.home.ouaza.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/20130509070158.18633.47628@hoothoot
Re: Doubts about PPA in Debian
On 05/07/2013 10:34 PM, Paul Wise wrote: On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote: Debian backports offers me *one* repository. I need 3 of them: I don't see why. The combination of suites we have now should be enough. Here is what I would do... - stable -1 (currently OpenStack Folsom) Ignore, is there any reason why an old version is interesting? It's currently not possible to upgrade from Essex (which is in Wheezy) to Grizzly (which is currently in Experimental). You need to upgrade through Folsom first. At least, that is the current upstream status, I'll have to find a solution. - stable (currently OpenStack Grizzly) sid+jessie+wheezy-backports+squeeze-backports-sloppy Well, I'd like to run a backport for Wheezy only, I don't want to have it in sid+jessie. Currently, I can't do that. Also, the rules in backports is that packages should be already migrated to testing. The point is, if I had PPAs, I wouldn't at all upload to SID and wait for a migration to testing, because it would be better if the packages were living in the PPA only (that would be a lot more flexible and adapted to my use case). I think that would be a bit sad and I hope you don't do that. I agree. I tried to explain that to upstream, but no luck so far... There's not much I can do, especially with a project of that size. Distributions like Ubuntu and Debian have the same pb though. Probably RedHat too. 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/518b570a.4080...@debian.org
Re: jessie release goals
On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote: Hi, now might be the right time to start a discussion about release goals for jessie. Here are some points that come into my mind right now (and some were already discussed very recently): * multiarch compatible binNMUs * discarding maintainer uploaded binary packages [!arch:all] * discarding maintainer uploaded binary packages [incl. arch:all] * extending binNMUs to allow rebuilding arch:all packages (so it's no longer a binary only but a sourceful no-change rebuild - the classic binNMU should stay of course) * source build dependencies (such that e.g binutils-mingw-w64 build depends on src:binutils instead of binutils-source) Mike -- 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/20130509081001.ga13...@glandium.org
Re: Merging / and /usr (was: jessie release goals)
On Thu, 9 May 2013 03:31:30 +0200, m...@linux.it (Marco d'Itri) wrote:
This is not relevant for what we are talking about because /usr *will*
be required be available to boot the system no matter where the files
currently in /{bin,sbin,lib} will end up.
Yes. That is really bad news and I hate the idea to be forced to do
things just because a few developers are too lazy to care about
robustness. But I also acknowledge that Debian does not have the
personpower to fix upstream's deliberate breakage.
If your goal is to have the smallest and least accessed file system
available for recovery then I recommend that you create a 200-250 MB
/boot and install grml-rescueboot.
That's how I do it for new installs. However, this is vastly more
complex than the traditional setup, and it doesn't help for systems in
maintenance mode that, for example, cannot be changed because of
service level agreements and certifications.
Using Debian happens beyond single-user home desktop settings, you
know.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uamgn-0002ad...@swivel.zugschlus.de
Re: Merging / and /usr (was: jessie release goals)
On Thu, 9 May 2013 03:43:44 +0200, m...@linux.it (Marco d'Itri) wrote:
Let's assume that at this point there are no files in /{bin,sbin,lib}
which have the same name of a file in /usr/{bin,sbin,lib} but are not
a symlink to them (which I suspect is something that we want anyway).
For each $file in /{bin,sbin,lib}:
if $file is a symlink to /usr/.../$file
do nothing
else
cp -a $file to /usr/...
ln -sf ../usr/.../$file $file
That's a hack which is acceptable for single-user home desktops. We're
talking about professional IT here.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uamhk-0002ar...@swivel.zugschlus.de
Re: Merging / and /usr (was: jessie release goals)
On May 09, Marc Haber mh+debian-de...@zugschlus.de wrote: That's a hack which is acceptable for single-user home desktops. We're talking about professional IT here. Great, if this is the strongest objection you have then looks like it can be done. -- ciao, Marco signature.asc Description: Digital signature
Re: jessie release goals
On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey m...@glandium.org wrote: On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote: Hi, now might be the right time to start a discussion about release goals for jessie. Here are some points that come into my mind right now (and some were already discussed very recently): * multiarch compatible binNMUs * discarding maintainer uploaded binary packages [!arch:all] * discarding maintainer uploaded binary packages [incl. arch:all] * extending binNMUs to allow rebuilding arch:all packages (so it's no longer a binary only but a sourceful no-change rebuild - the classic binNMU should stay of course) * source build dependencies (such that e.g binutils-mingw-w64 build depends on src:binutils instead of binutils-source) Yes! That was on my list as well ;-). The Built-Using stanza could even be filled in automatically in such cases... Stephen signature.asc Description: PGP signature
Re: wheezy postmortem re rc bugfixing
On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
It is good to have it released now, but I think we are all (mostly?)
agreed that wheezy took longer to release than we would have liked.
In particular, the RC bug count didn't drop quickly enough.
Thanks for bringing this up!
I would like to take this opportunity to post an experience report and
give some conclusions I'd make from that.
During the wheezy cycle I participated in the 2011 Hildesheim BSP. In my
experience BSPs are among the best places to get difficult issues sorted
out. Political issues tend to play less of a role there and it
participants tend to motivate each other not to give up on technical
challenges. I would like to thank all the BSP organizers for their
valuable contributions to the project.
During said BSP I settled on fixing #88010 (yes five digits, policy
violation, {lenny,squeeze}-ignore). It clearly meets the criterion of
hard and fixing it took more than a year. Here are a few observations
on the process:
* The largest amount of time used for fixing went into communication.
Sometimes I would wait for multiple months to receive an essential
answer from involved parties. This had a multitude of reasons and I
would like to avoid a blame game here, but this ultimately resulted
in missing the freeze and later resulted in last-minute changes.
* There were a great many people who helped me with technical aspects,
that were sufficiently isolated and did not require a broad view on
the issue. This applies especially to the changes in packaging, the
involved perl code, the usage of dpkg triggers and the transition
tool set.
* Even though I had a variety of people review the changes introduced,
the first attempts resulted in a variety of new failure modes.
Remark: The PPA thingy might be part of the solution here. As it
would make testing transitions easier.
* Try to think of workflows which might overcome these problems
Given the experience above and the experience with other RC bugs, I
would like to suggest to form semi-spontaneous teams around some RC
bugs. The rationale here being is that some hard RC bugs tend to be
quite complex and complexity made me give up on other issues. We already
have the notion of owner in the BTS, but its usage appears to be
limited (and I didn't use it either for RC bugs so far). By forming a
team around a particular issue, we can contain the complexity and
motivate each other. This is not to say that such a team is to do the
full fix, but to give a direction and coordinate the involved parties.
The team would be tasked with avoiding stalls in the progress, pinging
and possibly timing out involved parties. Possibly writing regular
progress summaries would also be helpful to evaluate the performance of
the team. Such summaries would also make switching the owner later
easier. This model should also work with single person teams, but I'd
fear that a single person could more easily run into political
acceptance issues.
This is just a rough sketch so far, and I cannot tell whether it
actually works. Rereading the above paragraph, it sounds a bit like
mini release goal.
Helmut
--
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/20130509090056.ga28...@alf.mars
Call for help: archive rebuilds
Hi, I'm unlikely to be able to do much archive rebuild work in the coming year, so I would welcome help on that front. Here is the job description: - maintain scripts to organize archive rebuilds, parse logs and file bugs Required skills: basic Ruby knowledge (or willingness to learn) scripts are in http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git and http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/ - do the archive rebuilds themselves on Amazon Web Services Required skills: basic AWS knowledge (or willingness to learn) - process results and file bugs (there are scripts that allow to automate most of the process). Required skills: good understanding of FTBFS bugs (common causes for failure, etc), and of the BTS - answer to questions from maintainers Overall, one important skill is the ability to dedicate time to this task on a regular basis (on average, approx. 3 hours every 3 weeks). The task covers normal archive rebuilds (rebuilding all packages, including source and arch:all, from source), but also custom rebuilds (new GCC/python/eglibc/... releases, clang), and possibly QA-specific targets (double-builds, non-minimal chroots, etc.) It is not required to be a DD or DM. Please reply to debian...@lists.debian.org if you are interested. Lucas -- 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/20130509093205.ga16...@xanadu.blop.info
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. Indeed, I believe that should work. It is the indended solution. If it doesn't work then that is a bug and needs to be fixed. ~Niels [1] Though she ignores them in Recommends/Suggests and possibly also in Breaks/Conflicts. A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). I would say that a foreign dependency on a library is never right. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. This is for interpreters and plugins/lib bindings where the normal automatic method can't work. So maybe DAK could be made more restrictive here. MfG Goswin -- 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/20130509093918.GA31432@frosties
Re: epoch fix?
Thomas Goirand z...@debian.org writes: On 05/08/2013 06:30 PM, Peter Samuelson wrote: # in unstable Package: bar Build-Depends: libfoo-dev (= 1.5) The 'bar' maintainer intended to require the unstable version of libfoo-dev, but in fact the dependency is satisfied from stable as well. Yeah! And this mistake is very easy to make. I did a similar woopsie recently myself with Breaks / Replaces, (which was quickly solved) even though I quite know what I was doing, simply because I forgot about the epoch. Of course, that made the Breaks / Replaces completely useless. Though, is there a way to fix human brains? I don't think so... Would having the epoch written in the generated file names solve the problem? I don't think so either... Looks like it might be possible to for test with lintian. I presume it's OK to add the implicit 0: to non-epoch depends? If so, lintian could complain whenever a dependency is specified on a package with an epoch, unless the versions specified also include an epoch, and if you really meant the pre-epoch version, you could just add the 0: to get rid of the warning. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpdxqX7u2zkk.pgp Description: PGP signature
Re: Merging / and /usr (was: jessie release goals)
On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote: On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote: On May 07, ?? ?? pashev.i...@gmail.com wrote: What about merging / and /usr ? An ambitious plan. I strongly support the everything in /usr scheme, but let's first consolidate support for standalone /usr must be mounted by the initramfs. I'm working on this at the present (I'm re-doing the proof of concept patches I made a few months back, to clean it all up and make it work in a wider number of cases). I hope to have something by the end of the week, time permitting. That said, I'm not in support of moving things to /usr; it's completely backward. Once we have / and /usr mounted in the initramfs, then we can work on deduplicating shared paths on / and /usr. This will give us the option of migrating either way in the future (if ever). If we do this, I'd prefer to make /usr a symlink to / on new installs, while retaining full backward compatibility for existing users, and requiring zero packaging changes. But the other way would also be possible--it would just be a matter of d-i setting up the links. But none of this is the primary reason for doing this initially. Regards, Roger If you make /usr a symlink to / then there will be to distinct paths to each file and that will confuse dpkg. The first problem that comes to mind is package A containing /bin/foo and package B containing /usr/bin/foo. Dpkg will happily install both without noticing the file overwrite conflict. Or package A 1.0 contains /bin/foo and package A 1.1 contains /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo with /usr/bin/foo) and then remove /bin/foo. Leaving you without /usr/bin/foo. MfG Goswin -- 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/20130509095031.GB31432@frosties
Re: DPA instead of PPA
On 05/09/2013 02:38 PM, Raphael Hertzog wrote: Hi, On Wed, 08 May 2013, Holger Levsen wrote: I actually really like this idea! (Though I suggest Debian Personal Archive.) It's really different from what people know as PPAs. To be fair, Personal is probably not relevant either. I expect many of those repositories to be maintained by teams. DSPA = Debian Special Purpose Archive DSPR = Debian Special Purpose Repository DASP = Debian Archive of Special Packages SPA = Special Package Archive bikeshed \o/ Seriously, any of the above would be better than PPA. Naming it like for Ubuntu fools our users into believing it is the same thing, when the plan is not like that. I like the first name above. 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/518b7469.2090...@debian.org
Re: Doubts about PPA in Debian
On 05/07/2013 04:12 PM, Tollef Fog Heen wrote: Providing backports doesn't free you from the burden of making sure upgrades work. Thomas is facing a very large chunk of work to make sure upgrades from the no-longer-supported E release to whatever might be in jessie, since upstream breaks APIs and doesn't support skipping releases when upgrading. Yeah, you got the point. Though what breaks is mainly db upgrades (using python-migrate, I'll have to care about adding previous scripts, etc.). 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/518b7509.3000...@debian.org
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote: On 05/07/2013 11:41 AM, Paul Tagliamonte wrote: On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote: On May 07, Paul Tagliamonte paul...@debian.org wrote: No please. We are good about making sure they each mean something important, and there's no good reason. Not really nowadays: more and more things needed at boot time are in /usr and there are no plans to fix them. We also support setups that might need this split due to low storage, such as arm devices. everything in /usr actually means that supporting these devices is much easier. Not when you have a 500 meg internal storage that the firmware boots off of, and using a multi-gig CF card to store the mega-awesome-app you're using it for. This seems to point to what I think may be a key question in the ongoing/recurring '/usr'-related discussions, which I don't think I've seen addressed in the iterations I've seen. If it has been addressed well, please point me to past iterations which have so addressed it, rather than rehashing the whole thing here just for my benefit. The question, expressed in a number of different ways to provide a type of clarity by triangulation, is: Why does /usr exist in the first place? Why was it created, way back in the day? What is its purpose, what is it for? My understanding, to the extent that I've had one, has always been that - to oversimplify it a bit - / is for installs of things which are system-essential, and /usr is for installs of things which are not. The definition of system-essential can be debated, but again, my understanding of it has been that it incorporates A: boot-essential (things required for boot) plus B: emergency tools (things you want to try to guarantee will be available in an emergency, things-are-broken-and-we-have-to-fix-them scenario, such as might leave you needing to rely on single-user mode). The initial problem was that the harddisk was too small. So you had to split things up into 2 harddisks somewhere. / was the first disk, /usr the second. We have long since past this problem. Except it is comming back. With embedded systems that boot from a small flash that contains / and then have /usr on a non-bootable drive. But those systems can put an initrd on flash to boot. I'm not aware of any situation where an initrd can't be used (can't, not don't want to). For Debian the problem has become that / must contain everything needed to be able to mount /usr. And that includes such odd cases as /usr on NFS over wlan and a million other permutations of any possible way to hide /usr somewhere. The problem in recent years has been twofold: 1) some people have become more creative and used new things to put /usr on. Like iscsi or nfs over wlan. So more tools are needed in / to make this possible. 2) most people don't have a seperate /usr or /usr on the same medium as / and upstreams have been ignorant or neglient about ensuring the right things end up in / and only things from / are used before mounting /usr. The less people have a seperate (and complicated) /usr the less this is tested and more bit-rot creaps in. We have reached a point where other distributions have given up and upstreams are saying they don't care for a seperate /usr anymore. The real-world scenario is obviously far more complicated than that - dragging in definitions for what goes in /etc and /var and /home, and further defining a distinction between /usr and /usr/local, and so forth. But the basic concept seems simple enough as far as it goes. Now, the next question is: does that distinction, that defining purpose for the existence of /usr, still make sense in the modern world? Almost everyone boots via an initrd nowadays AFAIK, which would seem to more or less negate the advantages of keeping boot-essential things separate that way - but almost still isn't everyone, and I don't know whether we want to explicitly step away from support for non-initrd boot configurations. The emergency tools side of it I'm less clear on. It's relatively unimportant for cases where you have physical access to the system in the emergency scenario, assuming you can take the machine down long enough to boot into a rescue environment on removable storage (LiveCD or USB drive, et cetera), but there may not be any analogous alternate fallback for cases where you only have remote access to a machine, or where taking the machine down that way may not be an option. There's also the question of what scenarios this could actually help in, which may be limited enough to make the entire thing negligible. On most (numerically) systems you have a bootloader that lets you choose what to boot and it is trivial to add an emergency initrd with all the repair tools you would ever want. That is actualy much better than using / for emergencies since then / will not be mounted and can be safely repaired too.
Re: DPA instead of PPA
On 09/05/13 07:38, Raphael Hertzog wrote: bikeshed \o/ You probably meant this to be a comment on the discussion rather than a suggested name, but until it gets uploaded to unstable, you can get GNOME 3.8 from the GNOME Team bikeshed actually sounds like a reasonable sentence to write. :-) (Or more seriously, maybe (mini|sub)-(archive|repository), to have slightly fewer acronyms floating around.) S -- 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/518b7cf6.3080...@debian.org
Re: Merging / and /usr (was: jessie release goals)
On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote: If you make /usr a symlink to / then there will be to distinct paths to each file and that will confuse dpkg. The first problem that comes to mind is package A containing /bin/foo and package B containing /usr/bin/foo. Dpkg will happily install both without noticing the file overwrite conflict. Or package A 1.0 contains /bin/foo and package A 1.1 contains /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo with /usr/bin/foo) and then remove /bin/foo. Leaving you without /usr/bin/foo. This is all very true. Once we have /usr mounted in the initramfs, we can correct such duplicate paths to prevent this; packages which provide a binary in /bin and a symlink in /usr/bin to make the binary available in early boot can simply move the binary back to /usr--it will be guaranteed to be available in early boot. Since two different paths would then be effectively equivalent, maybe we might also need dpkg itself to be aware of this so that it will refuse to overwrite, in addition to a manual audit of the existing paths. My current work on this is at http://anonscm.debian.org/gitweb/?p=users/rleigh/initramfs-tools.git;a=shortlog;h=refs/heads/usrmount It works for mounting a local /usr; testing NFS and NFS/local combinations is on my TODO list for tonight. This still needs further cleanup and testing. It will be ready for wider testing in a few days. It also needs a patch to util-linux so it doesn't try to fsck a mounted /usr at boot. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20130509110342.gq21...@codelibre.net
Re: wheezy postmortem re rc bugfixing
On 09/05/13 at 08:32 +0200, Niels Thykier wrote: The execution of the time-based freeze might have failed. Also, testing did not serving its purpose of always being in (a near-)releasable state[2] with its 500+ RC bugs at the start of the freeze was not ideal (either?). I think that one problem is that our current workflows are based on the illusion that all RC bugs are equal. Our tools (e.g. http://udd.debian.org/bugs.cgi) should get better at differenciating different kinds of RC bugs. For example: - old RC bugs vs new RC bugs: experienced bug squashers should focus on the old RC bugs, not on the maybe-trivial-to-fix new RC bugs. - RC bugs affecting popular/important packages vs RC bugs affecting minor packages (that we could remove without). We should include such distinctions in the various graphs we use to track progress. Also, we should be more agressive at getting down the number of RC bugs by automatically removing RC-buggy not-so-important packages. For example, if we keep the current time-based freeze policy for jessie, we could announce that all not-so-important RC-buggy packages will be removed from testing on freeze date. Lucas -- 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/20130509105503.ga21...@xanadu.blop.info
Re: wheezy postmortem re rc bugfixing
Hi! Lucas Nussbaum lu...@debian.org writes: Also, we should be more agressive at getting down the number of RC bugs by automatically removing RC-buggy not-so-important packages. For example, if we keep the current time-based freeze policy for jessie, we could announce that all not-so-important RC-buggy packages will be removed from testing on freeze date. I'm not so persuaded this will actually improve anything. During lenny freeze I've fixed a couple of these easy RC bugs on unmaintained leave packages when I had some 30 minutes of time and no good Idea of what to do. I have had similar timeslots too small to actually get into more difficult RC bugs but couldn't find anything to do during squeeze and especially wheezy freeze so I ended up doing *nothing*. Removing RC-buggy (and potentially not-taken-care-of) packages early may increase the average quality of software in the release (because these fixes mostly do exactly as much as is needed to fix the RC bug) but I'm far from persuaded it will increase release speed. Different thing for will-remove and dropping such packages late of course. Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/8761ysbe09@hepworth.siccegge.de
Re: wheezy postmortem re rc bugfixing
On Thu, May 9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote: Also, we should be more agressive at getting down the number of RC bugs by automatically removing RC-buggy not-so-important packages. For example, if we keep the current time-based freeze policy for jessie, we could announce that all not-so-important RC-buggy packages will be removed from testing on freeze date. define:not-so-important. I'm sure that'll be fun. Cheers, Julien signature.asc Description: Digital signature
Re: DPA instead of PPA
Another opportunity these XPAs will bring, especially the ones that will be used for staging large transitions, is to run piuparts and related tests to discover (and fix) problems before they get introduced into unstable. Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518b827b.9080...@debian.org
Re: wheezy postmortem re rc bugfixing
Lucas Nussbaum lu...@debian.org writes: Also, we should be more agressive at getting down the number of RC bugs by automatically removing RC-buggy not-so-important packages. This sounds like a good idea. If somebody is interested in the package they can easily reintroduce it after they have fixed the bug. -- 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/84fvxwpez8@sauna.l.org
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 08:14:32PM +0200, Marc Haber wrote: On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne hel...@subdivi.de wrote: On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote: Fedora updates are different. (And so are Ubuntu updates, if one considers that it's possible to provide fixup scripts to update-manager pre-upgrade.) As long as we're supporting upgrades through plain apt, that's going to be hard. Especially if you have non-distro packages installed that need to be migrated as well, with the tracking information updated. Maybe the issue here shouldn't be changing the default. After all there is a quite vocal opposition to such a step. I fail to see consensus in the recent mails without even contributing a personal opinion here. So really what does it take to e.g. move /bin and stuff to /usr? Did anyone try that? Where is that documented? What problems did occur? If we force a much bigger /, the chance of a broken / filesystem increases. If / is fine, one has a chance to fix the system without booting to rescue. So, a small / both decreases the probability of a boot failure and makes fixing breakage easier. The assumptions here are that a separate rootfs decreases the chance of breakage, and that you'll need the rootfs to perform the rescue. Does having two filesystems rather than one decrease the chances, or increase them? Neither are written to much during normal system operation, and they can both be mounted read-only. Do we have any concrete evidence one way or the other here? Regarding rescue, the initramfs has a rescue shell which I've found to be just as useful as single user mode. Once it has mounted the rootfs, you can chroot into that and do whatever you would normally do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as far as mounting the rootfs, then you'll need some rescue disc in any case. I find the busybox shell to be just as effective as a rescue disc in most cases. In the case where we're mounting /usr in the initramfs rather than having it on the rootfs, there's no practical difference to the current status quo (and this is intentional). The only change is that we provide the guarantee that /usr is available before init starts. If we change our software so that the system never gets beyond initrd stage if mount /usr fails, we increase the change of breaking boot because _two_ filesystems need to be fine and mounted before we leave initrd. Both changes are bad from a robustness point of view. Keeping the root fs small was a good idea 20 years ago, and it still is. I think this is primarily just shifting the lines of where responsibilities are divided. The initramfs is doing part of the job of what the separate rootfs was doing. If there's a problem, then you get the rescue shell in the initramfs rather than the rescue shell from the initscripts/single user mode. In all these cases, the system is unavailable for normal operations until the problem is fixed. There was some mention of putting fsck in the initramfs. I'm not sure whether I really like the idea or not, but from the point of view of having the tools to fix and mount the rootfs (and /usr) there when needed, it may well be useful, so long as we can avoid idiocy such as #701936. We still need the fsck helpers to work for the non-initramfs case and also not be utterly broken. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20130509113347.gr21...@codelibre.net
Bug#707554: ITP: hyphen-ru -- Russian hyphenation patterns for LibreOffice/OpenOffice.org
Package: wnpp Severity: wishlist Owner: Ilyas Gasanov torso.n...@gmail.com * Package name: hyphen-ru Version : 20030310 Upstream Author : Alexander I. Lebedev s...@scon155.phys.msu.su * URL : http://scon155.phys.msu.su/~swan/hyphenation.html * License : LPPL Programming Lang: none Description : Russian hyphenation patterns for LibreOffice I have patched Alexander Lebedev's hyphenation patterns (ruhyphal) already found in the texlive-lang-cyrillic Debian package and the ruhyphen CTAN package, so that they would work with LibreOffice. The reason why I have chosen exactly these patterns is because, among those released under a free license, they seem to give the best orphographical results while their format is generally supported by LibreOffice. These patterns have been released by the author under the terms of the LaTeX project public license version 1.2 (with an option of choosing any later version), thus I see no problems for my package to formally fit the DFSG and be included into the main distribution branch. Since I am not a Debian Developer yet, I'm uploading the complete package to the mentors.debian.net storage for sponsorship approval. Best regards, Ilyas -- 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/1368099204.5831.31.camel@lamed
can someone explain what is happen on line one from this listing?
Hello Developer Group,
can someone explain what is happen on line one from this listing?
why i loos the interrupt?
what is the Status 0x50?
has someone a idea in which Documentation an can finde more informations
about 0x50?
May 7 19:39:57 lxhs110a kernel: [316946.812055] ata2: lost interrupt
(Status 0x50)
May 7 19:39:57 lxhs110a kernel: [316946.812072] ata2: exception Emask
0x10 SAct 0x0 SErr 0x4405 action 0xf
May 7 19:39:57 lxhs110a kernel: [316946.812116] ata2: SError: {
PHYRdyChg CommWake DevExch }
May 7 19:39:57 lxhs110a kernel: [316946.812156] ata2: hard resetting link
May 7 19:39:58 lxhs110a kernel: [316947.536038] ata2: SATA link up 1.5
Gbps (SStatus 113 SControl 300)
May 7 19:39:58 lxhs110a kernel: [316947.560823] ata2.00: configured for
UDMA/133
May 7 19:39:58 lxhs110a kernel: [316947.560831] end_request: I/O error,
dev sdb, sector 25141733
May 7 19:39:58 lxhs110a kernel: [316947.560876] md: super_written gets
error=-5, uptodate=0
May 7 19:39:58 lxhs110a kernel: [316947.560880] raid1: Disk failure on
sdb4, disabling device.
May 7 19:39:58 lxhs110a kernel: [316947.560881] raid1: Operation
continuing on 1 devices.
May 7 19:39:58 lxhs110a kernel: [316947.560962] ata2: EH complete
May 7 19:39:58 lxhs110a kernel: [316947.595196] RAID1 conf printout:
May 7 19:39:58 lxhs110a kernel: [316947.595198] --- wd:1 rd:2
May 7 19:39:58 lxhs110a kernel: [316947.595201] disk 0, wo:1, o:0,
dev:sdb4
May 7 19:39:58 lxhs110a kernel: [316947.595203] disk 1, wo:0, o:1,
dev:sda4
May 7 19:39:58 lxhs110a kernel: [316947.608009] RAID1 conf printout:
May 7 19:39:58 lxhs110a kernel: [316947.608011] --- wd:1 rd:2
May 7 19:39:58 lxhs110a kernel: [316947.608013] disk 1, wo:0, o:1,
dev:sda4
thanks
Paulo
--
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/518b8c73.20...@ai-t.eu
Bug#707556: ITP: node-keypress -- Make any Node ReadableStream emit keypress events
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-keypress Version : 0.1.0 Upstream Author : Nathan Rajlich nat...@tootallnate.net * URL : https://github.com/TooTallNate/keypress * License : MIT Programming Lang: Javascript Description : Make any Node ReadableStream emit keypress events Previous to Node v0.8.x, there was an undocumented keypress event that process.stdin would emit when it was a TTY. Some people discovered this hidden gem, and started using it in their own code. . In Node v0.8.x (and above), this keypress event does not get emitted by default, but rather only when it is being used in conjuction with the readline (or by extension, the repl) module. . This module is the exact logic from the node pre-v0.8.x releases ripped out into its own module. . Bonus: Now with mouse support! -- 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/20130509115914.480.41796.report...@minobo.das-netzwerkteam.de
Re: Merging / and /usr (was: jessie release goals)
On Thu, 9 May 2013 12:33:47 +0100, Roger Leigh rle...@codelibre.net wrote: Regarding rescue, the initramfs has a rescue shell which I've found to be just as useful as single user mode. Isn't that the one that doesn't even have a shell history or tab completion? Once it has mounted the rootfs, you can chroot into that and do whatever you would normally do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as far as mounting the rootfs, then you'll need some rescue disc in any case. You have a point here. The problem is that people need to change their operations, which is hard for many people, let alone the case when emergency manuals need to be changed just for the sake of satisfying Lennart. I find the busybox shell to be just as effective as a rescue disc in most cases. I don't. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uapdl-00061q...@swivel.zugschlus.de
Re: Merging / and /usr (was: jessie release goals)
On Thu, 9 May 2013 10:40:14 +0200, m...@linux.it (Marco d'Itri) wrote: On May 09, Marc Haber mh+debian-de...@zugschlus.de wrote: That's a hack which is acceptable for single-user home desktops. We're talking about professional IT here. Great, if this is the strongest objection you have then looks like it can be done. If you don't care about the companies that use Debian and you want their sponsoring money to go elsewhere, yes, absolutely do this. Otoh, companies runnign IT shops are used to being screwed, so Debian screwing them will be an experience they're already used to. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uapez-000620...@swivel.zugschlus.de
Bug#707559: ITP: node-commander -- The complete solution for Node.js command-line interfaces
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-commander Version : 1.1.1 Upstream Author : TJ Holowaychuk t...@vision-media.ca * URL : https://github.com/visionmedia/commander.js * License : MIT Programming Lang: Javascript Description : The complete solution for Node.js command-line interfaces Commander is a light-weight, expressive, and powerful command-line framework for Node.js. . Inspired by Ruby's commander, this Node.js module provides command line option parsing, automated/customizable help texts, command line prompting password query, and many more features. -- 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/20130509122046.7363.14543.report...@minobo.das-netzwerkteam.de
Re: Merging / and /usr
Marc Haber mh+debian-de...@zugschlus.de writes: Isn't that the one that doesn't even have a shell history or tab completion? At least in squeeze I have both. Try booting with e.g. break=top to see yourself. -- 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/848v3opc6y@sauna.l.org
Re: wheezy postmortem re rc bugfixing
On 09/05/13 at 13:20 +0200, Julien Cristau wrote: On Thu, May 9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote: Also, we should be more agressive at getting down the number of RC bugs by automatically removing RC-buggy not-so-important packages. For example, if we keep the current time-based freeze policy for jessie, we could announce that all not-so-important RC-buggy packages will be removed from testing on freeze date. define:not-so-important. I'm sure that'll be fun. Given that: * the not-so-important status would only be used to decide that some packages can be safely removed from testing when they are RC-buggy, * the release team has authority on deciding what's inside testing I think that the release team can decide on such criterias. Actually, that's something the team already did during the wheezy freeze. I'm just proposing to do that doing that earlier, with more advertised criterias. For example, we could use the following rules: * source packages with binary packages of priority 'standard', 'important', 'required' are important * source packages building udebs are important * source packages building binary packages installed on more than 5% of popcon-reporting packages (that's popcon 7714 currently) are important * build-dependencies of important packages are important A quick hack resulted in: http://udd.debian.org/cgi-bin/important_packages.cgi http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=web/cgi-bin/important_packages.cgi Which gives 2567 such important packages. Of the 963 RC bugs affecting sid currently, only 185 affect sid's important packages. Lucas -- 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/20130509124450.ga22...@xanadu.blop.info
Re: Merging / and /usr (was: jessie release goals)
On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote: That's how I do it for new installs. However, this is vastly more complex than the traditional setup, and it doesn't help for systems in maintenance mode that, for example, cannot be changed because of service level agreements and certifications. And such systems are upgraded to a new release? That'd be surprising. Using Debian happens beyond single-user home desktop settings, you know. I'm pretty sure he knows, so that remark seems unnecessary. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#707571: ITP: node-channels -- Event channels in Node.js
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-channels Version : 0.0.5 Upstream Author : Peter 'Pita' Martischka petermartisc...@googlemail.com * URL : https://github.com/Pita/channels * License : Apache-2.0 Programming Lang: Javascript Description : Event channels in Node.js Channels keeps your messages in order for different endpoints (channels) of your Node.js application. . In Etherpad Channels is used to ensure changes for specific pads have their own channel (gateway) and changesets (planes) are assigned to specific channels (gateways). . Channels is useful if you need to have lots of different I/O operations on different endpoints that you need to keep in order. -- 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/20130509134739.587.2401.report...@minobo.das-netzwerkteam.de
Re: Merging / and /usr (was: jessie release goals)
On May 09, Marc Haber mh+debian-de...@zugschlus.de wrote: If you don't care about the companies that use Debian and you want their sponsoring money to go elsewhere, yes, absolutely do this. Actually I care a lot, since I happen to have a role in one which manages quite a bit of Debian servers (four digits of Debian servers). And there are some interesting business reason for which I want Debian to support a everything-in-/usr file system. So, please let me know if you have some technical objections better than it's an hack. -- ciao, Marco signature.asc Description: Digital signature
Re: Merging / and /usr (was: jessie release goals)
* Marco d'Itri m...@linux.it [130509 16:03]: So, please let me know if you have some technical objections better than it's an hack. Having a seperate / means you have an instant rescue image that has just the right kernel and tools you need to repair the rest of your system. You also have one small filesystem with all the important stuff like /etc in it while the boring large distro stuff is in another partition. You also have a partition border between most of the random stuff and the important stuff. All those are real advantages that people care about. A simple I do it differently or I do not care from your side is hardly anything someone can counter with technical arguments, so you will not see many. Bernhard R. Link -- 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/20130509143822.ga4...@client.brlink.eu
Re: Doubts about PPA in Debian
On 2013-05-09 15:58:02 +0800 (+0800), Thomas Goirand wrote:
On 05/07/2013 10:34 PM, Paul Wise wrote:
On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote:
[...]
Also, the rules in backports is that packages should be
already migrated to testing. The point is, if I had PPAs, I
wouldn't at all upload to SID and wait for a migration to
testing, because it would be better if the packages were
living in the PPA only (that would be a lot more flexible and
adapted to my use case).
I think that would be a bit sad and I hope you don't do that.
I agree. I tried to explain that to upstream, but no luck so far...
There's not much I can do, especially with a project of that size.
[...]
To be fair, it's mostly growing pains. The project is only a few
years old at this point and has over 500 active developers (a
significant percentage of whom do it as a full-time job). There
wasn't previously as strong a focus on long-term supportability and
maintainability as the codebase grew. OpenStack doesn't officially
do development work on bug fixes for releases over a year old, but
also doesn't discourage packagers/distributors from attempting to do
so (and is generally fairly helpful at pointing them in the right
direction if the bug can be easily demonstrated).
It has also recently grown a release upgrade testing suite in its
CI, so future releases will at least provide a fully tested model
for incrementally upgrading database schemas and configuration files
from one release of OpenStack to the next. For distributions
skipping intermediate releases this probably still means carrying a
stub of the skipped releases in the next release, enough to be able
to perform upgrades... but if you'll recall at our last summit there
was also consensus around further splitting out the upgrade
mechanisms so downstreams could make easier use of them (I think you
were in the room for that conversation).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
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/20130509144018.gu1...@yuggoth.org
Re: epoch fix?
On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote: Looks like it might be possible to for test with lintian. I presume it's OK to add the implicit 0: to non-epoch depends? If so, lintian could complain whenever a dependency is specified on a package with an epoch, unless the versions specified also include an epoch, and if you really meant the pre-epoch version, you could just add the 0: to get rid of the warning. This means the output of lintian will vary depending on what versions of the package are visible in the local packages list. AIUI that's something the lintian maintainers try very hard to avoid. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Doubts about PPA in Debian
On 05/07/2013 03:34 PM, Joerg Jaspert wrote: While there are certainly use cases that will stay in a PPA forever (Thomas described one) And I seriously wished it wasn't the case, and that upstream understood better what the distribution requirements are. This should be considered as the last resort, when there is no other way. 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/518bb8e5.2050...@debian.org
Re: Merging / and /usr (was: jessie release goals)
* Roger Leigh rle...@codelibre.net [130509 13:34]: The assumptions here are that a separate rootfs decreases the chance of breakage, and that you'll need the rootfs to perform the rescue. No, the point is that having two file systems reduces the amout of breakage you get. All the important stuff is in / while /usr is mostly static data easily (at least outside /usr/local, and even there more likely than say /etc) recoverable or not that important if lost. Also with the tools in / you can usually repair problems in /usr. There is just the right kernel and just the right versions of all tools. You can do most of the stuff with some rescue-disc, if the versions fits. But too often there are differences. And getting some other tool it misses means you need to either install it in an ramfs and hope you do not need to reboot or you need to have some spare partition on the hw left. And you do not have access to your fstab. While each of those problems is managable alone, they sum up. Each adds to the time you need. And time is often something you do not really want to spend in case you have a problem. And while there is no proof that when having one small and one large partition, the small partition is less likely to fail than everything in one large partition together, both reason and experience demand that this point is quite more than an assumption. Regarding rescue, the initramfs has a rescue shell which I've found to be just as useful as single user mode. Once it has mounted the rootfs, you can chroot into that and do whatever you would normally do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as far as mounting the rootfs, then you'll need some rescue disc in any case. I find the busybox shell to be just as effective as a rescue disc in most cases. rescue /usr in a seperate / + /usr setting usually means making sure it can be mounted again. (Or to transfer data elsewhere, which is also much easier when your normal network setup is already available). In the case where we're mounting /usr in the initramfs rather than having it on the rootfs, there's no practical difference to the current status quo (and this is intentional). The only change is that we provide the guarantee that /usr is available before init starts. Or in other words: to make essential functionality not available if /usr is broken. Bernhard R. Link -- 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/20130509150537.gb4...@client.brlink.eu
Re: Doubts about PPA in Debian
On 2013-05-09 22:55:33 +0800 (+0800), Thomas Goirand wrote:
[...]
And I seriously wished it wasn't the case, and that upstream
understood better what the distribution requirements are.
[...]
Actually, in this case (OpenStack) from what I've seen the upstream
community understands the distribution requirements quite well and
is, on the whole, sympathetic. It's not actively ignoring
distributor/packager concerns--the problem is there aren't enough
developers with an interest in maintaining code old enough for
distributions to carry long-term, since the current development
effort is mainly provided by donors who are interested in pulling
current code directly from the project rather than using
distribution packages (mainly because development is still moving
very, very fast compared to distributions' release schedules).
If enough interested developers suddenly walked up and asked to help
make long-term support happen (along with the additional CI
resources required, and then actually did the work), I don't think
it would be an issue. As the project ages and development stabilizes
further I hope this will begin to emerge naturally within the
developer community, and expect it will become easier to maintain
releases over longer periods of time. Right now there's just too
much code being ripped out, replaced, split into separate projects,
mashed together from separate projects and so on for that to be a
reasonable support expectation.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
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/20130509152953.gv1...@yuggoth.org
Re: epoch fix?
* Steve Langasek vor...@debian.org, 2013-05-09, 07:39: On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote: Looks like it might be possible to for test with lintian. I presume it's OK to add the implicit 0: to non-epoch depends? If so, lintian could complain whenever a dependency is specified on a package with an epoch, unless the versions specified also include an epoch, and if you really meant the pre-epoch version, you could just add the 0: to get rid of the warning. This means the output of lintian will vary depending on what versions of the package are visible in the local packages list. AIUI that's something the lintian maintainers try very hard to avoid. It certainly shouldn't looks at local package list. It could have a static data file listing all known packages with epoched versions, though. And if you have data also about _past_ versions, you can implement a better heuristics than Philip proposed. Porting epoch-mistmatch-finger[0] to Lintian was on my TODO list for a while, but to be frank it doesn't look like I'll find time to implement this any time soon. [0] http://lists.debian.org/20120705213427.ga2...@jwilk.net -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509155500.ga5...@jwilk.net
Re: Depends: libfoo:foreign ???
+++ Goswin von Brederlow [2013-05-09 11:39 +0200]: On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). This does seem wrong, especially in this case. I can't think of a case where it makes sense offhand, but there might be one. I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. We haven't yet formulated any policy on what is/isn't going to be allowed/deemed sensible. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. I don't think that's relevant/correct. A foreign-arch dep is appropriate when the binary is linked against/uses said library, and a same-arch libfoo-arch-cross isn't used instead. Said library could be a perfectly normal M-A:same package. I guess it's time to have a think about this stuff and write down some guidelines/policy. 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/20130509155927.gv2...@stoneboat.aleph1.co.uk
Re: jessie release goals
On 06/05/13 13:49, Andreas Beckmann wrote: now might be the right time to start a discussion about release goals for jessie. Some random make things less fragile ideas, from the packages that FTBFS with the new GLib[1]: * Packages intended to reach stable not FTBFSing just because a function they or their dependencies use was deprecated (implementation: do not use bare -Werror or -Werror=deprecated-declarations; do not define G_DISABLE_DEPRECATED, etc.; in GNOME-land, define GLIB_VERSION_MIN_REQUIRED etc. appropriately) * Packages intended to reach stable not FTBFSing when the compiler introduces a new warning[2] (implementation: do not use bare -Werror, and certainly not -Wall -Wextra -Werror; specific really bad things, like -Werror=implicit, are OK) Packages intended to reach stable includes unstable/testing, but not experimental or PPAs - it's OK, and perhaps even actively good, if development code is liable to FTBFS at the slightest provocation. Conversely, 64-bit-cleanness and general code quality would probably benefit from an archive rebuild with -Werror=implicit (or some suitable set of bad warnings). dpkg-buildflags already uses -Werror=format-security. S [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-ftbfs-20130509 [2] among amusing indications that -Werror is not quite right: byzanz: FTBFS: record.c:59:3: error: function might be possible candidate for 'gnu_printf' format attribute [-Werror=missing-format-attribute] -- 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/518bc8bc.7090...@debian.org
Re: Merging / and /usr (was: jessie release goals)
On May 09, Bernhard R. Link brl...@debian.org wrote:
Or in other words: to make essential functionality not available if
/usr is broken.
Again: this is not we are discussing. Essential functionality is moving
to /usr anyway, no matter if /bin will become a symlink to /usr/bin.
Having a seperate / means you have an instant rescue image that has
just the right kernel and tools you need to repair the rest of your
system.
OK, so you could have an even *smaller* / with a *real* independent
rescue image like grml in /boot.
You also have one small filesystem with all the important
stuff like /etc in it while the boring large distro stuff is in
another partition. You also have a partition border between
most of the random stuff and the important stuff.
Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have
a small filesystem with all the important stuff like /etc in it and the
boring large distro stuff (like 100 MB of kernel modules for each
kernel, currently in /lib) in another partition.
I am glad that we sorted out your use case as well.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: epoch fix?
On Thu, May 9, 2013 at 11:43 AM, Philip Hands p...@hands.com wrote: I presume it's OK to add the implicit 0: to non-epoch depends? No, that not okay. dpkg rewrites versions at times – mainly in /var/lib/dpkg/status – to a canonical form, so this information is lost at some point. Especially does it cause strange behavior in APT: The records in the Packages file (aka with 0:) will be different from the records in the status file (aka without 0:) so APT will think the records talk about two different versions of the package (as the dependencies are different). Example: Package: foo Filename: foo.deb Depends: bar (= 0:0.00-0) Package: foo Status: install ok installed Depends: bar (= 0.0) (And before someone asks: wontfix in APT for performance and code duplication with dpkg reasons, among others) In my eyes it would actually make sense to rewrite the version in a canonical form already at package creation time and warn in lintian if a version wasn't written in the canonical form (as this usually indicates a misunderstanding/bug already). Only problem I see with that is that dpkg isn't providing an interface for it so far which lintian could use. 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_fDVRw__N_qyeo=vrask96l79l535ifhthw_ctu-54w...@mail.gmail.com
Bug#707601: ITP: debmake -- helper script to make the Debian source package
Package: wnpp Severity: wishlist Owner: Osamu Aoki os...@debian.org * Package name: debmake Version : 4.0.0 Upstream Author : Osamu Aoki os...@debian.org * URL : none yet * License : MIT Programming Lang: Python3 Description : helper script to make the Debian source package This package helps you to convert a upstream source package (or VCS contents) into the Debian package by adding files required for the Debian source package. The generated debian/rules file uses the new dh command syntax from the debhelper (9) package. . The debmake command invoked in the upstream source tree without any option can generate template files which is good enough to create a single arch=any Debian binary package for local use. The generated files should be edited to make it conform to the Debian policy if the package is uploaded to the Debian archive. By adding few options, this command can generate template files for the arbitrary combination of the multi-binary and multi-arch package, etc. . This debmake command also scans copyright and license texts in the source files to help crafting the proper DEP-5 compatible debian/copyright file. This is working here. This generates proper dh command line with --with ... for python2 and python3 (with override lines). This also has options to use upstream make dist or tarball as the starting point. I am cleaning up code before upload. No problem for running multiple times and no more extra template files unless requested. FYI: The author thanks previous efforts on this topic (GPL): * debmake: 1996-1997 Christoph Lameter clame...@debian.org 1997-2006 Santiago Vila sanv...@debian.org command: deb-make, version up to 3.8 (shell script) (not in wheezy) * dh-make: 1998-2012 Craig Small csm...@debian.org command: dh_make (perl script) Version starts from 4.0.0 since old debmake was 3.8. === $ debmake -h usage: debmake [-h] [-a upstream-version.tar.gz | -d] [-p package_name] [-u upstream_version] [-r debian_revision] [-z extension] [-b package[:type]] [-c license_file] [-e f...@example.org] [-f firstname lastname] [-i] [-m] [-n] [-o] [-q] [-v] [-x] debmake: make Debian source packageVersion: 4.0.0 Copyright © 2013 Osamu Aoki os...@debian.org debmake builds the Debian package from the upstream source. Normally, this is done as follows: * The upstream tarball is downloaded as the upstream-version.tar.gz file. * The upstream_version.orig.tar.gz symlink is generated pointing to the upstream tarball. * It is untared to create many files under the upstream-version/ directory. * debmake is invoked in the upstream-version/ directory without any arguments. * Files in the upstream-version/debian/ directory are manually adjusted. * dpkg-buildpackage is invoked in the upstream-version/ directory to make debian packages. optional arguments: -h, --helpshow this help message and exit -a upstream-version.tar.gz, --archive upstream-version.tar.gz use the upstream source tarball directly (-p, -u, -z: overridden) -d, --distrun make dist equivalent first to generate upstream tarball and use it -p package_name, --package package_name set the Debian package name -u upstream_version, --upstreamversion upstream_version set the upstream package version -r debian_revision, --revision debian_revision set the Debian package revision -z extension, --targz extension set the tarball type, extension=(tar.gz|tar.bz2|tar.xz) -b package[:type], --binaryspec package[:type] set binary package specs, package=(-|-doc|-dev|-common|-bin|-dbg), type=(all|any|foreign|same) (This can have -bpackage1:type1,package2:type2,package3:type3) -c license_file, --copyright license_file add formatted license to debian/copyright -e f...@example.org, --email f...@example.org set e-mail address -f firstname lastname, --fullname firstname lastname set the fullname -i, --initialize set-up debhelper to run autoreconf -ivf to initialize for Autotools -m, --monoarchforce packages to be non-multiarch -n, --native make a native source package without .orig.tar.gz -o, --overwrite overwrite existing configuration files -q, --quitearly quit early before creating files in the debian directory -v, --version show version information -x, --extra generate extra configuration
Re: idea: generalized soft dependencies
On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin jac...@debian.org wrote:
Soft-Depends: a {90%}, b (= 1.2) {20%}, c (= 4) {99%}, c (= 6) {70%}
If we assume its already hard to decide recommends or suggests it will
be impossible to choose a number between 0 and 100. Basically we are rating
likelihood of usage here and while the one provided by a will be a
common one for many, I am not up to the task of deciding if it will be
used by 90%, 80% or just 70% so naturally numbers will be assigned at
random, which in turn means as a user I can't say: hey, install if
= 70/80/90 as it means something different for everyone.
Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
So supposedly on 50% of all desktops iceweasel is installed which can
in turn be used by the software having this dependency. Great, but I still
have no idea why 50% installed it and 50% don't.
Which 50% group I am part of? The tag desktop might give a hint, but
such tags need to be defined and carry a meaning. A tag like laptop
tells me that it will help with powersaving (which would probably be the
better tag name, as I will like want to install it on my phone too),
printing is useless if I don't have a printer, online and streaming
might not be the best ideas if I have no internet connection at all …
That's a lot harder of course, but caries way more useful information as
I have no idea how many people don't have their own nuclear power plant,
highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
that in my area (and I would probably still be wrong), but not on a global
scale.
Soft-Depends: debdelta {10%,text:to enable automatic delta downloading}
While this solves the why, we have a new problem: Translations
And these texts are quickly written in a way a user can't use:
What the hell is a delta? - debian-l10n-english to the rescue!?
Its really up to the debdelta package to tell the user what it does as in
this case it seems to be a plugin, so this should be an Enhances even if
from a technical point the glue to use debdelta is in the package the
enhances would point to.
Of course, this doesn't work if wget is used instead of debdelta in the
example as wget is used by a lot of stuff, but always for the same task:
So annotating all dependencies on wget with the tag use:downloading just
feels wrong. And the package wget is already tagged with use:downloading,
we just don't make proper use of this so far.
So in summary, I see a need for it, and I would like to reserve the syntax
we will use for build-profiles in build-dependencies also in normal
dependencies as use-profiles (as Johannes has already pointed to), but we
should really use the current information we already have much more and
take the new syntax we could use in ~2 releases as an override/selector
(e.g. iceweasel has 3 uses, so we could select which one is meant).
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_fComDVFrVKUTmCUNDDGaMQpmxmmrSZgfGoFy=qmkvk...@mail.gmail.com
Re: New version of libselinux makes libpcre3 pseudo-essential
On Wed, May 8, 2013 at 8:09 PM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Wed, 8 May 2013 11:56:15 +0200, Bastian Blank wa...@debian.org wrote: Please re-read the policy, especially 2.5: | Packages must not depend on packages with lower priority values | (excluding build-time dependencies). IIRC that policy paragraph is from the times where our CD build software didn't follow dependencies when choosing packages for images. Afaik, they have been following dependencies for a decade now, so this policy paragraph could be removed. Please don't. Various tools might depend on it. APT will e.g. refuse to consider required packages from being autoremoved and while it is fixed since squeeze, it used to boggle on violations (#583517). It's also using the priorities in its scoring calculations to decide which packages are more important to keep working (granted, dependencies will influence it too, but every point might count). Lifting this requirement makes priorities useless in the end as an optional package which is a dependency of an important package is not optional. It must be dealt with by software as well as people as if it is important, so lets just mark it that way – or drop priorities completely, but not some wishy-washy middle ground. 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_fc0jo4hhemeg_r9wghaqrpi7gungcuun3jbklowptg...@mail.gmail.com
Re: epoch fix?
On 05/08/2013 05:07 PM, Thomas Goirand wrote: On 05/08/2013 11:27 AM, Adam Borowski wrote: On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote: What I think should be fixed is the fact that it doesn't appear in the filename. I never understood why they don't. Did I miss something? Having a colon in CD/DVD images is likely to cause problems, with the chance of breakage reaching 100% if there's Windows nearby. Not sure what a clean way of escaping the colon would be. We don't *have* to use a semi-colon on the file names, if that char is a problem. Thomas Seems nobody is picking-up on the topic, so I'll try once more, because I'm convince there's something we could do here. How about replacing epoch separator char : by @ in the filenames for example? 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/518be46b.4010...@debian.org
Bug#707615: ITP: python-autopep8 -- tool that automatically formats Python code to conform to autopep8
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-autopep8 Version : 0.8.7 Upstream Author : Hideo Hattori hhatto...@gmail.com * URL : https://pypi.python.org/pypi/autopep8 * License : Expat Programming Lang: Python Description : tool that automatically formats Python code to conform to autopep8 autopep8 automatically formats Python code to conform to the PEP 8 style guide. It uses the pep8 utility to determine what parts of the code needs to be formatted. autopep8 is capable of fixing most of the formatting issues that can be reported by pep8. -- 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/20130509150714.31392.1496.report...@muck.riseup.net
Bug#707619: ITP: python-paisley -- CouchDB client written in Python to be used within a Twisted application
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-paisley Version : 0.3.1 Upstream Author : David Reid and Thomas Herve * URL : https://github.com/objcode/paisley * License : Expat Programming Lang: Python Description : CouchDB client written in Python to be used within a Twisted application Paisley implements the CouchDB API for Twisted. -- 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/20130509152120.1002.77317.report...@muck.riseup.net
Bug#707620: ITP: python-dirspec -- Python User Folders Specification Library
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-dirspec Version : 4.2.0 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/dirspec * License : LGPL-3 Programming Lang: Python Description : Python User Folders Specification Library A library for handling the XDG Base Directory specification, and the XDG User Directories for music, videos, etc… -- 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/20130509155316.12651.46511.report...@muck.riseup.net
Bug#707625: ITP: u1db -- Ubuntu One structured data storage - Python API
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: u1db Version : 0.1.4 Upstream Author : Canonical Ltd * URL : https://launchpad.net/u1db * License : LGPL-3 Programming Lang: Python, C Description : Ubuntu One structured data storage - Python API U1DB is a database API for synchronised databases of JSON documents. It’s simple to use in applications, and allows apps to store documents and synchronise them between machines and devices. U1DB itself is not a database: instead, it’s an API which can be backed by any database for storage. This means that you can use U1DB on different platforms, from different languages, and backed on to different databases, and sync between all of them. It's built to sync with your own servers or with Ubuntu One. -- 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/20130509183819.15506.65409.report...@muck.riseup.net
Re: can someone explain what is happen on line one from this listing?
It seems you have a faulty hard disk.
Istimsak abdulbsir
On May 9, 2013 7:47 AM, Mailbox maill...@ai-t.eu wrote:
Hello Developer Group,
can someone explain what is happen on line one from this listing?
why i loos the interrupt?
what is the Status 0x50?
has someone a idea in which Documentation an can finde more informations
about 0x50?
May 7 19:39:57 lxhs110a kernel: [316946.812055] ata2: lost interrupt
(Status 0x50)
May 7 19:39:57 lxhs110a kernel: [316946.812072] ata2: exception Emask
0x10 SAct 0x0 SErr 0x4405 action 0xf
May 7 19:39:57 lxhs110a kernel: [316946.812116] ata2: SError: { PHYRdyChg
CommWake DevExch }
May 7 19:39:57 lxhs110a kernel: [316946.812156] ata2: hard resetting link
May 7 19:39:58 lxhs110a kernel: [316947.536038] ata2: SATA link up 1.5
Gbps (SStatus 113 SControl 300)
May 7 19:39:58 lxhs110a kernel: [316947.560823] ata2.00: configured for
UDMA/133
May 7 19:39:58 lxhs110a kernel: [316947.560831] end_request: I/O error,
dev sdb, sector 25141733
May 7 19:39:58 lxhs110a kernel: [316947.560876] md: super_written gets
error=-5, uptodate=0
May 7 19:39:58 lxhs110a kernel: [316947.560880] raid1: Disk failure on
sdb4, disabling device.
May 7 19:39:58 lxhs110a kernel: [316947.560881] raid1: Operation
continuing on 1 devices.
May 7 19:39:58 lxhs110a kernel: [316947.560962] ata2: EH complete
May 7 19:39:58 lxhs110a kernel: [316947.595196] RAID1 conf printout:
May 7 19:39:58 lxhs110a kernel: [316947.595198] --- wd:1 rd:2
May 7 19:39:58 lxhs110a kernel: [316947.595201] disk 0, wo:1, o:0,
dev:sdb4
May 7 19:39:58 lxhs110a kernel: [316947.595203] disk 1, wo:0, o:1,
dev:sda4
May 7 19:39:58 lxhs110a kernel: [316947.608009] RAID1 conf printout:
May 7 19:39:58 lxhs110a kernel: [316947.608011] --- wd:1 rd:2
May 7 19:39:58 lxhs110a kernel: [316947.608013] disk 1, wo:0, o:1,
dev:sda4
thanks
Paulo
--
To UNSUBSCRIBE, email to
debian-devel-REQUEST@lists.**debian.orgdebian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/**518b8c73.20...@ai-t.euhttp://lists.debian.org/518b8c73.20...@ai-t.eu
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). Sorry for not knowing the answer to this, but does britney support :any dependencies? These don't require any cross-architecture dependency resolution, but should be satisfiable within each architecture; britney just needs to support them. This would let us finally make use of Multi-Arch: allowed in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: idea: generalized soft dependencies
Hi,
Thank you for comments.
2013-05-09 18:44, David Kalnischkies:
On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin jac...@debian.org wrote:
Soft-Depends: a {90%}, b (= 1.2) {20%}, c (= 4) {99%}, c (= 6) {70%}
If we assume its already hard to decide recommends or suggests it will
be impossible to choose a number between 0 and 100. Basically we are rating
likelihood of usage here and while the one provided by a will be a
common one for many, I am not up to the task of deciding if it will be
used by 90%, 80% or just 70% so naturally numbers will be assigned at
random, which in turn means as a user I can't say: hey, install if
= 70/80/90 as it means something different for everyone.
Interesting view. I saw it from exactly opposite direction: one
maintainer sees Recommends as '95%' and another as '60%'. I as
maintainer would have much easier time with writing percents or other
attribute criteries than putting all different stuff into two
categories, YMMV. 70% and 80% are close to each other, true, but 90% and
99% are two different things, and using current rules I'd put both to
Recommends. Many maintainers put 99%-stuff to Depends because users
cannot command disable '90%'-Recommends so they command disable all
Recommends. This is (part of) what I am trying to solve.
tl;dr: I would want to be able to differentiate between, for example,
- install this or your system will break (unless you did special things so it
does not);
- install this unless you know you'll never need this feature;
- this things is worth installing by default.
Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
So supposedly on 50% of all desktops iceweasel is installed which can
in turn be used by the software having this dependency. Great, but I still
have no idea why 50% installed it and 50% don't.
It was an example of maintainer guessing that half of users of some
software will want also iceweasel installed, provided the computer is
desktop.
Which 50% group I am part of? The tag desktop might give a hint, but
such tags need to be defined and carry a meaning. A tag like laptop
tells me that it will help with powersaving (which would probably be the
better tag name, as I will like want to install it on my phone too),
printing is useless if I don't have a printer, online and streaming
might not be the best ideas if I have no internet connection at all …
That's a lot harder of course, but caries way more useful information as
I have no idea how many people don't have their own nuclear power plant,
highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
that in my area (and I would probably still be wrong), but not on a global
scale.
I don't propose any specific attribute. I propose to have an ability to later
discuss and standardize these attributes.
Soft-Depends: debdelta {10%,text:to enable automatic delta downloading}
While this solves the why, we have a new problem: Translations
And these texts are quickly written in a way a user can't use:
What the hell is a delta? - debian-l10n-english to the rescue!?
[...]
You speak about problems of a specific example attribute. We might use
text: attribute, we might not use is. Unless your point is say that
(all) attributes don't help (and therefore the proposal doesn't make the
situation better), this is not what proposal is about.
Of course, this doesn't work if wget is used instead of debdelta in the
example as wget is used by a lot of stuff, but always for the same task:
So annotating all dependencies on wget with the tag use:downloading just
feels wrong. And the package wget is already tagged with use:downloading,
we just don't make proper use of this so far.
Sounds like I had not enough good example if you feel this was about
'use:downloading'. The idea of this example was not to repeat packages
descriptions, but say how the soft dependency will help exactly this
package in question. This one should illustrate better:
libcupt2-0: Soft-Depends: ed (text:to enable downloading PDiffs)
[...] we should really use the current information we
already have much more [...]
I kind of disagree here. Currently we have zero dependency-specific
information apart of a) what group of Depends/Recommends/Suggests the
maintainer put the dependency to b) possible free-form explanations in
long descriptions or other package documentation.
--
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/20130509192458.GB4105@debian-w500.Elisa
Re: idea: generalized soft dependencies
Hi, 2013-05-09 09:01, Johannes Schauer: [...] Soft-Depends: a [minthresh:90], b (= 1.2) [minthresh:20], c (= 4) [minthresh:99], c (= 6) [minthresh:70] Soft-Depends: iceweasel [minthresh:50 tag:desktop], curl [minthresh:95 !installed:wget] Indeed, this syntax would be just as good. -- 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/20130509192734.GC4105@debian-w500.Elisa
Debian development and release: always releasable (essay)
This is from Russ Allbery and myself. See http://wiki.debian.org/Debate for context, and http://wiki.debian.org/AlwaysReleasableTesting for the canonical version of this essay. We hope that the readers will take their time to read this, reflect on it, and then maybe write their own essay and add it to http://wiki.debian.org/JessieReleaseProcess . Comments on the wiki or by e-mail are, of course, always welcome. - - - The wheezy freeze has been much too long. At ten months, it's four months longer than what we've gotten used to in several previous releases. Had we managed to keep the freeze at six months, it would still have been too long. I believe there is something wrong in how we develop Debian, and how we do releases, and that by fixing them, we can have much shorter releases, with an increase in their quality. Freezes are long in part because we need to do so much work during them. Most importantly, we need to fix so many release critical bugs (RC bugs), that a short freeze is not possible, without drastically lowering the quality of Debian. A long freeze is highly frustrating to everyone. It's a very stressful period for the release team, obviously, but since the freeze affects all development, even those of our developers who do not care about the release feel its effects in their development. Our users would like fresh upstream versions, but that rarely happens in unstable, and because the freeze is so long, when the release actually happens, much software seems a bit stale. Upstreams, who would like to get their software into the hands of users as soon as possible, including via Debian, are also frustrated. We should aim for a short freeze, perhaps as short as two weeks, and certainly not longer than two months. This would remove the frustration, and fix the other problems related to a long freeze. However, to achieve a short freeze, we need to change how develop Debian. The fundamental change is to start keeping our testing branch as close to releasable as possible, at all times. For individual projects, this corresponds to keeping the master or trunk branch in version control ready to be released. Practitioners of agile development models, for example, do this quite successfully, by applying continuous integration, automatic testing, and by having a development culture that if there's a severe bug in master, fixing that gets highest priority. We can do similar things in Debian, and if we do, I believe that we can keep testing in a releaseable state almost all of the development cycle between two releases. The minimum necessary changes to achieve this, in my opinion, are: * An attitude change: we decide that releases are important, and that they're the job of the entire project, not just the release team. * Keep testing free of RC bugs. * We should use automatic testing much more extensively, to find problems as early as possible. * We should limit the number of packages we strongly care about for a release. Releases are important -- Releases are important to many, perhaps most, of our users. Hackers and hardcore powerusers don't necessarily care about them, of course, but most others do. A released version of Debian implies that the operating system works: there's a working installer, for example. It also implies that all the packages are expected to work together: there's no transitions going on, for example, that might break dependencies or reverse dependencies. A release is important to many users because it means that if they have to re-install, they will get back the same system they used to have. Or they can install another computer that will behave the same way as the first one. This reproducibility is also why enterprises like them: they can confidently assume that if they install fifty thousand machines, they'll all be the same. Without this kind of uniformity, system administration costs, and end-user support costs, become unmanageable. But releases are also important for us, as a project. They're an excellent point to stop and say, we have achieved this, and it is good. It's a reason for others to have a look at Debian and see that it is good. This generates a good feeling, which gives us more motivation to work on Debian. It's true that we can't expect every Debian developer to care about making a release. That's OK. We just need the minority who don't care to not get in the way of the release. Keep testing free of RC bugs The RC bug count for the testing branch should be kept low all the time. Right after a release, by definition, testing is free of RC bugs. With the current development model, right after the release we open the floodgates, and large number of new packages and versions enter testing. The bug count sky-rockets, but we don't care a lot about that until the next freeze gets closer. This means testing is not anywhere near in a releasable condition during most of the development cycle. We should,
Re: Depends: libfoo:foreign ???
On 2013-05-09 21:00, Steve Langasek wrote: [...] Sorry for not knowing the answer to this, but does britney support :any dependencies? These don't require any cross-architecture dependency resolution, but should be satisfiable within each architecture; britney just needs to support them. This would let us finally make use of Multi-Arch: allowed in the archive. At the moment, no. We had her treat pkg:arch as a package name causing it to always fail (as no package can have colon in their name). But feel free to file bugs for it (bonus points if they include tests[1]). ~Niels [1] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git;a=summary -- 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/518bffcf.6060...@thykier.net
Re: DPA instead of PPA
In article 518b7cf6.3080...@debian.org you write: On 09/05/13 07:38, Raphael Hertzog wrote: bikeshed \o/ You probably meant this to be a comment on the discussion rather than a suggested name, but until it gets uploaded to unstable, you can get GNOME 3.8 from the GNOME Team bikeshed actually sounds like a reasonable sentence to write. :-) +1 for the bikeshed name. I think it's a *perfect* fit! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.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/e1uax48-jr...@mail.einval.com
Re: can someone explain what is happen on line one from this listing?
On Thu, May 09, 2013 at 01:45:55PM +0200, Mailbox wrote: Hello Developer Group, can someone explain what is happen on line one from this listing? [...] This is off-topic; you should ask on the debian-user list or other support channel. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20130509201726.gd6...@decadent.org.uk
Bug#707640: ITP: node-security -- Safely encoding and decoding methods with Node.js
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-security Version : 1.0.0 Upstream Author : Chad Weider cwei...@oofn.net * URL : https://github.com/cweider/js-security * License : Expat Programming Lang: Javascript Description : Safely encoding and decoding methods with Node.js Safely encode/decode HTML, Javascript and CSS data compliant to the standard as demanded by the OWASP when using Node.js. -- 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/20130509201530.27625.20872.report...@minobo.das-netzwerkteam.de
Re: Debating difficult development issues in essay form
On Thu, 2013-05-09 at 20:45 +0100, Lars Wirzenius wrote: This e-mail is jointly from Lars Wirzenius and Russ Allbery. The executive summary: We'd like to see more thoughtful debates of important Debian development issues, and have created http://wiki.debian.org/Debate as a way to encourage them. A very good initiative. I hope it takes off. Looking forward to the posts there instead of at debian-devel. -- 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/1368131548.4595.37.camel@PackardBell-PC
Bug#707642: ITP: node-node-redis -- Redis client implementation for Node.js
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-node-redis Version : 0.1.6 Upstream Author : Tim Smart t...@fostle.com * URL : https://github.com/tim-smart/node-redis * License : Expat Programming Lang: Javascript Description : Redis client implementation for Node.js Redis is a networked, in-memory, key-value data store with optional durability. . This module provides Redis client support for Node.js. -- 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/20130509203247.32331.28859.report...@minobo.das-netzwerkteam.de
Re: Developer repositories for Debian
Raphael Hertzog hert...@debian.org writes: On Mon, 06 May 2013, Joerg Jaspert wrote: Nah, the webinterface just should end up like the DAM webinterface: You do whatever you need, then click a button - and voila, there is everything ready to copy/paste into a MUA. Send with sig, done. Why? This is just a band-aid and not what I would call a web interface. And except lazyness I don't see a good reason for that. Web interfaces can be secure (and with an audit trail in case of breach). After all we can manage our Debian passwords over a web interface... That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). -- 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/87haibnb9y@windlord.stanford.edu
Re: Debian development and release: always releasable (essay)
❦ 9 mai 2013 21:49 CEST, Lars Wirzenius l...@liw.fi : * Remove RC buggy packages sooner rather than later. An RC buggy package should be removed at soon as possible: when the bug is identified, allow a bit of time for the bug to be verified (was it actually an RC bug?), but after that, remove the package from testing, preferably automatically. If the package has reverse dependencies, remove those as well. This keeps testing releasable. The removed package can and will re-enter testing once it gets fixed. I think that's a very good idea. A threshold on the number of source packages that can be removed from testing due to an RC bug could be something like 10. The release team should be entitled to delay the removal if the bug is quite complex. I think that the other things you propose are too complicated: A package that is not included in one or more of the reference installations is a package we want to include in the release, but we will not delay the release for its sake. We should have a low threshold for removing such a package from testing: it could perhaps even be removed automatically one week after an RC bug is filed against it (assuming the bug affects the version in testing). If a package is important, an RC bug will get noticed and someone will step to fix the RC bug or ask for a delay. This avoids unnecessary debate on what is important and what is not and people fighting to get their packages in the right list. Tests for running reference installation might include the following: * Basic networking setup works: System responds to ping from the outside. * Mail server responds appropriate on the SMTP, submission, IMAPS, and POPS ports. * LAMP server responds on the HTTP and HTTPS ports. * A desktop system that automatically logs in a test user has the right processes running, and can start some common applications. * In each case, it's possible to log in remotely with ssh and run sudo apt-get install hello. Many people run unstable and a bug that would fail those kind of tests would get immediatly noticed and many bug reports are usually opened at once for each of those bugs. Maybe those tests would catch them one hour earlier but is it worth spending time to conceive those tests? These are trivial, even simplistic tests. However, if they pass, we know that at least the basic, fundamental things in the system are not horribly broken: networking, system administration, and the software that is meant to start in that reference installation. Furthermore, we know that the debian-installer works. That's a good foundation for further hacking. Maybe the installer is less daily tested but did we already have a major bug (one that does not pass the test you described) gone unnoticed? -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c pgpQIIIqPZawA.pgp Description: PGP signature
Re: New version of libselinux makes libpcre3 pseudo-essential
Игорь Пашев pashev.i...@gmail.com writes: Will it change anything except non-linux systems will get libpcre3 by default, while do not need it? Maybe make libselinux optional? ;-) windlord:~ apt-cache rdepends libselinux1 | tail libglib2.0-0 gdm3 dump dpkg dmraid dbus-1-dbg dbus cron coreutils aide-dynamic No. :) -- 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/87d2sznb1z@windlord.stanford.edu
Bug#707643: ITP: python-grokmirror -- Framework to smartly mirror git repositories
Package: wnpp Severity: wishlist Owner: Adrian Alves aal...@gmail.com * Package name: python-grokmirror Version : 0.3 Upstream Author : Konstantin Ryabitsev mri...@kernel.org * URL : https://git.kernel.org/cgit/utils/grokmirror/grokmirror.git * License : GPL Programming Lang: Python Description : Framework to smartly mirror git repositories Grokmirror was written to make mirroring large git repository collections more efficient. Grokmirror uses the manifest file published by the master mirror in order to figure out which repositories to clone, and to track which repositories require updating. The process is extremely lightweight and efficient both for the master and for the mirrors. -- 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/20130509203847.6826.85548.reportbug@xion
Re: Debian development and release: always releasable (essay)
Vincent Bernat ber...@debian.org writes: ❦ 9 mai 2013 21:49 CEST, Lars Wirzenius l...@liw.fi : A package that is not included in one or more of the reference installations is a package we want to include in the release, but we will not delay the release for its sake. We should have a low threshold for removing such a package from testing: it could perhaps even be removed automatically one week after an RC bug is filed against it (assuming the bug affects the version in testing). If a package is important, an RC bug will get noticed and someone will step to fix the RC bug or ask for a delay. This avoids unnecessary debate on what is important and what is not and people fighting to get their packages in the right list. Personally, I think it's important to be more transparent and systematic about how we designate packages as important or not important; it will add clarity and it will let us be more efficient and encourage people to be bold. The fact of the matter is that we already have those distinctions: we will remove random leaf packages from testing as soon as the release gets close, but we're not going to remove cron or bash. But the distinctions are fuzzy and require people to make (and then argue about) judgement calls. We can't eliminate the arguments entirely, but I think we can approach the process in a cleaner way that will require less constant debate. Package sets for critical purposes are useful in their own right. They make it clear why a package is important (and also why it may *cease* to be important), and they also provide a basis for automated testing. Personally, I'd be inclined to unify optional and extra (which at this point don't really represent a meaningful difference) and possibly even further simplify our use of priorities (it's not clear to me that standard is really buying us anything any more), replacing most of that with package sets for key use cases that we want to support. One interesting possibly that this would also open up (and please understand that I don't know if this would happen and I'm not positive that it's a good idea; I'm just throwing it out there) is that the teams who most care about a particular reference package set could also do some of the release management duties for that package set. For example, suppose we had a LAMP team of experts in that package set. Could they possibly take on, not just maintaining the list of packages, but doing freeze reviews and transition coordination for transitions that are contained within that set? To some extent, the desktop packaging groups (GNOME, KDE, etc.) already do some of this for those desktop environments, and I think that's quite helpful and might be useful to formalize further. Many people run unstable and a bug that would fail those kind of tests would get immediatly noticed and many bug reports are usually opened at once for each of those bugs. Maybe those tests would catch them one hour earlier but is it worth spending time to conceive those tests? Yes, absolutely. Because when you have the tests, it opens up all sorts of possibilities for automation. For example, you could, in the future, put newly-uploaded packages in a holding area until the tests pass and not allow them into the archive until they do. Breakage bugs in unstable are very valuable, but they also represent *breakage* and take someone's time and attention to write up. Anything we can catch on an automated basis saves precious human resources. These are trivial, even simplistic tests. However, if they pass, we know that at least the basic, fundamental things in the system are not horribly broken: networking, system administration, and the software that is meant to start in that reference installation. Furthermore, we know that the debian-installer works. That's a good foundation for further hacking. Maybe the installer is less daily tested but did we already have a major bug (one that does not pass the test you described) gone unnoticed? We've had system-breaking bugs in core packages like libc6 enter the archive in the past. They don't make it through to testing, no, but they do take up people's time and attention in unstable, and it's all more resources that we can't spend on other things that are more useful. And, over time, the tests can become more sophisticated. That's the great part about building a testing framework: once you have a good framework in place, it becomes much easier to add more tests, and you can build something like Lintian (which is now quite extensive) from a modest beginning. -- 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/8761yrn9sf@windlord.stanford.edu
Bug#707656: ITP: node-node-dequeue -- Simple Double Ended Queue Datastructure for Node.js
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-node-dequeue Version : 1.0.3 Upstream Author : Sean (lleo) M. Egan lle...@gmail.com * URL : https://github.com/lleo/node-dequeue * License : BSD-2-clause Programming Lang: Javascript Description : Simple Double Ended Queue Datastructure for Node.js Dequeue is implemented as a doubly linked circular list with a titular head node--an empty node to designate the beginning and the end of the circularly linked list. . It is a drop-in replacement for javascript-arrays-as-fifo. -- 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/20130509233319.7965.319.report...@minobo.das-netzwerkteam.de
Work-needing packages report for May 10, 2013
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 512 (new: 9) Total number of packages offered up for adoption: 139 (new: 5) Total number of packages requested help for: 64 (new: 3) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: elilo (#707112), orphaned 2 days ago Description: Bootloader for systems using EFI-based firmware Reverse Depends: bootcd-ia64 Installations reported by Popcon: 141 hsqldb (#707122), orphaned 2 days ago Reverse Depends: biomaj entagged eucalyptus-java-common hsqldb-server hsqldb-utils libbiojava1.7-java libbiojava3.0-java libhsqldb-java-gcj libopenjpa-java libreoffice-base (3 more omitted) Installations reported by Popcon: 71234 ko.tex (#707573), orphaned today Description: Korean TeX: Core macros Reverse Depends: ko.tex Installations reported by Popcon: 25 ko.tex-extra-hlfont (#707574), orphaned today Description: Korean TeX: Extra HLaTeX fonts Installations reported by Popcon: 3275 ko.tex-unfonts (#707575), orphaned today Description: Korean TeX: Base fonts Reverse Depends: ko.tex Installations reported by Popcon: 37 libapache-mod-layout (#707149), orphaned 2 days ago Description: Apache web page content wrapper Installations reported by Popcon: 51 libapache-mod-random (#707143), orphaned 2 days ago Description: Create random ads, quotes and redirects Installations reported by Popcon: 20 sampleicc (#707334), orphaned today Reverse Depends: libicc-utils-dev libsampleicc-dev sampleicc-tools Installations reported by Popcon: 70 ttf-alee (#707576), orphaned today Description: free Hangul TrueType fonts Reverse Depends: sdl-ball-data Installations reported by Popcon: 1190 503 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: ant-phone (#707572), offered today Description: An interactive ISDN telephone application Installations reported by Popcon: 12 dawgdic (#706886), offered 4 days ago Description: C++ library for DAWG dictionaries Installations reported by Popcon: 9 libb64 (#706894), offered 4 days ago Description: base64 encoding/decoding library Reverse Depends: libb64-dev Installations reported by Popcon: 6 python-dawg (#706887), offered 4 days ago Description: Python library for DAWG dictionaries Installations reported by Popcon: 1 sentinella (#707649), offered today Description: System monitor that can react to user chosen conditions Installations reported by Popcon: 134 134 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] openmx (#706711), requested 6 days ago Installations reported by Popcon: 178 [NEW] openni2 (#707056), requested 2 days ago Description: Debian package for openni version 2 software from OpenNi.org [NEW] parmetis (#706710), requested 6 days ago (non-free) Reverse Depends: libparmetis-dev libsuitesparse-metis-3.1.0 libsuitesparse-metis-dbg libsuitesparse-metis-dev parmetis-test Installations reported by Popcon: 218 apt-xapian-index (#567955), requested 1193 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 79336 asymptote (#517342), requested 1532 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 4821 athcool (#278442), requested 3117 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 66 balsa (#642906), requested 592 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 932 bastille (#592137), requested 1006 days ago Description: Security hardening tool Installations reported by Popcon: 188 cardstories (#624100), requested 745 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 9 chromium-browser (#583826), requested 1075 days ago Description: Chromium browser Reverse Depends: chromium chromium-browser chromium-browser-dbg
Re: DPA instead of PPA
On Thu, 09 May 2013, Steve McIntyre wrote: In article 518b7cf6.3080...@debian.org you write: On 09/05/13 07:38, Raphael Hertzog wrote: bikeshed \o/ You probably meant this to be a comment on the discussion rather than a suggested name, but until it gets uploaded to unstable, you can get GNOME 3.8 from the GNOME Team bikeshed actually sounds like a reasonable sentence to write. :-) +1 for the bikeshed name. I think it's a *perfect* fit! :-) At least for PPAEXT, it really fits... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510022018.ga18...@khazad-dum.debian.net
Re: Current and upcoming toolchain changes for jessie
On 09/05/2013 06:06, Florian Weimer wrote:
I mistyped, I meant ABI. I'm deeply sorry about that, it mangles my
statement quite badly.
AFAIK, this is the major reason why the C++11 support is still marked
as experimental.
C++ never had a set ABI in the standard. It's up to compiler/toolchain/library
writers to ensure that there aren't ABI breakages. Considering that you still
link against the same libstdc++.so.6 regardless of whether or not you use C++11
features, I don't see how avoiding C++11 features will avoid triggering a
mass-rebuild in the event of an ABI break in libstdc++6.
std::string, std::list and probably std::shared_ptr will have to
change ABI at some point.
When that happens, it'll probably be namespaced somehow, because the C++98
std::{string,list,shared_ptr}'s will still have to stay. Then C++11 programs
compiled against older libstdc++ will just continue to use the C++98
std::{string,list,shared_ptr} and remain binary-compatible. No recompilation
required there.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: Developer repositories for Debian
On Fri, May 10, 2013 at 4:33 AM, Russ Allbery wrote: That level of security isn't great, though. GPG keys are much more secure than that password. What we would want for equivalent security in a web interface is personal X.509 certificates. I think it would be interesting to have that infrastructure in place, but someone would need to build it (probably with some mechanism to bootstrap GPG keys into X.509 certificates -- and be careful of expiration times and figure out a good way to deal with revocation). That mechanism already exists (and supports SSH too): http://web.monkeysphere.info/ The monkeysphere developers are Debian folks and have discussed monkeysphere with DSA at various DebConfs. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FhKHGd7MVZ30zu6M_=okbsyenis1p8ptaak7gqcvl...@mail.gmail.com
Re: New version of libselinux makes libpcre3 pseudo-essential
On Fri, May 10, 2013 at 4:38 AM, Russ Allbery wrote: Игорь Пашев writes: Will it change anything except non-linux systems will get libpcre3 by default, while do not need it? Maybe make libselinux optional? ;-) windlord:~ apt-cache rdepends libselinux1 | tail ... No. :) Since it is Linux-specific, it is already optional on kFreeBSD so there is probably nothing for Игорь Пашев to do on his Debian and Solaris based system. pabs@asdfasdf:~$ apt-cache rdepends libselinux1 libselinux1 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6ENkhBtOyyfRVcW=rgT462CLndMXyekySEW=Z1T=ib...@mail.gmail.com
Re: DPA instead of PPA
Le Thu, May 09, 2013 at 08:38:02AM +0200, Raphael Hertzog a écrit : Hi, On Wed, 08 May 2013, Holger Levsen wrote: I actually really like this idea! (Though I suggest Debian Personal Archive.) It's really different from what people know as PPAs. To be fair, Personal is probably not relevant either. I expect many of those repositories to be maintained by teams. DSPA = Debian Special Purpose Archive DSPR = Debian Special Purpose Repository DASP = Debian Archive of Special Packages SPA = Special Package Archive Hi all, Fist of all, many thanks to Joerg and the FTP team to push this project forward. I find it exciting and innovative and I like that it is not simply reproducing Ubuntu's PPAs, but rather aims at providing a direct benefit to Debian's development in general. For this reason, I also recommend to avoid using PPA in the name. About the names discussed by Raphael and others, I also think that personal does not reflect well the goals suggested for PPAMAIN. Keywords like Special, Project, etc., sound to me more to the point. For SPA in particular, I think that would trigger puns in French, as is the name of a society that, among others, takes care of abandonned animals. Also, since PPAMAIN will be embedded in the Debian archive, maybe there is no need to repeat Debian in its name. I also would like to recommend to call these repositories in a way that shows directly how they are integrated in the archive. For instance distribution if it is one more entry in /dists, and area or pool if it is one more entry in /pool. Have a nice day, -- Charles PS: the bikeshed of the building where I live was repainted last year, and I did not propose a new color :) -- 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/20130510043456.gb23...@falafel.plessy.net
Accepted mathjax 2.1+20121028-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 09:38:36 +0400 Source: mathjax Binary: libjs-mathjax fonts-mathjax fonts-mathjax-extras Architecture: source all Version: 2.1+20121028-2 Distribution: unstable Urgency: low Maintainer: Dmitry Shachnev mity...@gmail.com Changed-By: Dmitry Shachnev mity...@gmail.com Description: fonts-mathjax - JavaScript display engine for LaTeX and MathML (fonts) fonts-mathjax-extras - JavaScript display engine for LaTeX and MathML (extra fonts) libjs-mathjax - JavaScript display engine for LaTeX and MathML Changes: mathjax (2.1+20121028-2) unstable; urgency=low . * Revert the Vcs-Git change, lintian doesn't like that. * Mark fonts packages as Multi-Arch: foreign, fixes a lintian warning. * Upload to unstable. Checksums-Sha1: a817ece435b6d65e7c5e0becf24eeb7a433c8ab1 2107 mathjax_2.1+20121028-2.dsc 226340c13c99a226d60e23075a602e57afd0b360 8834324 mathjax_2.1+20121028.orig.tar.gz a457baad6de4340ad32f624625a31edae7ca6682 9488 mathjax_2.1+20121028-2.debian.tar.gz 242a04b0a7274732f9efe7851c6133795698b5f4 888954 libjs-mathjax_2.1+20121028-2_all.deb 9cf7f069e529a897e6f9be42e5e3975eba8a3503 957964 fonts-mathjax_2.1+20121028-2_all.deb b197eef20b1a43784e2cec98773adc1532cd0db3 4958938 fonts-mathjax-extras_2.1+20121028-2_all.deb Checksums-Sha256: 58ba232ec30ee80cd96192ef97b44b4a8db0c4c5bc5295a7b1324214d3862c29 2107 mathjax_2.1+20121028-2.dsc ce6913dd1954b6d4ba99a349176b7d748996d78b6ba342e6bc8c4913d4e38995 8834324 mathjax_2.1+20121028.orig.tar.gz 6fe3a8020c7bc5f5c009d171d604dc77db9cac4b78338bcadb1a354297069304 9488 mathjax_2.1+20121028-2.debian.tar.gz 8cf89bc5532cd767593fb396ac000691298a4a682723654f6df6a05acd9420d2 888954 libjs-mathjax_2.1+20121028-2_all.deb dc7f6ca3e34a722c0e75984b01499cd952604b71c26102ee6317b7e11d580d6b 957964 fonts-mathjax_2.1+20121028-2_all.deb 769eeed87251377c30eddfc86a3c88282f187b2755cf6cfd5afa6555dd4b822e 4958938 fonts-mathjax-extras_2.1+20121028-2_all.deb Files: c9e8cd18a351197fd9bf0a39f17e17cb 2107 web optional mathjax_2.1+20121028-2.dsc 25a5b8c6f119145adb90ddf25cb7e724 8834324 web optional mathjax_2.1+20121028.orig.tar.gz 7fb5ebad45860ec4fccc1db4ab7cb722 9488 web optional mathjax_2.1+20121028-2.debian.tar.gz f818a9e8b2737b409ca37a4dee60b23f 888954 web optional libjs-mathjax_2.1+20121028-2_all.deb 9d3915f257939f99a65352b57323bc24 957964 fonts optional fonts-mathjax_2.1+20121028-2_all.deb 1ebddde6d905a03221858f55120194fa 4958938 fonts optional fonts-mathjax-extras_2.1+20121028-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRizp6AAoJEGAmk20vHIrgRpUP/3pY2t7cp6OXNJRbyKKtSl+Y l+dxvGmvHondptehZWNYqdhotmIB4Cr0Q+gkcmdtBXduvd8LMM7r8LE+Fw1zKZxN lli+sI6+IszcfGMW00HQnRL0YRt4mrdLdCsKmKQXBwvoYNzcoiq+ISfz+nj9pRH3 d309w0G/Rfv6/6dHzhEScSfrzCDTu6+fdyOxSpBB9WYYv6yVWyd/uVvaP8Xlcka9 727oNZxMQImF4JKP1kH6q31LLj16cDvdDR9DNhTEJczYu+BphHFLUi95gbRgyf8i F4q5SD8oGBy/k+YFjK/Y4Uu1Lj2bLnDnakUYxhP9+n6VXG9sBVHjrZ1xUfO8Ca+f vWRND2F3pZVvxuuajsgQDmOlthx049zQHfjrBYu1/jA1j5M04GSuWP7DSA1bx5Fk +utG2BxqAF/rRZQpvtl4CPw/vDI3BjDyX8kqePTaeDZmOGcDbKeCFGqvEn0D0iLu zGzVA+LK4j5F+O6Bgg5EJBEXkg7aeND2Q6OFEGfI85iV5Yu8TfbcVal845RpbFjK UN7emL7bG1PDXzcIE59ovtD+pZWVQZtYaUChUURrBn7JjouqiRLzexMjXR8khSOn T1ggqotRAHjw3Uhfp56z8MDhRTBLi2dDfOo1q/ejME//TmVXSDTpDDM3YyMAHVDv pJAgUE+ikWUKRRi0XJoP =ss9B -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/e1uakpv-pe...@franck.debian.org
Accepted pcre-ocaml 7.0.2-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 09 May 2013 08:19:33 +0200 Source: pcre-ocaml Binary: libpcre-ocaml libpcre-ocaml-dev Architecture: source amd64 Version: 7.0.2-2 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Stéphane Glondu glo...@debian.org Description: libpcre-ocaml - OCaml bindings for PCRE (runtime) libpcre-ocaml-dev - OCaml bindings for PCRE (Perl Compatible Regular Expression) Changes: pcre-ocaml (7.0.2-2) unstable; urgency=low . * Remove META from -dev (it is installed by -ocaml) Checksums-Sha1: 87412f138ce70a56f1b9cb95c479a937beb12765 2109 pcre-ocaml_7.0.2-2.dsc 2cfb018c54290ed8ad100511d7e94ef4a3c9 6448 pcre-ocaml_7.0.2-2.debian.tar.gz 788a7b6f57d6f0c8a34f40018b822f43aca31cd1 112644 libpcre-ocaml_7.0.2-2_amd64.deb 7e4b408ca303b12eb38d6349aeb7a7d25b283e2e 77574 libpcre-ocaml-dev_7.0.2-2_amd64.deb Checksums-Sha256: e5234450395bab506d1121004dfef099601ee8b556a8d5b1ea8c05681ed70b85 2109 pcre-ocaml_7.0.2-2.dsc d7e0a2f36bde08ddf9d4cc83287c24628894839210793b32fb7a91494f0dee9d 6448 pcre-ocaml_7.0.2-2.debian.tar.gz a0436c17f1d5716bdfc99a36b49f2b8459a02bbb90a7d246b94a87cf5fe96303 112644 libpcre-ocaml_7.0.2-2_amd64.deb 2161be6709793692d1cd808964204f3cdeeeb235d958becef12f14ebc02f3073 77574 libpcre-ocaml-dev_7.0.2-2_amd64.deb Files: 24aa10cbdbd59b4de1b146e9c568b8ed 2109 ocaml optional pcre-ocaml_7.0.2-2.dsc e6eb6cbbe73c8470d8b7023e5e515ee0 6448 ocaml optional pcre-ocaml_7.0.2-2.debian.tar.gz 481b0c20162fb31362644af03460239c 112644 ocaml optional libpcre-ocaml_7.0.2-2_amd64.deb bee7e59531b89a466c9003d73bfa1307 77574 ocaml optional libpcre-ocaml-dev_7.0.2-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRi0ESAAoJEHhT2k1JiBrTDz8P/RPJpkZeuiw1Uhl5KrAJiczH BWhVO6RxmXloJ2SC32C7143VMIB6MOc3BllcrRYzamklXbdxXPQTmt3JiZwSgp6M ll9SSX7Y5vRfe720ZLMZsiBqG52jeYxX6H8jXafbTyv1bKr9kDMrzGyCgzMGfvEz Xjm4am7R9z/EpvbhXMh17c5mYrozEQQ7cysXvRWmRbyNAz9y2RDcM8dWXRmCPQHP KeCUW0yRdVHTnJzMFrQ1qW8fb3mtPIf0+R5/NwPbkdtwe3/9+FRIGygwxQ9zCE3m YV1e27gmUDLiX0mzpmdxM7evklhoYetJhhWXq6tX0otfic813xdePWiBzY37thGY tGKmFqJS43BWOjLP2bdMlqtIF4Wwy7mvHOzYCl/iOB7PdQoNaEkZmS+arovMyFzB RWmlbkujDI83A9SethpXAwO8mxh9OElVrsSObIQdVkBqSuB2t1C7HhQyoxqrBzwM gD663YZ+oOXrZ7+xbng5IrWyM+RLnPbDjKsIsfgcYW8qQPqirF56str5fDtNuL7l 4jedpqCZUc/+iUx+TaUJc2iwZqq7qrAP7dDXSt6sqcFhC9RR+wRnaSjQgNhU3ZmC 8q0gp4VniPT7UpTJ45aBKhFrCr60V7KNy1yrVf4nkz3z6hQD0fOxp0R175ifTtVG GT9ILRz3Xen7y+XNCHWr =dNbR -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/e1uakq2-uj...@franck.debian.org
Accepted fonts-tlwg 1:0.5.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 12:52:19 +0700 Source: fonts-tlwg Binary: fonts-tlwg-kinnari fonts-tlwg-garuda fonts-tlwg-norasi fonts-tlwg-loma fonts-tlwg-mono fonts-tlwg-typewriter fonts-tlwg-typist fonts-tlwg-typo fonts-tlwg-umpush fonts-tlwg-sawasdee fonts-tlwg-purisa fonts-tlwg-waree fonts-thai-tlwg fonts-thai-tlwg-udeb latex-fonts-thai-tlwg ttf-thai-tlwg Architecture: source all Version: 1:0.5.1-2 Distribution: unstable Urgency: low Maintainer: Theppitak Karoonboonyanan t...@debian.org Changed-By: Theppitak Karoonboonyanan t...@debian.org Description: fonts-thai-tlwg - Thai fonts maintained by TLWG (meta package) fonts-thai-tlwg-udeb - Thai fonts in TrueType format for D-I use (udeb) fonts-tlwg-garuda - Thai Garuda font fonts-tlwg-kinnari - Thai Kinnari font fonts-tlwg-loma - Thai Loma font fonts-tlwg-mono - Thai TlwgMono font fonts-tlwg-norasi - Thai Norasi font fonts-tlwg-purisa - Thai Purisa font fonts-tlwg-sawasdee - Thai Sawasdee font fonts-tlwg-typewriter - Thai TlwgTypewriter font fonts-tlwg-typist - Thai TlwgTypist font fonts-tlwg-typo - Thai TlwgTypo font fonts-tlwg-umpush - Thai Umpush font fonts-tlwg-waree - Thai Waree font latex-fonts-thai-tlwg - Thai fonts for LaTeX from TLWG ttf-thai-tlwg - transitional dummy package Changes: fonts-tlwg (1:0.5.1-2) unstable; urgency=low . * Declare Multi-Arch: foreign for all binary debs. * Upload to unstable. Checksums-Sha1: 9d0f8bef3b7169fd90e7ff24598068b5b868a3f7 2880 fonts-tlwg_0.5.1-2.dsc ca1053f8349b09e607542122c0fcd2257b57 14929 fonts-tlwg_0.5.1-2.debian.tar.gz 8066e91978d71b1d788a522f3dcdacafea70ac69 290960 fonts-tlwg-kinnari_0.5.1-2_all.deb d811d2f488b8f04c6edc6cb039d02887252eedbc 181960 fonts-tlwg-garuda_0.5.1-2_all.deb da1fc71dffa1271e62a8f6b33014b4ca49b5e6c3 327330 fonts-tlwg-norasi_0.5.1-2_all.deb 6912cad9be7f1d09200397d11e2e0d034417f45f 181838 fonts-tlwg-loma_0.5.1-2_all.deb e1fe7cfdcbf14f3220a9896943f7c04ff98f180f 194952 fonts-tlwg-mono_0.5.1-2_all.deb e34215d49d2a0f488684c967c92e1dcf32b0fc07 196052 fonts-tlwg-typewriter_0.5.1-2_all.deb 97898bbfb5265ab1551fc37a924eeae4103dd085 196214 fonts-tlwg-typist_0.5.1-2_all.deb 6523536b3d0853c714fa8218124ef4b9d25e 195982 fonts-tlwg-typo_0.5.1-2_all.deb 1509645d407bb778c86cb90f19fed65445f7e01e 240408 fonts-tlwg-umpush_0.5.1-2_all.deb eea437b8f153f47657ecc49d3091aec6bd487be7 180158 fonts-tlwg-sawasdee_0.5.1-2_all.deb c24a37d7d4d4716970fa517ed54ce001b87fddf1 328024 fonts-tlwg-purisa_0.5.1-2_all.deb df2048a64ca5a72d18f69c5028a00c690071da7f 187450 fonts-tlwg-waree_0.5.1-2_all.deb c53591b1aa956d2665bc32fc0b7c4c169282300c 40092 fonts-thai-tlwg_0.5.1-2_all.deb 738d69d77bf85342e34269af656f1d6be15a6147 110086 fonts-thai-tlwg-udeb_0.5.1-2_all.udeb 324fcdcbe3f0a291b41f0439686b498d0766d70f 3217238 latex-fonts-thai-tlwg_0.5.1-2_all.deb 50703287a55a84f54a7662670dfd10f192be6ba9 36906 ttf-thai-tlwg_0.5.1-2_all.deb Checksums-Sha256: 88d2420862e96116b6b19cefd62053d66dd4503a7f44578df3169cfce60f367a 2880 fonts-tlwg_0.5.1-2.dsc f522459db7c7d64e221884a3b657ba78d55d008a778c6aecfe57419f92f09275 14929 fonts-tlwg_0.5.1-2.debian.tar.gz e9015d6f2907513302fa5bde482dfb659c9ae04a8a49fe8d1d887ed91ea16ddd 290960 fonts-tlwg-kinnari_0.5.1-2_all.deb 31fc82b23ce6b638040e65a595ab58d0c25ac9f82c010b82f8e43401e06729c7 181960 fonts-tlwg-garuda_0.5.1-2_all.deb b30b922de6f6b7ac4ec14b6281cd4c4b4cfa03ce65aa6f5cb06cd0e738f1b157 327330 fonts-tlwg-norasi_0.5.1-2_all.deb 01de666f6359d1c1ccd4666db9c620179868c14a505e3b60f39356c84bcdd41e 181838 fonts-tlwg-loma_0.5.1-2_all.deb 440e5539e3985b39f44430bd6f8df6dea541dbf43c8c6e354bb59c2ad7bff9d8 194952 fonts-tlwg-mono_0.5.1-2_all.deb 0b37e29352784a32695e33bab5ecb4e6b902f7c6eb134b55a12b7a79d04227f2 196052 fonts-tlwg-typewriter_0.5.1-2_all.deb 6abe43ed0916d894951c663b43ee4cd939b299b26614b718161d3a77c8aa25b2 196214 fonts-tlwg-typist_0.5.1-2_all.deb 7cce71fce49a2bb6f7565a5904a0cf3c2b52d1f461dd1930aba040182e8619b6 195982 fonts-tlwg-typo_0.5.1-2_all.deb 448e48b35c9848264c3112ab146cb08cde9652a0f001ad8c8679086624241c8d 240408 fonts-tlwg-umpush_0.5.1-2_all.deb 8a819dd6d930545f1f7d2abd5e0b67c18537a3062fdb7f498cb88b79438631ad 180158 fonts-tlwg-sawasdee_0.5.1-2_all.deb ba1f02e58ed73bc62e9cec34d41416cc44a0eec8297b7d0392f2f4a6d39780f1 328024 fonts-tlwg-purisa_0.5.1-2_all.deb fd291e222b31048cb14799b8539716fe1d681f1aa6ccb870d7c0a29338fe01c4 187450 fonts-tlwg-waree_0.5.1-2_all.deb d403e7ccc6725a2ebc1ed8fe2c610476796456514088730a4de4f0c0b06bf256 40092 fonts-thai-tlwg_0.5.1-2_all.deb 910397492981a047c295b3b81aa0e1b43582d54bf6a7942a777d012cd2bab728 110086 fonts-thai-tlwg-udeb_0.5.1-2_all.udeb bc1d089019ddc4a5f759dc74465dd323fc743688700674b250d429df90109d9b 3217238 latex-fonts-thai-tlwg_0.5.1-2_all.deb eb60e473a20c59b6f12fb6cb07ed39cbfc94add9d61e4b10498b4ad185c99d72 36906 ttf-thai-tlwg_0.5.1-2_all.deb Files: 4c7f41d295d068afae46f09bd4e9c170 2880 fonts optional
Accepted lightproof 1.5+git20121204-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 19 Apr 2013 00:51:39 +0200 Source: lightproof Binary: libreoffice-lightproof-en libreoffice-lightproof-hu libreoffice-lightproof-ru-ru Architecture: source all Version: 1.5+git20121204-3 Distribution: unstable Urgency: low Maintainer: Debian LibreOffice Maintainers debian-openoff...@lists.debian.org Changed-By: Rene Engelhard r...@debian.org Description: libreoffice-lightproof-en - Lightproof grammar checker for LibreOffice (English) libreoffice-lightproof-hu - Lightproof grammar checker for LibreOffice (Hungarian) libreoffice-lightproof-ru-ru - Lightproof grammar checker for LibreOffice (Russian) Changes: lightproof (1.5+git20121204-3) unstable; urgency=low . * upload to unstable Checksums-Sha1: dbe10a65937dd010c53dc0a0306f0de75292e03d 2048 lightproof_1.5+git20121204-3.dsc 4cb54fb1bae491896581f0e89aadea774ec976a4 2977 lightproof_1.5+git20121204-3.debian.tar.gz d1631d9b99c91e966b5f9863f3ae1684e5854740 28728 libreoffice-lightproof-hu_1.4.4+1.5+git20121204-3_all.deb 2087460fa58792e406f5ed9d9fb144090875f831 19178 libreoffice-lightproof-en_0.4.3+1.5+git20121204-3_all.deb c69c50bb5b4858c16bccf1f183c0746592d7731f 15642 libreoffice-lightproof-ru-ru_0.3.2+1.5+git20121204-3_all.deb Checksums-Sha256: 9060a628b829b809d2e1f83fec335fb121873132507dac6bb6be1022bafc6d06 2048 lightproof_1.5+git20121204-3.dsc c5f7845564bfe318d7e0389bdce1d0e5517dbd56dada0cb9539a1bfa3f54db85 2977 lightproof_1.5+git20121204-3.debian.tar.gz ad88fdb58ad610f75a6f0c90f5f00c56830130a8b779ee64f94146da74e8384c 28728 libreoffice-lightproof-hu_1.4.4+1.5+git20121204-3_all.deb f23dfbd56a88df92c9295abd5f52bb7822655f9fa06d7a003752039daa8fa571 19178 libreoffice-lightproof-en_0.4.3+1.5+git20121204-3_all.deb 0dd5edb6d31c3993f64e093af9aedafd93d4a57e1a008b5b3b26c99a51f91d76 15642 libreoffice-lightproof-ru-ru_0.3.2+1.5+git20121204-3_all.deb Files: 5a48b4c0c2280dc739dd3510f42a251f 2048 text optional lightproof_1.5+git20121204-3.dsc c1be4bd91b0a37c91edc2e298818f15d 2977 text optional lightproof_1.5+git20121204-3.debian.tar.gz 379dfcbe117586103daf78c79d2defa6 28728 text optional libreoffice-lightproof-hu_1.4.4+1.5+git20121204-3_all.deb 0b600a8fe7348ee73490c368048680df 19178 text optional libreoffice-lightproof-en_0.4.3+1.5+git20121204-3_all.deb b48fcacfa1f9f2bef7584fa88828dd05 15642 text optional libreoffice-lightproof-ru-ru_0.3.2+1.5+git20121204-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRf/hlAAoJEAqgRXHQPj5wBAAQAMRsaPSvXK1AcrT6AY726AoZ btKV/VV6lvABb3hzsb+jnGrnD38Q7T5PqnvazNGDZilDH+2ryMsWMohdx+vIteY6 tBLq1z0m49VqiNlhykHW2VEG+RcPlbqiIVGF6xKYKVsr8SHAdRzUCWmdc3lGeWqk QfJFATL3WO9NMsw2iUkuYLuoSfZ/Ejaa1V6jegQz0lHwQPV2YrAgbsubfnyA5Ry1 FtNPL5Z6Ef+YMykm3/MGWLKMxEfd4VbQrnVYktD6mvSMWkcq8joil6ysUrrFmcIN A29KcorgGyPvylC8kYq2ghFYUEytNo0oCDrJ8PlUmHHYtoCKsAQrwzUREXaw9xMy MeWqmckMl48b5qV/8m73O3FQQTPFUHqzExACXLVBowwUKZt0xLa1BL24CSbuMLYb KOfTphCXOV2AWKtp5xfmb2Yw+JyRrmdeL9N+IRx2Tv0hm03kILSMKrYelZD22+IV AGXoQ3VkMNvEL5pHi+2ebYkgFQKlzH9H8ehJaau2+jOCB4V3O5wHTqlQRL3F7S9Y SVd3wxgYTtSx4GiDp1pP0r+tsmTDhfYTUp7pSJDfoXNNYq1wvgSalKhkx1Xh6x/F CnqQ1Zqr/8YHB13lmGXq0KTVvSM2UYIVxkPaqMYAuG67u+9jvFA3ONZSyGJom3Sx J0sag6Emv51WiojCf59J =c5Zk -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/e1ualvn-0006zo...@franck.debian.org
Accepted sampleicc 1.6.4-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 00:31:47 +0200 Source: sampleicc Binary: libsampleicc-dev libsampleicc2 libicc-utils-dev libicc-utils2 sampleicc-tools Architecture: source amd64 Version: 1.6.4-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Rene Engelhard r...@debian.org Description: libicc-utils-dev - ICC profiles i/o and manipulating library and CMM -- utility libr libicc-utils2 - ICC profiles i/o and manipulating library and CMM -- utility libr libsampleicc-dev - ICC profiles i/o and manipulating library and CMM -- development libsampleicc2 - ICC profiles i/o and manipulating library and CMM sampleicc-tools - ICC profiles i/o and manipulating library and CMM -- tools Changes: sampleicc (1.6.4-2) unstable; urgency=low . * orphan package; set maintainer to Debian QA Group Checksums-Sha1: cc50e4c6bb11406274eb7aa9f9bcabd4731f45f2 1976 sampleicc_1.6.4-2.dsc cbc11cefabe684ce04730599dc41ea25a3f1e56a 3166 sampleicc_1.6.4-2.debian.tar.gz 8e4b4afaa28afc37ca421f54c723c69fe7ae3a0c 300668 libsampleicc-dev_1.6.4-2_amd64.deb a5fa300a653e0b34f3f021888dd271a69045a1e8 201964 libsampleicc2_1.6.4-2_amd64.deb f4f43724849e0ce0eccf7468e495b5db297c 29088 libicc-utils-dev_1.6.4-2_amd64.deb 31fd1e1a7830b6e41b8ee0ed67207644b1aef1a0 23528 libicc-utils2_1.6.4-2_amd64.deb d4d26e04d925744636b98cfca6bf5a64fc546a4b 102782 sampleicc-tools_1.6.4-2_amd64.deb Checksums-Sha256: 6e5e80edd62826613d4e0483c8a3740a28726fae84c2a6c557d6c27cde915d3e 1976 sampleicc_1.6.4-2.dsc 18cc06b7433ac021f7cd3866e0531ef844f17860fbd11810e52cb0db6ea7a35f 3166 sampleicc_1.6.4-2.debian.tar.gz 87bee09e9b150da01acca0b7aa2e4f3988025f866236af316d644064d46d59a2 300668 libsampleicc-dev_1.6.4-2_amd64.deb 310bb488f4ed0560e7d01ec2e4d16e37d29e4f5386f068c5c4fb8519257d171f 201964 libsampleicc2_1.6.4-2_amd64.deb 8c9a69206bc227a23b0bc8e282b82c3237d2cb530428f02540a25a31f43ef24c 29088 libicc-utils-dev_1.6.4-2_amd64.deb 4d520429a31d96bf9bb2c766a166dcea05be4679b4747a6ebc60f9d072a83971 23528 libicc-utils2_1.6.4-2_amd64.deb cb235e4ea6c3eb9ae13989875dd3d40585265324b681c701324650e437a484a2 102782 sampleicc-tools_1.6.4-2_amd64.deb Files: 8242991898ca82a31559ee657bbdd092 1976 libs optional sampleicc_1.6.4-2.dsc c6efe8a9cd2f3cf061d0683c23461f3e 3166 libs optional sampleicc_1.6.4-2.debian.tar.gz 28554f9d3fe75974499c6d6445109c2c 300668 libdevel optional libsampleicc-dev_1.6.4-2_amd64.deb 25bec8da55fa363b3b3b9856161b97c3 201964 libs optional libsampleicc2_1.6.4-2_amd64.deb 54005e9b9e199547981d1030b6eb0937 29088 libdevel optional libicc-utils-dev_1.6.4-2_amd64.deb 948865f4cd5f0606d0f073a64bc0ee05 23528 libs optional libicc-utils2_1.6.4-2_amd64.deb 3c927d5fa43229f42c156625c0ac02f3 102782 utils optional sampleicc-tools_1.6.4-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRi05oAAoJEAqgRXHQPj5wrAgP/1GA7MuXoAMJLkXQS/nnutBG RYczgguc8C6pgnVnzJ0vnN5V3am6Pg+aVesGGZbMaI33WFXmLpoXFYj5Wq4wpnJU NzNxVm6fhKJydBpPNsVXNjWBywzkDc+9wnUfv8HQnrOEeiSs4yii2cNjOMNfgAYF pYT5LgbSVq4BfW8Ax/Dv6OVClstO1YTWNKZ4mTOW534YTbq79e24VR3ePbLsPYUq qji9v3PGfzUCGslfxm5KxxhcVHdw9Sqkd3JYufGRu68yGaCY0EajPzL8GcK8UyEc UECLFemT9G47sp+WUdr2s/v942LmGXWXYQ/3dldW3xQv88sfY1rfOoyz0L1VyQeZ MDDJSV5vbZboPkX80d2NitnFAEtoNiscbfmX/LXzprkA3pOW84vMNmI7MX432OIj mTPhnCzvHtncg2rcqav/oEI+meVcwIkQdQXPJwQdfNTkHnbgKS4fxIA+AkOYaAS2 jXRHznpuamb76WVi3IkTgmw2m5dWypY0xW3ZA8ayadkVnm5xBPyscDydSXiW5Kvg tw2g2o+fpFGQblgiDBfaHv3LmnWq/VFU/0Lois6P/4iwLQyCeAm4LrdBxMooeaHK llmIpG92h8CyUxVTjiLRbebuFGfyA848CoUbHrG3Tah6yovSoQ6/iYyyRRI+6HaX 07+jD+MVPjhX+9StYgKJ =3K6u -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/e1ualvh-0007dv...@franck.debian.org
Accepted alsa-lib 1.0.27-3 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 09:59:00 +0200 Source: alsa-lib Binary: libasound2 libasound2-dev libasound2-dbg libasound2-udeb libasound2-doc Architecture: source amd64 all Version: 1.0.27-3 Distribution: unstable Urgency: low Maintainer: Debian ALSA Maintainers pkg-alsa-de...@lists.alioth.debian.org Changed-By: Jordi Mallach jo...@debian.org Description: libasound2 - shared library for ALSA applications libasound2-dbg - debugging symbols for libasound2 libasound2-dev - shared library for ALSA applications -- development files libasound2-doc - documentation for user-space ALSA application programming libasound2-udeb - shared library for ALSA applications (udeb) (udeb) Changes: alsa-lib (1.0.27-3) unstable; urgency=low . * Brown paper bag: use override_dh_auto_build-indep and dh_auto_install-indep to handle doxygen docs, to correctly avoid building docs on binary-arch-only builds. Thanks to Adam Conrad for the suggestion. * Pass --disable-static to configure. Checksums-Sha1: bbf25c65e2b9e459f3ef0b54e7e2372d6348d7c9 1626 alsa-lib_1.0.27-3.dsc e0e33e043fc87f3dfc1a2ff09cbe8dd417adbf8e 49738 alsa-lib_1.0.27-3.debian.tar.gz d95205fb438bfbbfb89e65c59e7bc70e4cf8b964 476248 libasound2_1.0.27-3_amd64.deb 8582ffd821d3465cdf701754af630ebb7ad66102 111680 libasound2-dev_1.0.27-3_amd64.deb c266a5f48b98831daf3e59a03a2276f87c2e4c76 1225050 libasound2-dbg_1.0.27-3_amd64.deb 3d8e580c46899e174a00bd43d4623b9514a7d7c0 325584 libasound2-udeb_1.0.27-3_amd64.udeb 5507b169c19aa5b4768b4adb3de36df2b96cfed9 1465988 libasound2-doc_1.0.27-3_all.deb Checksums-Sha256: 42bdfb7e4c226b65b1f06a67949b8faf3ada1b599461307ba8c1105132028150 1626 alsa-lib_1.0.27-3.dsc 3f81accfed48e6afc47c757af75d4519b45d2b10a9bee9f2744aa86631f1834f 49738 alsa-lib_1.0.27-3.debian.tar.gz 4d1ff01cb920446b2da2a011972012a45bd88227c6bf61baf95535e986e035ae 476248 libasound2_1.0.27-3_amd64.deb 2c346428ec4413e48341b0227c53e386631c547978f2e69ea56c1ea11210895e 111680 libasound2-dev_1.0.27-3_amd64.deb 77e36f4e7d4f22a34b6b61bea60237a734904c1ef6bb4b92e17669ca094a6730 1225050 libasound2-dbg_1.0.27-3_amd64.deb 0113f7f94ebe67a31b4e5a56fcb81b14e523b03ff69eb0d25cb97d905b6eb4c9 325584 libasound2-udeb_1.0.27-3_amd64.udeb 458204ab0c2106b5d77f5510acb1eca545fd78e0e43470b06d0d30efd65a83ad 1465988 libasound2-doc_1.0.27-3_all.deb Files: 2d91e253a83d23f8be378cb81f98953d 1626 libs optional alsa-lib_1.0.27-3.dsc 63607b5ba629199b0e6368260b14a0dd 49738 libs optional alsa-lib_1.0.27-3.debian.tar.gz 26b759b11f383f765a307946d6f51593 476248 libs optional libasound2_1.0.27-3_amd64.deb be86f75134db4fd776bdf1c4f7b9482e 111680 libdevel optional libasound2-dev_1.0.27-3_amd64.deb 8dd80b4183a8b1cbd48810f6311fb9db 1225050 debug extra libasound2-dbg_1.0.27-3_amd64.deb 8d0db7d8a89160af891b49258582cc74 325584 debian-installer optional libasound2-udeb_1.0.27-3_amd64.udeb f37eac9d4e1fd5b3cf6b7075c1fcc4f4 1465988 doc optional libasound2-doc_1.0.27-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGLW40ACgkQJYSUupF6Il6cPACgtrCZx2ABFx//ledQvMNtZgwH necAoOUxZTXjKK6cxlzWNMcUF4lPewBp =f5hl -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/e1uanrw-0007pc...@franck.debian.org
Accepted blobby 1.0~rc3-2 (source amd64 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 May 2013 21:49:41 +0200 Source: blobby Binary: blobby blobby-server blobby-data Architecture: source amd64 all Version: 1.0~rc3-2 Distribution: unstable Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Felix Geyer fge...@debian.org Description: blobby - Volleyball game with blobs blobby-data - Volleyball game with blobs (data files) blobby-server - Volleyball game with blobs (server) Changes: blobby (1.0~rc3-2) unstable; urgency=low . * Upload to unstable. * Bump Standards-Version to 3.9.4, no changes needed. Checksums-Sha1: 119b17a2304857eaa720167cc4fb32ba1e2e7522 2144 blobby_1.0~rc3-2.dsc ea335a365dad1df15d46c35256489644e1588051 7092 blobby_1.0~rc3-2.debian.tar.gz 0de5783000fb9de99e72a67d4a20225030ae0418 356182 blobby_1.0~rc3-2_amd64.deb 4d093549a95dc9d79787c4c64149936dbc0ed56b 172408 blobby-server_1.0~rc3-2_amd64.deb f948fd1a4069ccc5966cf64231cf8f1aec5640c9 1031882 blobby-data_1.0~rc3-2_all.deb Checksums-Sha256: 70216bcc082b13a575e1c0fd8ed87dc4c4b793b2ba3ee726625b7dd76b58735f 2144 blobby_1.0~rc3-2.dsc 85225143260f949f1ad55b664ad247f4eae6041c3bdd608f7c880059acb8ba53 7092 blobby_1.0~rc3-2.debian.tar.gz 5b8306a43f07059e7732889e3e81b47aa5c6f6ee1ee72349066e5cf2375e32c4 356182 blobby_1.0~rc3-2_amd64.deb 53aee8ded6543da023b276431020e51da052b03625aee878cdefe90860b7adbb 172408 blobby-server_1.0~rc3-2_amd64.deb a2219a1cc9aa44f3f807dbc0ef9c54dd2df692d61f24bb926a20c44fac45f98f 1031882 blobby-data_1.0~rc3-2_all.deb Files: 460a0b5f74e34d2a7736c7618c800510 2144 games optional blobby_1.0~rc3-2.dsc 01039dd46d0561e9260cd885bac843b5 7092 games optional blobby_1.0~rc3-2.debian.tar.gz b356f2ee59fa1fd8ff23fbdcc63e07cd 356182 games optional blobby_1.0~rc3-2_amd64.deb 126d6171d79dab9a29361dd518206390 172408 games optional blobby-server_1.0~rc3-2_amd64.deb 06c7ef46c0bd66e7cb4181117c262b7c 1031882 games optional blobby-data_1.0~rc3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRi1muAAoJEP4ixv2DE11F3UoP/iO9cboty5obn2Yzwf9vUTu4 9CXfE8x2sfTn5S/OzEVjHWEGnPsDBRSTPdRNSDWayKt9fjOFmu9t/ASlFqxmCK5+ dTAqBYuxwHJWnjwPPdWQJf+LAtZkkSkrePcSzi+8FfuIfSYG+z87UD3XQ0Z725Yj KGySyCx3xaVgwPoYtkBe7VORk5mKfKs60u0ahwivSmWqcJy+HLjIkjrCOwHoaF9k +xmBaA9Wx4BozkuC1v17svjCVE8UDwuOVTl89HVi4FgBMO/BvuHci4ynvbDr478W WJiKSEIMEJrNLqk38IT9SBHP70jpZQB8AGWFKc9MN+9UFLpR1r13h3vEyseJ+PKf LKmsQXJ0KmTId81WwR1dXOXi89RgeAcVyUg3SW7U2UHUXJXyk6fkRq+j3MaXMHYo SmeJuwkACfusHFeU1vL499hd/aErwCkiv7eTRJMottrTf9Pbe8LurklI9a2Qyylp 2HljOoIflAOgqsyk7hoLyd0nXX2AdH52AdhLi/3IgxrFQLa52QYH/Wnk5dPrRC64 wbv1NT/CNbT/0nhWkgxqCFvE7SMTRuukdthVoPZ4zsUWiMZJHTq/gkIit/BZUt7u nHq1jmy4sAgdmq72W9+zU3pInHwvZsMvIIthjFi2oFwbsgG5h2FjJxk/G3zCN3Tn NlDOzIQzIue48jA3nYlx =Ghg1 -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/e1uans5-0007rb...@franck.debian.org
Accepted cairosvg 0.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 May 2013 08:22:22 +0200 Source: cairosvg Binary: python-cairosvg python3-cairosvg Architecture: source all Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Changed-By: Michael Fladischer fladischermich...@fladi.at Description: python-cairosvg - SVG to PDF/PS/PNG converter based on Cairo python3-cairosvg - SVG to PDF/PS/PNG converter based on Cairo (Python3 library) Closes: 707425 Changes: cairosvg (0.5-1) unstable; urgency=low . [ Michael Fladischer ] * New upstream release (Closes: #707425). * Bump Standards Version to 3.9.4. * Update year in d/copyright. . [ Jakub Wilk ] * Use canonical URIs for Vcs-* fields. Checksums-Sha1: e12f261a799677f108b2e40deab91e65aeadaaf6 2168 cairosvg_0.5-1.dsc df78987cc664d2ebea0e2df83320d2181f48f649 24790 cairosvg_0.5.orig.tar.gz cfd5c0995da3423e6c992b9fd514603989c16232 4343 cairosvg_0.5-1.debian.tar.gz ad145cb716d18dd24e9f62a5fa19b7533bf26002 25026 python-cairosvg_0.5-1_all.deb fa6b6a369f15f961cbb9ffc8487d418d0404c525 24732 python3-cairosvg_0.5-1_all.deb Checksums-Sha256: 55dd14785199593b2af162aeb7bdce7b7997637d12b242a2516ce6e24edfcbfa 2168 cairosvg_0.5-1.dsc 9aa311fb832c37bf376a4bbcf0b97beddc4527e4fbd918cdd35d42bc3200e170 24790 cairosvg_0.5.orig.tar.gz af146a249523990f6de34fd255bd4751c5d2327476aafca412e0dad57db41613 4343 cairosvg_0.5-1.debian.tar.gz c7c07d2babd571caf15e6b358b142d9a4f4bd40e4524dc324e236c8c941f5242 25026 python-cairosvg_0.5-1_all.deb ac42f685ba8d33730d77bf5ea4e9a5dc4e77cadf65d3b9a20861eac1b211623d 24732 python3-cairosvg_0.5-1_all.deb Files: ee2ea7c640739dd57314570023855733 2168 python optional cairosvg_0.5-1.dsc 6c092cce2b2ade47054aea6657173cbf 24790 python optional cairosvg_0.5.orig.tar.gz 9421d874e75694fc0c05035d3a69a425 4343 python optional cairosvg_0.5-1.debian.tar.gz c1d3c5ce7e4dec74a53528630d10c17d 25026 python optional python-cairosvg_0.5-1_all.deb 98d328f1993575ef6e9e6b0ae5c8 24732 python optional python3-cairosvg_0.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJRi2z6AAoJEJ0LXlse7I8OhjUQAOExhp9dqz5HiHu35tXfAHYG dGV+HFiwZgSSdDkmtFhkJL+fkI0Uf5X27osbgDaPzAsqjbQ+/uGUVPbV5O33BlNe zEmVgBkzCvDAjLDvjgNOB3y3pqlt5+DMJrL2uRQmwMY95iZuAhSrEhYkemym5T6p ytAxMiIQQn4Bq/W/6hM26zO2iQtyimo1s5AhLwaDvoVX14i216RTwVGSggH8dkOn Pil5m45tjfqE4l0J9HN1FckNGWxx95y6+tQHQYQoEfXIxcjqZqaZc5pgDd+AATu2 oC85n3qqzR52VHNtiMFWrSYnmN77WThWWP1/rW1VIoEkLsgLT1PE2HWsU79076pT NtK2AA+c3J34gvRszTFqXrXgxHxayjTFhKJTbI1bP2AP6yHQzBT+EDBsNkxBRT1c yhnJDjLmjeb4yUhAGoPzkDTvU7zs7hjfH+0Y/bH4wR0rttjYm+pISgmIYtbuTJJQ NwtZ7fHAHzrz/lmYlgqXjSWJyWKctboz/MJrZsWgn9kEregs6HlbyUxDNGlR+yWK 496fy+ZbRX4s2hkbaHaPsM12F6cIFuN8jTWdqo/7SPar6valYMoSTOk6YIfMZ0mA ZwDgYpnV8A4AYQ2xLmsI7Cue4oawpyNK3kYlb9yPAq6Zuoampy8Y/c5WX6YwS33n QC1HFGTRo7I04xk2pIln =JaEi -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/e1uans9-0007ry...@franck.debian.org
Accepted colorhug-client 0.2.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 10:36:41 +0200 Source: colorhug-client Binary: colorhug-client Architecture: source amd64 Version: 0.2.0-2 Distribution: experimental Urgency: low Maintainer: Michal Čihař ni...@debian.org Changed-By: Michal Čihař ni...@debian.org Description: colorhug-client - Tools for the Hughski Colorimeter Changes: colorhug-client (0.2.0-2) experimental; urgency=low . * Add missing build dependency on libxml2-utils. Checksums-Sha1: 7030dd6b6480cf9803ae8a822f7d04a98a0fb428 2228 colorhug-client_0.2.0-2.dsc e6ee76a924fec2f395ee2de3de97d3e373eaa76d 2892 colorhug-client_0.2.0-2.debian.tar.gz a858c232f4b2c7d03c8ed0385d5b774edb002bd8 536140 colorhug-client_0.2.0-2_amd64.deb Checksums-Sha256: 410f1ad09f73a4d7c76944620b076d7cfc74a4b46659bcf7136f2103cc4b59f2 2228 colorhug-client_0.2.0-2.dsc 117ae8d87cfb1962fbf3c6d2922d92736a6f3a51ae1c7db2a35814ac82a95b48 2892 colorhug-client_0.2.0-2.debian.tar.gz ff7a4726dc8c844f10ef53f6947741398bf2397e3c53a3b0fb89fd76f1defd77 536140 colorhug-client_0.2.0-2_amd64.deb Files: be9ba45d8624a671eea50a15f5170915 2228 graphics extra colorhug-client_0.2.0-2.dsc 9c6f9a012244634d989f0472cfcf6874 2892 graphics extra colorhug-client_0.2.0-2.debian.tar.gz 2912a2a463dc25e754feb92017afe32b 536140 graphics extra colorhug-client_0.2.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRi2HiAAoJEGo39bHX+xdNLzYP/1lp2dBIG+fbglMCrA/pEOya zF/LevgRnkdBZva4djOm/i13vePU9g74WYgndNReblWhZn+bFptltjiDA/ykXq4T KfSNvBUtboquiIh9itroikHiaDgZPFftD3oD6sY74IFgQa2j8+C4+JhWjjcTINh8 C4MJOqSgaf5kz6UgksSPkSJfHOwTjfehTogk0UQh6hNFPWjVDsfxAlvyz1hxCmSj WgDhTlRxJ643Wrzu1CROzED+QIwXligd89gDGoiYe+k7udcNP7a96UHuWrLzrbxb ErRuQQCWe5oCLNi2qx0ROHnnU96z3Aqph5yK0ZUql0O1N+B2te5oPgIqIn7InvAh ndUqgrG0uC39ZOWUU0o1owQBRD3qU9Fs6viOXt8hSddbIh3TqimwlLt6EWvZtp/3 IkItCb0rMArwDVnj11smgS4v2JAyGMNX7C+dKH6qUjFO9eRUcvKdEUl18xR26naD yqhoWUhGkvc5tBoT9cLZ5Twl/iUPoWg1Gn3KHR4GavdHo0XE+w+FnP6JEOd8rdjp i7d7tUoAHLyyRnbtoFFUdkRf2zgt3bGCqdEFGA0VkbnXNniUoZQwtA67vttgGFCs ixOjc9Qtr0HTtBIBlL+E5FzW7I40tAa3Yl55IMmzvMG5ynxb3rwbg9WOet+KITsg yAWwuq/F05Gp68gQXXs1 =0xK7 -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/e1uansd-0007te...@franck.debian.org
Accepted fonts-sil-padauk 2.80-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 09:24:54 +0200 Source: fonts-sil-padauk Binary: fonts-sil-padauk fonts-sil-padauk-udeb Architecture: source all Version: 2.80-2 Distribution: unstable Urgency: low Maintainer: Debian Fonts Task Force pkg-fonts-de...@lists.alioth.debian.org Changed-By: Christian Perrier bubu...@debian.org Description: fonts-sil-padauk - smart Unicode font for languages in Myanmar fonts-sil-padauk-udeb - Debian-Installer font for the Burmese language (udeb) Closes: 707120 Changes: fonts-sil-padauk (2.80-2) unstable; urgency=low . * Bump standards to 3.9.4 (checked) * Bump debhelper compatibility to 9 * Drop ttf-sil-padauk transitional package * Add Multi-Arch: foreign field * Add Breaks and Replaces to better transition after package renaming * Use xz extreme compression for deb packages * Use git for packaging: adapt Vcs-* fields * Use machine-readable copyright format 1.0 * Use Package-Type in place of XC-Package-Type * Replace libgraphite-2.0.0 by libgraphite2-3 in Suggests Closes: #707120 Checksums-Sha1: 6b838df3b0ae154c7596f117e29a737c536dfdbf 2189 fonts-sil-padauk_2.80-2.dsc 916173febd530016d7873702aa6dfba446daa01d 773796 fonts-sil-padauk_2.80.orig.tar.xz 9361974375e6f7ca9e3774d2774a7dbf2139ca3e 5784 fonts-sil-padauk_2.80-2.debian.tar.gz 6b1e059546004595625438cc3a42a449c0d72546 270016 fonts-sil-padauk_2.80-2_all.deb d2ebd1dbd7fb9e3b28fbf803576361b588b56d1c 92528 fonts-sil-padauk-udeb_2.80-2_all.udeb Checksums-Sha256: 5df78dd5255cb98409574110dafcae3654232df58309306c58f459131c3439ca 2189 fonts-sil-padauk_2.80-2.dsc 7e8d3aa84f27ab8d2037938b1438f06b21ef345484ee6ec32a9cf36bdeafe71d 773796 fonts-sil-padauk_2.80.orig.tar.xz 8acb61edda92fa9a49f795f8e22e842f3e14c354bf1c297e31f6d7116c91e84e 5784 fonts-sil-padauk_2.80-2.debian.tar.gz 2524ecbf2b7468de1d8d8d002e97419152e0d49d7b5402e8411dc18a1bbaaa4a 270016 fonts-sil-padauk_2.80-2_all.deb 5df841db5ee8e1b1e4594fbf7429145582adfe0bbb1a0c3b2a93ec2903035281 92528 fonts-sil-padauk-udeb_2.80-2_all.udeb Files: 437d4eaf05bd3fff185b9058dc63e661 2189 fonts optional fonts-sil-padauk_2.80-2.dsc 27bce6e7453a42de4b9ff938f8bf173d 773796 fonts optional fonts-sil-padauk_2.80.orig.tar.xz a9580e8b14947fd9ec1b06658dae1c45 5784 fonts optional fonts-sil-padauk_2.80-2.debian.tar.gz 0a6b83a925aa45a25baa8f320ee52ecd 270016 fonts optional fonts-sil-padauk_2.80-2_all.deb 3fe84c2ba915dab13b0ff3743c0f163f 92528 debian-installer optional fonts-sil-padauk-udeb_2.80-2_all.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUBUYtRlIcvcCxNbiWoAQJIbQ/+NypZ0KkLMsHxwpJ4uiumDv1nXzIR IXqT6UOKSrmVALBz6lD0gsFDQeTtbQ9Zk3Mw3whkY1Xlbg9XAschHLPlzLk1nkv6 xUTZ1KEIfNCi7FnsCek13G86RkdYEUdyxcBz98zdpEUBOt5sWJccehL5hBt39qmh HNTtJPdA1Rj5lm35gGSxcPHt1yYwKeRz4OeVOMCkTLgWUyPmq4MbrtWd6GAA1aNl H635m1Y2l9dOgTj7NUo0g1xbu2hj4ypZBTbWiXsgkhtuoG2mzdJjSRtHr3jbNeAZ RlqlkAEWzQeEfycfeLGOVMW1oQ1HVL7QSJAqqRN0VCLsziShGGrJqM9IRRRcXdcY WRrZUhujyyddGS7NnWd7JmdyKuYIsJlC1Gkgud+/4v0bZLmT2lxjc0RnLO0YZ0de P62ObNar+p+dnr2TfRYht2g/StYAU7hMI3gnEbhkpckH7VERgW1YIF+L6867IERz J6fO3pgtCw5W2uS9OwHBYETEeNiMdRuVxqiI1dyutclhzSg06vxgALDiF6KS5V5/ N+5A+nvyKga11dfgZaF10GX3sopR3nyOcJII4wYnTrKL+Xzeo8AcKuim5mmXrnEv 0naUQ+ML9n+tfBMBx6QecXJQ0ooMdmKk8ItwESiI7OmiQUqSf9vG6v6KF+Fw/ChG 6Ek9cOXWC6s= =o+u1 -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/e1uansp-0007yu...@franck.debian.org
Accepted fonts-sipa-arundina 0.2.0-6 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 14:49:05 +0700 Source: fonts-sipa-arundina Binary: fonts-sipa-arundina latex-fonts-sipa-arundina ttf-thai-arundina Architecture: source all Version: 0.2.0-6 Distribution: unstable Urgency: low Maintainer: Theppitak Karoonboonyanan t...@debian.org Changed-By: Theppitak Karoonboonyanan t...@debian.org Description: fonts-sipa-arundina - Thai DejaVu-compatible fonts latex-fonts-sipa-arundina - Thai DejaVu-compatible fonts for LaTeX ttf-thai-arundina - transitional dummy package Changes: fonts-sipa-arundina (0.2.0-6) unstable; urgency=low . * Update LaTeX documentation location. - Install texmf doc links under /usr/share/texmf/doc instead of /usr/share/doc/texmf, according to tex-common 4.0 change. - B-Dp on tex-common (= 4.01), for proper misc-Depends generation. * debian/copyright: Update years. * Declare Multi-Arch: foreign for all font packages. * Bump Standards-Version to 3.9.4 (no changes needed) Checksums-Sha1: 0df007526d3bb8b9099e253ec1d38c17d98f8bfa 2230 fonts-sipa-arundina_0.2.0-6.dsc 916d5f394679cf0f7444e595c3818f0efbe5d3fa 6438 fonts-sipa-arundina_0.2.0-6.debian.tar.gz a97b3791c9e46d7a3a2fe4a4cfa1310fa9618527 438268 fonts-sipa-arundina_0.2.0-6_all.deb 6b72a99abee7b98b1b10e3d720674c608cff3bfe 882644 latex-fonts-sipa-arundina_0.2.0-6_all.deb 5ddf2fdc77e40537d89cc034ee2f34076246033d 9812 ttf-thai-arundina_0.2.0-6_all.deb Checksums-Sha256: 12c7ada497bd297ce7f573e39b3d6374bef63f2e04f95ff76b120e2ac35105c6 2230 fonts-sipa-arundina_0.2.0-6.dsc 77fba51fa0096f88db4f576ff8a0eda8a32016c9bcca836e6fa0fafdc22aa354 6438 fonts-sipa-arundina_0.2.0-6.debian.tar.gz 285fa2eee86d905c7ec7d7e2e2d6b4779c4eaacb7ad3ef999609c75276d0b093 438268 fonts-sipa-arundina_0.2.0-6_all.deb 197f25563dd0d185313949769c0716fcebe7f7c210d81dd6435b6a45db10 882644 latex-fonts-sipa-arundina_0.2.0-6_all.deb 7caa3db304f3b6795054fa7f3604463bc5b2d4dd5c34e7c04545ce065e3d1576 9812 ttf-thai-arundina_0.2.0-6_all.deb Files: 6a3e3569ca53dc78edbbdb15cd383dc3 2230 fonts optional fonts-sipa-arundina_0.2.0-6.dsc 6c2b4abc4c006bb4824298deeb84cd37 6438 fonts optional fonts-sipa-arundina_0.2.0-6.debian.tar.gz f91142b02a85b666d2b17cb1b61d0420 438268 fonts optional fonts-sipa-arundina_0.2.0-6_all.deb 61a0fd22d9e052794bd97207cac7107d 882644 fonts optional latex-fonts-sipa-arundina_0.2.0-6_all.deb 8aaffd350a3e05ecbfc4bd66aa6dc7e9 9812 oldlibs extra ttf-thai-arundina_0.2.0-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRi1ZEAAoJEKLrrtG2+QJBR24QAIVrT233NOT5XSViAq41Oky+ XzYViiz2s9lhL4Wh6PcK//EZEH/YFp/VIChP9gVt5slUbJAo/ybUkuMMVULuBsE7 cs8NuRRva35RXPev7GLXDboF7xfNsQnfeF1UmBC68dlLi+tB9G+UqxMNWrMYsnu5 DXOeeiSDYS+vYogVdXNY+gEH/G5Za+MdsN3Nk4WOekU2QPDjQ7G+1T6GlW90BfSb 5OE7lRkp0zWk2b4EAq3XFr61bFvtPPsWldMumtM9yCZUC6Yqm82tK2BC/ciPKUUC h4p+ueitgfVCRCsGKrbOzarQxHG9JVMhsZfG85/WwmYL/+UER97Yihx4aYJkFNHO ZfIczD8O1eQYa3t8+C9bIua2WViOooezZjFSouzsK36bq90Q6VqShXe7A33OqlQi LlsyZIqXPGEkUL5rtqp7P+K1caD+wztlIpq+ZBKz5tJbmauHJjjGjndCeiK35JUY DtaZd356/e//PdI91OWuSOWRFXl8jmipJNZkrVyEaqixU9+Lbje5VdH9rBjFKuVo PZAevs+sYL5XdWnhmNrkND4/3NfPCXip9oIyX+GrcTEG0zuXIxR1h5dTjYTBLX+S TzVKcj3ciWgS1Bipmp4jI2cDYxglnW03iipSpLaFIKDM159Iyjl9eCvX/dMmqCnU iGZ3vuey9ZmY5jSx6/om =L06e -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/e1uansu-0007zo...@franck.debian.org
Accepted gnome-sushi 0.4.1-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 09:43:48 +0100 Source: gnome-sushi Binary: gnome-sushi Architecture: source amd64 Version: 0.4.1-4 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org Changed-By: Simon McVittie s...@debian.org Description: gnome-sushi - sushi is a quick previewer for nautilus Closes: 707394 Changes: gnome-sushi (0.4.1-4) unstable; urgency=low . * Team upload. * Add debian/patches/05-deprecated.patch: do not define G_DISABLE_DEPRECATED, which is incompatible with GStreamer 0.10. (Closes: #707394) Checksums-Sha1: a8a298415f8e49c18045164983f6a6b4d315355c 2441 gnome-sushi_0.4.1-4.dsc c401b686d1504d5c79a41e0dbc7c11367dad6ea5 6624 gnome-sushi_0.4.1-4.debian.tar.gz 8a0cdd9296fe952300793f83664abc88a100256c 59808 gnome-sushi_0.4.1-4_amd64.deb Checksums-Sha256: ac898d582191c2fbb63678caec37e36184b09579ad46b78abcb6e431b477c801 2441 gnome-sushi_0.4.1-4.dsc 8449b68c9e23e2b46726251b6e356a073043915b9cdca35d8f07e51d2b259339 6624 gnome-sushi_0.4.1-4.debian.tar.gz c16db519a4c63e00a596078799c30a5baf45d33fa76c9f94ecc30f103e2757ff 59808 gnome-sushi_0.4.1-4_amd64.deb Files: 511b932a8a4253099934176377ddae38 2441 gnome extra gnome-sushi_0.4.1-4.dsc 8f22812407a30e7904233035cc5dfeae 6624 gnome extra gnome-sushi_0.4.1-4.debian.tar.gz d2746535c0c795d140e09ca0d3d38cac 59808 gnome extra gnome-sushi_0.4.1-4_amd64.deb -BEGIN PGP SIGNATURE- iQIVAwUBUYtlkE3o/ypjx8yQAQjsrg/+PcPUiCMgqUfE1pFolRa9PaQFsxtCJov3 MYnOeI23L26kQp305Tnb+2MrnIiYwADYE6puL2OProGYWMbX06G2rZjLRNyRwocV uaqfXrDvYE8nECaEpmPioZagsZFf63C6mLBI5B+rX1+MuBBuP5/U/8RDM0l7INW2 B4vdAfWJHVc4RaoXn2ig0hGBtLxfflHy0a3HS7GQna+FibB32BHfVDQ2KZcQKlKi CduuHeNeUYlYnPBxOKCf5Tte2cI+Pw8/pb9ZvV8WdtRSH99DWocg3zqVHTFKrdaW UOqkx+vNGlh66pTZOodPz1/oiB1ln0/0SNoQ67A9anNaapsDfQyffgniTlONbYpX MDgJE1cob5Q1hO73wUCJbRuSV3Px58eN1bQn2oIsK5Gy+iIYkbtwNIX98LP7z8cx J8WvtWH5wFVamz7IPeTPWQ3FWOCwtVBUU8tPXX0N0W9A9nc6OkYQn7smLLcEwpjd Onziz+yewt4p5CfqyVE3Y/MqxzTXKbH1MBL3hvBFXkTs0P7dErttaQQdREru2/wS u89qQ5p7SElSnLyFFSBdau4tz7xw/aDhs58I5cjGoKwmWeBBx2fWLL3vTbzG/Kri dkOD8re/JVRO/cx3463j08P09ZN8NQQfPE9sYWYiYQJm5DqCQ2SGxi8BI4ltM8XB sHpf2B5umMU= =vXWg -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/e1uant5-00082x...@franck.debian.org
Accepted ifrit 3.3.4-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 May 2013 16:18:57 +0100 Source: ifrit Binary: ifrit Architecture: source i386 Version: 3.3.4-4 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Colin Watson cjwat...@debian.org Description: ifrit - powerful tool for visualizing 3-dimensional data sets Changes: ifrit (3.3.4-4) unstable; urgency=low . * QA upload. . [ Ilya Barygin ] * Build-depend on libtiff-dev rather than libtiff4-dev. Checksums-Sha1: a17b8339ea75cf3a5cf402c786b8b9e19748855f 1935 ifrit_3.3.4-4.dsc bcb9a6887af539204d21fd24c004dc45777c6b1e 6724 ifrit_3.3.4-4.diff.gz ccac5752828eb3ed04e8b2df33e49d4a5dd3c1aa 2273966 ifrit_3.3.4-4_i386.deb Checksums-Sha256: 9851146b0619b13f475f0275ffe5f29018fd43b93210098aa37e6627de15d63b 1935 ifrit_3.3.4-4.dsc 6ca7e251ee2a188088aa65b271283b9ab49650a78174a347ccc054ccbbd63700 6724 ifrit_3.3.4-4.diff.gz afb44f6b750b6dab98882e9ffd7382155032d12190228cf5a0b509123addb843 2273966 ifrit_3.3.4-4_i386.deb Files: 1b2ee67d57dac55740a92a548ccee845 1935 science optional ifrit_3.3.4-4.dsc 4633a418d82d8aeb5124a8663c67771e 6724 science optional ifrit_3.3.4-4.diff.gz 5f4b85fec6b1de6068e4d30e7ad0861b 2273966 science optional ifrit_3.3.4-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Colin Watson cjwat...@debian.org -- Debian developer iQIVAwUBUYti6Dk1h9l9hlALAQhQCQ/+MRal3LPPqv9puKryU5YV5Lg3HG2jOZWt OMN9e+O65a/Y7BH2KZtGYK+v7nkVIWHnAfv7z3qv0k85ShHe4X9MknONUpn+Xnlw 8f1Sr8aQrarV5MqFN1hx+ECEhHRv9NSEF7Oo+/xkgTBwHD7UsQz9gIHBP8HUidia WfL7wQ34mBwGVGLIgoiZtRosevOXH1V4W2uanc1VyOJ1doXFzjm+YWQ5WurEWqBH Xa7IY/edE6osGGtKZ+dNKBcE6L0IeGs8JgfZu0FvnZqaYWDOw5TO8BxrDCyBtDDA y3NEGf/NejroB0VC6927Eahjcj0C7G4feoNow4Z7wwXGzv4vaKvl3i/jp8kRV3Oj WGpEQ1U1zRkvdomYRH3uIigSQi455eM9HPYRgHGZDWfPvk1l1bRlBxlWpR5aaMRU xi7faWkRIl0eVkhwKyLRdslI0Sx1pyw91fWReeN9jrPB1IYRgKcCxJadrkvq+ivo 1MRSqduMW0xyOZ4P71FvOOiJeZ0CEeY+BQEj0JvVS5/WwVy3RPnY75e4ENuWWMJr 0JnOk0sUNldqCMdDqFu/AoGJ9EBVxt1rm6VBR96pt6d7dGnilLztbzHoJqMHj1cz JGelVvZHPREf90I7kgFsKY4F0DZVBvEpE6gAioS2DHdy5IK6G23Hd/ZUC7Rdjv74 JbO6QYeY57A= =lpAg -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/e1uant9-00083m...@franck.debian.org
Accepted logfs-tools 20121013-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 10:12:40 +0200 Source: logfs-tools Binary: logfs-tools logfs-tools-dbg Architecture: source amd64 Version: 20121013-1 Distribution: unstable Urgency: low Maintainer: Filesystems Group filesystems-de...@lists.alioth.debian.org Changed-By: Luk Claes l...@debian.org Description: logfs-tools - Tools to manage logfs filesystems logfs-tools-dbg - Tools to manage logfs filesystems (debug) Changes: logfs-tools (20121013-1) unstable; urgency=low . * New upstream version. Checksums-Sha1: 7d11b30912d3c4ab7f449e460374e8aac7395194 1838 logfs-tools_20121013-1.dsc db149ff1368cd45c98fc1f1dfaf1897d0facf86b 21978 logfs-tools_20121013.orig.tar.gz af420c0e27d1b3fa238e3dde776b077fb79f0bc5 3243 logfs-tools_20121013-1.debian.tar.gz b8604e50b729aea775bd3b6af4e58f27c8b4e248 14668 logfs-tools_20121013-1_amd64.deb 520bc454924b2b467efdc720ec6c7b525da85760 36948 logfs-tools-dbg_20121013-1_amd64.deb Checksums-Sha256: bb718dea2790f821a7b72c5b858de97d3ecf904f751933921c17d2fc9d494493 1838 logfs-tools_20121013-1.dsc 2d170b728f8dfcf5eafb0bcec9904ab9baf11b942c15dc978a37068658bd05c6 21978 logfs-tools_20121013.orig.tar.gz a00114d8296721090a8b0f21798b92b61c45ecd58d0d6fc39fb2728a17fa7ade 3243 logfs-tools_20121013-1.debian.tar.gz ad626c8a7e90b94c1ad8ace60fc18f988786ff1708a85d6b412956573ef3ae71 14668 logfs-tools_20121013-1_amd64.deb 3d8adaced6eca0794cba8b4137db17f4838f4f684b3a690d6640222f51f6d3a5 36948 logfs-tools-dbg_20121013-1_amd64.deb Files: 60c7e0bbbf66a9d665d39299471ed639 1838 kernel optional logfs-tools_20121013-1.dsc 70013b7649c557c64e0c6dd8a6e0463a 21978 kernel optional logfs-tools_20121013.orig.tar.gz 2ec8cf2826c2d76d4845ceda8766c619 3243 kernel optional logfs-tools_20121013-1.debian.tar.gz 6b4fdfa4539a88441f75d91277bf5cb6 14668 kernel optional logfs-tools_20121013-1_amd64.deb 08a4d0461ee66054b3deea69c11c2868 36948 debug extra logfs-tools-dbg_20121013-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRi1xSAAoJECEnNxubsjBi/AkQAKNB7TR/HOJyL3tn/q3ZJY5+ SjCupaucmpmZgbhOBbM3uO8du5rvkv+U4qvRxltDTtAjNFVhTP9DHeugnFCv1QsV UbWlvV9xc5wun8C5hCPtuwEhsWc2WsCnr+GYkabhDoQAPocCsFPh+dWD+wra8ggJ fNkdTaQ39Xwe/3YyfxBd3Eez6RwE4Daa0dCai/1YStVSgR3VGzvd6dieqqlWJRch /psW3uU+kf9aVReIjSht3Wb+zS+fqZJ8Yzu2Z8gEanP/aowruXOasLOx846zAqaO +P6b45J6zxZqH4CxfkGYEG+rRDZt0StFncEl9Z80yvUJykAhvMMpqtxE25D6p25o W09ZNl0gSgIogC0ugY01vJCvyipk+Nd9fqlx39JyT6XULxSr7w61LiHcwJZrs+Bv rb/1vgu7WxFy6hvlSRA8s2sA8ktV8nNTCrlWfqCGJNo/ON6d0VTuSJAXiH8jHs+J Mq1Fi3pu88CTzcQ44MHxnpnpdjKT1v6G7k0m90UkMYGMfxq2QNGkTO7bPmNzSFhl fPgg72V0AsrQz1TDr4DMpOlKOhprZ5vN28rWlE4KCGA0HYqvnaZ91gMRywXJqNkp U2utxMayQ8OqpPttNillkYYk9cPy8+dYsp+YF80n5tlKg1dRV0fKLCGd1DhzMj1n Of4I8KCirjTfJzvx3ykD =jK3W -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/e1uantf-00084r...@franck.debian.org
Accepted openssh 1:6.2p1-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 09:45:57 +0100 Source: openssh Binary: openssh-client openssh-server ssh ssh-krb5 ssh-askpass-gnome openssh-client-udeb openssh-server-udeb Architecture: source i386 all Version: 1:6.2p1-2 Distribution: unstable Urgency: low Maintainer: Debian OpenSSH Maintainers debian-...@lists.debian.org Changed-By: Colin Watson cjwat...@debian.org Description: openssh-client - secure shell (SSH) client, for secure access to remote machines openssh-client-udeb - secure shell client for the Debian installer (udeb) openssh-server - secure shell (SSH) server, for secure access from remote machines openssh-server-udeb - secure shell server for the Debian installer (udeb) ssh- secure shell client and server (metapackage) ssh-askpass-gnome - interactive X program to prompt users for a passphrase for ssh-ad ssh-krb5 - secure shell client and server (transitional package) Changes: openssh (1:6.2p1-2) unstable; urgency=low . * Fix build failure on Ubuntu: - Include openbsd-compat/sys-queue.h from consolekit.c. - Fix consolekit mismerges in monitor.c and monitor_wrap.c. Checksums-Sha1: c44666cb144860b2597c29e98fee6fa34063ae89 2571 openssh_6.2p1-2.dsc 80788ad525ca4739fef816cd0f6808f65748e503 253109 openssh_6.2p1-2.debian.tar.gz 9b1a3bab7ec821a26a26757d389ece5e34b00aaf 1081672 openssh-client_6.2p1-2_i386.deb b55d88ba94bdc39623c24ab0c8c6aec66f1cd8bf 361346 openssh-server_6.2p1-2_i386.deb 4621d6f0d5aa2a33a8d2f9bbb0100f79c0308949 1250 ssh_6.2p1-2_all.deb 0bc90d489a0e3c2fa4206a514e06d1f56bb24ce8 101950 ssh-krb5_6.2p1-2_all.deb 0e93c86d5c95d1588d23fe07e35c2c7359ee0f1a 109820 ssh-askpass-gnome_6.2p1-2_i386.deb 3613637171c630a1003aebded83781f6279ef8bc 183106 openssh-client-udeb_6.2p1-2_i386.udeb d49420179e160a857dfbf7b48b159c09bf97f4d5 208472 openssh-server-udeb_6.2p1-2_i386.udeb Checksums-Sha256: 9f853109c9379c429dd01466a712b790c1383ac83ba00769966d70690bdeed9c 2571 openssh_6.2p1-2.dsc c64a77ae772e9c306e8409ce95ca6f546b1a9689d8d8fdbe2ffc8bdf9991432e 253109 openssh_6.2p1-2.debian.tar.gz c12f88bd6942652ad61faf84faba94bcdb58b9f48fe17159edb0a8f2ba242331 1081672 openssh-client_6.2p1-2_i386.deb b2eb27920a202873d5467095d8b1a9561c186f60ade63d0c3dcbfe3f474cdce9 361346 openssh-server_6.2p1-2_i386.deb e0e87dbe2aad881505172da7972e137d0936f74fa292b21b3ffaca13c85d2836 1250 ssh_6.2p1-2_all.deb 9e02704b4d02a2760ba29b0b43e32e5f7f4357021ef008e28ba903999e56188c 101950 ssh-krb5_6.2p1-2_all.deb b7b3bba9980d4173c4f27f260347b5bc78cf540f72a113be185f7ea52f433446 109820 ssh-askpass-gnome_6.2p1-2_i386.deb 9605a194f7b1d04f5e80fd6d660d8c7425b1349e4855fe451ced052cd9b5c663 183106 openssh-client-udeb_6.2p1-2_i386.udeb d45dcd9bcec30c0a785098af2b316fc124e1b2e6a98b499bac0f7064c929048f 208472 openssh-server-udeb_6.2p1-2_i386.udeb Files: 6b8d44b92f530bd3308f0f4a8258829e 2571 net standard openssh_6.2p1-2.dsc c1907116e20dfddffbd612b9442a40d4 253109 net standard openssh_6.2p1-2.debian.tar.gz b85382a6ca1c5780c0681c6edcf9666a 1081672 net standard openssh-client_6.2p1-2_i386.deb c60b4e803ba3bf8351a04c0f79d48fd8 361346 net optional openssh-server_6.2p1-2_i386.deb 228b5d619d87c2d24ed91340e8fdea4b 1250 net extra ssh_6.2p1-2_all.deb 21c06e3097105322382f74a54a0c1993 101950 oldlibs extra ssh-krb5_6.2p1-2_all.deb 40184f016bd12ed18912fff37b6faeb3 109820 gnome optional ssh-askpass-gnome_6.2p1-2_i386.deb 3f985a5a493e81848632a7d0c782b5cb 183106 debian-installer optional openssh-client-udeb_6.2p1-2_i386.udeb 8eb7b5b76a245f519f6541cf5629fe4e 208472 debian-installer optional openssh-server-udeb_6.2p1-2_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Colin Watson cjwat...@debian.org -- Debian developer iQIVAwUBUYtk2zk1h9l9hlALAQi61w//X0dDt1SSpKYDlgiY25tWDbqZys5G9DnR HLaxo8oDh+Uo3TicpsbtvJcVr+AQKfVcNef/f7zmX4+BPTlLDEzNufoFvODI5S3M H5oPlor626t34upCKE4wgorSnOBrhVs2hsg+x8AxwY+7dwF7JgL1lw/PyQGPFcZ+ 0Xl2gNyJmC1LPtgUuSUEFKJoQ395XPQ0peNOMS7ceYEVePUHTFM8Co/WXR04Lk5E EUM6Pem1G0haZ0V+rncyaxfMvm4u709/f6ohnfioD4ZWNKcLjJsA5nycKdr1DkGN lEmdgeziDtuFAX+wFHUbPSPQQb18ondvxBxdhG2xBGB50GC0x6RSTfxwZaDW6TrB Z151XUs5G4Y7CLuVkPXliS5tEuyR7JW867op0w+p7AJLRw3NgZXd8K0KzgeKICLi vnOXdHsvnf6CZuiD2EvrNJX3M8sne4bnLy36k8k+6ccykZL9drIdt5KjHaXnl5Yc geDfCed0HuZprrzp2PDxxNfbMdkojOlVhD60k9qUIKksACItfc+hURcZit8So87s a0JkRQ/MtsDYkpVojfUYwseFJuyKZgnhO7ZA0bQedvFOpduwM2ncFpnpAintBmdd zPGq4F3WG3LjOyddorTg8tCQJiQds1hwtvciLNCkULXsLG+VwIQuzvjlig1Bqzk2 Rkbd3NBwcdU= =0BeF -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/e1uanu3-0008i2...@franck.debian.org
Accepted puppet-lint 0.3.2-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 10:13:12 +0200 Source: puppet-lint Binary: puppet-lint Architecture: source all Version: 0.3.2-2 Distribution: unstable Urgency: low Maintainer: Puppet Package Maintainers pkg-puppet-de...@lists.alioth.debian.org Changed-By: Stig Sandbeck Mathisen s...@debian.org Description: puppet-lint - check puppet manifests for style guide conformity Changes: puppet-lint (0.3.2-2) unstable; urgency=low . * Upload to unstable Checksums-Sha1: 0d62cb38764c98c42b2ed69a61bfac41252fdb66 1430 puppet-lint_0.3.2-2.dsc d8dd92e34778de9d04b479a5add274b7729e0acb 2539 puppet-lint_0.3.2-2.debian.tar.gz fad7ae4c9238c59de224f134e5ceb76bc693451f 21682 puppet-lint_0.3.2-2_all.deb Checksums-Sha256: 0e6b203560054096d0a3d7b1ddf45a16a56559f41681b8eb4645aec460d20820 1430 puppet-lint_0.3.2-2.dsc aae5d9bce2f819823a3eb5e8e05cfe0f13fde42e24e12dccd8ee7a4bab487001 2539 puppet-lint_0.3.2-2.debian.tar.gz ca3659c509fb4fa875e76274b3b8694ac10bbda90c190aa96d50d89b3815a4d8 21682 puppet-lint_0.3.2-2_all.deb Files: 09c922ea3bf497283ec90a783d6fb9af 1430 ruby optional puppet-lint_0.3.2-2.dsc 81e5909010c0161c69b7442c59d608d3 2539 ruby optional puppet-lint_0.3.2-2.debian.tar.gz 6afd8e74c4cceb2f9ab53babd380e309 21682 ruby optional puppet-lint_0.3.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGLXOcACgkQQONU2fom4u6jkgCcCOc5nNuWz53DmHUsege6GTw+ yP0AnRocDxM60gRymXrYjYhaZiJEbWvN =D9cD -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/e1uanux-0008np...@franck.debian.org
Accepted purple-plugin-pack 2.7.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 10:29:33 +0200 Source: purple-plugin-pack Binary: pidgin-plugin-pack Architecture: source amd64 Version: 2.7.0-2 Distribution: unstable Urgency: low Maintainer: Felix Geyer fge...@debian.org Changed-By: Felix Geyer fge...@debian.org Description: pidgin-plugin-pack - Collection of Pidgin plugins Changes: purple-plugin-pack (2.7.0-2) unstable; urgency=low . * Use dh-autoreconf. Checksums-Sha1: ef89a26bf4979932ab76104ad8702967f7517b36 2097 purple-plugin-pack_2.7.0-2.dsc 1dc85edfce731a0f6bb3aeaf2e320ea2b9b73956 8566 purple-plugin-pack_2.7.0-2.debian.tar.gz e5069b54fd5ddbce1572a1478eb067b9abf60621 383684 pidgin-plugin-pack_2.7.0-2_amd64.deb Checksums-Sha256: 2cc676862f4692d1444089129e78b7a8cc2923bfdbc8f215386d3b56b3dda84c 2097 purple-plugin-pack_2.7.0-2.dsc 80093969977252e7ca859305c9798428d5993cabc69e9348b524cb78969bff01 8566 purple-plugin-pack_2.7.0-2.debian.tar.gz c9a333cbb4d9188a933db4f7dc6629c21fcf0504ea3c727e63596425d23e5382 383684 pidgin-plugin-pack_2.7.0-2_amd64.deb Files: 8047b0d84b1ea1e194440234c6ecf1ad 2097 net optional purple-plugin-pack_2.7.0-2.dsc 4ffd194dd618d67bbd08f88252b093db 8566 net optional purple-plugin-pack_2.7.0-2.debian.tar.gz a7d4c1289951ff3f9685906a0f2741dd 383684 net optional pidgin-plugin-pack_2.7.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRi2A2AAoJEP4ixv2DE11FWHIP/0N7uBox3sSy/4L7YM3myPGZ amkCjE+dnUZxY1Vkpf5eolaWN8NVNXHcTPEcYaokW3MOvKKmJ5mMj0C7aBw+UjAS PtYq+HjcTQyq70HcDN7mNibrKUQJJkzXYhcMy9kE1Ka5RLsxCvBJ7M3OluKeU+N8 rLGk1YLGaRD5XRHpBuYqV4nQeb1U7a023wZpsc+W11ubDCIAkxP1QpNdALqwkCMR rR+yvbfbIy92lstY7rhPnmYsYjj7MtTVm6Fwgy7nwnaA1p/QZmXwKLmg+WjuuTXU b2pSYykAuQmF55WcHVLvhXVPBh1ldSGj+9hgm26w+nnIy/LaZs3BjCVLKAiPztBC 9RLEPL4NDQDhjKI4/qhFPXM6QnEfc/cU443s7q6tP36SDDH3fy9+Wp++vf9gIBK6 aKb2kXzgx/TKwUoOthQIqMfr/lFoDToz+lkyqHJ/Fq8JaOqDm6Bk6aIn566mN01C kEAvotRS2u9hiY6TieCm8qQs/p3COBHrF02izlCVKL2VCEcbYtuCCCY6baSZyrig vBD4zzMVuLa+LCcJX06x9hSd0cUoznoNBmsBPmSuesJILtFMBfZRc9U7UXsDTA/n A79r39RkLvjiprw6KwY15p1AsRygNjP88UXIXcQJLrtcpmtNVOYj7EHFA4TQqkCs qfiDUJJlIqXOz9oAjeF4 =1pYh -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/e1uanub-0008oy...@franck.debian.org
Accepted drc 3.2.1~dfsg0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 May 2013 16:36:04 +0200 Source: drc Binary: drc Architecture: source amd64 Version: 3.2.1~dfsg0-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Jaromír Mikeš mira.mi...@seznam.cz Description: drc- digital room correction Changes: drc (3.2.1~dfsg0-1) unstable; urgency=low . [ Jaromír Mikeš ] * Set dh/compat 9 * Fix VCS canonical URLs. . [ Alessio Treglia ] * New upstream release * Remove DM-Upload-Allowed field, not needed anymore. * Refresh patches, properly set CFLAGS,LDFLAGS in the makefile. * Refresh 01-makefile.patch, partially applied upstream. * Remove myself from the Uploaders field. * wrap-and-sort -a -s * Bump Standards. * Update copyright and licensing information. Checksums-Sha1: 8e8f76ff5b65fa7d6339ff8f62b6a1bb6184b99f 1932 drc_3.2.1~dfsg0-1.dsc cd41669cee9eb98d6341147c9fbe31597935fa4a 1837721 drc_3.2.1~dfsg0.orig.tar.gz 2ff4052681955b86c1a0e141fc7ff2bc58f3ffa9 10101 drc_3.2.1~dfsg0-1.debian.tar.gz 6310f6673b29ba6c298f57d6a21721a20e8d8144 894302 drc_3.2.1~dfsg0-1_amd64.deb Checksums-Sha256: 11e9b46a04cb80ca80c2d23d556e9ac55df2bc5ab5cb89f3a726d4c86a23bbd0 1932 drc_3.2.1~dfsg0-1.dsc c8a8f0fa9288890dd0a6564c210567256069b05b99cd2f5ed5adc80c6dfcbf1e 1837721 drc_3.2.1~dfsg0.orig.tar.gz 5f4efb1e0f0300fde75b76892aa47e344d4e8ba273c9f227791c19d1479172a1 10101 drc_3.2.1~dfsg0-1.debian.tar.gz 02f2f42dd76c58ba1b23a51de4864a2b44ed0fbd8b98d00bc16e15f9e78a94f0 894302 drc_3.2.1~dfsg0-1_amd64.deb Files: 485eb2421bfecfb2894c82a2ca28a75a 1932 sound optional drc_3.2.1~dfsg0-1.dsc efab2da8ee0b4630a285c14b2f82b2e3 1837721 sound optional drc_3.2.1~dfsg0.orig.tar.gz b5c404a5721eca012cd65ac5d1f10bef 10101 sound optional drc_3.2.1~dfsg0-1.debian.tar.gz 5c33f2a70bbe97af4475ae4fc5198118 894302 sound optional drc_3.2.1~dfsg0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRi3XEAAoJEFsBlFXiuE+lrI0P/2GKBsH52Apnxbjyl5T1BIhh XrDdRiAKGYfl6TvliAySqeARwQCf5N/e6eRFEnjECymOW8FnHvLZnBPkgMDJmVtX 1fThgZv6J/1ss9Znavr1nBYwhWJgN0xwEr0CiHZDy2zspvyxf0dylhi0MI6MTPy0 ErIgJyYfSmmU/X5YeT5FWm3uMKwH0z9NlCILzFFiJQlUw4vEv37dWtqHKtClwGuT 9OYayGatdRsstNYNBS1F2RhIfdN5A7e2FFWJP3m5zbGoHcZKe05S/3sTm5tVFpBG i97rrY62Oq9ulsoys7d0diMYQ1tTEqX5qAgDgUcY5hvT9Cq6l2PR9d2bN6PtCx7e POiFLfchirmMwceTuz7eTdh2ZQzffqeJ7R7qivHakaMe+CDTH9EDrKtACw3xIKrS Hzz5FhYuHuhvzvO6bPESNOxzdgXoNZr3hRd5dxE41X9IB8h3Lh7u64VAeDGEFrD6 XDDdcNeYnmNfFIhnIdX0ZD0AQVcIIa6miNE/4zjMBzKlXhXXd64951w97nBQ5E/0 il3hb7CwZr2wZH0Y6uGDZX3aWEt0nZTM4Wi/XMD/QBmPTwpztlbYFiPcWtH5PEAJ nxPI0FBT9WtocshtSKCcHi1lHNsHKr6vIoiCL7LXKFy7DeDXAUi0yKEz+Rvty1pQ Lm6/ZzR+PpA7f2HP5LcC =v2Rn -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/e1uanv2-00067b...@franck.debian.org
Accepted grub2 2.00-14 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 May 2013 00:14:55 +0100 Source: grub2 Binary: grub2 grub-linuxbios grub-efi grub-common grub2-common grub-emu grub-emu-dbg grub-pc-bin grub-pc-dbg grub-pc grub-rescue-pc grub-coreboot-bin grub-coreboot-dbg grub-coreboot grub-efi-ia32-bin grub-efi-ia32-dbg grub-efi-ia32 grub-efi-amd64-bin grub-efi-amd64-dbg grub-efi-amd64 grub-efi-ia64-bin grub-efi-ia64-dbg grub-efi-ia64 grub-ieee1275-bin grub-ieee1275-dbg grub-ieee1275 grub-firmware-qemu grub-yeeloong-bin grub-yeeloong-dbg grub-yeeloong grub-theme-starfield grub-mount-udeb Architecture: source i386 Version: 2.00-14 Distribution: unstable Urgency: low Maintainer: GRUB Maintainers pkg-grub-de...@lists.alioth.debian.org Changed-By: Colin Watson cjwat...@debian.org Description: grub-common - GRand Unified Bootloader (common files) grub-coreboot - GRand Unified Bootloader, version 2 (Coreboot version) grub-coreboot-bin - GRand Unified Bootloader, version 2 (Coreboot binaries) grub-coreboot-dbg - GRand Unified Bootloader, version 2 (Coreboot debug files) grub-efi - GRand Unified Bootloader, version 2 (dummy package) grub-efi-amd64 - GRand Unified Bootloader, version 2 (EFI-AMD64 version) grub-efi-amd64-bin - GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) grub-efi-amd64-dbg - GRand Unified Bootloader, version 2 (EFI-AMD64 debug files) grub-efi-ia32 - GRand Unified Bootloader, version 2 (EFI-IA32 version) grub-efi-ia32-bin - GRand Unified Bootloader, version 2 (EFI-IA32 binaries) grub-efi-ia32-dbg - GRand Unified Bootloader, version 2 (EFI-IA32 debug files) grub-efi-ia64 - GRand Unified Bootloader, version 2 (IA64 version) grub-efi-ia64-bin - GRand Unified Bootloader, version 2 (IA64 binaries) grub-efi-ia64-dbg - GRand Unified Bootloader, version 2 (IA64 debug files) grub-emu - GRand Unified Bootloader, version 2 (emulated version) grub-emu-dbg - GRand Unified Bootloader, version 2 (emulated debug files) grub-firmware-qemu - GRUB firmware image for QEMU grub-ieee1275 - GRand Unified Bootloader, version 2 (Open Firmware version) grub-ieee1275-bin - GRand Unified Bootloader, version 2 (Open Firmware binaries) grub-ieee1275-dbg - GRand Unified Bootloader, version 2 (Open Firmware debug files) grub-linuxbios - GRand Unified Bootloader, version 2 (dummy package) grub-mount-udeb - export GRUB filesystems using FUSE (udeb) grub-pc- GRand Unified Bootloader, version 2 (PC/BIOS version) grub-pc-bin - GRand Unified Bootloader, version 2 (PC/BIOS binaries) grub-pc-dbg - GRand Unified Bootloader, version 2 (PC/BIOS debug files) grub-rescue-pc - GRUB bootable rescue images, version 2 (PC/BIOS version) grub-theme-starfield - GRand Unified Bootloader, version 2 (starfield theme) grub-yeeloong - GRand Unified Bootloader, version 2 (Yeeloong version) grub-yeeloong-bin - GRand Unified Bootloader, version 2 (Yeeloong binaries) grub-yeeloong-dbg - GRand Unified Bootloader, version 2 (Yeeloong debug files) grub2 - GRand Unified Bootloader, version 2 (dummy package) grub2-common - GRand Unified Bootloader (common files for version 2) Closes: 698914 703539 705636 Changes: grub2 (2.00-14) unstable; urgency=low . * Merge from Ubuntu: - Don't call update-grub in the zz-update-grub kernel hook if /boot/grub/grub.cfg doesn't exist. - acpihalt: expand parser to handle SSDTs and some more opcodes. Fixes test suite hang with current seabios. * Remove kernel-specific grub.d conffiles that were dropped from packages built for all but their corresponding kernel type in 1.96+20090307-1 (closes: #703539). * Look for grub-bios-setup in /usr/lib/grub/i386-pc/ as well (closes: #705636). * Merge 1.99-27.1 (thanks, Steve McIntyre): - Add entries for Windows Boot Manager found via UEFI in os-prober (closes: #698914). Checksums-Sha1: 11f965b84c85ac6d288f621dcbdfd62b1d0ebb8e 4455 grub2_2.00-14.dsc 040809869832ebd5a62b3c861beac2204cc750c6 353347 grub2_2.00-14.debian.tar.gz 11518fadb54f9b0c4c1b04adf38433a75e0fa2c9 2500 grub2_2.00-14_i386.deb a027383ee455a82b5a784f6c7eb26a749a0756af 1088 grub-linuxbios_2.00-14_i386.deb 4b8bc414ed1870ea348475fbb1f9a5831399fa84 1098 grub-efi_2.00-14_i386.deb 996a5a1c3268df7a555ef1a70d6632ec09442829 2025386 grub-common_2.00-14_i386.deb 07c70c0089c75ff1bee2377e97a88ddf45ecb0ed 115550 grub2-common_2.00-14_i386.deb 4e461e9a0c0b0dc4b1886bfc7d787a61e368e607 2340242 grub-emu_2.00-14_i386.deb eaa8f1debbee53565c5f36b254072056558f3423 1775118 grub-emu-dbg_2.00-14_i386.deb 43f5f2dabaff6a0dc0fae12ed189f19e04159bfc 800084 grub-pc-bin_2.00-14_i386.deb fe1e1e53857218d8481c0131cfa51063da6e17fd 2317248 grub-pc-dbg_2.00-14_i386.deb 9ab5a1a1cf8adada3defceaad6697501391b0437 168506 grub-pc_2.00-14_i386.deb 222df3c60bf87e13e7d83f1416228f9ba19ffcc0 1006052 grub-rescue-pc_2.00-14_i386.deb 5c077ecd1b71db484ba3565b27709cdf5ed00fff 522924 grub-coreboot-bin_2.00-14_i386.deb
Accepted gtypist 2.9.2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 09 May 2013 11:49:19 +0200 Source: gtypist Binary: gtypist Architecture: source amd64 Version: 2.9.2-1 Distribution: unstable Urgency: low Maintainer: Ben Armstrong sy...@sanctuary.nslug.ns.ca Changed-By: Daniel Leidert dleid...@debian.org Description: gtypist- simple ncurses touch typing tutor Changes: gtypist (2.9.2-1) unstable; urgency=low . * New upstream release. * debian/control: Dropped DM-Upload-Allowed. (Standards-Version): Bumped to 3.9.4. * debian/gtypist.lintian-overrides: Drop unused override unusual-interpreter. * debian/rules: Enable hardening flags for build. * debian/patches/220581_gtypist_vim_support.patch: Updated. * debian/patches/695777_update_info_doc.patch: Dropped. * debian/patches/debian_hardening.patch: Added. - Fix an FTBFS enabling hardening flags. * debian/patches/series: Adjusted. Checksums-Sha1: e380d4abe2e619709be34d393dd7cc4b99ef2b1c 1322 gtypist_2.9.2-1.dsc 212fc8b01a876ab92071d95eff31603946d256fb 1575158 gtypist_2.9.2.orig.tar.gz 859677055fc6b9fb5450e2203eba6193524bf445 9120 gtypist_2.9.2-1.debian.tar.gz 3f6eebafa4f0c13edb1a3db8c669c8c844ff0e8b 1092400 gtypist_2.9.2-1_amd64.deb Checksums-Sha256: c4334293f53a3e3372f7d675b53bcdc15f214abd790800dfb2ee8fbb2299e88d 1322 gtypist_2.9.2-1.dsc f5e33744d78b3d6f6e793d0bac6d344a828949ef6dbc1fc4846891af6abd96d3 1575158 gtypist_2.9.2.orig.tar.gz d276a7753c96bc8e03b98eca0a0f5aa9d9ca99c9b8590282aef01bb18cf06a60 9120 gtypist_2.9.2-1.debian.tar.gz 9d7b8b7f2728e45290cbe38310083ab7e75a3877bc5b88945e3019d887198a91 1092400 gtypist_2.9.2-1_amd64.deb Files: 8e90f28c8946ad098ad9c9c31bd82c6b 1322 misc optional gtypist_2.9.2-1.dsc e6f5ce16d3bdb335f7c698957bc54526 1575158 misc optional gtypist_2.9.2.orig.tar.gz 28680c84959ee4528258d5683d5cfe97 9120 misc optional gtypist_2.9.2-1.debian.tar.gz 6e2ab25de9abd4a3c3a0193732caee6f 1092400 misc optional gtypist_2.9.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGLcoEACgkQm0bx+wiPa4xvxgCfXzk6l3LfK2+jnwFvMaPdY7Zm SPMAoLjc8TMDLCkJ0OYBGt/txaFqiA5P =fe/E -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/e1uanvh-0006ed...@franck.debian.org
