Re: Packaging a new release of released SW, not considered by the DM?
On Thu, 2012-05-31 at 17:40 -0500, Gunnar Wolf wrote: Svante Signell dijo [Thu, May 31, 2012 at 11:45:13PM +0200]: It's *usually* not what you want to do. There are several cases where different versions of the same program are available in Debian, and I am unfamiliar with the case at hand, but it's usually where a specific older version of a package is depended upon by large amounts of software, and changes in new versions are not compatible. They often bring in maintenance hell issues. One example is to upload a new release to experimental, not sid! Being there does not automatically make it progress to sid, tesing and stable does it? In this case, you should discuss with the DM about the whatever reason you mention, maybe bring it up here (so it gets wider exposure and more informed people get to have a say). You can ultimately ask the Technical Committee, but that's a venue of action very seldom taken (and I think that even very seldom might be an overstatement). Well the DM is *non-responsive*, what to do? Thank you for your time, Fortunately, I'm not a hurd porter any longer an whatever you choose to do it is not longer my business. Thank you for your attention Huh‽ Well, the original question I replied to was posted by you... I fail to understand your answer. There was no mention of any specific program, architecture, kernel or whatever. Just to clarify, I have been contributing with bug reports and patches for various packages, etc for a long time. I'm not a DM or DD. Regarding DMs the non-responsiveness of *some* of them is frustrating, they don't bother to comment on _any_ of the bug reports. Is that the way a DM is supposed to work? And with the recent discussions on d-devel about hijacking etc it seems that if you are a DM for a package is set in stone *forever*. I really wonder if Debian is for me at all. There are other free software distributions, Ubuntu, Redhat Fedora, Mandriva, etc. I've been contributing there before. And there are even really free software distributions. So why stick to Debian? -- 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/1338534995.5450.136.ca...@hp.my.own.domain
Maintainer responsible for or only doing maintenance?
On 12-05-31 at 06:08pm, Holger Levsen wrote: On Donnerstag, 31. Mai 2012, Jonas Smedegaard wrote: You still avoid my question: What does Maintainer: mean? why do you ask rhetoric questions? It's defined in policy and you know it. So whats the point? Context of my question is Bernd arguing that responsibility lies at the uploader, not only for the contents of the upload but also for its future maintenance. My point is that either we are all wasting our time declaring a meaningless Maintainer: control field, or Bernd is wrong and the uploader responsibility is for the contents of the upload - which includes stating who is then to be held responsible for the maintainance. In my interpretation, maintainer is expected to act responsibly. Uploader is expected to act responsibly too: The act of uploading covers ensuring the vailidy of statements in the packaging (which is especially tricky for sponsoring of work outside our Web of Trust). The act of uploading does *not* IMO cover ongoing maintenance of the package. But you are right, let's simply look at Policy. I found this at §3.3: The maintainer is responsible for maintaining the Debian packaging files, evaluating and responding appropriately to reported bugs, uploading new versions of the package (either directly or through a sponsor), ensuring that the package is placed in the appropriate archive area and included in Debian releases as appropriate for the stability and utility of the package, and requesting removal of the package from the Debian distribution if it is no longer useful or maintainable. Enrico told me (discretely, possibly assuming it was common knowledge to the rest of the community) that Maintainer: is often a mailinglist which cannot be in our WoT and therefore cannot be held responsible. And that therefore the uploader really is the responsible party. Let's see what is said about Uploaders: control field (again §3.3): If the maintainer of the package is a team of people with a shared email address, the `Uploaders' control field must be present and must contain at least one human with their personal email address. See Section 5.6.3, ``Uploaders'' for the syntax of that field. Hmm. Did you see that? According to Policy, maintainer is responsible - even for the tasks done by uploaders - and uploaders are not defined as responsible. I might be missing something, but searching all of Policy I found only tools, scripts, authors (of the Policy document) and maintainers to be described as responsible. My point here is not to be nitpicking with Policy and claiming that noone but maintainers are responsible - but I do find it quite hard to fathom that maintainers are *not* responsible. Did I miss something? Did Bernd perhaps simply mean that in *addition* to maintainers, uploaders also have a bit of responsibility for some things (but not maintenance which is what this thread is about)? Could have helped me to understand what Bernd meant if he had simply answered my direct question instead of talking around it answering question with a counter-question, Is my point clear now (even if is may disagree with my reasoning)? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Packaging a new release of released SW, not considered by the DM?
On Friday 01 June 2012 09:16:35 Svante Signell wrote: Regarding DMs the non-responsiveness of some of them is frustrating, they don't bother to comment on any of the bug reports. Is that the way a DM is supposed to work? I don't think so. And with the recent discussions on d-devel about hijacking etc it seems that if you are a DM for a package is set in stone *forever*. There's a middle ground between hijacking and letting a package rot: Debian developers reference provides instructions to deal with inactive and/or unreachable maintainers [1]. I know from experience that following this process is an exercice is patience, but it's the best way to deal with maintainers which may be distracted by, well, real life events. I really wonder if Debian is for me at all. There are other free software distributions, Ubuntu, Redhat Fedora, Mandriva, etc. I've been contributing there before. And there are even really free software distributions. So why stick to Debian? Heh, I could give you an answer, but it would be valid only for me ;-) All the best [1] http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.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/201206011028.22691@debian.org
Re: Packaging a new release of released SW, not considered by the DM?
Hi Svante, On 12-06-01 at 09:16am, Svante Signell wrote: Regarding DMs the non-responsiveness of *some* of them is frustrating, they don't bother to comment on _any_ of the bug reports. Is that the way a DM is supposed to work? And with the recent discussions on d-devel about hijacking etc it seems that if you are a DM for a package is set in stone *forever*. The general rule is that when you are maintainer for a package, you stay maintainer. ...but maintainer role is not forever, though. But Debian praise stability and reliability, and both are generally helped when you are not shopping around but devote time to and grow detailed knowledge about specific pieces over longer time. ...but Debian rules are not set in stone, either¹. Note how I said generally several times above. What you experience at the mailinglist is discussing what is facts *today*, both to hold each other to an agreed consensus, and to consider if relevant to change to a different (hopefully better) consensus in the future. Hope that helped you gain interest in Debian :-) - Jonas P.S. I am not _always_ yelling and nitpicking. At least that's what Siri (my girlfriend), Gunnar Wolf and Andreas Tille tells me... ¹ Ahem. Debian Policy _is_ probably what most would call set in stone, but - as I suspect was also partly Andreas Tille's point in his once-a-day mail yesterday - we wrote that law ourselves, and are free to rewrite it. So soapstone or something... :-) -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Maintainer responsible for or only doing maintenance?
Jonas Smedegaard d...@jones.dk writes: My point is that either we are all wasting our time declaring a meaningless Maintainer: control field, or Bernd is wrong and the uploader responsibility is for the contents of the upload - which includes stating who is then to be held responsible for the maintainance. In my interpretation, maintainer is expected to act responsibly. I think this is too stark, or at least I feel like my personal position on this is part of an excluded middle. For the specific case of sponsored packages, for exactly the reasons that you have argued previously on this thread, we know that the package maintainer's affiliation with (and often committment to) Debian may not be as strong as the Debian Developer who is sponsoring the package. Therefore, in the specific case of sponsored packages, while the package maintainer is still responsible, we ask the sponsor to exercise some oversight over that responsibility and be prepared to step in if the maintainer is not fulfilling that responsibility for whatever reason. I think we also, at least informally, recognize the sponsor has having more control over the package than they normally would when they're not the maintainer, precisely because with repsonsibility should come the power to exercise that responsibility. I don't know if this is all explicitly written down anywhere, but it's certainly my feel of the general consensus and social expectations of the people who discuss this sort of thing on debian-mentors. -- 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/87ipfb75ka@windlord.stanford.edu
Re: Maintainer responsible for or only doing maintenance?
[Jonas Smedegaard] Is my point clear now (even if is may disagree with my reasoning)? I find your point quite clear, but suspect you misunderstood those claiming the sponsor have responsibilities regarding package maintenance. To me it is obvious that the sponsor is also responsible for a package, when the maintainer become unresponsive or missing. When the maintainer is active and available, the sponsor do not have to step in and the responsibility is sleeping. :) The maintainer is responsible in the day to day maintenance, but when I sponsor packages I also keep in mind that I might end up having to care about the package some time in the future if the listed maintainer looses interest or disappears for other reasons. You seem to argue that this should not be the case. Is this because of your current sponsor practice, or is there some other experience behind your view on the responsibilities of a package sponsor in Debian? -- Happy hacking Petter Reinholdtsen -- 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/2fl62bbmloo@login2.uio.no
Re: amd64 as default architecture
Guillem Jover guil...@debian.org writes: On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote: On Sun, May 20, 2012 at 1:10 PM, Sven Joachim svenj...@gmx.de wrote: On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote: Slightly OT but I wanted to mention it for its similarity: One thing that should be tested and then documented prominently as yay or nay in the wheezy upgrade notes is wether one can cross-grade from i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and then migrate to a 64bit userspace. Won't work in wheezy, apt does not support crossgradesà¸. Why? What breaks? Any bugs filed yet? I'm sure you are right that it currently doesn't work out of the box. I don't agree with killing this for wheezy without having some idea of how much breakage is involed though. I've seen reports from other people that have done crossgrades in the past with some handholding so it isn't impossible. Testing (see below) shows that there is one big issue, namely that crossgrading wants to remove the package before installing the new one. Everything else seems to be minor and package specific issues (like dash trying to overwrite its diversion). But testing on a minimal chroot is hardly conclusive so if you know other issues then feel free to speak up. There is no real reason to require apt to do the heavy lifting here. It would be nice, but it is a one-time action, so a specialized tool wouldn't hurt muscle memory too much. Install essentials and apt and you should be good to go to proceed as usual, just with a different architecture⦠I disagree that this is a one-time action, people might want to cross-grade specific packages back and forth, not just the entire installation. Also unsafe cross-grade does not only affect the Essential set, it also affects anything involved in the boot process, if for whatever reason the system crashes and apt would have removed such package the system would be rendered unbootable. Crossgrading a single package should already work. That is just normal multiarch stuff. As long as the dependencies are resolved, which multiarch does, there should be no problem. All assuming the package doesn't have architecture specific data that will break (like git-svn). Except with the essential set you don't always have dependencies. But I'm not concerned there. You always have depends on libraries through the shlibs/symbols files and everything else is (or should be) Multi-Arch: foreign and work in any arch. Even most essentials are easy to crossgrade, the only really difficult one is dpkg and it's dependencies as you have to take care of not breaking it while it crossgrades itself. I guess I don't see the additional complexity in the dpkg specific case, it just needs the shared libraries to be installed which should be co-installable anyway, and the rest being M-A:foreign. The complexity in dpkg (and apt) is the metadata. When crossgrading apt/dpkg the notion of native and foreign architecture switches and that impacts /var/lib/dpkg/info/ and the handling of Arch:all packages. So lets test this: cdebootstrap -v sid sid http://ftp.debian.org/ # dpkg --add-architecture i386 # apt-get update # apt-get install apt:i386 dpkg:i386 Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt:i386 : Depends: debian-archive-keyring:i386 but it is not installable E: Unable to correct problems, you have held broken packages. Doh, debian-archive-keyring isn't Multi-Arch: foreign (yet). Lets fix that and try again: # apt-get install apt:i386 dpkg:i386 Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386 libc6:i386 libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386 zlib1g:i386 Suggested packages: aptitude:i386 synaptic:i386 wajig:i386 dpkg-dev:i386 apt-doc:i386 python-apt:i386 glibc-doc:i386 locales:i386 The following packages will be REMOVED: apt dpkg The following NEW packages will be installed: apt:i386 dpkg:i386 gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386 libc6:i386 libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386 zlib1g:i386 WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! apt dpkg 0 upgraded, 11 newly installed, 2 to remove and 0 not upgraded. Need to get 10.3 MB of archives. After this operation, 16.1 MB of additional disk space will be used. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I
Re: amd64 as default architecture
Ben Hutchings b...@decadent.org.uk writes: On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: Eventually (wheezy+2? +3?) we would stop building a kernel package for i386. As in drop the i386 arch? No, keep i386 userland only. Though we might consider reducing even that to a 'partial architecture' that has only libraries (similar to ia32-libs today, only cleaner). Ben. Which basically means i386 is droped but we still support 32bit stuff for amd64. Isn't there still a large demand for i386 in the industry/embedded sector? 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/87396fnyhz.fsf@frosties.localnet
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
m...@linux.it (Marco d'Itri) writes: On May 18, Russ Allbery r...@debian.org wrote: I do this work in cases where keeping the patches separate is useful for some reason, but mostly it's not. Some of my packages have 30-60 patches (mature software...), and merging them would make them impossibile to understand. Is there a VCS workflow which would make such packages easier to manage than with quilt? (I like quilt, BTW.) -- ciao, Marco Check out gitpkg. It has hooks to create the quilt patches from a set of feature branches in some form. Also note that in this scheme where you produce a single debian patch you would not be working on the single debian patch. You would still work on your 30-60 feature branches (or whatever else you use instead of a patch queue). The single debian patch would just be the fallback for people that can't access your VCS. The single patch would be hard to understand but it would be unfair to compare it to 30-60 patches in a patch queue. What you have to compare the single patch with is a single debian diff.gz. Obviously if you can make a meaningfull patch queue with seperate patches that is preferable. The single patch method is for situations where you can't. 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/87y5o7mj4t.fsf@frosties.localnet
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: Goswin von Brederlow goswin-...@web.de writes: If you need to change a file then that means that file isn't source anymore but generated. Try switching to out-of-tree builds if you have something like that. What is the advantage of that? From the Debian policy, I don't see a need why sources should kept untouched during the build process. Less surprises by someone unfamiliar with the source. For example: - you (as in some porter, not the maintainer) build the source to reproduce a FTBS - it fails as expected - you edit the broken file - you build again and it works - you call clean so you can make a patch - clean restores the original source file destroying hours of your work If I would be unfamilar with the source, I would just not expect that the package behaves as I would do it myself. Instead, I would be ready for the case that it does tricky, undocumented things with the source -- and create the debian patch before I am going to build the package. Why should a porter expect more from a package than the requirements specified in the policy? Because I'm an optimist. When I work on a new source package I naively assume that the source is nice and does no evil, ugly, hackish things. Obviously that leaves me disapointed when it does. But all of that doesn't mean a source isn't better if it doesn't do evil, ugly, hackish things. Policy might not require it but common sense encourages it. It is just the better design: the package was built with a patched source, so only the patched version knows for sure how to clean it up. Note that it only calls clean with unpatched sources if you specifically unpatched your source before calling it. If you insist so much on this standard: why does debuild (or dpkg-buildpackage) undo the patches if they were not applied before? In this case, it would be up to the (rare) people to unpatch if they need this. One could even provide a debuild/dpkg-buildpackage option for that (like --unpatch-after-build or so), or do it in a hook. There already is the uapply-patches option. But then the patch is always unpatched after build instead of returning to the state prior to build. So I think having the clean target make sure patches are applied if needed is the better design. which again does not behave as expected: if clean depends on patch, then after debuild clean the packages is in the patched state even if it was unpatched before. Yes, if you just depend on patch then that is the result. clean: $(PATCH) clean up everything $(UNDO_PATCH) where PATCH is a makro that records the current patch state (like dpkg itself does) and UNDO_PATCH a makro to return the patch state to what was saved. I haven't tried this but you can probably make those makros use exactly the state file and format dpkg uses for abest results. I think the best way would be that debuild/dpkg-buildpackage would not automatically unapply the patches (so it would leave the source in the It doesn't automatically unapply the patches. It only restores the state you had before the dpkg-buildpackage was called. way that is described as standard for Debian), with a special option Which means that if you start with the standard of patches applied then they will remain applied. But if you manually deviate from the standard then it will preserve that deviation too. or hook that does this for those who really need it (and know what they are doing). Which would mean that you would have to unapply patches every time you try to build while working on a patch. With the current behaviour I can do quilt push foo.patch (foo.patch being somewhere in the middle) edit file quilt refresh debuild edit file quilt refresh debuild edit file quilt refresh debuild I was describing the case of having changes commited to the RCS and generating debian/patches/* automatically (or a single debian-changes patch). A single debian-changes patch is evil -- even Lintian complains there. Handling a single debian-changes patch is something I would explicitely *not* take as a valid use case. Is there a way to automatically handle a bunch of individual patches trough an RCS? git-pkg has something for that for example. Best regards Ole 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/87txyvmidm.fsf@frosties.localnet
Re: zlib and biarch/triarch
Thorsten Glaser t...@mirbsd.de writes: Just curious⦠I thought one is supposed to use Multi-Arch now, and that biarch/triarch can finally go away. Seeing the trouble broonie has with zlib, why are those packages still built anyway? Canât they please go away? bye, //mirabilos gcc still, and will remain doing so for some time, builds biarch (multilib) and needs any number of Build-Depends. 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/87pq9jmi7u.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Henrique de Moraes Holschuh h...@debian.org writes: On Fri, 25 May 2012, Thomas Goirand wrote: for small files, and in that case, it's faster. In reality, it's not that much faster, thanks to Linux caching of the filesystem, Under heavy filesystem IO load, yes it is. By several orders of magnitude. Even without load it is much faster because fsync() becomes a NOP. Disk based filesystems add sequenze points where you have to wait for the disk to catch up before continuing while tmpfs does not. It also saves on wear of the disk if the files are small and short lived, like temp files for gcc. No point writing the file to disk if it gets deleted 10s later. the point. Maybe we should add a /small-files-on-tmpfs (choose a better name, of course...) folder so that apps know what to do, that'd be a lot more graceful than just switching to whole /tmp to tmpfs without any app knowing about it. Nice idea, but it would be worthless. In fact it is the other way. We have /var/tmp for the large file since about forever, and important platforms that have /tmp in memory since the early 2000's (Solaris) And that STILL wasn't enough for people to not screw it up and dump large files in /tmp. There is also no problem with having large files in tmpfs. Only requirement is that you make tmpfs large enough and add enough ram and/or swap to cope with it. All the complaints about /tmp as tmpfs come down to one simple issue: The size of the tmpfs isn't chosen well. It would be more constructive to find a better heuristic for the size there. 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/87lik7mhl9.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Carlos Alberto Lopez Perez clo...@igalia.com writes: On 25/05/12 12:14, Henrique de Moraes Holschuh wrote: On Fri, 25 May 2012, Thomas Goirand wrote: for small files, and in that case, it's faster. In reality, it's not that much faster, thanks to Linux caching of the filesystem, Under heavy filesystem IO load, yes it is. By several orders of magnitude. This is a corner case. Defaults should be sane for most of the cases, and not for corner cases. Also defaults should prioritize stability (and non-breakage) over performance. With tmpfs on /tmp you are breaking many applications that assume that they have enough space to write on /tmp like the flash player ( see Debian bug #666096 ) or cdrecord software ( see #665634 ). And again, tmpfs isn't breaking it, only the size of /tmp. A 1GB real /tmp filesystem breaks them just like a 1GB tmpfs breaks them. So make /tmp large enough. Improve the heuristic that defines the size for tmp. The FHS [2] does not define *nothing* about the size of /tmp or /var/tmp. It *only* says that programs using files under /tmp must not assume that this files are preserved between invocations of the program So please, *stop* saying that /tmp should be only for small files because this is simply *not* *true*. It is *not* defined on any standard that files on /tmp should be small. Period. It is also *not* defined on any standard that files on /tmp may be big. Period. Sorry, that argument simply cuts both ways. An application that stores files in /tmp without checking size and/or handling ENOSPC properly is just broken and needs to be fixed regardless. 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/87hauvmgwm.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Nikolaus Rath nikol...@rath.org writes: Thomas Goirand z...@debian.org writes: On 05/25/2012 05:33 PM, Mehdi Dogguy wrote: What if we're installing Debian on a very small system, and that we need operations with big files in /tmp? Increase your swap? So, in this case, we will have the following scenario: - An app writes in /tmp - There's not enough space, so the system starts swapping, including some apps. Which happens regardless wether tmp is tmpfs or a real filesystem. The more IO there is the more likely some app gets swapped out. - The file gets written to /tmp, then gets read - Finally, the file gets deleted With tmps that instantly frees up all the memory and swap used by the file. With a real FS the file data remains in the dirty cache until such a time as the disk has cought up with writing it all and then it is thrown away. So potentially memory is freed up much later. - Then we have randomly very sloppy reaction of apps that were swapped out so that the file could be written in /tmp. Which, without tmpfs, then has to additionaly first wait for the dirty cached data to be written out causing huge delays because you get two seeks per page, 4k read/writes and no read-ahead. I believe tmpfs memory is swapped out preferentially, so your scenario doesn't have to play out like that. However, paging being a complex process, it's not impossible either. Is that something people are actually seeing? Because I haven't encountered this. It happens. But that isn't to say it doesn't equally (or worse) happen with a real FS. Paging is a complex process and there are so many factors involved that predicting the behaviour becomes pure guesswork. I would say both Thomas and my scenario are equally likely to occur. No matter what the default is there will be some users that hit the worst case. 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/87d35jmgf9.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Vincent Danjean vdanjean...@free.fr writes: Le 25/05/2012 05:03, Russell Coker a écrit : On Fri, 25 May 2012, Serge sergem...@gmail.com wrote: Q: /tmp on tmpfs increases apps performance. A: What apps? Real apps don't write files during performance-critical operations. Even if they do, they write large files. And large files are written faster when they're written on real disk, rather then swapped out and slow down the entire system (see the Who uses /tmp part). The apps that can really benefit from tmpfs are too rare. And we're talking about default settings and most common cases. Any application which writes synchronously (through fsync(), fdatasync(), or opening with O_SYNC) will get a massive performance benefit from using tmpfs. If some kind of sync is required by the application, I think this is because the application want to ensure the data are really written to the disk so that their state remains coherent even in case of crash. If the application is ok to have this kind of data written to tmpfs (ie in memory), I do not see the interest of using sync at first. Can someone shows me a valid use case of sync on tmpfs? Regards, Vince You might also need to [fm]sync() to ensure the data written by one application can be read by another, to ensure the state remains coherent between multiple processes. And don't forget that disk based filesystems add syncs internally to ensure their own coherent state. Applications do get blocked by those too. 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/878vg7mg4h.fsf@frosties.localnet
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow goswin-...@web.de writes: debian-de...@liska.ath.cx (Ole Streicher) writes: I think the best way would be that debuild/dpkg-buildpackage would not automatically unapply the patches (so it would leave the source in the It doesn't automatically unapply the patches. It only restores the state you had before the dpkg-buildpackage was called. It does not since it keeps the compiled files. If you mean it serious with restoring the state, you should call clean here, too. or hook that does this for those who really need it (and know what they are doing). Which would mean that you would have to unapply patches every time you try to build while working on a patch. With the current behaviour I can do quilt push foo.patch (foo.patch being somewhere in the middle) edit file quilt refresh debuild [...] You can do the same even if either clean is called before the unpatching was done, or if neither clean nor unpatching was done, since quilt recognizes the state. The point is really: The state * compiled files (*.o etc.) from a patched package, but * unpatched source files is inconsistent. Best regards Ole -- 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/ytzsjef6zu1@news.ole.ath.cx
Re: Moving /tmp to tmpfs makes it useless
Salvo Tomaselli tipos...@tiscali.it writes: Because paging out a couple Gigabytes is veery different from writing a couple Gigabytes to disk, of course. Yes because writing that on disk will only block the thread performing the write, not every thread that tries to allocate memory. Wrong. The thread doing the write will just write to cache and not block at all. That is until you run out of cache. And then any thread that needs to allocate memory will block until such a time as some dirty memory is written. Now with multiple cores it becomes a bit more complex since then you have seperate queues. So only one core might block anything needing memory on that core. If anyone wants to experience that then write out some GB of data over NFS. After a short while processes will hang while others keep running. 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/874nqvmfwu.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Carlos Alberto Lopez Perez clo...@igalia.com writes: On 25/05/12 12:20, Henrique de Moraes Holschuh wrote: On Fri, 25 May 2012, Salvo Tomaselli wrote: Because paging out a couple Gigabytes is veery different from writing a couple Gigabytes to disk, of course. Yes because writing that on disk will only block the thread performing the write, not every thread that tries to allocate memory. What IO scheduler are you using? It must not be CFQ. CFQ will happly screw it up and stall both readers and writers when the number of dirty pages gets too large (which will happen if you write a gigabyte file to disk). Either that, or you're cheating and your backend devices are simply fast enough that it doesn't matter (fast RAID or fast SSD). The real question is: what does it better under CFQ+IO contention? Several threads doing filesystem IO, or the swapper? Hint: it is not an easy question to answer because it depends on the load, type of load, and backend device. I think that any user that has been using Linux for a while knows how ugly the things become when the systems starts swapping. When the system is swapping, the whole system will become so unresponsive while the swapping process is taking place that even your mouse pointer will stop moving. And this is *very* *very* annoying. This is so annoying, that I even had configured my laptop with a very low amount of swap, since I rather prefer the oom-killer to kill the application that is filling the ram than rather suffer this annoying situation. So please, don't argue about theoretical things about virtual memory or IO schedulers. If you are a desktop Linux user, you should know how ugly the things get when the system is swapping. That is swapping out binaries or their data and needing to wait for it to be swapped back in. The problem is the waiting for it to be swapped in there, not that you are swapping. With large data on tmpfs you will be swapping out lots of data but you won't block waiting for stuff to be swapped back in in general. Only something reading back the file will block, not your mouse cursor. I don't know the ultimate reason behind this ugly behaviour of Linux when the swapping process is happening, but I know this is real and it happens because I have experimented this situation myself more than a couple of times. It's a matter of that gets swapped and linux choosing the wrong thing to swap (far too often). There is some bug in linux that when you have lots and lots of IO at some point the swap heuristics tip over and start swapping apps and usefull data to create more cache space for IO. Doesn't matter that you already have 3GB for cache, it still swaps out your mouse cursor and then things go real bad. 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/87zk8nl10x.fsf@frosties.localnet
Re: May be ITP: mime-support-extra to close #658139 (Was: Breaking programs because a not yet implemented solution exists in theory)
Hi, On Thu, May 31, 2012 at 10:56:50PM +0200, Michael Biebl wrote: On 31.05.2012 21:35, Andreas Tille wrote: In any case the idea is to collect issues of broken mime support where maintainers are unable / not willing to respect Debian policy 9.7. Adding more entries is simple: Just add the according mime file as pkg.mime and add pkg to Enhances in debian/control. I don't think adding such a package is a good idea. It's just an ugly work-around. Fully ACK. That's why the first of the option what could be done was to leave it as local package and do not upload it officially. In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is already a patch by brian m. carlson. Any effort regarding this issue should be spent getting this patch ready and applied to mime-support. I would consider the severity of this bug to low considering that several applications are broken if we will not fix this problem before the next stable release. Is there anything which prevents an upload of this fix? If there would be no soonish upload I'd consider increasing the severity to make sure it will not be forgotten somehow. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120601113352.gd31...@an3as.eu
Re: Moving /tmp to tmpfs makes it useless
Salvo Tomaselli tipos...@tiscali.it writes: So what? If you write to a normal file system, it goes into the page cache, which is pretty much the same as writing into tmpfs. tmpfs will make it stay forever in the RAM, caches are flushed to disk and their space can be used for new things. - Ted No, tmpfs will be swapped out if you don't use a file for a while but something else uses memory, including IO caching. The difference to a disk based filesystem is that most disk based filesystems force the write out after a short wait (1-60s). 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/87vcjbl0ma.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useless
Josselin Mouette j...@debian.org writes: Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit : There is one significant difference though. When you read data back to memory from swap, the kernel does not remember that it already exists on disk; when the data is evicted from memory again, it is unnecessarily rewritten to disk rather than just dropped. Thus, if you do multiple read iterations through a large set of data (which does not fit in memory) on tmpfs, each iteration does disk read AND write rather than just read. I donât know enough of the kernel innards, but it sounds to me that if a previously swapped page hasnât been modified, it should be kept on swap *and* memory as long as possible. If it does not, it sounds like a bug, but it would indeed lead to the behavior you describe for this specific usage pattern. Linux certainly has a notion of cached swap, i.e. pages from swap that are also unmodified in memory. As long as you have enough swap the kernel should not reap the swapped data and know that it is already on disk when it wants to evict the page. 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/87r4tzl0ik.fsf@frosties.localnet
Re: Moving /tmp to tmpfs makes it useful
Serge sergem...@gmail.com writes: I'm asking for *popular* apps, that create files in /tmp, *never put large files* there, and become *noticeably* faster with /tmp on tmpfs? gcc, ocamlopt, mc, lintian 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/87hauvkzl0.fsf@frosties.localnet
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Serge sergem...@gmail.com writes: 2012/5/28 Roger Leigh wrote: The primary cause of problems is simply that the tmpfs /tmp isn't big enough. [...] what guarantees are offered by the system in terms of minimum and maximum available space on /tmp? [...] Consider the default: /tmp is on the rootfs (which [...] may have lots of free space or very little). [...] consider tmpfs mounted on /tmp: the size specifies the total available space. Well, technically, we already guarantee that. The option TMP_OVERFLOW_LIMIT does. It mounts /tmp to tmpfs if there's too few free space there. But we can make it better. Idea: mount /tmp to tmpfs only when amount of free space in /tmp is fewer than amount of RAM. That should be: mount /tmp to tmpfs only when amount of free space in /tmp is fewer than the tmpfs would have or when /tmp is currently read-only. Technical details: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and then compares `df /tmp/` with amount of RAM available. 3. If amount of RAM is larger it mounts /tmp to tmpfs 4. otherwise leaves /tmp as it is. This way we can guarantee that there will be as much space in /tmp as possible but *at least* as much as the amount of RAM available. Looks reasonable? Will that suit everyone? No. If /tmp is already mounted as a seperate partition then tmpfs should not be mounted. It might be neccessary to mount a tmpfs if the remaining size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur if the seperate /tmp filesystem is broken in that it can't be cleaned. With people doing stupid things like using just one partition you easily have 3TB free in / and therefore /tmp. Actualy having less space in /tmp than tmpfs would get would be quite rare. So tmpfs would basically never be used despite the benefits. Even non stupid setups can have lots of space in /. Specifically when you have /usr on / instead of a seperate partition. Having a few GB free there is quite reasonable. Still a tmpfs makes more sense. Even worse / can be read-only and then you always need a tmpfs for /tmp or a seperate partition. Or maybe I just like tmpfs and have configured my system to set the right options in /etc/default/tmpfs. You are completly ignoring that configuration. In general your option assumes that you need the maximum amount of free space in /tmp. That is simply not true. In most cases a small /tmp is just peachy. Because of this it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. Best I can come up with is that applications that need lots of space in /tmp, which are few, could check in postinst and give a debconf notice that /tmp should be resized according to /usr/share/doc/something/README.tmp-resize to at least xGiB. IMHO: this option should not break anything (and may even fix something) so it can be enabled by default. But it MUST be possible to disable it for those rare cases when admin intentionally left /tmp on a small partition. Your option would make all my systems unbootable since / is read-only, includes /usr and has some GB free space. 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/87d35jkyvq.fsf@frosties.localnet
Re: amd64 as default architecture
On Fri, 2012-06-01 at 11:59 +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: Eventually (wheezy+2? +3?) we would stop building a kernel package for i386. As in drop the i386 arch? No, keep i386 userland only. Though we might consider reducing even that to a 'partial architecture' that has only libraries (similar to ia32-libs today, only cleaner). Ben. Which basically means i386 is droped but we still support 32bit stuff for amd64. Isn't there still a large demand for i386 in the industry/embedded sector? I don't know; nor whether they use Debian much. But those are two sectors not well known for keeping their software updated, i.e. they might not care about a lack of future releases.. I'm not suggesting there's any need to decide a timescale for this, anyway. I'm just proposing that we plan to have that transitional stage for some time before actually removing i386. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Moving /tmp to tmpfs makes it useless
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote: On 05/28/2012 05:32 AM, Roger Leigh wrote: On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote: On 05/25/2012 07:44 PM, Roger Leigh wrote: However, the majority of software which finds the tmpfs too small has unreasonable expectations of what can be expected to be available (by default). We welcome you to rewrite / patch these software then! Good luck, the list is huge, and growing every day this thread is alive. (As an aside, could you possibly reduce the number of mails you're sending. You've sent at least 12 today, and most of them all said essentially the same thing.) I'll do that when people will stop ignoring arguments posted on the very first message of the thread, like the fact so many popular applications are writing big files to /tmp, and that it's simply unrealistic to believe we can fix them all before Wheezy. You seem to forget it once more in this post as well. Nothing in this thread has been ignored. Please don't make unwarranted assumptions. Stating the same thing in 20 different replies doesn't make it any more useful than stating it in one. I'm well aware of the issues involved and haven't forgotten anything. The primary cause of problems is simply that the tmpfs /tmp isn't big enough. Applications are creating files which use up all the space. I'd like us to consider the problem in terms of what guarantees are offered by the system in terms of minimum and maximum available space on /tmp. Consider the default: /tmp is on the rootfs, and there is a single filesystem (which might be very large or quite small, and may have lots of free space or very little). In this case, we offer no guarantees about the available space. Now in the typical case, we might well have tens, or even hundreds, of GiB available, which can be used by files under /tmp. But this is not guaranteed. There might be next to no free space. Now consider tmpfs mounted on /tmp: the size specifies the total available space. This is guaranteed to be available; it's both the minimum and maximum, so while it /might/ place a lower upper limit on size than a regular filesystem would, it also guarantees that this space will be available Unless I didn't understand how tmpfs work, you have no guarantee as well. Once your memory is eaten by apps, and your swap gets full, you are in the exact same situation as having your /tmp holding partition full, at the exception that your system becomes totally unusable and unstable. The defaults have been carefully (perhaps even too conservatively) chosen to prevent any problems with the system becoming unusable. And you are not correct here. The tmpfs defaults to guaranteeing a certain fixed size being available, as I stated above. If the memory was used up by applications and data, then the system will swap, drop cached data, flush unwritten data to disc etc. in order to make room for it. You are *guaranteed* to be able to use that space, and it does not cause problems (modulo the size limit being too small). The important point is that the space is absolutely guranteed to be available, which is something a regular filesystem does not, unless you dedicate a separate filesystem to /tmp. 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/20120601123246.gn...@codelibre.net
Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote: On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote: I've read across different debates about whether using tmpfs is good or bad but I could not find the most important reason, so here it is... I haven't got anything particularly new to add to the discussion here. [This was also posted to LWN in part.] As mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674517 it was originally intended that this feature only be enabled for new installs, not on upgrade. As mentioned in this bug, some of that has been rectified already in git. We will also correct the configuration for users who got tmpfs enabled during upgrade, but this needs careful testing. The main issue for it being enabled on upgrades is that insufficient swap may be available to have a reasonable amount of space. This is also an issue for new installs--we do need some support in the installer for this as well. I'm certainly not averse to switching the default back, if this is the best solution at the present time for the majority of our users. As was seen in both this an earlier discussions, there is not a clear-cut consensus here--there are from what I can tell approximately equal numbers in the for and against camps. It's clear we can't satisfy everyone no matter which is picked as the default. As mentioned, the use of tmpfs really boils down to peoples expectations of what /tmp is /for/. The size of what may be stored isn't specified in any standard, so it's not fair to say that it's only usable for small files. But using a tmpfs does place a restriction of the size of the files which may be used. That said, allowing certain applications to store multi-GiB files on /tmp causes its own indirect problems in addition to the immediate: these programs are often broken on smaller systems due to not being able to cope with running out of space, and impose a requirement for vast amounts of temporary space. These programs are broken on systems with a smaller rootfs, irrespective of the tmpfs issue. Maybe we need to distinguish not on size, but on speed of access, and have /tmp for fast access and a separate location for slower disc-backed storage, which would be more suited to the storage of streaming media, ISO images etc. which are going to have a longer lifetime, and also tend to be larger. None of these uses benefit from being on a tmpfs in the general case. (I've used /scratch for this in the past, though currently it's a 1 TiB btrfs RAID1 under /srv/scratch.) Obviously out of scope for wheezy. The important part of what we've achieved for wheezy is having tmpfs filesystems mounted on /run (and optionally /run/lock and /run/shm). The tmpfs on /tmp uses the same infrastructure in our init scripts, and we mount tmpfs on /tmp in two special cases: if the rootfs is read-only and no /tmp mount exists in fstab, and if /tmp contains less than a certain amount of free space. This is one part of making it possible to run with a read-only rootfs out of the box, and also to aid recovery if booting when the rootfs is full, respectively. The default of whether we mount tmpfs on /tmp by default or not is really only a minor part of the other improvements we have in wheezy--it really doesn't matter which is the default, so long as it works. While I'm in favour of this being tmpfs, if there are too many programs which break which can't be fixed, then we'll have to switch back to using a regular filesystem. Maybe we'll then be able to reconsider it for wheezy+1. [As an ironic aside, when testing RAMTMP=no in rcS for backward compatibility for #674517, I ran out of space on /tmp and broke gcc/ld. On my system, there's only a few hundreds of MiB free on the rootfs; tmpfs is absolutely needed here!] 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/20120601124026.go...@codelibre.net
Re: Debian documentation permalinks
On 30/05/12 22:42, Karl Goetz wrote: On Wed, 30 May 2012 13:20:24 +0100 Philip Ashmore cont...@philipashmore.com wrote: On 30/05/12 12:29, Bernd Zeimetz wrote: On 05/26/2012 09:09 PM, Philip Ashmore wrote: On 05/26/2012 06:53 AM, Jonathan Callen wrote: On 05/25/2012 10:03 PM, Philip Ashmore wrote: Hi there. First, here's what I'm talking about - http://en.wikipedia.org/wiki/Permalink Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully the above link won't rot. And here's the permalink to the above article, as it was when the preceding post was made: http://en.wikipedia.org/w/index.php?title=Permalinkoldid=483438630 Or, if you prefer links that don't indicate where they're really going: http://en.wikipedia.org/w/index.php?oldid=483438630 I'm happy and sad with this. Happy that Wikipedia provides permalink support. Sad that it didn't document it in its article about permalinks. Is there documentation on this feature somewhere? Permalinks, along with the fact that MediaWiki is free GPLv2, makes a compelling argument for moving Debian documentation to MediaWiki. Which documentation are you talking about? Most official documentation should have a fixed URL. If you are talking about the wiki: retrieving a fixed version from moinmoin is the same as in mediawiki. So I can't see a useful argument here, only FUD trying to talk people into using Mediawiki. Hi there and thanks for your feedback. I'm talking about the fact that Debian has mail archives that may include links to documentation that has changed since the mail was written, possibly rendering the mail thread misleading or nonsensical. Any documentation system that can provide a means to refer to a specific version (permalinks) would be better than what's there now. Could you give examples of things lacking permalinks? thanks, kk http://wiki.debian.org/BridgeNetworkConnections It doesn't mention which version(s) of Debian it applys to. It doesn't provide links to versions that apply to previous or testing versions of Debian. I also couldn't find a permalink on the page. Oh and I couldn't get it to bridge from my wifi to the ethernet port. Does anyone else out there wish there was an app that (graphically) simulated packet flow/filtering based on test configurations? This page is definitely not noob-friendly, or is that a feature? Philip -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc8bf4e.4070...@philipashmore.com
Re: Moving /tmp to tmpfs makes it useless
If anyone wants to experience that then write out some GB of data over NFS. After a short while processes will hang while others keep running. True, that's what i was saying. But if there is not enough memory, it's not only one process that will hang. It's everything. So i think that adding pressure on the RAM, which is absolutely not as aboundant as disk space is a mistake, for a generic configuration. If you know that you aren't going to hit that high memory allocation then.. free to use tmpfs. -- Salvo Tomaselli -- 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/201206011510.52802.tipos...@tiscali.it
Bug#675467: ITP: bilibop -- run Debian from external media
Package: wnpp Severity: wishlist Owner: bilibop project quid...@poivron.org * Package name: bilibop Version : 0.1 Upstream Author : bilibop project quid...@poivron.org * URL : https://poivron.org/~quidame/bilibop_project/ * License : GPL-3.0+ Programming Lang: Shell Description : run Debian from external media Bilibop is a collection of scripts using or used by other programs (initramfs- tools, udev, aufs, mount, GRUB2) to help admins to maintain a Debian GNU/Linux operating system installed on a removable and writable media. One of its main goals is to fix security issues or harden standard rules and policies to make the system more robust in this particular situation. The bilibop source package builds the following binaries: bilibop: metapackage bilibop-common: shell functions to find the drive hosting the root filesystem (dm-crypt, LVM, loop devices, aufs and any combination of them are supported) bilibop-rules: udev rules to fix the removable drive hosting the running system, and all its partitions, as members of the 'disk' group (fixes bug #645466). Other optional features for the desktop environment (based on Udisks). bilibop-lockfs: make a standard installation to behave like a LiveUSB. Can be used as an alternative (and enhancement) of the fsprotect package. -- 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/20120601131051.5723.72626.reportbug@xporter
Re: Moving /tmp to tmpfs makes it useless
No, tmpfs will be swapped out if you don't use a file for a while but something else uses memory, including IO caching. unless too many things want to use memory, then tmpfs gives a great contribution in taking down the machine. As you pointed out yourself in another email, under memory pressure the kernel starts doing odd choices. So the point is: is it correct to enforce a default setting that will break many software that would otherwise work flawlessy, and that makes the machine less reliable but faster for certain kind of tasks? -- Salvo Tomaselli -- 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/201206011513.46456.tipos...@tiscali.it
Re: Debian documentation permalinks
On Fri, 2012-06-01 at 14:10 +0100, Philip Ashmore wrote: On 30/05/12 22:42, Karl Goetz wrote: On Wed, 30 May 2012 13:20:24 +0100 Philip Ashmore cont...@philipashmore.com wrote: On 30/05/12 12:29, Bernd Zeimetz wrote: On 05/26/2012 09:09 PM, Philip Ashmore wrote: On 05/26/2012 06:53 AM, Jonathan Callen wrote: On 05/25/2012 10:03 PM, Philip Ashmore wrote: Hi there. First, here's what I'm talking about - http://en.wikipedia.org/wiki/Permalink Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully the above link won't rot. And here's the permalink to the above article, as it was when the preceding post was made: http://en.wikipedia.org/w/index.php?title=Permalinkoldid=483438630 Or, if you prefer links that don't indicate where they're really going: http://en.wikipedia.org/w/index.php?oldid=483438630 I'm happy and sad with this. Happy that Wikipedia provides permalink support. Sad that it didn't document it in its article about permalinks. Is there documentation on this feature somewhere? Permalinks, along with the fact that MediaWiki is free GPLv2, makes a compelling argument for moving Debian documentation to MediaWiki. Which documentation are you talking about? Most official documentation should have a fixed URL. If you are talking about the wiki: retrieving a fixed version from moinmoin is the same as in mediawiki. So I can't see a useful argument here, only FUD trying to talk people into using Mediawiki. Hi there and thanks for your feedback. I'm talking about the fact that Debian has mail archives that may include links to documentation that has changed since the mail was written, possibly rendering the mail thread misleading or nonsensical. Any documentation system that can provide a means to refer to a specific version (permalinks) would be better than what's there now. Could you give examples of things lacking permalinks? thanks, kk http://wiki.debian.org/BridgeNetworkConnections It doesn't mention which version(s) of Debian it applys to. It doesn't provide links to versions that apply to previous or testing versions of Debian. It's a wiki, so how would we ensure that? I also couldn't find a permalink on the page. Oh and I couldn't get it to bridge from my wifi to the ethernet port. Not particularly surprising; that recipe is a nasty hack. Routing makes more sense. Does anyone else out there wish there was an app that (graphically) simulated packet flow/filtering based on test configurations? This page is definitely not noob-friendly, or is that a feature? It's a wiki, so how would we ensure that? Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Moving /tmp to tmpfs makes it useless
And you are not correct here. The tmpfs defaults to guaranteeing a certain fixed size being available, as I stated above. If the memory was used up by applications and data, then the system will swap, drop cached data, flush unwritten data to disc etc. in order to make room for it. You are *guaranteed* to be able to use that space swap is shared between every process, it's not for tmpfs only... so there is no such thing as *guaranteed*. -- Salvo Tomaselli -- 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/201206011605.48078.tipos...@tiscali.it
Re: Moving /tmp to tmpfs makes it useless
2012/6/1 Roger Leigh wrote: I'm certainly not averse to switching the default back, if this is the best solution at the present time for the majority of our users. If only it was the best solution... As was seen in both this an earlier discussions, there is not a clear-cut consensus here--there are from what I can tell approximately equal numbers in the for and against camps. I don't see the for camp. I only see the against and not against. People from against camp list the problems. And others from not against camp are saying that it's not that bad. Nobody shown why it's a good default yet. Can you name arguments from the for camp, or at least quote them? What software became faster/better because of tmpfs? Just some popular software that anybody can run and say wow, it's twice faster with /tmp on tmpfs. None, then why forcing it? Maybe we need to distinguish not on size, but on speed of access, and have /tmp for fast access and a separate location for slower disc-backed storage Why do you call /tmp on tmpfs fast? Does it make anything faster? If not then what's the point in reinventing /tmp in a separate location? [As an ironic aside, when testing RAMTMP=no in rcS for backward compatibility for #674517, I ran out of space on /tmp and broke gcc/ld. On my system, there's only a few hundreds of MiB free on the rootfs; tmpfs is absolutely needed here!] Ehm... A few questions, I'm just curious: 1. Don't you use -pipe option for gcc? 2. How have you managed to fill a few hundreds of MiB with gcc!? 3. What do you think about default RAMTMP=auto idea: in addition to the RAMTMP=no and RAMTMP=yes implement RAMTMP=auto value: mounting /tmp to tmpfs only when this increases free space in /tmp? Meaning, if you have more than 20%VM free space in /tmp on disk, than no tmpfs mounted (the Idea: mount /tmp to tmpfs depending on free space and RAM mail)? It would solve the problem of small root and at the same time all the tmpfs problems will go away. -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEreZE=ov=07aiclrju6hx1m6dkmw_2+on6w-ffqlrp...@mail.gmail.com
Re: Debian documentation permalinks
On 01/06/12 14:53, Ben Hutchings wrote: On Fri, 2012-06-01 at 14:10 +0100, Philip Ashmore wrote: On 30/05/12 22:42, Karl Goetz wrote: On Wed, 30 May 2012 13:20:24 +0100 Philip Ashmorecont...@philipashmore.com wrote: snip Could you give examples of things lacking permalinks? thanks, kk http://wiki.debian.org/BridgeNetworkConnections It doesn't mention which version(s) of Debian it applys to. It doesn't provide links to versions that apply to previous or testing versions of Debian. It's a wiki, so how would we ensure that? By mentioning which version(s) of Debian it applies to. I also couldn't find a permalink on the page. Oh and I couldn't get it to bridge from my wifi to the ethernet port. Not particularly surprising; that recipe is a nasty hack. Routing makes more sense. Does anyone else out there wish there was an app that (graphically) simulated packet flow/filtering based on test configurations? This page is definitely not noob-friendly, or is that a feature? It's a wiki, so how would we ensure that? Ok, I guess I'm being off topic here - I'm talking about a Debian package that can 1. Accept the same configuration files/syntax as the real services do. 2. Allows the user to describe some hypothetical networking set-up, possibly involving multiple networking interfaces on multiple machines. Also, network manager interactions should be visible too. 3. Can identify the kinds of packets that each machine would be expected to send / accept based on role options (DHCP, wifi, Gateway, non-configurable) configurable with dialogs. 4. Can display a simulation of the packets being routed/forwarded/rejected based on the configuration 5. Can generate scripts to be run on one or more of the target machines (that run Debian?) to verify a particular configuration deployment among the target machines. Ben. Philip -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc8cfed.4090...@philipashmore.com
Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)
On Tue, Jul 26, 2011 at 6:03 PM, Paul Wise wrote: On a related note, an OEM mode for d-i is something I believe we currently lack. Requirements for this would be the above unconfigured systems idea plus some on-boot UI to configure the system (timezone, users, etc). The Mint folks have created OEM images, it might be interesting to digg into these if anyone is interested in implementing this for Debian: http://blog.linuxmint.com/?p=2046 -- 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/CAKTje6EBp3Fkg9h1GH=ekuozvchom8m-ws1tonscdyjaa+q...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
2012/6/1 Goswin von Brederlow wrote: That should be: mount /tmp to tmpfs only when amount of free space in /tmp is fewer than the tmpfs would have or when /tmp is currently read-only. Yes, of course. IIRC current script already checks for read-only root. So this check don't have to be added. Looks reasonable? Will that suit everyone? No. :'-( If /tmp is already mounted as a seperate partition then tmpfs should not be mounted. Hm... Good point. Debian should not try to be smarter than admin. If admin specified a mountpoint for /tmp then it must be used whatever size it is. It might be neccessary to mount a tmpfs if the remaining size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur if the seperate /tmp filesystem is broken in that it can't be cleaned. Yes, I guess so. With people doing stupid things like using just one partition you easily have 3TB free in / and therefore /tmp. Actualy having less space in /tmp than tmpfs would get would be quite rare. This idea comes from an attempt to make everything work for small root partitions without breaking things that were working before. So tmpfs would basically never be used despite the benefits. Well, nobody named the benefits yet. Just the problems. There were a few attempts with some artificial test scripts, but no examples of real applications becoming faster with /tmp on tmpfs. And it's kind of pointless to change the defaults just to make some useless scripts faster. I could try finding a better solution if I knew the benefits. Or maybe I just like tmpfs and have configured my system to set the right options in /etc/default/tmpfs. You are completly ignoring that configuration. Or course, if you set the option it must be used. I was not suggesting to force that, just add one more option. For example in addition to RAMTMP=yes and RAMTMP=no add value RAMTMP=auto, and make it default value. So if you set RAMTMP=yes you'll get tmpfs (whatever you set in fstab). But if you don't set it you'll get auto behavior. In general your option assumes that you need the maximum amount of free space in /tmp. That is simply not true. It should solve all the tmpfs problems listed in the thread and break nothing. That was the goal. In most cases a small /tmp is just peachy. In *some* cases I would say. But I see nothing good in a small /tmp for default debian users. :) Because of this it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. I assume that it's still possible to change default options. I.e. you're free to change RAMTMP and TMP_SIZE to your needs. Best I can come up with is that applications that need lots of space in /tmp, which are few, could check in postinst and give a debconf notice that /tmp should be resized One of those few applications is tar, used by mc. I can't suggest a proper tmpfs size for it. ;) Your option would make all my systems unbootable since / is read-only, includes /usr and has some GB free space. I considered that. I was just trying to keep description shorter and easier to understand. A more complete description would look like: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and checks `df /tmp/` for free space and partition 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 3.b. if RAMTMP != auto then print a warning 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 3.f. else RAMTMP == no 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space then RAMTMP=yes 5. if RAMTMP == yes then mount /tmp to tmpfs Maintainer will probably write a better code. PS: Have you thought about mount-binding /tmp to /home/tmp for your read-only root systems? Or your /home partition isn't local? -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEpy-zwzyKB7MYsGb=xCB6sBPAKD6uyDDVRF9GnrZ1=o...@mail.gmail.com
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: Hi, ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). I don't think this is that black and white indeed. In the case of unresponsive non-DD maintainer, obviously the Sponsors (having more powerful pedals and knobs than the sponsoree wrt to the archive) have several courses of action (in no particular order; various combinations are also possible): * step in and maintain the package themselves * ask for help, search for co-maintainers, etc * suggest orphanage * you name it and I guess this is a very basic, but fairly sufficient measure to handle the the case of run-away non-DD maintainers. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206011806.53799.danc...@spnet.net
Target path variables in debian/rules
I am building a package where I'm overriding the man page generation to
include man pages that are generated at build time. A simplified version
of the override in my debian/rules is:
override_dh_installman:
dh_installman --
/somepath/create-a-man-page ${mandir}/man1/packagename.1
However, I don't know how to specify the target path for the man pages,
which I've tentatively indicated by ${mandir} in the above snippet. I'm
not using autoconf, which seems to set some path variables.
What should I write instead of ${mandir} to get the proper path (so that
the entire path on my particular system becomes
debian/packagename/usr/share/man/man1/packagename.1)?
--
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf
smime.p7s
Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote: In general your option assumes that you need the maximum amount of free space in /tmp. That is simply not true. In most cases a small /tmp is just peachy. Because of this it is hard to set a minimum size where tmpfs would be too small to be usefull. For some user that would be 100MB, for others it is 100GB. /tmp is for temporary files, so I expect my /tmp to hold all these files, in my case DVD ISO images (downloaded or localy generated) that I will burn and then delete. So my /tmp is at least 20GB. BluRay users may need more. If this is not the meaning of /tmp, then rename it. Diskspace is cheap and easier to spare than my RAM. So, yes, if someone has one 3TB partition which is writeable, then /tmp belongs to disk not to RAM. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Starting services automatically after install
I'm trying to dig through the archives to see if this has been discussed,
and I'm only finding random one-off discussions here and there about it.
Nothing concrete. If it has already been discussed in great detail, my
apologies.
By default in Debian, when a service package is installed, such as
openssh-server, or isc-dhcp-server, it starts the service. This seems
counter-intuitive to me. I would think that the standard mode of practice
for installing and running a service would be as follows:
1. Install package
2. Configure service
3. Start service
Instead, I find myself doing a lot of:
1. Install package
2. Stop service
3. Configure service
4. Start service
I only bring this up, because I recently booted into a Debian Live 6.0.4
image, and found 32 (thirty-two!) services listening on external
interfaces, including port 6667! Further, ISC DHCP tried starting, although
it failed. Why is a DHCP server trying to start on a rescue tool?! Why is a
rescue tool running any services at all?! Especially ones listening on
external interfaces!
Anyay, that's off-topic. Just because I have installed a service package,
doesn't mean I want the service immediately running after installation. I
would like to spend the necessary time as an administrator to configure and
secure the service to my liking, before starting the service.
I would be interested in the opinions of the rest of the development
community on this, and why Debian handles services the way it does
currently. For comparison, Fedora and Red Hat Enterprise Linux do not start
a service after install. {Free,Open,Net}BSD start some, but never on
external interfaces. AFAIK, Arch Linux does not any services by default
after installation. . It seems that only Debian-based operating systems do.
Thanks,
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
--
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/20120601172242.ge12...@kratos.cocyt.us
Re: Maintainer responsible for or only doing maintenance?
On 12-06-01 at 11:21am, Petter Reinholdtsen wrote: [Jonas Smedegaard] Is my point clear now (even if is may disagree with my reasoning)? I find your point quite clear, but suspect you misunderstood those claiming the sponsor have responsibilities regarding package maintenance. To me it is obvious that the sponsor is also responsible for a package, when the maintainer become unresponsive or missing. When the maintainer is active and available, the sponsor do not have to step in and the responsibility is sleeping. :) The maintainer is responsible in the day to day maintenance, but when I sponsor packages I also keep in mind that I might end up having to care about the package some time in the future if the listed maintainer looses interest or disappears for other reasons. You seem to argue that this should not be the case. Is this because of your current sponsor practice, or is there some other experience behind your view on the responsibilities of a package sponsor in Debian? I do not mean to say that sponsors should not be held responsible for maintenance, just that such responsibility *currently* isn't obvious - as e.g. Bernd seems to argue - and that I find that problematic. I read Policy as defining Maintainer as _socially_ responsible entity, and Uploader as optional _sub-entity_ when Maintainer cannot also hold _technical_ responsibility. Sponsoring breaks that logic, but I believe we can restore it by treating sponsoring exactly the same as we do teamwork. Let me try to explain...: Once upon a time we had maintainers that maintained and was held responsible for that. Back then I found it sensible that the Maintainer: field was prominent throughout our tools - it was hardcoded into each source and binary package (not resolved through network queries via e.g. PTS web pages or who-uploads), and appears in e.g. aptitude. Today I find the Maintainer field a joke. In the future I would like Debian to again use the Maintainer field to indicate who is *responsible* for maintenance. So yes, this is tied to my sponsor practice: I don't do sponsoring (in the common sense of the term), but (when we cannot find a suitable existing team to join) form a two-person team with me as Maintainer and the non-Debian-member as Uploader. That makes only the Uploader field somewhat a joke, similar to how it commonly is for teamwork nowadays. In my opinion a person outside of the Debian WoT does not make sense as a Maintainer, exactly because failures go unnoticed: Sponsors ought to take responsibility but are not on display so if they forget (or even worse, don't care) then we may only discover it much later in frustrated threads like this one. Debian is not a company. We don't pay the work done in money, and don't fire people not performing well. Instead, Debian is a social organism where work is paid or punished by your name being prominently tied to your work. Problem is, if you are not hanging out in Debian social circles you don't feel the encouragement/pressure of your name on Debian billboards. And even if you do, others in Debian have trouble locating you, because you are not tied to our WoT. Please note that the reliability of the WoT is not the issue here - only the practicality of those email addresses being uniquely identifiable and cross-referenced in our structures so who is who is easily identifiable. Some may argue that I steal fame from the person doing the actual work on the package. I feel that I take fame (or shitstorm) of _responsibility_ of the package maintenance, and whoever doing the underlying _changes_ are documented in changelog. If my fellow unofficial maintainer later wants to apply for becoming DM or DD, proof of her/his actual contributions and skills in packaging is clearly tracked. I find sponsoring to be a hack, causing responsibility of maintenance to get blurred, with the consequence of packages going unmaintained too silently too easily. Also, I find that sonsoring is not needed: Anything done in sponsoring can be done by teamwork instead. Sure, for those sponsoring today feeling that their only responsibility is to _upload_ will feel that teaming up with the sponsoree instead is more responsibility - and that is exactly the point: sponsoring *is* more responsibility than just uploading, and today it is not clear, because we tag our sponsorees as maintainers even if in reality they (in my optic) cannot truly carry that role. I truly and sincerely hope that I am not stepping on the toes of non-Debian folks doing packaging work. That is absolutely not my intent - on the contrary I would want to make it more clear who is doing what and with which responsibility attached. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description:
Re: Moving /tmp to tmpfs makes it useless
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again, it is unnecessarily
rewritten to disk rather than just dropped. Thus, if you do multiple
read iterations through a large set of data (which does not fit in
memory) on tmpfs, each iteration does disk read AND write rather than
just read.
Linux certainly has a notion of cached swap, i.e. pages from swap that
are also unmodified in memory. As long as you have enough swap the
kernel should not reap the swapped data and know that it is already on
disk when it wants to evict the page.
I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated memory is not itself immediately swapped out and the file
should already be in swap from before.
The script below can be used to test the behavior. It creates a file,
then loops alternatively reading the file and allocating+freeing memory.
It's noteworthy that sometimes the read performance also drops over
iterations (maybe the swap layout becomes more fragmented?). I used the
given sizes for testing on a machine with 8 GiB memory. This load does
run faster on ext4 than tmpfs.
#!/usr/bin/python3
FILESIZE = 50
MEMSIZE = 65
FILENAME = '/tmp/alloctest'
from time import time
def main():
print(creating file)
t = time()
with open(FILENAME, 'wb') as f:
ss = FILESIZE
while ss:
s = min(ss, 100)
f.write(b'x' * s)
ss -= s
print(file creation time: %.1f % (time() - t))
i = 0
while 1:
print(iteration %d, reading file % i)
i += 1
t0 = time()
t = t0
with open(FILENAME, 'rb') as f:
while f.read(100):
pass
print(file read time: %.1f % (time()-t))
print(filling memory)
t = time()
s = b'x' * MEMSIZE
print(memory fill time: %.1f % (time()-t))
t = time()
b'aaa' in s
del s
print('memory read time: %.1f' % (time()-t))
print(total time: %.1f % (time()-t0))
print(press return for next iteration)
input()
main()
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1338571137.21597.28.camel@glyph.nonexistent.invalid
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-06-01 at 06:06pm, George Danchev wrote: On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: Hi, ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). I don't think this is that black and white indeed. In the case of unresponsive non-DD maintainer, obviously the Sponsors (having more powerful pedals and knobs than the sponsoree wrt to the archive) have several courses of action (in no particular order; various combinations are also possible): * step in and maintain the package themselves * ask for help, search for co-maintainers, etc * suggest orphanage * you name it and I guess this is a very basic, but fairly sufficient measure to handle the the case of run-away non-DD maintainers. Sorry if I am dense, but those pedals and knobs look like maintenance ones to me: Simply relabel the sponsor as maintainer as Scott (non-)proposes and it _is_ black and white to me. I am genuinely interested in understanding the reasons for labeling sponsoree rather than sponsor as maintainer. Could you (or anyone) elaborate on that? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Starting services automatically after install
Hi Aaron,
On 12-06-01 at 11:22am, Aaron Toponce wrote:
Just because I have installed a service package, doesn't mean I want
the service immediately running after installation. I would like to
spend the necessary time as an administrator to configure and secure
the service to my liking, before starting the service.
Debian goal is - as you probably know already - for packages to work out
of the box. For daemons this means they are started by default.
If a package (service or not) is insecure by default, it is a bug!
Severity of such bugs vary - e.g. some may consider it insecure for a
web server to publicly display a static page saying It works! while
most probably won't.
You can override the default of daemons using policy.d.
What I do for chroots - which you can adapt to your own personal needs,
is to install the package policyrcd-script-zg2 and add the attached
config file as /usr/local/sbin/policy-rc.d .
Hope that helps,
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
#!/bin/sh
# $Id: policy-rc.d,v 1.5 2007-01-16 09:59:43 jonas Exp $
#
# Copyright © 2006 Jonas Smedegaard d...@jones.dk
# Description: Suppress system V scripts if invoked within a chroot.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
# Policy-rc.d is mentioned in manpage invoke-rc.d(8) and documented at
# http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt
set -e
PRG=`basename $0`
TEMP=`getopt -s sh --long list,quiet -n $PRG -- $@`
if [ $? != 0 ] ; then echo Terminating... 2 ; exit 1 ; fi
eval set -- $TEMP
# Stolen from udev postinst
chrooted() {
if [ $(stat -c %d/%i /) = $(stat -Lc %d/%i /proc/1/root 2/dev/null) ];
then
# the devicenumber/inode pair of / is the same as that of /sbin/init's
# root, so we're *not* in a chroot and hence return false.
return 1
fi
return 0
}
quiet=
list=
while true ; do
case $1 in
--quiet) quiet=1 ; shift ;;
--list) list=1 ; shift ;;
--) shift ; break ;;
*) echo Internal error! ; exit 1 ;;
esac
done
initscript=$1
actions=$2
runlevel=$3
if [ $list ]; then
cat EOF
The following policies are known to this policy daemon:
default:All actions are allowed.
chroot: If invoked from within a chroot environment,
no actions are allowed, else all are allowed.
This policy daemon care not about actions, so all standard actions
(start, [force-]stop, restart, [force-]reload and status), and any
additionally implemented ones, are supported.
EOF
exit 0
fi
if chrooted; then
if ! [ $quiet ]; then
echo 2 Chroot environment detected, suppressing sysV script.
fi
exit 101
fi
exit 0
signature.asc
Description: Digital signature
Re: Starting services automatically after install
Aaron Toponce aaron.topo...@gmail.com writes:
I'm trying to dig through the archives to see if this has been discussed,
and I'm only finding random one-off discussions here and there about it.
Nothing concrete. If it has already been discussed in great detail, my
apologies.
It has -- repeatedly.
This is almost certainly going to result in a long and pointless thread,
to go with a long series of similarly long and pointless threads. *sigh*
I would be interested in the opinions of the rest of the development
community on this, and why Debian handles services the way it does
currently. For comparison, Fedora and Red Hat Enterprise Linux do not start
a service after install. {Free,Open,Net}BSD start some, but never on
external interfaces. AFAIK, Arch Linux does not any services by default
after installation. . It seems that only Debian-based operating
systems do.
The reason that RedHat don't start things is that their default approach
has been to install a whole load of stuff that you might possibly want,
and allow you to enable it when you are inspired to give some new
service a try.
The Debian approach has always been to not install anything that you
don't intend to use. It is also to ensure that if you do choose to
install something, it should be doing something useful by the end of the
install (if possible, security considerations allowing).
That is also why Debian and RedHat diverge when it comes to prompting
the user for configuration questions -- RedHat just want the software to
install, whereas Debian wants it to be useful, so may need to ask
questions.
It also leads to the fact that you can do major release upgrades of
Debian, whereas that's not really supported in RedHat, as chances are
your configuration is going to get trashed to some extent, and they
don't have the chance to ask you what you want to do about it.
Both approaches are valid, and are mostly a matter of taste. If you
are using a distribution that uses one assumption, it's not useful to
start introducing packages that work on the opposite assumption.
If you don't like the assumptions, you are much better off switching to
a distribution that you prefer, rather than trying to persuade the
overwhelming majority of the people that like the current assumptions,
and use Debian because of those assumptions, that they should change
their minds because they are supposedly wrong for liking it that way.
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
pgp2qZzklgqK0.pgp
Description: PGP signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 08:20:40AM +0200, Raphael Hertzog wrote: On Wed, 30 May 2012, Steve Langasek wrote: There is no excuse for hijacking a package, ever. If the maintainer is MIA, use the MIA process to get the package orphaned. This goes too far IMO. One of the reasons why the MIA process has been setup is because many DD fear forcibly taking over or forcibly orphaning a package. So instead of relying on random DD to do it, we put up some best practice procedure and a team to handle this. But this process is not set in stone, and if a DD believes that the best course of action is to orphan/take over a package, he should certainly be free to do it all by him/herself. Informing the MIA team for tracking purpose is still a good idea, though. So I should probably clarify, because I misspoke in my previous message. By MIA process I was not merely referring to the process used to determine that a Debian developer is MIA and should have their account expired; I was also referring to the longstanding process of discussing package orphaning on the QA mailing list, and having the QA team make a determination that a package is de facto maintainerless and should be orphaned. The important thing here is still that the decisions are made by consensus within the QA *team*, not as a decision by a single developer who decides to take over the package. This is an important check on developers deciding in the moment that their particular pet issue should trump our conventions. So no, I stand by my statement that an individual DD should not take it upon themselves to decide that a package should be orphaned. This sort of thing needs to be a community decision. On Thu, May 31, 2012 at 01:08:11PM +0100, Ian Jackson wrote: Steve Langasek writes (Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team): A hijack is, by definition, a declaration by the hijacker that they believe they are not answerable to the project's processes for how package maintenance is decided. It is antisocial vigilanteism and it is not acceptable. Our processes for how package maintenance is decided are utterly dysfunctional. If the TC had _ever_ voted to remove a maintainer who wanted to keep hold of a package, it might be at least reasonably possible to argue that the TC was the right forum for these disputes. As a sitting member of the Technical Committee, I encourage anyone who sees a package being hijacked to immediately bring it to the attention of the TC. I will without hesitation vote to have the hijacker barred from being made the maintainer of the package. Instead of this kind of aggressive approach to those who are IMO quite reasonably working around our dysfunctional formal processes, how about working towards fixing those dysfunctional processes ? I await with interest your suggestions for revising the way the TC deals with problematic maintainers. I have been arguing for years that we need a much more robust approach. Right, so the constitution says that it's the TC that decides whenever there's a question of maintainer. But in practice, when one of the would-be maintainers is not doing the work and not responding to email, I don't think there should be any need for the formal process of a TC vote. I think it's more than sufficient to get a consensus on the mailing list that the maintainer isn't coming back, *after* making an appropriate effort to contact the maintainer and waiting a suitable amount of time for a response. And indeed, this is the convention that's been in place for approximately the past decade on the debian-qa list. The key points of this process are: - It's not a decision by an individual that the package can be orphaned (and silence does not imply consent). - An effort is made to actively contact the maintainer on the subject of orphaning, rather than assuming the maintainer's non-interest based on the state of bugs. - The maintainer is given a suitable amount of time to respond. A week is not a suitably long waiting period. Indeed, the minimum waiting period here should *at minimum* be longer than the longest NMU waiting period. - The orphaning does *not* go ahead over the maintainer's objection. If the current maintainer objects, they should be persuaded by reasoning or the matter should be referred to the TC. This is very different from what some people mean when they use the word hijack. In part, I think we have a terminological problem here; I don't know if it's a matter of non-native speakers using the word differently, but the word hijack clearly refers to a /hostile act/. By definition, anything that could legitimately be called a hijack should not be permitted; and anything that we believe should be permitted should not be referred to as hijacking. Otherwise, people will infer that all kinds of inappropriate and hostile behavior is ok when it shouldn't be. And when people *do* engage in that
Re: Target path variables in debian/rules
Hi,
On Fri, Jun 1, 2012 at 12:33 PM, Ole Wolf o...@naturloven.dk wrote:
However, I don't know how to specify the target path for the man pages,
which I've tentatively indicated by ${mandir} in the above snippet. I'm
not using autoconf, which seems to set some path variables.
This may only be a partial help for you (you will still need to specify the
/usr/... etc stuff), but this is the method we use in the Debian Perl group
to build the path:
PACKAGE = $(shell dh_listpackages)
TMP = $(CURDIR)/debian/$(PACKAGE)
Using this method, you can substitute $(PACKAGE) for the package name,
which may make your rules file a little prettier...
Please see this page for this and other tricks:
http://pkg-perl.alioth.debian.org/debhelper.html#note_on_paths
Cheers,
Jonathan
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
]] Jonas Smedegaard Hiya, I am genuinely interested in understanding the reasons for labeling sponsoree rather than sponsor as maintainer. Could you (or anyone) elaborate on that? If I'm sponsoring a package, it means I've checked that its quality is good enough that I consider it a worthwhile addition to Debian. I'm not doing the actual maintenance, I'm reviewing parts of the maintenance being done, and so giving me the maintainership would be wrong. There's both the «who should you talk to about this package» as well as crediting the person who's doing the actual legwork. (I'm talking about what I do here, I'm not saying this is the one and only way to do sponsorship.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vg6olrq@xoog.err.no
Re: Starting services automatically after install
]] Jonas Smedegaard Hi Aaron, On 12-06-01 at 11:22am, Aaron Toponce wrote: Just because I have installed a service package, doesn't mean I want the service immediately running after installation. I would like to spend the necessary time as an administrator to configure and secure the service to my liking, before starting the service. Debian goal is - as you probably know already - for packages to work out of the box. For daemons this means they are started by default. The problem here is of course for those that really need a bit of configuration before they're usable. [...] You can override the default of daemons using policy.d. A problem with using policy-rc.d is you don't know whether a service is being started because it's the initial install or if it's because of an upgrade. I'll sometimes not want the service to start on initial installation (because chef is just about to plop its configuration into place), but if it's an upgrade, then please just restart the service. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nquolif@xoog.err.no
Re: Starting services automatically after install
On Freitag, 1. Juni 2012, Aaron Toponce wrote: I'm trying to dig through the archives to see if this has been discussed, #661496 and friends. -- 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/201206012211.58305.hol...@layer-acht.org
Re: Starting services automatically after install
Hi Tollef, On 12-06-01 at 09:55pm, Tollef Fog Heen wrote: ]] Jonas Smedegaard Hi Aaron, On 12-06-01 at 11:22am, Aaron Toponce wrote: Just because I have installed a service package, doesn't mean I want the service immediately running after installation. I would like to spend the necessary time as an administrator to configure and secure the service to my liking, before starting the service. Debian goal is - as you probably know already - for packages to work out of the box. For daemons this means they are started by default. The problem here is of course for those that really need a bit of configuration before they're usable. [...] You can override the default of daemons using policy.d. A problem with using policy-rc.d is you don't know whether a service is being started because it's the initial install or if it's because of an upgrade. I'll sometimes not want the service to start on initial installation (because chef is just about to plop its configuration into place), but if it's an upgrade, then please just restart the service. You could setup your local policy to check if the service exist in e.g. /etc/local-ok-services/ and then when you've customized or security-checked or whatever each service you do a touch /etc/local-ok-services/$service Or did I misunderstand? (We haven't spoken much in person, but I regard you as pretty clever so am surprised that you describe this as a problem and I feel it so simple to solve...) Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi, On Freitag, 1. Juni 2012, Steve Langasek wrote: [...] This is very different from what some people mean when they use the word hijack. In part, I think we have a terminological problem here; I don't know if it's a matter of non-native speakers using the word differently, but the word hijack clearly refers to a /hostile act/. By definition, anything that could legitimately be called a hijack should not be permitted; and anything that we believe should be permitted should not be referred to as hijacking. Otherwise, people will infer that all kinds of inappropriate and hostile behavior is ok when it shouldn't be. And when people *do* engage in that kind of hostile behavior, yes, I think it should be referred to the TC and we should disapprove of it. But when people are taking reasonable steps to confirm that a package is abandoned before taking it over - let's call this salvage - I have no problem with that; it should be encouraged and supported. thanks for explaining, makes completly sense to me now! :-) (And I do think it's partly a language issue. For non-native speakers hijack is probably a bit more romantic and less obviously evil 8-) cheers, Holger (And for those poor people (should they exist...) just reading my mail and not Steve's and thus having no idea what is ment with salvaging a package: go read Steve's mail.) -- 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/20120601.16740.hol...@layer-acht.org
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Fri, Jun 1, 2012 at 4:22 PM, Holger Levsen hol...@layer-acht.org wrote: Hi, On Freitag, 1. Juni 2012, Steve Langasek wrote: [...] This is very different from what some people mean when they use the word hijack. In part, I think we have a terminological problem here; I don't know if it's a matter of non-native speakers using the word differently, but the word hijack clearly refers to a /hostile act/. By definition, anything that could legitimately be called a hijack should not be permitted; and anything that we believe should be permitted should not be referred to as hijacking. Otherwise, people will infer that all kinds of inappropriate and hostile behavior is ok when it shouldn't be. And when people *do* engage in that kind of hostile behavior, yes, I think it should be referred to the TC and we should disapprove of it. But when people are taking reasonable steps to confirm that a package is abandoned before taking it over - let's call this salvage - I have no problem with that; it should be encouraged and supported. I kinda like Package reappropriation myself :) thanks for explaining, makes completly sense to me now! :-) (And I do think it's partly a language issue. For non-native speakers hijack is probably a bit more romantic and less obviously evil 8-) cheers, Holger (And for those poor people (should they exist...) just reading my mail and not Steve's and thus having no idea what is ment with salvaging a package: go read Steve's mail.) -- 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/20120601.16740.hol...@layer-acht.org -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/CAO6P2QS07EHUODXJ=RdudQDzqBz88=DvhA1ad=7xzwdmcbf...@mail.gmail.com
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote: Especially do I fail to understand why a member of the TC, who took part in such discussions before (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an example), and encouraged people to do so (that is how I understand the mentioned mail), So to be clear, no, I was not endorsing a hijacking of that package. My mail there was a response to an ill-considered defense of the current bacula maintainer at that time. I think I'm allowed to believe both that a package is not well-maintained, and that developers shouldn't take matters into their own hands to resolve such problems. The bacula package *was* in bad shape at that time, and something needed to be done. That doesn't mean the particular something that was done - starting a painful flamewar on debian-devel that led to the previous maintainer deciding to walk away from the package (i.e., voluntarily orphaning it after being demotivated) was the right thing to do. However, since the maintainer did walk away voluntarily, the TC didn't really have grounds to intervene... and probably wouldn't have sided with him anyway, so probably wouldn't have been less painful. Many of the earlier hijack mails on debian-devel also followed a very different process than the one described in the present thread (e.g., allowing an indeterminate amount of time, resulting in the original maintainer resuming maintenance of the package - https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted in amicable resolutions, with the previous maintainer explicitly approving the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html); or were intercepted by someone in the know, who diverted the hijack to an NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html). Unfortunately, it seems this has served as precedent, and the message people have taken away is that it's perfectly ok to hijack packages... when almost none of the hijacking statements have ever resulted in anything of the sort. is now on a killing spree. All he is doing is to encourage people to give up their idea to improve Debian. From hijacks to killing sprees... yes, I definitely think there's a language barrier of some kind here. ;) -- 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: Maintainer responsible for or only doing maintenance?
On 06/01/2012 05:19 PM, Russ Allbery wrote: I don't know if this is all explicitly written down anywhere, but it's certainly my feel of the general consensus and social expectations of the people who discuss this sort of thing on debian-mentors. I don't know if what you pretend is written somewhere, but at least I know one place where it's written the exact opposite of what you are claiming (it took me quite some time to remember where I read it...): http://wiki.debian.org/DebianMentorsFaq#What_if_I_upload_a_package.2C_and_then_my_mentee_disappears.3F And specifically: Having said that, this does create some extra work for people who decide to work on QA. Then later: maintainers and packages enter and exit Debian; it's part of a life cycle. It's okay to upload mentees' packages knowing that you risk going through an orphaning/adoption process later. So, here, we have the wiki page from mentors.debian.net (which is not authoritative, I admit) that says the exact opposite thing of what you are telling (it says that an unmaintained package would go to the QA team), and nothing in the policy or in the developer's reference that agree with you. Without taking any side, either you or the mentors.d.o wiki page is wrong. 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/4fc92921.4040...@debian.org
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
now that I notice the subject change I also notice the original subject... hi Thomas 8-) -- 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/201206012243.38011.hol...@layer-acht.org
Re: Starting services automatically after install
On 01.06.2012 19:22, Aaron Toponce wrote: By default in Debian, when a service package is installed, such as openssh-server, or isc-dhcp-server, it starts the service. This seems counter-intuitive to me. I would think that the standard mode of practice for installing and running a service would be as follows: There are some valid use cases why services should not be run automatically after installation. Historically, the information when to start a sysv service (start priority) was encoded in the update-rc.d call in the maintainer scripts. As a result, we've seen a lot of those dreadful /etc/default/service files with ENABLE/DISABLE flags. We do have quite a few services which ship such ENABLE=false default configuration. With the switch to dependency based boot and encoding the relevant information in the LSB header, it is much simpler to enable or disable a service. I think it would be great, if dh_installinit provided a new mode, where it adds the necessary start/stop calls to the maintainer scripts but ships the service disabled by default. I.e. the service would be disabled after the initial installation, the administrator configures and enables the service, and future updates ensure that the service is restarted on upgrades as is usually done. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Friday 01 June 2012 20:08:22 Jonas Smedegaard wrote: On 12-06-01 at 06:06pm, George Danchev wrote: On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: Hi, Hi, ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). I don't think this is that black and white indeed. In the case of unresponsive non-DD maintainer, obviously the Sponsors (having more powerful pedals and knobs than the sponsoree wrt to the archive) have several courses of action (in no particular order; various combinations are also possible): * step in and maintain the package themselves * ask for help, search for co-maintainers, etc * suggest orphanage * you name it and I guess this is a very basic, but fairly sufficient measure to handle the the case of run-away non-DD maintainers. Sorry if I am dense, but those pedals and knobs look like maintenance ones to me: Maintaining a package via long series of non-invasive NMUs does not declare maintainership (I meant pedals as in sponsors are able to upload without their sponsoree). It is just inconvenient for both the maintainers and the end users, and should be a temporal measure in the ideal case (and yes, I know we have packages in the archive effectively maintained via NMUs for many years). Simply relabel the sponsor as maintainer as Scott (non-)proposes and it _is_ black and white to me. I am genuinely interested in understanding the reasons for labeling sponsoree rather than sponsor as maintainer. Could you (or anyone) elaborate on that? Maintainer field is meaningless, it is very meaningful. Why not just think of it this way (hopefully this could make you sleep better :) - If a Maintainer field points to a non-DD entity and that entity disappears from the horizon, then a DD-entity (the Sponsor [1], the Safeguard if you want) should do something meaningful to help to resolve the situation. This is not to say that the DD-entity (the Sponsor) is then allowed to perform hostile acts and all sorts of unlawful interferences (e.g. a hijacks) in the terms of the Debian normative docs. [1] http://udd.debian.org/sponsorstats.cgi -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206012309.57302.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 01.06.2012 21:49, Tollef Fog Heen wrote: ]] Jonas Smedegaard Hiya, I am genuinely interested in understanding the reasons for labeling sponsoree rather than sponsor as maintainer. Could you (or anyone) elaborate on that? If I'm sponsoring a package, it means I've checked that its quality is good enough that I consider it a worthwhile addition to Debian. I'm not doing the actual maintenance, I'm reviewing parts of the maintenance being done, and so giving me the maintainership would be wrong. There's both the «who should you talk to about this package» as well as crediting the person who's doing the actual legwork. Nod. This is basically the same I do when sponsoring a package. I carefully review the package before the upload and that's about it. I don't keep track of bugs that are filed against this package nor do I start maintaining it / feel responsible for it. If my upload fucked up other packages or created a mess in an ongoing transition, then of course I would feel responsible sorting this out together with the maintainer. But in the usual case a sponsored upload is a one-time thing ( I do have regular sponsoree's though) Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Moving /tmp to tmpfs makes it useless
On 01/06/12 13:33, Goswin von Brederlow wrote: I don't know the ultimate reason behind this ugly behaviour of Linux when the swapping process is happening, but I know this is real and it happens because I have experimented this situation myself more than a couple of times. It's a matter of that gets swapped and linux choosing the wrong thing to swap (far too often). There is some bug in linux that when you have lots and lots of IO at some point the swap heuristics tip over and start swapping apps and usefull data to create more cache space for IO. Doesn't matter that you already have 3GB for cache, it still swaps out your mouse cursor and then things go real bad. This makes sense. Many times I have experimented this situation while copying a large file from a quick device (hdd) to a very slow device (cheap usb stick) IMHO The logical way of behaving in such situation is to slow-down the IO bandwidth of the processes that are filling the cache, by sending to sleep any process that requests more IO while the cache is full instead of trying to free RAM by swapping out things from the RAM to the swap. Do you know any way to avoid (or mitigate) this? Perhaps some sysctl variable? Can't Linux be configured to just block (sleep) any process that requests IO while the cache is full? Perhaps a good idea would be to limit the cache size on a per-PID basis and block (sleep) the pid while its cache is full. Thanks! Best regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: Target path variables in debian/rules
Jonathan, fre, 01 06 2012 kl. 15:36 -0400, skrev Jonathan Yu: This may only be a partial help for you (you will still need to specify the /usr/... etc stuff), but this is the method we use in the Debian Perl group to build the path: PACKAGE = $(shell dh_listpackages) TMP = $(CURDIR)/debian/$(PACKAGE) Using this method, you can substitute $(PACKAGE) for the package name, which may make your rules file a little prettier... Thanks! It turns out I wasn't entirely off then, because in my original rules file I used $(CURDIR) and a hard-coded package name. The $(shell dh_listpackages) adds some additional generality, but I was actually thinking that there might be some further generalization options that might even eliminate the directory structure. That is, although man pages currently go to /usr/share/man/man?/.+[0-8](.gz)?, somehow I thought some MANDIR or similar variable would be more appropriate. Still, I'm glad to learn it's Debian kosher to hard-code the paths. -- Ole Wolf Rødhættevej 4 • 9400 Nørresundby Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf smime.p7s Description: S/MIME cryptographic signature
Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote: Q: /tmp on tmpfs increases apps performance. A: What apps? Real apps don't write files during performance-critical operations. Even if they do, they write large files. And large files are written faster when they're written on real disk, rather then swapped out and slow down the entire system (see the Who uses /tmp part). The apps that can really benefit from tmpfs are too rare. And we're talking about default settings and most common cases. OK, some benchmarks were requested in this thread in a few places. Can't find them again since they got lost in the volume of mail. I resisted doing any so far because I didn't feel that they would be particularly informative, and also because the results would be fairly predictable, and additionally because while tmpfs /can/ improve performance, it's only one of the reasons why we might want to use it. Summary These tests were all performed on current unstable using a core2 quad core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and Btrfs internally using RAID1 over 2 1TiB partitions. The system has 8 GiB RAM and 16 GiB swap, and a 4.8 GiB tmpfs on /tmp (using the experimental initscripts default of 20%VM). For all results, n=20 with error ± SEMean. Stats were done in R. 5 passes were performed before recording data to ensure consistency. 1) Checkout of several tags in a git repository tmpfs 11.17s ± 0.05s ext4 18.51s ± 0.60s btrfs 15.81s ± 0.29s 2) Building a package (sysvinit) tmpfs 20.08s ± 0.03s ext4 21.08s ± 0.03s btrfs 20.52s ± 0.03s 3) Unpacking of a large zip file tmpfs 12.45s ± 0.01s ext4 19.69s ± 0.52s btrfs 12.79s ± 0.32s 4) Unpacking of large uncompressed tarfile tmpfs 1.16s ± 0.00s ext4 17.61s ± 0.41s btrfs 5.12s ± 0.20s So the outcome is fairly obvious. I/O bound jobs perform superbly on tmpfs; in examples 3 and 4, the times are for how long it takes to unpack 1.2 GiB of data. Without the overhead of uncompression, making it largely CPU bound, tmpfs is the fastest by far. The package build is a combination of both I/O and CPU bound jobs, so the differences aren't so big, while git is more I/O bound, again showing tmpfs to be faster. So if you're doing a lot of I/O, tmpfs is unquestionably faster. If you're almost entirely CPU bound, the benefit is marginal, but still measurable. If you're doing a mixture, you do see some benefit, but you'll need to profile your specific case to determine exactly how much. Now, these are just four simple tests. They deliberately use hot caches, using several warm up runs to ensure that. No unnecessary swapping or disc activity should occur. If you have a system which is swapping, of course the tmpfs performance will drop, just as if you have a lot of filesystem I/O, the I/O performance will also drop. These are rather harder to test accurately and consistently, so I haven't done this at present. If anyone wants to, feel free. The other caveat is that due to the use of hot caches, and lack of explicit fsyncs, this will actually artifically inflate the performance of the disc-based filesystems in the common case, since all of the data being processed is in the buffer/page cache. It's only measuring writes. So for most workloads, the performance of tmpfs is most likely much better than reported here (by a factor of at least two, probably quite a bit more). These could be added; again, if anyone wants to do that, please feel free. Regards, Roger Methods and results 1) checkout of git repository #!/bin/sh set -e for pass in $(seq 1 5); do sh -c for tag in v3.0 v3.1 v3.2 v3.3 v3.4; do git checkout \\$tag\; done done for pass in $(seq 1 20); do /usr/bin/time -f '%e' -a -o $1 \ sh -c for tag in v3.0 v3.1 v3.2 v3.3 v3.4; do git checkout \\$tag\; done done d tmpfs ext4 btrfs 1 11.31 22.42 17.15 2 11.30 22.13 15.35 3 11.04 19.63 15.46 4 11.24 19.12 15.51 5 11.50 18.00 14.96 6 11.01 22.55 15.15 7 11.17 16.29 15.11 8 11.04 23.57 17.42 9 11.20 15.21 15.17 10 11.68 18.20 15.86 11 10.74 17.81 15.22 12 11.30 18.25 15.43 13 10.96 21.94 15.43 14 10.80 14.61 20.39 15 11.27 15.34 14.99 16 11.28 18.04 16.46 17 11.65 17.35 15.53 18 10.97 16.46 15.16 19 10.79 16.73 15.51 20 11.22 16.46 14.91 sapply(d, mean) tmpfsext4 btrfs 11.1735 18.5055 15.8085 sapply(d, semean) tmpfs ext4 btrfs 0.0583243 0.6044565 0.2855330 2) Building a package (sysvinit) #!/bin/sh set -e for pass in $(seq 1 5); do sh -c dpkg-buildpackage -us -uc done for pass in $(seq 1 20); do /usr/bin/time -f '%e' -a -o $1 \ sh -c dpkg-buildpackage -us -uc done sb tmpfs ext4 btrfs 1 20.11 21.06 20.56 2 20.13 21.28 20.58 3 20.15 20.90 20.46 4 19.82 21.01 20.52 5 19.94 21.03 20.83 6 20.06 21.09 20.43 7 20.06 21.19 20.48 8 19.94 20.82 20.38 9 20.16 21.00 20.29 10 20.03 21.16 20.48 11
Re: Target path variables in debian/rules
On Fri, 01 Jun 2012 23:37:16 +0200, Ole Wolf wrote: PACKAGE = $(shell dh_listpackages) TMP = $(CURDIR)/debian/$(PACKAGE) Using this method, you can substitute $(PACKAGE) for the package name, which may make your rules file a little prettier... Thanks! It turns out I wasn't entirely off then, because in my original rules file I used $(CURDIR) and a hard-coded package name. :) The $(shell dh_listpackages) adds some additional generality, but I was actually thinking that there might be some further generalization options that might even eliminate the directory structure. That is, although man pages currently go to /usr/share/man/man?/.+[0-8](.gz)?, somehow I thought some MANDIR or similar variable would be more appropriate. Still, I'm glad to learn it's Debian kosher to hard-code the paths. That's fine, yes. If you'd like to avoid the paths in debian/rules, you could also do something like: 1) create the manpage in d/rules and save it under debian/: override_dh_auto_build: dh_auto_build /script/to/create/manpage $(CURDIR)/debian/manpage.1 2) let dh_installman install it: echo debian/manpage.1 debian/package.manpages 3) make sure the generated manpage gets removed during clean: echo debian/manpage.1 debian/clean More complicated than just writing it into the temporary $(CURDIR)/debian/$(PACKAGE)/... path during build, but also works and makes debian/rules shorter. Cheers, gregor, who prefers the first option -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones: Lastime signature.asc Description: Digital signature
Bug#675528: ITP: ocl-icd -- Generic OpenCL ICD Loader
Package: wnpp Severity: wishlist Owner: Vincent Danjean vdanj...@debian.org [ opencl-headers maintainers, please read until the end of this ITP ] * Package name: ocl-icd Version : 1.0 beta2 Upstream Author : Brice Videau brice.vid...@imag.fr * URL : http://forge.imag.fr/projects/ocl-icd/ * License : BSD Programming Lang: C Description : Generic OpenCL ICD Loader This source package will provide two binary pakages: Package: ocl-icd-libopencl1 Description: Generic OpenCL ICD Loader OpenCL (Open Computing Language) is a multivendor open standard for general-purpose parallel programming of heterogeneous systems that include CPUs, GPUs and other processors. . This package contains an installable client driver loader (ICD Loader) library that can be used to load any (free or non-free) installable client driver (ICD) for OpenCL. It acts as a demultiplexer so several ICD can be installed and used together. Package: ocl-icd-dev Description: Development files to build a ICD Loader OpenCL (Open Computing Language) is a multivendor open standard for general-purpose parallel programming of heterogeneous systems that include CPUs, GPUs and other processors. . This package provides a header file that allows a OpenCL implementation to build a installable client driver (ICD). With a ICD, an OpenCL implementation can be used by any OpenCL program without the need to link the program to the specific OpenCL implementation. A few word about the context. There exist lots of OpenCL implementations. A OpenCL program can either link to a specific OpenCL implementation or it can link to a standardized libOpenCL library that allows the program to dynamically choose the OpenCL implementation or even to use several OpenCL implementations in the same program. In fact libOpenCL is only a wrapper (more exactly a dispatcher) to OpenCL implementations provided as ICD. ocl-icd is the only one (to my knowledge) free implementation of such a ICD Loader. The main difficulty to implement it is that all compatible ICD must provide a structure filled with OpenCL function pointers, but there is no free documentation about the order of these functions. So ocl-icd sources include tools to help to find this order from closed-sources OpenCL implementations (by creating a fake OpenCL ICD and letting the closed-source ICD Loader execute the faked functions). Once the order is found, it is registered into a database. Vendors ensure between them that functions are always at the same place so the database is only filled when a new closed-source ICD Loader uses more functions. Entries in the database are never modified nor removed. ocl-icd also provides a header file declaring this structure of function pointers so that any OpenCL implementation will be easily able to provide an ICD. The goal is to add such an ICD to free OpenCL implementation such as LIBCLC or clover. The Debian package will only use the database (ocl_interface.yaml in the sources), so it will not have any non-free dependencies. However, it needs opencl-headers that are currently in contrib. This is why I would ask opencl-headers maintainers to reconsider the place of opencl-headers. If I understand correctly, opencl-headers have been uploaded to contrib because their only use case would be to compile an OpenCL program for a closed-source OpenCL implementation (mainly amd or nvidia). Now, opencl-headers is required to compile this free ICD Loader. And this free ICD Loader has all what is needed to compile a free ICD from free OpenCL implementation. So, is it possible to upload opencl-headers to main instead of contrib? Regards, Vincent PS: a preliminary package is on my repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120601223811.15142.94880.report...@eyak.imag.fr
Re: Orphaning php-codesniffer, then take it over by the PHP PEARteam
Steve Langasek wrote: On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote: Especially do I fail to understand why a member of the TC, who took part in such discussions before (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an example), and encouraged people to do so (that is how I understand the mentioned mail), So to be clear, no, I was not endorsing a hijacking of that package. My The bacula package *was* in bad shape at that time, and something needed to be done. That doesn't mean the particular something that was done - starting a painful flamewar on debian-devel that led to the previous maintainer deciding to walk away from the package (i.e., voluntarily orphaning it after being demotivated) was the right thing to do. However, since the maintainer did walk away voluntarily, the TC didn't really have grounds to intervene... and probably wouldn't have sided with him anyway, so probably wouldn't have been less painful. I don't think the outcome can be accurately described as voluntarily orphaning it after being demotivated. He didn't really orphan it; he only gave up trying to get it back after it had already been hijacked and he could not find sponsors to upload his competing version. Many of the earlier hijack mails on debian-devel also followed a very different process than the one described in the present thread (e.g., allowing an indeterminate amount of time, resulting in the original maintainer resuming maintenance of the package - https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted The linked-to mail does not show such a resolution; changelog shows that the original maintainer made one more upload, there was one NMU, and then the would-be hijacker took over the package anyway. in amicable resolutions, with the previous maintainer explicitly approving the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html); or were intercepted by someone in the know, who diverted the hijack to an NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html). Unfortunately, it seems this has served as precedent, and the message people have taken away is that it's perfectly ok to hijack packages... when almost none of the hijacking statements have ever resulted in anything of the sort. In 3 of those 4 cases the maintainer did change. I think making extra bureaucracy a hard requirement would likely have a negative total effect, due to some desirable takeovers like the Bacula one not happening at all as a result. is now on a killing spree. All he is doing is to encourage people to give up their idea to improve Debian. From hijacks to killing sprees... yes, I definitely think there's a language barrier of some kind here. ;) You seem to think it's a contradiction to both use a term with negative connotations such as hijack to describe an action and to say that the action is the right thing to do. I don't consider it contradictory. The word hijack acknowledges that it is a controversial action, one which you should expect to defend, and which perhaps wouldn't be required in an ideal world. But it can still be the best choice in practice. -- 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/1338591082.21597.51.camel@glyph.nonexistent.invalid
Re: Moving /tmp to tmpfs makes it useless
On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote: On 01/06/12 13:33, Goswin von Brederlow wrote: I don't know the ultimate reason behind this ugly behaviour of Linux when the swapping process is happening, but I know this is real and it happens because I have experimented this situation myself more than a couple of times. It's a matter of that gets swapped and linux choosing the wrong thing to swap (far too often). There is some bug in linux that when you have lots and lots of IO at some point the swap heuristics tip over and start swapping apps and usefull data to create more cache space for IO. Doesn't matter that you already have 3GB for cache, it still swaps out your mouse cursor and then things go real bad. This makes sense. Many times I have experimented this situation while copying a large file from a quick device (hdd) to a very slow device (cheap usb stick) IMHO The logical way of behaving in such situation is to slow-down the IO bandwidth of the processes that are filling the cache, by sending to sleep any process that requests more IO while the cache is full instead of trying to free RAM by swapping out things from the RAM to the swap. Do you know any way to avoid (or mitigate) this? Perhaps some sysctl variable? Can't Linux be configured to just block (sleep) any process that requests IO while the cache is full? Perhaps a good idea would be to limit the cache size on a per-PID basis and block (sleep) the pid while its cache is full. I don't think it makes any sense to have a hard per-process limit. Also, it's not generally possible to account dirty pages to specific processes exactly. But I think you will be pleased with this change that was included in Linux 3.2: http://lwn.net/Articles/456904/ 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/20120602000140.ge20...@decadent.org.uk
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On June 1, 2012 10:00:52 AM Serge wrote: ... I considered that. I was just trying to keep description shorter and easier to understand. A more complete description would look like: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and checks `df /tmp/` for free space and partition 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 3.b. if RAMTMP != auto then print a warning 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 3.f. else RAMTMP == no 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space then RAMTMP=yes 5. if RAMTMP == yes then mount /tmp to tmpfs Maintainer will probably write a better code. Much better... if TMPTIME != 0 it will be necessary to mount the FS based /tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, then mount --bind the tmpfs on /tmp. Keeping track of whether /tmp was FS or tmpfs based when the system last shutdown could be used to skip all that since RAMTMP=yes implies TMPTIME=0 regardless of the setting in /etc/default/rcS. - Bruce -- 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/201206011934.18503.bms...@shaw.ca
Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
Hi Mike, I have been trying to get hold of Patrick too, and succeeded in getting hold of him ~ 1 day ago. He's still active, just very busy. I hope to get a longer chat with him over the coming days with respect to lmms specifically, but I'll mention this discussion too. -- Regards, Miah -Original Message- From: Bart Martens ba...@debian.org To: Mike Gabriel mike.gabr...@das-netzwerkteam.de Cc: debian-devel@lists.debian.org, win...@debian.org Subject: Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o) Date: Fri, 1 Jun 2012 04:29:38 + Mailer: Mutt/1.5.20 (2009-06-14) On Thu, May 31, 2012 at 09:19:37PM +0200, Mike Gabriel wrote: Dear all, I have been trying to contact Patrick Winnertz (winnie-at-d.o). I would like to see iTalc in Debian upgraded to 2.0 Relevant bug report from 3 September 2011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640200 but Patrick is neither replying to contact attempts via mail (Debian Edu mailing list, directly), nor to contact attempts via IRC. My first attempt to reach him is about 3-4 weeks ago. That is a good reason to have a look at the MIA database. Recent upload: http://lists.debian.org/debian-devel-changes/2012/04/msg01990.html Recent message on list: http://lists.debian.org/debian-wnpp/2012/05/msg00180.html So Patrick Winnertz is not MIA. Earlier this year Patrick handed over the maintenance of slbackup / slbackup-php to me. This last contact was via IRC. Has anyone heard from him, recently? If so, can you give him note to get in contact with me (or the Debian Edu team)? If I do not hear from anyone on debian-devel@l.d.o within a week, I will contact the MIA team and request orphanage of italc. I'm not sure but I don't think that the MIA team would orphan italc, because Patrick Winnertz is not MIA. It would be nice to get some feedback from Patrick Winnertz about this. First priority is to fix the FTBFS bug 671489. If you intend to update italc to the newest upstream release, then please retitle bug 672636 to an intention to NMU. Regards, Bart Martens -- 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/1338602555.5940.3.ca...@thinkpad3.darksilence.net
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 06/02/2012 04:43 AM, Holger Levsen wrote: now that I notice the subject change I also notice the original subject... hi Thomas 8-) LOL ! I'm amazed that it's seems I'm capable of creating huge uncontrollable threads out of nowhere (eg: this isn't the first time). I swear its never intended ! :) 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/4fc98a24.3020...@debian.org
Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
Hi all, thanks to all those who replied to my search quest. I got hold of Winnie as well and things are in flow. Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de - Original message - Hi Mike, I have been trying to get hold of Patrick too, and succeeded in getting hold of him ~ 1 day ago. He's still active, just very busy. I hope to get a longer chat with him over the coming days with respect to lmms specifically, but I'll mention this discussion too. -- Regards, Miah -Original Message- From: Bart Martens ba...@debian.org To: Mike Gabriel mike.gabr...@das-netzwerkteam.de Cc: debian-devel@lists.debian.org, win...@debian.org Subject: Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o) Date: Fri, 1 Jun 2012 04:29:38 + Mailer: Mutt/1.5.20 (2009-06-14) On Thu, May 31, 2012 at 09:19:37PM +0200, Mike Gabriel wrote: Dear all, I have been trying to contact Patrick Winnertz (winnie-at-d.o). I would like to see iTalc in Debian upgraded to 2.0 Relevant bug report from 3 September 2011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640200 but Patrick is neither replying to contact attempts via mail (Debian Edu mailing list, directly), nor to contact attempts via IRC. My first attempt to reach him is about 3-4 weeks ago. That is a good reason to have a look at the MIA database. Recent upload: http://lists.debian.org/debian-devel-changes/2012/04/msg01990.html Recent message on list: http://lists.debian.org/debian-wnpp/2012/05/msg00180.html So Patrick Winnertz is not MIA. Earlier this year Patrick handed over the maintenance of slbackup / slbackup-php to me. This last contact was via IRC. Has anyone heard from him, recently? If so, can you give him note to get in contact with me (or the Debian Edu team)? If I do not hear from anyone on debian-devel@l.d.o within a week, I will contact the MIA team and request orphanage of italc. I'm not sure but I don't think that the MIA team would orphan italc, because Patrick Winnertz is not MIA. It would be nice to get some feedback from Patrick Winnertz about this. First priority is to fix the FTBFS bug 671489. If you intend to update italc to the newest upstream release, then please retitle bug 672636 to an intention to NMU. Regards, Bart Martens -- 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/1338610890.1455.2.camel@Nokia-N900
Accepted stealth 2.03.00-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 31 May 2012 22:15:50 -0700 Source: stealth Binary: stealth stealth-doc Architecture: source amd64 all Version: 2.03.00-1 Distribution: unstable Urgency: low Maintainer: Frank B. Brokken f.b.brok...@rug.nl Changed-By: tony mancill tmanc...@debian.org Description: stealth- stealthy File Integrity Checker stealth-doc - stealthy File Integrity Checker Changes: stealth (2.03.00-1) unstable; urgency=low . [ Frank B. Brokken ] * New upstream release depends on Bobcat 3.01.00 . [ tony mancill ] * d/compat set to 8 Checksums-Sha1: db3c7e57d81ecb9485a45d206bfcf14a9a4bfcf6 2168 stealth_2.03.00-1.dsc 9d4b20dd6cd183b45eac977412e17d262143f30a 237613 stealth_2.03.00.orig.tar.gz 085caa37459cec18402f07ee9253918a5449cc14 8911 stealth_2.03.00-1.debian.tar.gz eb2b7dce6fbd2a3ca6522555db38ee80b7cc3a2a 84616 stealth_2.03.00-1_amd64.deb 8837a00056873e1febac60a136b088cb1cf09d7b 419112 stealth-doc_2.03.00-1_all.deb Checksums-Sha256: a19218f94f04a3a168e3461c6674a34ce6f8b1cbba94bb1a96172341f94e7fdd 2168 stealth_2.03.00-1.dsc 2cf435906dcb4c06bf44539ed6a7765eb4a80ae60207c57be4aa6849b0a3432f 237613 stealth_2.03.00.orig.tar.gz 3f7515ac1e89de450d061a68ff2568eb760687b7858fa2a58ebaf00e9075fce6 8911 stealth_2.03.00-1.debian.tar.gz 10d24e01ce026bf0a7d686b24c769559e509dec3abe4d27ab4e52a72c70e3190 84616 stealth_2.03.00-1_amd64.deb 49c77cc2404dae64f2ce8a7d7d1b69033d7e2c24c3972f8c8bd8d360a0bb71c8 419112 stealth-doc_2.03.00-1_all.deb Files: 502372cc3a9b5aec3c7df1e0057b0849 2168 admin optional stealth_2.03.00-1.dsc df623a467ecd92e68be63c9212cde781 237613 admin optional stealth_2.03.00.orig.tar.gz a2ebe0b63ef90c9fd6a7071db0ff78d2 8911 admin optional stealth_2.03.00-1.debian.tar.gz 4bbefac1468961ea2bcb11d50c6ad5b9 84616 admin optional stealth_2.03.00-1_amd64.deb 48bf4924988f74996bcc133cf46f9ed7 419112 doc optional stealth-doc_2.03.00-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJPyFdFAAoJECHSBYmXSz6WI4UP/0ZHvur+4P0WBE5iprrBnHYw SYBeTR3hywzpBmbpMQB9Wwv+HpekH0kp3LoZ33+Y2mRbgt2yz0HfRVrEBPfh5+z+ KLpuE7R0Hty1kVvZ8VpzsPj8eSrtEWAfZ901ffHRvNLtcPrMb4U19OC6Qf7aiOCA 66rfkZZkIgJyDr4LN5y7J45WVy4lvFJOvZZomyVlngvDbmHAfodFiaPLkzOVOiOC jGD8wiaZck/IefLyPguJEbzTuHW1vOIJbDqxZW7vSepBCZtcYTuIwQlJlNoPO6qz HB7OUgiiv32Iz/XZp7csh7hJ885vqAmlD1+B0WC7TlHBz+Ix8rr7hP5lLszHYi11 WVcwn/LW2HLDGjKnqdZ5OVWkHGmagH0Oi1WyfTk95yVDW76Ixg29UWM35zWu8MbK 4dHunLQbq+sEbtWReUa58u3/OSUWgWxhd2Rm7bsOl3B1W195nF5+3KiwelWe3d5b DOIEbrPOJ5UXP79XpIIcN3Y2VthhMo2nvjd7hxLagRUHiZXxMMCOuylbFmKV+ImB RVMcq5JnyJCOwOl5otb90yPJb/W9B+Et0vOwJmOOFKeTxkAHMzVRoG5Fd3xE2QCF UMlJu9N/5gO0qPY82NBkjsneSW8KgERlD1Okpn6NHF4ERmg1a/JLd6m6FEicQIaO cBxMrXRQqdyvQL8MPGRs =15rk -END PGP SIGNATURE- Accepted: stealth-doc_2.03.00-1_all.deb to main/s/stealth/stealth-doc_2.03.00-1_all.deb stealth_2.03.00-1.debian.tar.gz to main/s/stealth/stealth_2.03.00-1.debian.tar.gz stealth_2.03.00-1.dsc to main/s/stealth/stealth_2.03.00-1.dsc stealth_2.03.00-1_amd64.deb to main/s/stealth/stealth_2.03.00-1_amd64.deb stealth_2.03.00.orig.tar.gz to main/s/stealth/stealth_2.03.00.orig.tar.gz -- 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/e1sakwz-0007ah...@franck.debian.org
Accepted ruby-heckle 1.4.3-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 19 May 2012 17:52:59 -0500 Source: ruby-heckle Binary: ruby-heckle libheckle-ruby1.8 libheckle-ruby Architecture: source all Version: 1.4.3-3 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Gunnar Wolf gw...@debian.org Description: libheckle-ruby - Transitional package for ruby-heckle libheckle-ruby1.8 - Transitional package for ruby-heckle ruby-heckle - Mutation tester (unit test sadism(tm)/test pentester) for Ruby Changes: ruby-heckle (1.4.3-3) unstable; urgency=low . [ Cédric Boutillier ] * Repackaged using the gem2deb infrastructure . [ Gunnar Wolf ] * Make the package build only for Ruby 1.8, as it depends on ruby-parsetree. FWIW, using ruby-sourcify was attempted, but it's not a complete enough replacement. Checksums-Sha1: 6f5371b441da2b5e3c8afc362d04d9604be978e2 2244 ruby-heckle_1.4.3-3.dsc 4d26af03c99330451e9358c900376e426288d3fa 16885 ruby-heckle_1.4.3.orig.tar.gz 94ee4ea293589bf71bf50da00f8ec073cdb6385e 5391 ruby-heckle_1.4.3-3.debian.tar.gz ab0def8f82ce65f4242e3fab8530d7c0eff26c47 15744 ruby-heckle_1.4.3-3_all.deb f611508d017044b2a2153342bba6bb78783e37e6 4486 libheckle-ruby1.8_1.4.3-3_all.deb 6f2eafbe24ac3717506ae51251931c0e1883c6ca 4472 libheckle-ruby_1.4.3-3_all.deb Checksums-Sha256: 310781e9ca82115ba3692918aeba9614ce37c7d1da889be3eb6692fb97917cb7 2244 ruby-heckle_1.4.3-3.dsc 103c372f091f1622f70b4c146ffc4f42496787332f5a16c4ec0abe2b7d8c9ee5 16885 ruby-heckle_1.4.3.orig.tar.gz 24820a41f62ab238d939f89c6a3262975e417f88e969a9a2727b57dc69083181 5391 ruby-heckle_1.4.3-3.debian.tar.gz bab82f688ff1761797e2f179098e4bb736ac1f6c20a7e405b7e0770ee5b5d80c 15744 ruby-heckle_1.4.3-3_all.deb 2c1e3ee83b453369ec4ce5869ad4df51acae257e9908c922739fbe0fdfbec932 4486 libheckle-ruby1.8_1.4.3-3_all.deb 39ac42d47bc2d45ccdd14c1328a4bc2f05f2cf548bb8cb2c88ae301f1396ee9b 4472 libheckle-ruby_1.4.3-3_all.deb Files: d9c2008186a522786cfe7438b1891b7c 2244 ruby optional ruby-heckle_1.4.3-3.dsc 05543acdef603a1cbf13710a4268740a 16885 ruby optional ruby-heckle_1.4.3.orig.tar.gz 3ad5ce0c23f00a6524b438848a563f7e 5391 ruby optional ruby-heckle_1.4.3-3.debian.tar.gz bde83c0eb4364ac241514db8c2fe856b 15744 ruby optional ruby-heckle_1.4.3-3_all.deb 21b5ce35fc41e7c77a7651d8b0517546 4486 oldlibs extra libheckle-ruby1.8_1.4.3-3_all.deb c3180f6cbb183b11145872dfbb9770cd 4472 oldlibs extra libheckle-ruby_1.4.3-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPxOETAAoJEGc6A+TB25IfbHkQAKxATwKVqvCu2lPGsTPViWB8 6vM75crWlfZPEbAflyn/6625zXTaqSNbk8nfowbkWXJEJ+OnFvGPAb9Y8lqo8QsW 250uc2cQgdVy0Hy+MZxmnzhEqeuXIwFyra3mvCasTj1As0hHTP5hVjngXVYTSzYy G0aUs8iNYaXq4qVXSh/JJUqtOxCBxB7zpy+c3+qn0w09e2ewuAC6lOqrh+QwcR0N b7H1XtuBY6oClZ0MqgJsQxyf2F/E/rhJiigBfbX1jGAp+NHb+EnKXE7/j9PoxOo7 Q23JCx9VDV0nNy4h79FoxZLOkMOExsK6g9b88eI7WkCAhf4ONJyAMhcAh2mYBHtn 8KSysgEwJa5tYIMfVXrfQVFbEYHqD/OPokTTAz4r11clbcgZhakqWHjpTXRzvg2B ddtQX70GvJaHw5k05KcNF4OxrGPNuFG5hkGrJdHjWNfDlPsqfJ2Nt+kfTbUGntQR FS9Yn/z/GlRWwzfWHE0ap9V0psa0h2StJcUg8ob/8Z2PKPeR4uDzmLnBfjFoGOLr k7JIlhtzQ95K2+2n3Uyq4JfcllVZ8MwIf8I5EPXQhJ4lGe8kvC4XKd4yOJ77kpRD urrkOeUxbP+6OC2L6mCZVziZ4Ns7qe44fLWohYrKW/VcrXX7aUi2uhSbx9hDJGEp 925cUrilyepF2LgvzAzw =v+MK -END PGP SIGNATURE- Accepted: libheckle-ruby1.8_1.4.3-3_all.deb to main/r/ruby-heckle/libheckle-ruby1.8_1.4.3-3_all.deb libheckle-ruby_1.4.3-3_all.deb to main/r/ruby-heckle/libheckle-ruby_1.4.3-3_all.deb ruby-heckle_1.4.3-3.debian.tar.gz to main/r/ruby-heckle/ruby-heckle_1.4.3-3.debian.tar.gz ruby-heckle_1.4.3-3.dsc to main/r/ruby-heckle/ruby-heckle_1.4.3-3.dsc ruby-heckle_1.4.3-3_all.deb to main/r/ruby-heckle/ruby-heckle_1.4.3-3_all.deb ruby-heckle_1.4.3.orig.tar.gz to main/r/ruby-heckle/ruby-heckle_1.4.3.orig.tar.gz -- 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/e1saldf-vw...@franck.debian.org
Accepted ruby-ihelp 0.4.5-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 17:08:18 +0200 Source: ruby-ihelp Binary: ruby-ihelp libihelp-ruby libihelp-ruby1.8 Architecture: source all Version: 0.4.5-3 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Paul van Tilburg pau...@debian.org Description: libihelp-ruby - Transitional package for ruby-ihelp libihelp-ruby1.8 - Transitional package for ruby-ihelp ruby-ihelp - Ruby console contextual help Changes: ruby-ihelp (0.4.5-3) unstable; urgency=low . * Source packages adapted according to the new Ruby policy: - Build for ruby1.8 only; the ruby1.9.1 RI driver API is too different. - Migrated to pkg-ruby-extras git repos. Changed the Vcs-* fields in debian/control accordingly. - Changed the depends and recommends to follow the new Ruby library naming scheme. * debian/control: - Added a default DM-Upload-Allowed field set to yes. - Standards-Version bumped to 3.9.3; no changes required. - Set XS-Ruby-Versions to ruby1.8. - Added the homepage. - Changed the build-depends for using gem2deb instead of ruby-pkg-tools. - Switched the maintainer with the uploaders field as per new convention the team is the default maintainer. - Added libihelp-ruby and libihelp-ruby1.8 as transitional packages. - Added a recommend on ruby-ferret (needed for full text search). * debian/copyright: reworked to fit the Debian copyright format version 1.0. * debian/patches: added remove_rubygems.patch. * debian/ruby-ihelp.doc-base: register the generated RDoc documenation. * debian/ruby-ihelp.docs: install the README and TODO files. * debian/ruby-ihelp.manpages: renamed file from libihelp-ruby1.8.manpages. * debian/source/lintian-overrides: added overrides for the descriptions of the transitional packages. Checksums-Sha1: c59562d16cafafb1afd76f87d0abdef0da654399 1495 ruby-ihelp_0.4.5-3.dsc 28e7921aa0ba2c5e53a35aaf42df9573e67abee1 19218 ruby-ihelp_0.4.5.orig.tar.gz 5b3f6d67266454b22b59cfba86baf82e24d0a9d0 5409 ruby-ihelp_0.4.5-3.debian.tar.gz d51abac1c4c3cf240eb8350c6814acd0e021cd8d 39492 ruby-ihelp_0.4.5-3_all.deb 7202d4c04e830c527da554646339aa418418c0b7 3962 libihelp-ruby_0.4.5-3_all.deb 404a5ea778797355509f4004d2402a61d00baee7 3958 libihelp-ruby1.8_0.4.5-3_all.deb Checksums-Sha256: fee80c3b23903bfec51ddfcf92d7f32df3ca1f61fd9696fc24746a8fc166638e 1495 ruby-ihelp_0.4.5-3.dsc 78e50c8d892c6a65627e587c62caa9788abb8f7d7044066341156acf68d96677 19218 ruby-ihelp_0.4.5.orig.tar.gz eafaf518137b6a06f060fe927520d038202683de0bf8f545d0f449aace51 5409 ruby-ihelp_0.4.5-3.debian.tar.gz 577c4fde7a1e1081f4ca777500394c4d95414f62bbaeb3c3a1fa848a64cc2052 39492 ruby-ihelp_0.4.5-3_all.deb 6ef987cbaf05e5993e6a5bf9882cee2a94fab86f391635bb6c272ae8a2b97d5c 3962 libihelp-ruby_0.4.5-3_all.deb 288d76fba148ba4d9a8b532a7795ee0e2aae69a24e02dfd1655d97792a083083 3958 libihelp-ruby1.8_0.4.5-3_all.deb Files: bce877b6c6f849a6cce9a9e16b1f1ba4 1495 ruby optional ruby-ihelp_0.4.5-3.dsc 266c55939d6b171b08fb9aa2910e42bc 19218 ruby optional ruby-ihelp_0.4.5.orig.tar.gz bc12c66e4350998c9344df3dc27da25e 5409 ruby optional ruby-ihelp_0.4.5-3.debian.tar.gz 502cea675ea1ad759a70627c6df4b272 39492 ruby optional ruby-ihelp_0.4.5-3_all.deb 280505a15cdd02a38b57ee5773e98eb4 3962 oldlibs extra libihelp-ruby_0.4.5-3_all.deb 2ba3282143880284a24bc68cac3ce727 3958 oldlibs extra libihelp-ruby1.8_0.4.5-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/E7H4ACgkQJBBhylAGQYGk3gCdFFXA6S/jrmSktoNk5GS48pqX 4hUAnjoSMgDBmvSA03BOMaaQvvcWBB5P =ncZ/ -END PGP SIGNATURE- Accepted: libihelp-ruby1.8_0.4.5-3_all.deb to main/r/ruby-ihelp/libihelp-ruby1.8_0.4.5-3_all.deb libihelp-ruby_0.4.5-3_all.deb to main/r/ruby-ihelp/libihelp-ruby_0.4.5-3_all.deb ruby-ihelp_0.4.5-3.debian.tar.gz to main/r/ruby-ihelp/ruby-ihelp_0.4.5-3.debian.tar.gz ruby-ihelp_0.4.5-3.dsc to main/r/ruby-ihelp/ruby-ihelp_0.4.5-3.dsc ruby-ihelp_0.4.5-3_all.deb to main/r/ruby-ihelp/ruby-ihelp_0.4.5-3_all.deb ruby-ihelp_0.4.5.orig.tar.gz to main/r/ruby-ihelp/ruby-ihelp_0.4.5.orig.tar.gz -- 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/e1saldt-00010w...@franck.debian.org
Accepted ruby-innate 2012.03-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 01:40:56 +0200 Source: ruby-innate Binary: ruby-innate libinnate-ruby1.8 libinnate-ruby1.9.1 libinnate-ruby Architecture: source all Version: 2012.03-1 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Cédric Boutillier cedric.boutill...@gmail.com Description: libinnate-ruby - Transitional package for ruby-innate libinnate-ruby1.8 - Transitional package for ruby-innate libinnate-ruby1.9.1 - Transitional package for ruby-innate ruby-innate - core web-framework part of Ramaze Changes: ruby-innate (2012.03-1) unstable; urgency=low . * New upstream release. * Add myself to Uploaders: * Bump Standards-Versions: to 3.9.3 (nothing particular) * Transition to the new Ruby policy + renaming source and binary packages + using gem2deb packaging tool * Convert copyright file to DEP-5 copyright-format/1.0 * Override lintian warning about duplicate description of transitional packages Checksums-Sha1: 037c10f508e66f897cb7d2d60a8ae1b068ae7c93 1680 ruby-innate_2012.03-1.dsc 8399e379c4b8e4480e3120246849d9d7dea453b7 104075 ruby-innate_2012.03.orig.tar.gz d94c4b4418b85d99ab0731ed55054d76d20d66ec 3928 ruby-innate_2012.03-1.debian.tar.gz 04fa68e47bf8b2f565d29fdf3f3a2720c887e7e8 84776 ruby-innate_2012.03-1_all.deb 54e8acf68c2d336abc3f06cb593542872eda4f1f 31006 libinnate-ruby1.8_2012.03-1_all.deb a229c25558fbf83bb2d1f88ee1fc042cf44c904a 31008 libinnate-ruby1.9.1_2012.03-1_all.deb 538dbcc541ae2171b6126a5e3048be36069ee9de 31000 libinnate-ruby_2012.03-1_all.deb Checksums-Sha256: 474caf6cfb0bfd8dbba6e4f08afe834e22bab4042fe7a939cee76a593def8b9a 1680 ruby-innate_2012.03-1.dsc ee4a6b957487e0dcd19d177c8b0930ca1efe1039918848e89bd725128a91999b 104075 ruby-innate_2012.03.orig.tar.gz 5da57fb2dbdcd990ef6f9a65061cd9e85ca27835f5343ee04f5498e180e7357f 3928 ruby-innate_2012.03-1.debian.tar.gz 277a8a08f24659a7812de557d9cc4bdc6c4ecef0fc63a5fb6a4b101aab0fe1f9 84776 ruby-innate_2012.03-1_all.deb 053c8885a443e7e6a002cbeb27091bed3993ab54c3963d592f98ecaffb97be0c 31006 libinnate-ruby1.8_2012.03-1_all.deb 278196955afab3632e1210bf1b1019bb6280c39068dbb52406701f5df75a70d9 31008 libinnate-ruby1.9.1_2012.03-1_all.deb 8e6c2e269e42cb43f4bc53886f531a0bd60713beff7a7fabe501847a3a4caf50 31000 libinnate-ruby_2012.03-1_all.deb Files: b04136a97606b9331cc694386d340b1d 1680 ruby optional ruby-innate_2012.03-1.dsc b85fc0f23118eb3f16b3ebe08fd792bb 104075 ruby optional ruby-innate_2012.03.orig.tar.gz 4765137ef2c195323ec89b16aaf2b644 3928 ruby optional ruby-innate_2012.03-1.debian.tar.gz d30581cfe8e55f1a8d62ea3e4dfa0842 84776 ruby optional ruby-innate_2012.03-1_all.deb f51de33bd267b28c82711e294a53e2ca 31006 oldlibs extra libinnate-ruby1.8_2012.03-1_all.deb f12cea8b67fa5f6866dab3fee126700f 31008 oldlibs extra libinnate-ruby1.9.1_2012.03-1_all.deb fa15397704d68acd1c885fa6e25dd169 31000 oldlibs extra libinnate-ruby_2012.03-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/E0P8ACgkQJBBhylAGQYGgxQCgi8EzsURm21IFDHhhMFge23Ha 270AoJXrQ2seN5D//rw9FofLV1Z5AHw5 =0lMT -END PGP SIGNATURE- Accepted: libinnate-ruby1.8_2012.03-1_all.deb to main/r/ruby-innate/libinnate-ruby1.8_2012.03-1_all.deb libinnate-ruby1.9.1_2012.03-1_all.deb to main/r/ruby-innate/libinnate-ruby1.9.1_2012.03-1_all.deb libinnate-ruby_2012.03-1_all.deb to main/r/ruby-innate/libinnate-ruby_2012.03-1_all.deb ruby-innate_2012.03-1.debian.tar.gz to main/r/ruby-innate/ruby-innate_2012.03-1.debian.tar.gz ruby-innate_2012.03-1.dsc to main/r/ruby-innate/ruby-innate_2012.03-1.dsc ruby-innate_2012.03-1_all.deb to main/r/ruby-innate/ruby-innate_2012.03-1_all.deb ruby-innate_2012.03.orig.tar.gz to main/r/ruby-innate/ruby-innate_2012.03.orig.tar.gz -- 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/e1sale5-00011u...@franck.debian.org
Accepted ruby-zoom 0.4.1-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 22:16:35 +0200 Source: ruby-zoom Binary: ruby-zoom libzoom-ruby libzoom-ruby1.8 Architecture: source amd64 all Version: 0.4.1-3 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Paul van Tilburg pau...@debian.org Description: libzoom-ruby - Transitional package for ruby-zoom libzoom-ruby1.8 - Transitional package for ruby-zoom ruby-zoom - Ruby/ZOOM provides a Ruby binding to the Z40.50 Object-Orientatio Changes: ruby-zoom (0.4.1-3) unstable; urgency=low . * Source packages adapted according to the new Ruby policy: - Build for ruby1.8 only; extension needs to be ported to ruby1.9.1. - Migrated to pkg-ruby-extras git repos. Changed the Vcs-* fields in debian/control accordingly. - Changed the depends and recommends to follow the new Ruby library naming scheme. * debian/control: - Added a default DM-Upload-Allowed field set to yes. - Standards-Version bumped to 3.9.3; no changes required. - Set XS-Ruby-Versions to ruby1.8. - Changed the build-depends for using gem2deb instead of ruby-pkg-tools. - Switched the maintainer with the uploaders field as per new convention the team is the default maintainer. - Added libzoom-ruby and libzoom-ruby1.8 as transitional packages. - Added build-depends on rake and ruby-test-unit for running the test suite. * debian/copyright: reworked to fit the Debian copyright format version 1.0. * debian/patches: added fix_assert_in_test.patch. * debian/ruby-tests.rake: derived test suite from Rakefile. * debian/ruby-zoom.docs: renamed from libzoom-ruby1.8.docs. * debian/ruby-zoom.examples: renamed from libzoom-ruby1.8.examples. * debian/source/lintian-overrides: added overrides for the descriptions of the transitional packages. Checksums-Sha1: 025868444669ae7e290f9dab3145feef19e1 1593 ruby-zoom_0.4.1-3.dsc 51d7e274ecf129a5af45b43846ef14d6ada972a1 20745 ruby-zoom_0.4.1.orig.tar.gz 6f424bc1eb601290b6a94d649340f0621ab94ede 3195 ruby-zoom_0.4.1-3.debian.tar.gz a689cf344a17bd5f586feda53b9e987bca19f290 17516 ruby-zoom_0.4.1-3_amd64.deb 6721115daffad6f25551bfebc875438036e90c59 4226 libzoom-ruby_0.4.1-3_all.deb e185700dd3d62a21b10529a59bd78865caed752a 4236 libzoom-ruby1.8_0.4.1-3_all.deb Checksums-Sha256: 799473ef1f785eddec7a3ab2eea02ea7a549dd9faa39743d3a5f83b1ae4e7d7e 1593 ruby-zoom_0.4.1-3.dsc e59748f47a32b1e735c0098e45acef60567fe710183ad1add32792478440 20745 ruby-zoom_0.4.1.orig.tar.gz 80e53cb3e431b30bad7a9e156e643ab3f52b17ce7e35f1b3584cd08d214a0d24 3195 ruby-zoom_0.4.1-3.debian.tar.gz 40781d4a8832faafe9f3e67e8bc2a9463e22dd829cc298d1018845ca838c4575 17516 ruby-zoom_0.4.1-3_amd64.deb f322f8449bfb2ec221e6a5dbc0f0ce1a2430206abf3b27b25e4c0e109ad09dd5 4226 libzoom-ruby_0.4.1-3_all.deb ded4c5bad96383a05908bee2d68338f704f1f143c3f19cfa7eaa17c34188f681 4236 libzoom-ruby1.8_0.4.1-3_all.deb Files: 01eb16769dd986656c62d2651af432bf 1593 ruby optional ruby-zoom_0.4.1-3.dsc 5ff771b628329a4c564cea1597ee66df 20745 ruby optional ruby-zoom_0.4.1.orig.tar.gz be150001ff67cd18e50828e5b2e86201 3195 ruby optional ruby-zoom_0.4.1-3.debian.tar.gz 9ee23d48909eea478273ff350e05649b 17516 ruby optional ruby-zoom_0.4.1-3_amd64.deb f61dcc2421cfd4e793c6fbf677424683 4226 oldlibs extra libzoom-ruby_0.4.1-3_all.deb f189abe37f16cc284b28fcf227f4ed60 4236 oldlibs extra libzoom-ruby1.8_0.4.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/FL54ACgkQJBBhylAGQYFE4QCdG/6pbjiBVCTtKZnK4Ntjst1n 960AnjuVSiat2/8bwGKfYGTmKo9dOziA =3hSh -END PGP SIGNATURE- Accepted: libzoom-ruby1.8_0.4.1-3_all.deb to main/r/ruby-zoom/libzoom-ruby1.8_0.4.1-3_all.deb libzoom-ruby_0.4.1-3_all.deb to main/r/ruby-zoom/libzoom-ruby_0.4.1-3_all.deb ruby-zoom_0.4.1-3.debian.tar.gz to main/r/ruby-zoom/ruby-zoom_0.4.1-3.debian.tar.gz ruby-zoom_0.4.1-3.dsc to main/r/ruby-zoom/ruby-zoom_0.4.1-3.dsc ruby-zoom_0.4.1-3_amd64.deb to main/r/ruby-zoom/ruby-zoom_0.4.1-3_amd64.deb ruby-zoom_0.4.1.orig.tar.gz to main/r/ruby-zoom/ruby-zoom_0.4.1.orig.tar.gz -- 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/e1saleh-00012t...@franck.debian.org
Accepted abyss 1.3.4-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 01 Jun 2012 08:38:29 +0200 Source: abyss Binary: abyss Architecture: source amd64 Version: 1.3.4-2 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org Changed-By: Andreas Tille ti...@debian.org Description: abyss - de novo, parallel, sequence assembler for short reads Changes: abyss (1.3.4-2) unstable; urgency=low . * Team upload * debian/upstream: BibTeX compliant authors Checksums-Sha1: e6f0b723580651bbfc2194bcebbba72d6b7aa04c 1408 abyss_1.3.4-2.dsc 882cba2db2c7aebed6d0ac77f0080092d4f6e257 9334 abyss_1.3.4-2.debian.tar.gz 5fae46fb79fb9ce5cc1f90f5c960140973bc5eff 1751468 abyss_1.3.4-2_amd64.deb Checksums-Sha256: a8be57f7f186855b14b448b34524591b8f3bb57d7147b6408aaad7636cab9b5e 1408 abyss_1.3.4-2.dsc 18e874d30fd43198d4e138a0ae571c049766faca544b8dd9feba743da90422a7 9334 abyss_1.3.4-2.debian.tar.gz fd86b8aa2526df1a961f14bd8263e9396b15c36f41da6e34fd31e079cfa968ff 1751468 abyss_1.3.4-2_amd64.deb Files: f43a06aa26f1cdbc4c2e51fb66db2f79 1408 non-free/science optional abyss_1.3.4-2.dsc a3c95212207476cfb218fd47f5fa87c2 9334 non-free/science optional abyss_1.3.4-2.debian.tar.gz 9a2f58beac6aaad23eb89ce936e05936 1751468 non-free/science optional abyss_1.3.4-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/IZHQACgkQYDBbMcCf01rF1ACghQqv+LVpEGa3gHipn8zrhiYe hWYAnRS4iXhDioc+29P/u6+YMf2gWeT1 =rhMH -END PGP SIGNATURE- Accepted: abyss_1.3.4-2.debian.tar.gz to non-free/a/abyss/abyss_1.3.4-2.debian.tar.gz abyss_1.3.4-2.dsc to non-free/a/abyss/abyss_1.3.4-2.dsc abyss_1.3.4-2_amd64.deb to non-free/a/abyss/abyss_1.3.4-2_amd64.deb -- 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/e1salew-00019s...@franck.debian.org
Accepted wine 1.4-0.3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 22 May 2012 01:08:10 -0400 Source: wine Binary: wine wine-bin libwine-dbg libwine-dev libwine libwine-alsa libwine-bin libwine-capi libwine-cms libwine-gl libwine-gphoto2 libwine-ldap libwine-openal libwine-oss libwine-print libwine-sane Architecture: source amd64 Version: 1.4-0.3 Distribution: experimental Urgency: low Maintainer: Debian Wine Party pkg-wine-pa...@lists.alioth.debian.org Changed-By: Michael Gilbert mgilb...@debian.org Description: libwine- Windows API implementation - library libwine-alsa - Windows API implementation - ALSA sound module libwine-bin - Windows API implementation - system services libwine-capi - Windows API implementation - ISDN module libwine-cms - Windows API implementation - color management module libwine-dbg - Windows API implementation - debugging symbols libwine-dev - Windows API implementation - development files libwine-gl - Windows API implementation - OpenGL module libwine-gphoto2 - Windows API implementation - camera module libwine-ldap - Windows API implementation - LDAP module libwine-openal - Windows API implementation - OpenAL module libwine-oss - Windows API implementation - OSS sound module libwine-print - Windows API implementation - printing module libwine-sane - Windows API implementation - scanner module wine - Windows API implementation - standard suite wine-bin - Windows API implementation - binary loader Changes: wine (1.4-0.3) experimental; urgency=low . * non-maintainer upload * fix wine-gecko symlink Checksums-Sha1: 845663617857d603258e85634bdc5e2d1b90fb2b 5056 wine_1.4-0.3.dsc c2886eb21ee1b0be9d07c2030e7b939c7ab06fa5 71811 wine_1.4-0.3.diff.gz 2711eef6eab9251c5dc5ab4b6457967d93fc1c2c 1544 wine_1.4-0.3_amd64.deb b3b0bddebc1e37f839027b40720aeebfbd041665 52816 wine-bin_1.4-0.3_amd64.deb 6cfd20a9046e372eda7276e9193c18978fdf61d7 45117102 libwine-dbg_1.4-0.3_amd64.deb 545bb018077ef45aca2f550e75773eb2af5b0274 5087842 libwine-dev_1.4-0.3_amd64.deb 6a19863f272dc6e02da44d6909087ae08c6bd7e1 16576794 libwine_1.4-0.3_amd64.deb 1f052449842ae3ef2987d9b549d9fab0dde00223 48828 libwine-alsa_1.4-0.3_amd64.deb 069503caa8deb0e7308f87000d367fdd13f301ed 2823262 libwine-bin_1.4-0.3_amd64.deb 39436daf1a78862deffc03348ce18cb268f75928 6466 libwine-capi_1.4-0.3_amd64.deb 72d4ba77bab2c46f4c71bc8857e8ea35c387c75f 23952 libwine-cms_1.4-0.3_amd64.deb 19f41004865a65e0c4fae80ecd55ed91b35685e7 782552 libwine-gl_1.4-0.3_amd64.deb 3c1a6cbfeaf4e6b7c276a854128a5fa611b8e576 17760 libwine-gphoto2_1.4-0.3_amd64.deb ed052bd50c0fecbeb8ee2e9ff3a35d0226cc87dc 111052 libwine-ldap_1.4-0.3_amd64.deb acef55b5d07b8026b721abf00274d64d08a6bd4d 16844 libwine-openal_1.4-0.3_amd64.deb b3b5ea63fce39c53b93ae7ad6598ccf218092d8d 49896 libwine-oss_1.4-0.3_amd64.deb e828e34622aeed565b972efd4ab20ae54d5a2e67 119616 libwine-print_1.4-0.3_amd64.deb 20d3b73c21fd8593c9d731fb9b83b35e6f04cc0d 26256 libwine-sane_1.4-0.3_amd64.deb Checksums-Sha256: efb50c844d13914d9f2be8b9083bf0bfe23f74a11659753dc56b51581f8a6908 5056 wine_1.4-0.3.dsc 3806bf14aa0ac6b95a4e47baee85fe2b28f7d7724aa3d1f57e70fb66700ae0ab 71811 wine_1.4-0.3.diff.gz 8350c3f43f9a6ce476f80fa109e1c3eb2f8a68ae190d280fbcb82763c254cfed 1544 wine_1.4-0.3_amd64.deb 065e10f65580a35158aeba42bf4abb3ea3179ae4317052efcb308808c5d82e22 52816 wine-bin_1.4-0.3_amd64.deb ad389698f1016f6a3b61d0dd3d2f1e6cc0916c8e02aaa395878057a7c425d6e3 45117102 libwine-dbg_1.4-0.3_amd64.deb b82100681b2bbee585332fe312493f7e9f0d176190309761d53b157097eb146c 5087842 libwine-dev_1.4-0.3_amd64.deb dd2d567c3c53299db3a06967baae7f728ac9e79eb1beb7beb6af23a7ff7b3aa0 16576794 libwine_1.4-0.3_amd64.deb 665b667e55279571117a0543d772b18432c1677788117c28d53bc3546b639298 48828 libwine-alsa_1.4-0.3_amd64.deb 1c56a2341f8ad653f8384cf97dd01455a83e9279686a41b39062f18e842d3baf 2823262 libwine-bin_1.4-0.3_amd64.deb 8e3c800669beb0457492f6d5dc00d5c422257fede356eef05e3f36c36f3b06fd 6466 libwine-capi_1.4-0.3_amd64.deb 43c140b67bfc471a8e2397f1acce5a2386fbc130a87e1a7cdde6d41ae5829bda 23952 libwine-cms_1.4-0.3_amd64.deb 84876ee50ecf01cb9cc175eec538f325e67a0cd4564082105583fe5249125d3b 782552 libwine-gl_1.4-0.3_amd64.deb e5788952820b5ff479bb8bad6cf231c72c46a4accb439082f5c895d8ed8c7434 17760 libwine-gphoto2_1.4-0.3_amd64.deb b32679d601409487aa7f4789c6c3a12b7ed330bf098ec35caa57ceb71c4ac33f 111052 libwine-ldap_1.4-0.3_amd64.deb 0611e0648610cbb5b09c4113932ffabe2d439db0d61bcc401cfad17376c68613 16844 libwine-openal_1.4-0.3_amd64.deb 8d652b3cfe090c8c5b09ae742ce2928ed198e79b40011f642e0e0258005d3012 49896 libwine-oss_1.4-0.3_amd64.deb c1b4206929ecfbc720a889be992cf1848bd8a1d07bb2fcc82fd9447005e654d1 119616 libwine-print_1.4-0.3_amd64.deb b9033c79284224767db103cec522673480963fa04e8f958a2d5128c70f862b32 26256 libwine-sane_1.4-0.3_amd64.deb Files: e7cd885c238b029b3c5c1a4720da1835 5056 otherosfs optional wine_1.4-0.3.dsc 3601b069a433ba6009b620ea94c9c51c 71811 otherosfs
Accepted apper 0.7.2-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 22 May 2012 10:45:24 +0200 Source: apper Binary: apper apper-appsetup apper-data apper-dbg Architecture: source amd64 all Version: 0.7.2-1 Distribution: unstable Urgency: low Maintainer: Matthias Klumpp matth...@tenstral.net Changed-By: Matthias Klumpp matth...@tenstral.net Description: apper - KDE package management tool using PackageKit apper-appsetup - Extended Listaller support for Apper apper-data - KDE package management tool using PackageKit (data files) apper-dbg - Debugging symbols for Apper Changes: apper (0.7.2-1) unstable; urgency=low . * New upstream release: 0.7.2 - Automatic Refresh Cache properly fixed - Initial Listaller support (optional) - Supported filter added (depends on the backend) - KDED plugin runs on a separate thread to avoid desktop freezes - Fixed updating packages that were on untrusted repos - Fresh manual pages (thanks to Matthias) - Many other bug- and Krazy fixes * Updated debian/copyright * Switch to compat-level 9 * Updated watch file * Split out arch-indep apper-data package * Add apper-appsetup package for Listaller modules * Remove old replacement for KPackageKit: No longer required * Removed manpages: Pages are upstream now * Override lintian false-positive about icon-sizes * Allow DM upload Checksums-Sha1: f1ff5e457f9279ec33bbf223ee9fdaf03320e502 2224 apper_0.7.2-1.dsc 610f7b22e311fa2e0c9b5c8c01196d3e52111e4a 2355017 apper_0.7.2.orig.tar.bz2 3f315f20b65d2b694b7452ffb3bb6d0f095bbec9 4232 apper_0.7.2-1.debian.tar.gz 9eeccc202d4bebb3eff4be33f611fa1b1ecf2c5f 341228 apper_0.7.2-1_amd64.deb 5f0e73f6e55e4806debd89041c877d89e0a2f583 25684 apper-appsetup_0.7.2-1_amd64.deb 0099dc1bcf30e1f835a52f80783e8e4ab4782cc5 1038452 apper-data_0.7.2-1_all.deb 5987b347c7bf6cc218e1408ff9cb728a8010e61f 6396396 apper-dbg_0.7.2-1_amd64.deb Checksums-Sha256: ec9a832e3fd8f818b3a62e2a8cc3087555d0cff5112ae346ee37ae9248546712 2224 apper_0.7.2-1.dsc 975fede728e7ab96d8e244ae721a2e15ae40b9fb1cd189a1f4afd46c400b219f 2355017 apper_0.7.2.orig.tar.bz2 53972df47293ddc8a0dc48d87f95a4775f2bb7445949b66886c12cee1b1a1204 4232 apper_0.7.2-1.debian.tar.gz d16625289f164e8f1a7d4e38a1c1d354b6868f5aea4cfa195ccf48db16bd388f 341228 apper_0.7.2-1_amd64.deb 79e7298a21d9cccfe060646dff55d08e11d6777829b30fc2b58c19831cbc06d9 25684 apper-appsetup_0.7.2-1_amd64.deb 656d66d50dc9fc15fd906032767e440e7f38eec8c9c7521671f524a7267d0e40 1038452 apper-data_0.7.2-1_all.deb 9dde0d5dc9a92290138df56b756a44766d2b56d2d84f791733d6fc79c25aee38 6396396 apper-dbg_0.7.2-1_amd64.deb Files: cbcc5a4ed7e029570af6d96263d51e46 2224 kde optional apper_0.7.2-1.dsc 1be14e90327a55325226dffcd07a42fd 2355017 kde optional apper_0.7.2.orig.tar.bz2 6c89d1c6054ce4c39f97a0f111f59ede 4232 kde optional apper_0.7.2-1.debian.tar.gz a796b0558b9df2c80d45cdf13126ff2d 341228 kde optional apper_0.7.2-1_amd64.deb 7b0d4e91228a0a141b3b08ccb92cb7af 25684 kde optional apper-appsetup_0.7.2-1_amd64.deb 98f15eaf3a81d40c552f17a01ed32677 1038452 kde optional apper-data_0.7.2-1_all.deb d05874f52ac6bdf52ca4c84fee4a11b6 6396396 debug extra apper-dbg_0.7.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPxB02AAoJEGT+wHBUdj6byB4P/3PofqdXjT5eRR0rpxx0HrUI 1WjfgRB2BcDWE1d6uLLs2pGjdPZXCA2xPilus5Zg9SLTuw4Og3qy5m+70DfqjeUQ /HWxBQ/WzmCr+AymEk1msxrPlofuYzj+0oJC/K8XwkmXXee/uNYWfoP/dcscZKck 7oqJz5jo8Y5LintMV2qXwQQPfupzzaytfVKAkb0lXAwyV0Zs0R0f8PyDYxAAhQr0 1ynGYYqHMH1+DbZ6NWUeE3fGYOAZNhAkOV8LzlZvGNqtQPhmAtYaI4euVqX/6j/d hzQQa3Q9T7RoNbvXZpz6NfFgwXrN7PB6zBj1UgmAan5uL0pygcWCaniS8owKoBr0 0QdHwvZXwTU0iVYBIhna1JEwy32ygQ3Gm8zKtbFHUkQFC3NRUWwV+VQLs6UkHmxg d7q8y4VSAiGLum+WB9EBUFmD/J5gocWwTOAaIkSHBC1VsXASK8vYRIXbjCe9YafF PJQwLZuBC5benZT84ALMpaCbZ9I5/7TwQVPc8Z3aKi7kvgvZjtt8jJN7oPkuEIJM XbnyLxvSTSQBZVaVgtF1nsxMlxJULCfFLWZnmfWZx13zEtmhq7fv/gxTuat6hIeN raY22z3hpLDnSZ91S3oXktyCJvto6K/qydx5yVBzC/wRnxajB0IjG6nGOP2B3hv8 /FaDtys0/eFtwv2LlYK4 =Rsr+ -END PGP SIGNATURE- Accepted: apper-appsetup_0.7.2-1_amd64.deb to main/a/apper/apper-appsetup_0.7.2-1_amd64.deb apper-data_0.7.2-1_all.deb to main/a/apper/apper-data_0.7.2-1_all.deb apper-dbg_0.7.2-1_amd64.deb to main/a/apper/apper-dbg_0.7.2-1_amd64.deb apper_0.7.2-1.debian.tar.gz to main/a/apper/apper_0.7.2-1.debian.tar.gz apper_0.7.2-1.dsc to main/a/apper/apper_0.7.2-1.dsc apper_0.7.2-1_amd64.deb to main/a/apper/apper_0.7.2-1_amd64.deb apper_0.7.2.orig.tar.bz2 to main/a/apper/apper_0.7.2.orig.tar.bz2 -- 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/e1sals9-0002yu...@franck.debian.org
Accepted rpm 4.10.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 29 May 2012 13:26:18 +0200 Source: rpm Binary: rpm rpm2cpio rpm-common rpm-i18n librpm-dbg librpm3 librpmio3 librpmbuild3 librpmsign1 librpm-dev python-rpm Architecture: source amd64 all Version: 4.10.0-1 Distribution: unstable Urgency: low Maintainer: Michal Čihař ni...@debian.org Changed-By: Michal Čihař ni...@debian.org Description: librpm-dbg - debugging symbols for RPM librpm-dev - RPM shared library, development kit librpm3- RPM shared library librpmbuild3 - RPM build shared library librpmio3 - RPM IO shared library librpmsign1 - RPM signing shared library python-rpm - Python bindings for RPM rpm- package manager for RPM rpm-common - common files for RPM rpm-i18n - localization and localized man pages for rpm rpm2cpio - tool to convert RPM package to CPIO archive Changes: rpm (4.10.0-1) unstable; urgency=low . * New upstream release. * Bump soname in package versions. Checksums-Sha1: b4d35fe590b6b08d5acf118e41bcc7e67c39b8b6 2690 rpm_4.10.0-1.dsc d78f19194066c3895f91f58dc84e3aad69f0b02c 3530378 rpm_4.10.0.orig.tar.bz2 019fc97c68de60246d25bdce517968b0216dbb69 34135 rpm_4.10.0-1.debian.tar.gz ce1445195baa7767636b5e3004371cd210684afc 1066758 rpm_4.10.0-1_amd64.deb b7e4bf2674a37a701748f01ea0d3b07cbfd07623 922154 rpm2cpio_4.10.0-1_amd64.deb 66317a68154ebb9470f9497c74a091548195da79 938268 rpm-common_4.10.0-1_amd64.deb 14d3202fe58f48fd270085e702f4556ef87c335a 1437568 rpm-i18n_4.10.0-1_all.deb e10a6ab50a943e101e2ea2f9804eb6ac7740861b 2312898 librpm-dbg_4.10.0-1_amd64.deb f34438cbfba91c46d5ffc60dc9644ac3a75a89a5 1103086 librpm3_4.10.0-1_amd64.deb 674f0c3a6de900b859bc7142f418170509fa5017 996188 librpmio3_4.10.0-1_amd64.deb dab9988565a85b2ba8d74f8a1c18d9a664bd6414 986566 librpmbuild3_4.10.0-1_amd64.deb 98842b3368334de4aa4a807f0daf77e5db123636 925834 librpmsign1_4.10.0-1_amd64.deb 44988d68da46ccd51f7139e40fa61e4f1c592809 978406 librpm-dev_4.10.0-1_amd64.deb 668a1f7170245d7e647e2be8edb225574dc33634 999378 python-rpm_4.10.0-1_amd64.deb Checksums-Sha256: 650ec46fc9a990f2e102bd436990c378e4d7a3db9dc7e94ee29d4450a36ed372 2690 rpm_4.10.0-1.dsc 0e2e237235b64c07ee4a4152e4eb77aad4eb559737eac9b6713c5e1bcabfe4a9 3530378 rpm_4.10.0.orig.tar.bz2 039e1ca4657038312b0d83325df0676e9b9c47bc5d677619f7ceeeb6fea7284c 34135 rpm_4.10.0-1.debian.tar.gz 6474f6b753829489b4aa0c23f90aefa58288b926a68e937638af8e58e2895d87 1066758 rpm_4.10.0-1_amd64.deb fa3c2aa191edb74cbcd244ca96b81d49b79cb0f0a5ad308ce70a2fd19231882a 922154 rpm2cpio_4.10.0-1_amd64.deb aa8c1e12e9d0f2e87f4d7f2032e2fb31592cf8e5ee8a9a99b2d7ca504a1093f3 938268 rpm-common_4.10.0-1_amd64.deb a6a89adb9912e542fda58b9013283a5e68eb0468229101666bc7efa0d0f91160 1437568 rpm-i18n_4.10.0-1_all.deb 7d9aee5bb01e781050a3431b9d1c8926aa5d5d21319249d03e586472587255ae 2312898 librpm-dbg_4.10.0-1_amd64.deb 39dc9b36a596f6b979b064e60f4d341fde659241e2b41e5f9f424f984ee6ba9d 1103086 librpm3_4.10.0-1_amd64.deb a42149d72e451c71aa586238ef7e1e27afe156fef6d6854eddc6cd66d1c706a9 996188 librpmio3_4.10.0-1_amd64.deb 9d05c0755767eb3460491678ff5803028d186b419ca5cac5d3e20e224ed1d8d2 986566 librpmbuild3_4.10.0-1_amd64.deb 014fe0428b9618172a2b596dc40104333532cd96c7f25f75a393599a1d8768ac 925834 librpmsign1_4.10.0-1_amd64.deb acf6ac3b917dacf8866d29a681fa80a651150028fbce1c7db477b83ed3b78796 978406 librpm-dev_4.10.0-1_amd64.deb 3ccb4959905bd1b34172528570f59f7bfadeb2a296b1fdc2fc3835dc43aa9bec 999378 python-rpm_4.10.0-1_amd64.deb Files: be379512c6c876c75e00a14e0a663d78 2690 admin optional rpm_4.10.0-1.dsc 6531fa74f06df0feee774688538241e8 3530378 admin optional rpm_4.10.0.orig.tar.bz2 cefe5e5142d5c6fb1e7bcb85dfbbf340 34135 admin optional rpm_4.10.0-1.debian.tar.gz 48e3f5bdedaf3e23feb9ef7f80e3e140 1066758 admin optional rpm_4.10.0-1_amd64.deb 2763ac7b0b4027f1c5f3f47903e5578d 922154 admin optional rpm2cpio_4.10.0-1_amd64.deb 01986e8fb9d22724ab7a8d323d144fa2 938268 admin optional rpm-common_4.10.0-1_amd64.deb 02dcbdffe3159b009e6adbbfd4610d07 1437568 localization optional rpm-i18n_4.10.0-1_all.deb 5b40ceb50db4da5f8b1d9bad94db523c 2312898 debug extra librpm-dbg_4.10.0-1_amd64.deb 82ab5883f455653b60da9e65775b21c0 1103086 libs optional librpm3_4.10.0-1_amd64.deb 8cd18b33f893f447df3ec421110d1518 996188 libs optional librpmio3_4.10.0-1_amd64.deb 8d12e52c4bec626f95049de0cac75c17 986566 libs optional librpmbuild3_4.10.0-1_amd64.deb 49aaa32b71a85d91ffd82d185d09bff1 925834 libs optional librpmsign1_4.10.0-1_amd64.deb aa7f26f773ea5138a20957a1b6b217eb 978406 libdevel extra librpm-dev_4.10.0-1_amd64.deb 894f767e84a173dbc1db508231079ea8 999378 python extra python-rpm_4.10.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPxLNtAAoJEGo39bHX+xdNUHwP/jFvs3fL8lLc0VUbIMbFoEMU JGaoWnaZBCtoNqnJ6l9EqsuH+xiHKAEH9ok5LVXBm5TLIKoxu8vzIXWseskds6MR r2vcqAXtCLi2Ana5QKgJGNygqj/b7Qx4rNutEdeoumImOl8UP92cbI0Kb/ktRfH8
Accepted ruby-shadow 2.1.4-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 08 May 2012 18:45:21 +0900 Source: ruby-shadow Binary: ruby-shadow libshadow-ruby1.8 Architecture: source amd64 all Version: 2.1.4-1 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Taku YASUI t...@debian.org Description: libshadow-ruby1.8 - Transitional package for ruby-shadow ruby-shadow - Interface of shadow password for Ruby Changes: ruby-shadow (2.1.4-1) unstable; urgency=low . * New upstream release. * Ruby package transition - Change package name to ruby-shadow * Change maintainer to Debian Ruby Extras Maintainers. - akira yamada ak...@debian.org and Taku YASUI t...@debian.org are uploaders. * Commit debian source to git.debian.org. - git://git.debian.org/pkg-ruby-extras/ruby-shadow.git - Add Vcs metadata to debian/control. * Change source format to '3.0 (quilt)'. * Bump Standards-Verson to 3.9.3. * Use gem2deb to build package. Checksums-Sha1: fc0d0e857040979061c7af3e207a6b39496f58e3 2095 ruby-shadow_2.1.4-1.dsc 4d9b91c213cf2cc1c74a8d8b25876d1fb56b89f9 5437 ruby-shadow_2.1.4.orig.tar.gz 5ca227b5cffe669a65556cc92dd7aec465721735 3609 ruby-shadow_2.1.4-1.debian.tar.gz 30789abf422f19c539826d605413a3fc951d6321 12494 ruby-shadow_2.1.4-1_amd64.deb 7b40748a6ac55618a925893c9bdd35f08e42545b 4822 libshadow-ruby1.8_2.1.4-1_all.deb Checksums-Sha256: 9bb48dd240b2c96beef1b1339a3b86501e7048fac089dbb09845f0432cd53f7a 2095 ruby-shadow_2.1.4-1.dsc 3fd2ad3421c464a29abfd2282f3a0e531a29721198f0afc13aca502d9876a742 5437 ruby-shadow_2.1.4.orig.tar.gz 892f1dab606d9fe96d0ef5b21d8a829f25dc857c72a6132ee924ce247b01ca40 3609 ruby-shadow_2.1.4-1.debian.tar.gz ea3323fcddb4997b8e27a59bc80c35d275cad7225382eb9a60f63b443bc8fec0 12494 ruby-shadow_2.1.4-1_amd64.deb 4ccb2404fda0e501d33204bdfe1e09b6db24888e942a77eee9f94d24ff45a1e4 4822 libshadow-ruby1.8_2.1.4-1_all.deb Files: 31bb9880aca442829e752e15211f434d 2095 ruby extra ruby-shadow_2.1.4-1.dsc 587be19e4bf5bda8d52f872e2c927453 5437 ruby extra ruby-shadow_2.1.4.orig.tar.gz e9e13165cd3c5556e9931ea3d5542edf 3609 ruby extra ruby-shadow_2.1.4-1.debian.tar.gz 6bc03f957e4feaa6d6eb0ec89f39 12494 ruby extra ruby-shadow_2.1.4-1_amd64.deb f606fd7828c81330a634ef048e2c2098 4822 oldlibs extra libshadow-ruby1.8_2.1.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPqPNcAAoJEEDXFs/pCc3u6vUP/RKnAuRUzWztCz0jDfy3nNTw Mnh8y4Q8lSVB5E985UcJMQfjRLw8cqUIEdX8aQRBpzTnphaS/jyaHl/FjUr/9Oo/ 0NWnL4bFuTAIPf4c3CSV8X3M2VAseocSGWx4AEDE7FdePrTqJnCVAAGcKo0BwqYx sP3FM9dZa6hTXaHa9wzi/iqozAlt+najeccZTD4bW8VQ0HNhctWrIBGt8f34PNvd RnYiBGI3Pol5tpQb6GFuAh288+wZ37DoTLiydcZmQk4vjTPUQFcdYKPk/miP2IMM 3oDJqYvqfUSlz8gWSWovoNODUAG/8BUlVzlxiyhF4S0xbbN5GbRGoE4/oK3ZtaIp Sbhfx6c8misCsQhw0VoR9A4UwSaVfLASIzS/lEDRAdplzLEHGbs/+Yqv8qaCIIgV jBxmFONCYC0IVq0io26Ob8gOeqEUcgVhqr1OcVZ+3N7vb8KSMS8EGfIZLHHpPMll fL6G7Kho/Elnk/mMP8c7KG4odVKBl8UsyL1d3zJawDewuNJsI3DchOJnM7OFgOeZ 1cRE+SAdi4q7bicnmnOzh+p5VDF9cRPMnPvQGv0OqH4eZiixi4kIjMA4+XQU6emY XPYj6OjGzJm5X+6EpzIeEb6rGZbhcvNRHyIjiH/9ZgtR3fdZID5XdOJREXwRKTVc nPWb4A0Je1r2R8DWMG6V =jtVJ -END PGP SIGNATURE- Accepted: libshadow-ruby1.8_2.1.4-1_all.deb to main/r/ruby-shadow/libshadow-ruby1.8_2.1.4-1_all.deb ruby-shadow_2.1.4-1.debian.tar.gz to main/r/ruby-shadow/ruby-shadow_2.1.4-1.debian.tar.gz ruby-shadow_2.1.4-1.dsc to main/r/ruby-shadow/ruby-shadow_2.1.4-1.dsc ruby-shadow_2.1.4-1_amd64.deb to main/r/ruby-shadow/ruby-shadow_2.1.4-1_amd64.deb ruby-shadow_2.1.4.orig.tar.gz to main/r/ruby-shadow/ruby-shadow_2.1.4.orig.tar.gz -- 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/e1salsb-0002be...@franck.debian.org
Accepted ruby-shadow 2.1.4-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 31 May 2012 01:08:31 +0900 Source: ruby-shadow Binary: ruby-shadow libshadow-ruby1.8 Architecture: source amd64 all Version: 2.1.4-2 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Taku YASUI t...@debian.org Description: libshadow-ruby1.8 - Transitional package for ruby-shadow ruby-shadow - Interface of shadow password for Ruby Changes: ruby-shadow (2.1.4-2) unstable; urgency=low . * debian/copyright: Add license disclaimer, * Add debian/patches/010_fix_license to fix license clause. Checksums-Sha1: f9ea4d20c4299bd9fde362b3efd0a2f097216c7d 2095 ruby-shadow_2.1.4-2.dsc d2174ee1c10fd20f022848211eba0d8448d8d694 4091 ruby-shadow_2.1.4-2.debian.tar.gz 533b505740dc4b314f57de53c81a637a35a606ee 13294 ruby-shadow_2.1.4-2_amd64.deb c336489ff429ee868fe8aeee2c34ee20027596a7 5038 libshadow-ruby1.8_2.1.4-2_all.deb Checksums-Sha256: 1756f61cc8305ef2388fdc0cf07263b597fc595350d7e615af6691d52aebd419 2095 ruby-shadow_2.1.4-2.dsc ac61ef597787720746b286676fb88812b49b95f5aa0cca87ce6625f84dbd90c8 4091 ruby-shadow_2.1.4-2.debian.tar.gz 25470900238e4b14037e821cded9121342f4fee611e48bd045376751c5916abb 13294 ruby-shadow_2.1.4-2_amd64.deb cb0af1b9c7f2b5e4aa6356c888b6efd3f12e655e8d35d88a35322c6fa71ac2e6 5038 libshadow-ruby1.8_2.1.4-2_all.deb Files: 73bdcb7df0b73876d4158c47cdff0a5a 2095 ruby extra ruby-shadow_2.1.4-2.dsc 11dac3ee62f06aae5ab61e9d2021ee73 4091 ruby extra ruby-shadow_2.1.4-2.debian.tar.gz 9365050004a14b72fed6432f78f222ec 13294 ruby extra ruby-shadow_2.1.4-2_amd64.deb 20516e613ce35de14b8d2989f56f04c3 5038 oldlibs extra libshadow-ruby1.8_2.1.4-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPx6dyAAoJEEDXFs/pCc3ucVAP/0ff4xEbwZq1OiAz0vehytTB Iv3OZuH46F/n5/kGcYP/6UwEZc0Qo7flUUFQ2mQwWdZjVg7KK94CMZqsKPa9ssDu zo5tyBE4m9lNDMgaGvc3SmZxlzQMFhH/bus5Js8n9n1G1n0wEK9YDTEZAfzl2dFt pd+i6LsmEi2XqJkfOkWWC29jWUKojJ92PREwYyxLGcUmp5APXRbkte54vtx1j4R/ tp8TXCIzN81aOz2RW0IbV4p47pngE59z/qJVY6HRih8QdcEHvpRuUnxiEOfvIyAM SRlde5aZ2qwG1E2cMIIZ/kq2h7671CwcpiLrC2pLvuZ0WbrZwjzR9HRi3Nrq840+ zrhH/mKoxVHTNuqTGTEk0dmkKLo571U0T4lvDKebq3pHOHq6PTBxe5H8Ir8o5Lcp Jx6K5aWzNGQ3UvwQksRLVkI1034YGnaHrZbIgzyJt9XCGm6BiyVWSYSKXUdaoMOj UIYOntq5A5ERJnkPFW3Rhlg1MHWWGEQxZQ0CNdZD5Sm1e6vbCvnidi9Qg995OANz A9YBXypPePmHW/0rMe6E/6kWb0TdJXEM2oskcqys5bnvryYiQbGVegqwUligZfKd W/mn5Js3s9dP1ktZ6UHlUOHS2rqLo50c6WezPM3BYjxPbcRPsgJqMZ4hwVwI5I2I 3utCLDLbwfAhonazg6rI =QfuI -END PGP SIGNATURE- Accepted: libshadow-ruby1.8_2.1.4-2_all.deb to main/r/ruby-shadow/libshadow-ruby1.8_2.1.4-2_all.deb ruby-shadow_2.1.4-2.debian.tar.gz to main/r/ruby-shadow/ruby-shadow_2.1.4-2.debian.tar.gz ruby-shadow_2.1.4-2.dsc to main/r/ruby-shadow/ruby-shadow_2.1.4-2.dsc ruby-shadow_2.1.4-2_amd64.deb to main/r/ruby-shadow/ruby-shadow_2.1.4-2_amd64.deb -- 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/e1salsl-0002c9...@franck.debian.org
Accepted tortoisehg 2.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 29 May 2012 00:59:17 -0700 Source: tortoisehg Binary: tortoisehg tortoisehg-nautilus Architecture: source all Version: 2.4-1 Distribution: unstable Urgency: low Maintainer: Ludovico Cavedon cave...@debian.org Changed-By: Ludovico Cavedon cave...@debian.org Description: tortoisehg - Graphical tool for working with Mercurial tortoisehg-nautilus - Graphical tool for working with Mercurial (Nautilus extension) Closes: 671473 Changes: tortoisehg (2.4-1) unstable; urgency=low . * Imported Upstream version 2.4 (Closes: #671473). * Re-add Nautilus extension (LP: #990527). * Update Standards-Version to 3.9.3. * Update copyright format. Checksums-Sha1: 508426a0cc549bbf2ba41edd8c301fe34dc470cb 2050 tortoisehg_2.4-1.dsc cde776dc9eb29ed9fca0d67e027adcbd4841e6c6 8978194 tortoisehg_2.4.orig.tar.gz b7e1d01f60426d266d6530ba616f1d0f54fcb297 19866 tortoisehg_2.4-1.debian.tar.gz c97087654828abc9d7ac00c682e5136fa36406ad 3698972 tortoisehg_2.4-1_all.deb 3e8005c4aa4b5ef09e48a3e908c3750373df7975 14720 tortoisehg-nautilus_2.4-1_all.deb Checksums-Sha256: d3099c517e65562f94b10010758c30d96a6bfe2e8c8a544308523c0fac4d2eed 2050 tortoisehg_2.4-1.dsc 117029ff1912b98c52cd89ebc6ee6aa5d4375bff67bbc1d2ee9f2bd636d06233 8978194 tortoisehg_2.4.orig.tar.gz 88f22deab5ccaf1a971ad374fba4be75475474ac974f3c5a0fdb339c04ae8918 19866 tortoisehg_2.4-1.debian.tar.gz a74277351cff90dfd500cca8c1950c2c1a062778b2ea3492148b3091653f 3698972 tortoisehg_2.4-1_all.deb 091e89068e8b744e815c05fbba27c9e4be763cd3b5d0c7c959fa6fcfff09e6b3 14720 tortoisehg-nautilus_2.4-1_all.deb Files: 2f6f03073acf43b401a854eafcdeec9a 2050 vcs optional tortoisehg_2.4-1.dsc 4c4eebbf6bcf2942cb702a5fda70afb8 8978194 vcs optional tortoisehg_2.4.orig.tar.gz badd556f44e3973c1a2513d87a8da61e 19866 vcs optional tortoisehg_2.4-1.debian.tar.gz fb8bfb5733e774b7eb67ac1c64ab9b78 3698972 vcs optional tortoisehg_2.4-1_all.deb 7a9bbf96bd1ede1dba3b5becc9de6ffe 14720 vcs optional tortoisehg-nautilus_2.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPxIfGAAoJEBPAtWZ6OLCwcxoQAJ1C1JNvcXJIC55QwGW0qirm 9vIMsDBHkqYpfqDxQVk3b16H0P4EALN9vZobEXXWWZH3n3bgtGeP3aZj2nYHIk6a AHu3eoeh2PJUw7teunWZSWrG0y7rVEBJz42VZReJ4lIHk58ShLTSA3s0HIh6nTLR o/oQjfEHZkMfuc/61DO3Sewp8o3s6GhS8lxi7VUsdpqVtvKPThr9d2Y5EyoArx9I W29t41C0CWa5wDe15lOmq7Cy5ySDcYJQxctIHJr31IXamYiH4Lm23MVo/PYqAuq9 HyYQ933o2qBBmPDYDtQnUAKzGwMgSJbWntDfndGQsMkMvgvb0x6m9tfTJdUz2Tbs z2sFt6KRu1N0v8dy5GtWF2T6puToIHm8E1gHFplNf95NVsht17deksC8NB2k33FO TUmqHtFcHMEy8NnwiYo6MLuvRjYfuycjj3e7hIMFg7UdTRpUznffzkeYMVdPSvoO /kygBra5hiNY33gxtbl+ke3r8UncO0xDswgbnaa4SpUAEZGjPmw2g43laQhmjLXJ 7QpBrDWjOFyAZzrMZpqvA+luqR4K+HTWkREnringv/Lu2nI6G45i3bJAujtzPtxd Qfpb2JWrnWarjpd6U/8iR7GDk/Ir+cV5j8SdQ5EbyYJxkYSVGATnMwh0cR1cgkb6 eeWBCTHQs4w+7Xkf+QWZ =+RFd -END PGP SIGNATURE- Accepted: tortoisehg-nautilus_2.4-1_all.deb to main/t/tortoisehg/tortoisehg-nautilus_2.4-1_all.deb tortoisehg_2.4-1.debian.tar.gz to main/t/tortoisehg/tortoisehg_2.4-1.debian.tar.gz tortoisehg_2.4-1.dsc to main/t/tortoisehg/tortoisehg_2.4-1.dsc tortoisehg_2.4-1_all.deb to main/t/tortoisehg/tortoisehg_2.4-1_all.deb tortoisehg_2.4.orig.tar.gz to main/t/tortoisehg/tortoisehg_2.4.orig.tar.gz -- 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/e1salsw-0002gm...@franck.debian.org
Accepted codeblocks 10.05-2.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 05:03:19 + Source: codeblocks Binary: codeblocks codeblocks-common libcodeblocks0 codeblocks-dbg codeblocks-contrib codeblocks-contrib-dbg codeblocks-dev libwxsmithlib0 libwxsmithlib-dev libwxsmithlib0-dev Architecture: source amd64 all Version: 10.05-2.1 Distribution: unstable Urgency: low Maintainer: David Paleino da...@debian.org Changed-By: Matthias Klose d...@debian.org Description: codeblocks - Code::Blocks integrated development environment (IDE) codeblocks-common - common files for Code::Blocks IDE codeblocks-contrib - contrib plugins for Code::Blocks IDE codeblocks-contrib-dbg - Debugging libraries for the Code::Blocks contrib plugins codeblocks-dbg - Code::Blocks debugging libraries codeblocks-dev - Code::Blocks development files (SDK) libcodeblocks0 - Code::Blocks shared library libwxsmithlib-dev - wxSmith development files (Code::Blocks plugin for RAD GUI editin libwxsmithlib0 - wxSmith shared library (Code::Blocks plugin for RAD GUI editing) libwxsmithlib0-dev - dummy transitional package for wxSmith development files Closes: 667138 Changes: codeblocks (10.05-2.1) unstable; urgency=low . * Non maintainer upload. * Drop build dependency on libstdc++6-4.5-dev | libstdc++6-4.4-dev. * Fix build failures with GCC 4.7, build with -fpermissive. Closes: #667138. Checksums-Sha1: 6c928b3c381c0448229187c36cf2342ab754318f 1862 codeblocks_10.05-2.1.dsc c7981449320c5c8708e9aafeb4c1608a0da44178 20603 codeblocks_10.05-2.1.debian.tar.gz ce9881431ba3c8bc0355cc8f36afea83d930faeb 1876484 codeblocks_10.05-2.1_amd64.deb 2cd893b1c2a0d0b123286090b3d84ad446120b34 2943022 codeblocks-common_10.05-2.1_all.deb 547353861ddb443640e0a7e9b9171b779a98ba06 1957464 libcodeblocks0_10.05-2.1_amd64.deb c576edcd16e756e08213b8a7282a84b11e9b8d6a 728276 codeblocks-dbg_10.05-2.1_amd64.deb dffa97f51ac0344e9038643cc83f26bfe152b44e 3684774 codeblocks-contrib_10.05-2.1_amd64.deb f6443d7f70e37ebbb3f5ccbfa52e4338ee2b9d03 905232 codeblocks-contrib-dbg_10.05-2.1_amd64.deb 5bcfe9dbf6959cf4bcd2643630fec4b547f3454e 455166 codeblocks-dev_10.05-2.1_amd64.deb 98bf45d97481ef2b420707dc593b7773ec3aa9dc 1182292 libwxsmithlib0_10.05-2.1_amd64.deb d2da41d956d06d5d72f171e5f41a67e87b3c5dd6 424010 libwxsmithlib-dev_10.05-2.1_amd64.deb 126dbf7be053cd98a354286d70ab6baca716 240240 libwxsmithlib0-dev_10.05-2.1_amd64.deb Checksums-Sha256: 678f4d2d5f7a055fb828c229f6a07d761e6748230ca338196025ec58e1ca7813 1862 codeblocks_10.05-2.1.dsc c323bddd4994b6cdc0d35f9f16df39c73bbdea544341c387f6b23267811c6a32 20603 codeblocks_10.05-2.1.debian.tar.gz 46050c4b7d7544509eae9e27f0820bdf189544b217fbccc7ad301fd433f958dd 1876484 codeblocks_10.05-2.1_amd64.deb d92df99ccbeb5976652058f0877ef3cbe37c1d188c0ad998ad0beb454855646b 2943022 codeblocks-common_10.05-2.1_all.deb c64c751810bb45e13ecf9afbd12a4ed40fc89a2a5794b121c4c5d11889e5781a 1957464 libcodeblocks0_10.05-2.1_amd64.deb 63c49be57e3cbf9083b55c34e6f5f6ac94a6720a50c126909868899d7d9960a6 728276 codeblocks-dbg_10.05-2.1_amd64.deb 35c89fb09488d0a53bc5dabffdb83772352b791fc97f37a5608880fee8861d21 3684774 codeblocks-contrib_10.05-2.1_amd64.deb 0cfbf4dcf55f8efc906382c06b843e1ac8933519aa19d1de6adc1d27929522a5 905232 codeblocks-contrib-dbg_10.05-2.1_amd64.deb 5b8be492e205481029b2c22f5f9ef80df1fcdb2bf2512bc34440d9000d831382 455166 codeblocks-dev_10.05-2.1_amd64.deb d889b1c58bbb4bcc263a8b1e8344402580ad9402f9f9cfedfa0ec36bccb2a4c7 1182292 libwxsmithlib0_10.05-2.1_amd64.deb 8bc0b920c0cfa38d5a0068700d3f1436183e4e221f9c97650ca1c91a78bd6a55 424010 libwxsmithlib-dev_10.05-2.1_amd64.deb 33fafe70c9dcd53a083c9f3f703ded87cde02de6867af06b57fd3eb5aa4a65cb 240240 libwxsmithlib0-dev_10.05-2.1_amd64.deb Files: 2ac3d8a0579aca4217e0524464687d29 1862 x11 optional codeblocks_10.05-2.1.dsc 7fd8163418001aaf9fdd37ab84d8df6a 20603 x11 optional codeblocks_10.05-2.1.debian.tar.gz add30b72f436f84cd5a63c3e6028f81e 1876484 devel optional codeblocks_10.05-2.1_amd64.deb c5b3fe8e916b5569827f88ced31a8966 2943022 x11 optional codeblocks-common_10.05-2.1_all.deb 7ef522c92d28c4b4c3d723aebb87b0b3 1957464 libs optional libcodeblocks0_10.05-2.1_amd64.deb 0c29b19a973c56786449f0cbef63f64c 728276 debug extra codeblocks-dbg_10.05-2.1_amd64.deb c69603266f138556e0af4d7b71c8b346 3684774 x11 optional codeblocks-contrib_10.05-2.1_amd64.deb 8dc35716ca481c91737719affe10aee2 905232 debug extra codeblocks-contrib-dbg_10.05-2.1_amd64.deb 254dfea2357d94d392476593195736c4 455166 libdevel optional codeblocks-dev_10.05-2.1_amd64.deb f48a5e9cfb3c64226301ba33e8d42026 1182292 libs optional libwxsmithlib0_10.05-2.1_amd64.deb f4fa6d24ee24a9ca761d872b05d68282 424010 libdevel optional libwxsmithlib-dev_10.05-2.1_amd64.deb f78163988e846c4bc2d06b1711603540 240240 libdevel optional libwxsmithlib0-dev_10.05-2.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux)
Accepted fso-gsmd 0.11.2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 29 May 2012 14:51:31 +0200 Source: fso-gsmd Binary: fso-gsmd fso-gsmd-dbg fso-gsmd-openmoko fso-gsmd-ezx fso-gsmd-htc fso-gsmd-gta04 Architecture: source amd64 Version: 0.11.2-1 Distribution: unstable Urgency: low Maintainer: Debian FreeSmartphone.Org Team pkg-fso-ma...@lists.alioth.debian.org Changed-By: Sebastian Reichel s...@debian.org Description: fso-gsmd - freesmartphone.org GSM daemon fso-gsmd-dbg - debugging symbols for freesmartphone.org GSM daemon fso-gsmd-ezx - freesmartphone.org GSM daemon for Motorola EZX devices fso-gsmd-gta04 - freesmartphone.org GSM daemon for the GTA04 device fso-gsmd-htc - freesmartphone.org GSM daemon for HTC devices fso-gsmd-openmoko - freesmartphone.org GSM daemon for Openmoko devices Changes: fso-gsmd (0.11.2-1) unstable; urgency=low . [ Simon Busch ] * Imported Upstream version 0.11.2 * Build from vala source and not from precompiled c source * Update dependencies * Update debian source watch configuration * Create packages for our plugin packages for any architecture * Add support for the GTA04 device (it's packaged as fso-gsmd-gta04) * Drop remove-fsogsm.h.patch * Update sms-store-dir.patch to include support for GTA04 configuration * Update fix-pkglibdir.patch to match newer configure.ac * Drop use-private-libdir.patch; it's upstream with version 0.11 now * Use version 9 of debhelper utility * Connman support is gone; remove dependency and configure option * Remove dependency on libfsodata-dev package . [ Sebastian Reichel ] * Build package with --as-needed Checksums-Sha1: 875ee1941c853d7d93f2197de78b4d41e7790577 2534 fso-gsmd_0.11.2-1.dsc 0bcd3dc5291fab4185041406f8a108ee53906bfd 1163563 fso-gsmd_0.11.2.orig.tar.bz2 a6c9d34aec8fb7990aabce915ddc9e3f79a1d644 7407 fso-gsmd_0.11.2-1.debian.tar.gz 13a66f39c009601eb7f11efb7bcd818a2c0ed278 502074 fso-gsmd_0.11.2-1_amd64.deb 72fa6e15ae9f651cf9bfd8528cd9a654a1f6702f 1688398 fso-gsmd-dbg_0.11.2-1_amd64.deb da2b2c75f521362f0b55e1fba0b40a09af5a22cc 32178 fso-gsmd-openmoko_0.11.2-1_amd64.deb 764c47453044a7917b83856a17b5ff85c76fcde3 23350 fso-gsmd-ezx_0.11.2-1_amd64.deb cb961b8c46da16adad748572d6a02577938693db 18402 fso-gsmd-htc_0.11.2-1_amd64.deb 76f6f665e15b96fd9ce8aad508d9c1ca1c879146 25504 fso-gsmd-gta04_0.11.2-1_amd64.deb Checksums-Sha256: 18f3f1c4b5258783a3a819b10e3bc106261350915796e739f390ebbaa1e95e1d 2534 fso-gsmd_0.11.2-1.dsc 1eb0a1a51367e6437fae18cf1c24a0ff36fec5814c61b1f96e3579b7b56387bf 1163563 fso-gsmd_0.11.2.orig.tar.bz2 2d3ffcb318a49e076c9c919f3dd04f5ce946112c8fb0b1f8777d6dba3e9af92f 7407 fso-gsmd_0.11.2-1.debian.tar.gz b93b3715eaaa7b5495c617060e31607a3fff257a4db673b3c5508972855e58a0 502074 fso-gsmd_0.11.2-1_amd64.deb 53fe614554c3c3ca00b50157665d60c633ca8435047de4803f7717ad64bebcdf 1688398 fso-gsmd-dbg_0.11.2-1_amd64.deb 179e8e70358912a6a143d517bed8f12695afa9e04717667dc176424fa0c45929 32178 fso-gsmd-openmoko_0.11.2-1_amd64.deb 862602887168ef2f136e45f0760279ff9643d5b96c2f180eb579887b23481f1a 23350 fso-gsmd-ezx_0.11.2-1_amd64.deb dcfa255e9107f93de73c9441969881ddee3ffac64514cce92e0fb0f08c42210b 18402 fso-gsmd-htc_0.11.2-1_amd64.deb 2c1da7a774b0ad40a3fb4ddfe45ba7af53ae6060945e864ab05c0d81ca840471 25504 fso-gsmd-gta04_0.11.2-1_amd64.deb Files: 19d6e0fd63b8c6cbd03bca42e15512f4 2534 misc extra fso-gsmd_0.11.2-1.dsc 874123fe6b664bb40daf6168cdf981b2 1163563 misc extra fso-gsmd_0.11.2.orig.tar.bz2 75bf25f706c29857c2c1106912646bfe 7407 misc extra fso-gsmd_0.11.2-1.debian.tar.gz 3761777c2b932f10cd4beab98e74ab7e 502074 misc extra fso-gsmd_0.11.2-1_amd64.deb 9124f20b5d16c29383f60978bbe75c3f 1688398 debug extra fso-gsmd-dbg_0.11.2-1_amd64.deb 11dc267eb2738b6f823a54e048c4cac5 32178 misc extra fso-gsmd-openmoko_0.11.2-1_amd64.deb 26afd3dad49281598c8b673d512206bc 23350 misc extra fso-gsmd-ezx_0.11.2-1_amd64.deb 8cc1a5b751c8cc0b713185d710b50b0d 18402 misc extra fso-gsmd-htc_0.11.2-1_amd64.deb 42b52d7b438e9b20d13bc4ebc302e106 25504 misc extra fso-gsmd-gta04_0.11.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPxQvoAAoJENju1/PIO/qaJIQQAJEUE1xKixbDMDIBG2e0CiNN RHLofCbKu1+VGL3IbyGJcAiVr3/oHjufo2TqgbAPnwdgnElTIoe/o1s6+reFfrM9 /YcKkZQA+FYko3uVF3BSPK1VfTkWkLqYb6fc13H37fHXf0ZyhbNteR4l5K3eQwiu Bd6vjV04ku2QvLFES3DnKDHrT9G3dvs/osZk8xNskEKbJNjKE+qXmxun7gPte7fh HAP9UmNNwO2HIF0N+SukF0SGiWYo72g0p5/sY1WymJzky8ow9RAL9Szx0n0Mni6+ IKJDk+qfPk5uNUlqc8w+cVFyRI/4zN+ldzAIuuwYWbDhg3deFk4RAOcgi5cR1uNp VmKQusDOL+XMaOTLGzfYz+tvmi912ePMG5hOPxcnXBrX3bL2MJ1bjnPTmVoaoC+9 GZkFAam3IakyF50xsVSUceM2J1fF9AZBudBuYlE//yP3DrswVYYb9AQLeLhFOCwf XgxKkOYWunVADMltCr3hahKXg07Ljo6cPkOIgP4m5WUq2WjkULi1Z9ijLoOj5FtP mt8B+1gpA3Tarkaehy1p90mjYmHCz25azoFpmorGKK0NUkfnkwIRUpLKPTExbzg3 /0jpwELzbAuH2QPfGlEcjdPLYtW3utKpGzFoaHJiWaYThhTZn+F6IGc8kfQjqIAd jrR/Ru6YGo/Z2NKbu5Sg =jAcu -END PGP SIGNATURE- Accepted: fso-gsmd-dbg_0.11.2-1_amd64.deb to
Accepted gnustep-back 0.22.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 28 May 2012 14:56:36 +0300 Source: gnustep-back Binary: gnustep-back0.22 gnustep-back0.22-art gnustep-back0.22-cairo gnustep-gpbs gnustep-back-common gnustep-back-dbg Architecture: source all amd64 Version: 0.22.0-1 Distribution: experimental Urgency: low Maintainer: Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org Changed-By: Yavor Doganov ya...@gnu.org Description: gnustep-back-common - GNUstep GUI Backend - common files gnustep-back-dbg - GNUstep GUI Backend - debugging symbols gnustep-back0.22 - GNUstep GUI Backend gnustep-back0.22-art - GNUstep GUI Backend (art) gnustep-back0.22-cairo - GNUstep GUI Backend (cairo) gnustep-gpbs - GNUstep PasteBoard server Closes: 663388 666334 Changes: gnustep-back (0.22.0-1) experimental; urgency=low . * New major upstream release. * debian/rules (v_gui): Bump to 0.22, which depends on -base 1.24 which in turn does not lead to the automatic creation of $HOME/GNUstep (Closes: #663388). Don't include /usr/share/quilt/quilt.make; remove patch/unpatch depedencies. Enable hardening. * debian/control.m4 (Build-Depends): Remove quilt. Add libxcursor-dev. (Depends, Suggests): Replace ttf-freefont with fonts-freefont-ttf. (Replaces, Breaks, Provides): Remove; no longer needed. (gnustep-back-dbg) Recommends: Set to libgnustep-gui0.22-dbg. (Standards-Version): Set to 3.9.3; no changes required. * debian/control: Regenerate. * debian/source/format: Switch to 3.0 (quilt) so that patches are always applied (Closes: #666334). * debian/README.source: Delete; redundant. * debian/gnustep-back-common.preinst: Remove defoma cleanup code. * debian/gnustep-back-common.prerm: Likewise. Also delete unowned files/directories under /var. * debian/patches/cairo-fc.patch: Refresh. * debian/patches/autoreconf.patch: Regenerate. * debian/patches/format-security.patch: New, fixes FTBFS with -Werror=format-security; thanks Mathieu Trudel-Lapierre / Ubuntu. * debian/patches/series: Update. * debian/copyright: Update copyright years. Checksums-Sha1: 35951dbb560ff0ea818bf7e9fd3e99282025aa2f 1864 gnustep-back_0.22.0-1.dsc da21dbb7844fb5acecf0323daf35392c11a1e4af 935034 gnustep-back_0.22.0.orig.tar.gz 6991ca62e7744b0b8b1536a6a2907051a00ba19b 66419 gnustep-back_0.22.0-1.debian.tar.gz 3328eae1b86b3ed91757dc719a0d8481c7693f4a 69532 gnustep-back0.22_0.22.0-1_all.deb db4eca2799319ec4f989fed6d0c59661eaa3b1d6 76496 gnustep-back-common_0.22.0-1_all.deb 6481ea2df415688deff2c51c7ef32bc7a99e8b79 334578 gnustep-back0.22-art_0.22.0-1_amd64.deb bb4668439e903456407ff8400979a2b4c20b44a0 280364 gnustep-back0.22-cairo_0.22.0-1_amd64.deb 9c77f79bc80063d61cbbee3b2b95c95ef2fd38b0 97014 gnustep-gpbs_0.22.0-1_amd64.deb 95954f17645d77814ccdff7735a3a253cd08429e 1219038 gnustep-back-dbg_0.22.0-1_amd64.deb Checksums-Sha256: fc4695e468f5bc173fbb71711f528e146b458c769c57bf01b0b644f1ff97b10b 1864 gnustep-back_0.22.0-1.dsc b9bf26346737d87160af669c3073b4eb511c743056af90aedb631e1537513608 935034 gnustep-back_0.22.0.orig.tar.gz 573314fa7b585e0dbef2dbc7cd828173b847ead85309d420afd952f45129 66419 gnustep-back_0.22.0-1.debian.tar.gz 76323c36c3febaddcbf2197cae6afb10f147537205922442c9cc5af413f2842e 69532 gnustep-back0.22_0.22.0-1_all.deb 81f90d1655290d67170e7c29911b1c5128d3b0bd025a81d6aa4f6becf5558e34 76496 gnustep-back-common_0.22.0-1_all.deb 2fda765f8b09d266b139bc00452297f6f7922c67b33028c50961e6233ae4 334578 gnustep-back0.22-art_0.22.0-1_amd64.deb 08b4857082e7025da13b84631269c820b3d6404ea97d30e1994a563def204a37 280364 gnustep-back0.22-cairo_0.22.0-1_amd64.deb a4a41b41c31aac56f7e185c4721088405df02494c32e81ae6ef1542c6c36bd54 97014 gnustep-gpbs_0.22.0-1_amd64.deb 19eddf29177406b506bc7ef16defd0664ed1ee90fad40f8306f3306c4f6dfeec 1219038 gnustep-back-dbg_0.22.0-1_amd64.deb Files: 55a9c47dc47ff38c7badf2f7e9bcd4d2 1864 gnustep optional gnustep-back_0.22.0-1.dsc 6ea64404d78766f93d192ff467162f53 935034 gnustep optional gnustep-back_0.22.0.orig.tar.gz 7e34413734b05301f32e7c6e7b63 66419 gnustep optional gnustep-back_0.22.0-1.debian.tar.gz 5932220e1cb68f0de52e2b8ff230a7cb 69532 libs optional gnustep-back0.22_0.22.0-1_all.deb 5ad587e45078714b4818148867d2473d 76496 gnustep optional gnustep-back-common_0.22.0-1_all.deb 9a9ee7750e8a668ad22eafa7977f361c 334578 libs optional gnustep-back0.22-art_0.22.0-1_amd64.deb 5862bc3113c12ed824b1b22dad53526c 280364 libs optional gnustep-back0.22-cairo_0.22.0-1_amd64.deb fb11df57f124101c0cc9cafd4bb499b2 97014 gnustep optional gnustep-gpbs_0.22.0-1_amd64.deb 41801f1de868db2207937bdc94ede178 1219038 debug extra gnustep-back-dbg_0.22.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/Fvo4ACgkQfNdgYxVXvBAGTgCggtiIMS1EcTSoY09Aw28hshiy UlEAoK/GlC6Hy6gCkY3MWFiTV7ei+A2Z =NzjM -END PGP SIGNATURE- Accepted:
Accepted grass 6.4.2-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 17:23:07 +0200 Source: grass Binary: grass grass-core grass-gui grass-doc grass-dev-doc grass-dev Architecture: source all i386 Version: 6.4.2-1 Distribution: unstable Urgency: low Maintainer: Debian GIS Project pkg-grass-de...@lists.alioth.debian.org Changed-By: Francesco Paolo Lovergine fran...@debian.org Description: grass - Geographic Resources Analysis Support System (GRASS GIS) grass-core - GRASS GIS core components grass-dev - GRASS GIS development files grass-dev-doc - GRASS GIS Programmers' Manual grass-doc - GRASS GIS user documentation grass-gui - GRASS GIS graphical user interfaces Closes: 615667 650361 671991 Changes: grass (6.4.2-1) unstable; urgency=low . [ Hamish Bowman ] * Packaged new upstream version. * Reorganize binary packages, new: grass-core, grass-gui, grass-dev-doc. * Patch g.extension.sh to check for the needed grass-dev package. * Remove outdated cruft from debian/fixscripts.sh and debian/rules. * Install the full Programmers' Manual. * Use system's copy of jquery.js in the Programmers' Manual. * libmysqlclient-dev replaces libmysqlclient15-dev. (closes: #650361) * Use xdg-open for GRASS_HTML_BROWSER when available. (closes: #615667) * Policy bumped to 3.9.3, using metapackages archive section for 'grass'. * Fix g.extension.sh test for the grass-dev package. * Add patch to fix C++ FTBFS for gcc 4.7.0. (closes: #671991) * Support for dh_python2, byte-compile .py at postinst. * Clean up TODO list. . [ Francesco Paolo Lovergine ] * Moved to use TIFF 4.0.1 instead of the legacy flavor. * Moved to use libgdal-dev (introduced in 1.9+) b-d. Checksums-Sha1: dbc401b92f2467a8ae3c9f640ee372177c5895c6 2029 grass_6.4.2-1.dsc abe8ddf5eabb7a1d79db75d5f838b7ba2a2e3bb2 23652330 grass_6.4.2.orig.tar.gz 78bc4efd3314d25deacd43935a851c7f0d97069f 26472 grass_6.4.2-1.debian.tar.gz c70b30599891d9537a1d1519f7562cb9623aedb7 14292 grass_6.4.2-1_all.deb a973ae90abdef08e4610e83f2d58fbc79c6d4518 6489062 grass-doc_6.4.2-1_all.deb 74fac9c1326ef314a77394e121851127c0a574db 27093184 grass-dev-doc_6.4.2-1_all.deb c6a5e9a035fcc3aaeaf83b1cead19f8b4f16eafb 11194220 grass-core_6.4.2-1_i386.deb 24c55c6c0f83f4e70805f20202ddba8be579b0d8 2366494 grass-gui_6.4.2-1_i386.deb f19baa3c62cae63ab8afaed3a4e7b8ed7e13bced 218022 grass-dev_6.4.2-1_i386.deb Checksums-Sha256: 6c112c085c9082ce1bf55ffd0be4ebfcacc3dd6a0c908741e0a94a562b529ed8 2029 grass_6.4.2-1.dsc a5cee9c95bebb25e66fd0383d4b34154b277513dde122e1d34610d3d0e3ff3f2 23652330 grass_6.4.2.orig.tar.gz f113802d0b8e3631cd0b2a36a81ff1d22ced1de80abfd0eba6d0cb6ad999b7bb 26472 grass_6.4.2-1.debian.tar.gz 552e3666b6f484c06dd07ceb26d27b449ce6e4a4b5552343d79d0810cbdcc125 14292 grass_6.4.2-1_all.deb ce6f361a9cc6d513bc140ce9d46a8320d26f38db811e3403130c27ffefd12bc7 6489062 grass-doc_6.4.2-1_all.deb 5c8b44b81122232cacd6471c37185e1478a08716f46e2d20c40a7cc2fc7338da 27093184 grass-dev-doc_6.4.2-1_all.deb b4efd281eb0e5cbe647770030a006150a3e9b85dfd81c4ca3cddb5ba58e378aa 11194220 grass-core_6.4.2-1_i386.deb 28b5232745a099a85a38f3a670fd393f5a272e722f3ac453fea21b7b6b995944 2366494 grass-gui_6.4.2-1_i386.deb 98f9d96b509c62703aea0a2b3c61ce417f9c82de2a401dd1850f9b4cb798994b 218022 grass-dev_6.4.2-1_i386.deb Files: f114aef8d12903f84856d47911efd942 2029 science optional grass_6.4.2-1.dsc 38071bd3dd0fffa70152507e4f3a900e 23652330 science optional grass_6.4.2.orig.tar.gz f45517780d5997df1245ac585b25b921 26472 science optional grass_6.4.2-1.debian.tar.gz 50fd428cda9db0c0b6fa4115cf4c5f1c 14292 metapackages optional grass_6.4.2-1_all.deb e8200cbb423f65f320797dd769dde08d 6489062 doc optional grass-doc_6.4.2-1_all.deb 0b93c77b7f86c35e77bb650d958c873f 27093184 doc optional grass-dev-doc_6.4.2-1_all.deb 39fe8fe720c394f4a9ac2ef232cf669d 11194220 science optional grass-core_6.4.2-1_i386.deb de3366f0ec7ea459c0659a0233854eda 2366494 science optional grass-gui_6.4.2-1_i386.deb c0f4c255222c0633ce7437c153d2a262 218022 devel optional grass-dev_6.4.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/GDIEACgkQpFNRmenyx0cfSwCgy26EWOXagdUqqSaQom4VePMk O0cAn0hnwkSdbfz1J2NORDeUvGwJeIcN =vXOT -END PGP SIGNATURE- Accepted: grass-core_6.4.2-1_i386.deb to main/g/grass/grass-core_6.4.2-1_i386.deb grass-dev-doc_6.4.2-1_all.deb to main/g/grass/grass-dev-doc_6.4.2-1_all.deb grass-dev_6.4.2-1_i386.deb to main/g/grass/grass-dev_6.4.2-1_i386.deb grass-doc_6.4.2-1_all.deb to main/g/grass/grass-doc_6.4.2-1_all.deb grass-gui_6.4.2-1_i386.deb to main/g/grass/grass-gui_6.4.2-1_i386.deb grass_6.4.2-1.debian.tar.gz to main/g/grass/grass_6.4.2-1.debian.tar.gz grass_6.4.2-1.dsc to main/g/grass/grass_6.4.2-1.dsc grass_6.4.2-1_all.deb to main/g/grass/grass_6.4.2-1_all.deb grass_6.4.2.orig.tar.gz to main/g/grass/grass_6.4.2.orig.tar.gz -- To UNSUBSCRIBE, email to
Accepted lua-event 0.4.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 30 May 2012 20:05:26 +0200 Source: lua-event Binary: lua-event lua-event-dev liblua5.1-event0 liblua5.1-event-dev Architecture: source amd64 all Version: 0.4.1-1 Distribution: unstable Urgency: low Maintainer: Enrico Tassi gareuselesi...@debian.org Changed-By: Enrico Tassi gareuselesi...@debian.org Description: liblua5.1-event-dev - Transitional package for lua-event-dev liblua5.1-event0 - Transitional package for lua-event lua-event - asynchronous event notification library for Lua lua-event-dev - libevent development files for the Lua language Changes: lua-event (0.4.1-1) unstable; urgency=low . * New upstream release * Switched to dh-lua * Bumped Standards-version to 3.9.3, no changes * Packages renamed according to the new lua policy * debian/compat to 8 Checksums-Sha1: 7ac303ee22aaa32e91ed89e6d07b597e05783577 1426 lua-event_0.4.1-1.dsc 926e5b23652f19b89ffcbd1fec5fe31f920636e9 29650 lua-event_0.4.1.orig.tar.gz e8e323f3b7d406fd035b2d5d1ac5c5f874f55d57 2911 lua-event_0.4.1-1.debian.tar.gz 90f9d0d6ca5cdeb03fd6c747d571334796d23036 16026 lua-event_0.4.1-1_amd64.deb b19da0a22912eee51440afa9c2b5eb929c320367 17898 lua-event-dev_0.4.1-1_amd64.deb 34b13bedefb65dbd709d0a42571610e909c80b2f 4448 liblua5.1-event0_0.4.1-1_all.deb 16541fe9f8572762bfc35f66e6528fdc785a56a9 4458 liblua5.1-event-dev_0.4.1-1_all.deb Checksums-Sha256: f4d76d8282ed01125ff9313dfb1deca04d9353088d05a760c6e6acc20b06c944 1426 lua-event_0.4.1-1.dsc 95fd0fc2a894354b1be60e8d26b171092fe98a219ec53f1e8be249a78c588c49 29650 lua-event_0.4.1.orig.tar.gz f5124151e24c4b28d2e44e3998bfee50a16f5c7d79e6c1ad316cf5188810fb55 2911 lua-event_0.4.1-1.debian.tar.gz 927a5ad04873faac8846e00d05e2a8d4c4bf4bc008120d74e85f118f44bc04d2 16026 lua-event_0.4.1-1_amd64.deb 1460aa3094b228c89bb0433b7c1a0edf2ec6abce9ed71d5d7cb5fd29f3ea843f 17898 lua-event-dev_0.4.1-1_amd64.deb 2b93c22e27dde8d12d237d583f469d6979bd7fdc86e391922cd512b6d2214622 4448 liblua5.1-event0_0.4.1-1_all.deb c4fac0acacd81e293bd7d6df2f3121d5300454349c13c6771a72b212ef3a3658 4458 liblua5.1-event-dev_0.4.1-1_all.deb Files: 499d5d4dcfdb03960cc46947cc81222a 1426 interpreters optional lua-event_0.4.1-1.dsc 1fd6451c55435bcfbf33484ba4d3dffc 29650 interpreters optional lua-event_0.4.1.orig.tar.gz 9740516b9546eae98731db9b3d4f5ef5 2911 interpreters optional lua-event_0.4.1-1.debian.tar.gz 6423309df3773c4d621c885eaba84194 16026 interpreters optional lua-event_0.4.1-1_amd64.deb 7dd657fec5305e046cc64b6caff37f4c 17898 libdevel optional lua-event-dev_0.4.1-1_amd64.deb 4b6c48b4405b7c7d790b2baf16c1239b 4448 oldlibs extra liblua5.1-event0_0.4.1-1_all.deb fcea51459f3b6689f0f32c3fec492ef7 4458 oldlibs extra liblua5.1-event-dev_0.4.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/Gb2gACgkQ7kkcPgEj8vLteQCgjHNDWxzvVlCLLVoVsDF9C1m/ 85EAnA+jSeYG5LlrlK0xpjR5Ts9G8CGz =Jjyx -END PGP SIGNATURE- Accepted: liblua5.1-event-dev_0.4.1-1_all.deb to main/l/lua-event/liblua5.1-event-dev_0.4.1-1_all.deb liblua5.1-event0_0.4.1-1_all.deb to main/l/lua-event/liblua5.1-event0_0.4.1-1_all.deb lua-event-dev_0.4.1-1_amd64.deb to main/l/lua-event/lua-event-dev_0.4.1-1_amd64.deb lua-event_0.4.1-1.debian.tar.gz to main/l/lua-event/lua-event_0.4.1-1.debian.tar.gz lua-event_0.4.1-1.dsc to main/l/lua-event/lua-event_0.4.1-1.dsc lua-event_0.4.1-1_amd64.deb to main/l/lua-event/lua-event_0.4.1-1_amd64.deb lua-event_0.4.1.orig.tar.gz to main/l/lua-event/lua-event_0.4.1.orig.tar.gz -- 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/e1sam8g-0006pq...@franck.debian.org
Accepted memchan 2.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 30 May 2012 09:38:40 +0400 Source: memchan Binary: tcl-memchan tcl-memchan-dev Architecture: source i386 Version: 2.3-2 Distribution: unstable Urgency: low Maintainer: Sergei Golovan sgolo...@debian.org Changed-By: Sergei Golovan sgolo...@debian.org Description: tcl-memchan - Tcl extension for in-memory channels - runtime library tcl-memchan-dev - Tcl extension for in-memory channels - development files Changes: memchan (2.3-2) unstable; urgency=low . * Renamed libmemchan-tcl into tcl-memchan and libmemchan-tcl-dev into tcl-memchan-dev to comply the Debian Tcl/Tk policy. * Bumped debhelper compatibility version to 8. * Switched to 3.0 (quilt) source package format. * Added hardened build flags using dpkg-buildflags. * Bumped standards version to 3.9.3. * Use sf redirector in debian/watch uscan control file. Checksums-Sha1: 09122f617e57234cd85f0ffc61f3cb8cd658cbec 1059 memchan_2.3-2.dsc 7eedd356d59a800f254126d62d7124e0f2019413 5400 memchan_2.3-2.debian.tar.gz cd69464cfa9752146e99a5ee152be1964f2e9dfa 52672 tcl-memchan_2.3-2_i386.deb b8bf5b07823d19de506cc0dc90e74e68fd2e3436 26396 tcl-memchan-dev_2.3-2_i386.deb Checksums-Sha256: 15a5e6fd458859cc85eba6c6d484755a938f0823fea93ae991917dac1f663cc7 1059 memchan_2.3-2.dsc 99262161ede90ee24a66a2207e5d9b9cfe14073011edfecf2c05c652ebe0bec1 5400 memchan_2.3-2.debian.tar.gz d7716067e383acd0c3b52b0d708d363bc9f8f963d6e55d244506177bfcb889af 52672 tcl-memchan_2.3-2_i386.deb a7b443da3ff6b74bc0182668df850b2782a9efa4a797522a603c59e5337c34f6 26396 tcl-memchan-dev_2.3-2_i386.deb Files: a6994e53f227856326b6084a877196d5 1059 interpreters optional memchan_2.3-2.dsc 0c6406b082acb153156681e898c8f80c 5400 interpreters optional memchan_2.3-2.debian.tar.gz 1601ef58219d071be2add3599cff14a7 52672 libs optional tcl-memchan_2.3-2_i386.deb f2f08e595d4ed5ca8da670e7b441b8ea 26396 libdevel optional tcl-memchan-dev_2.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFPxiq4IcdH02pGEFIRAqG4AJ9kB5X39yqhQ7J3uJTedUV9gUEZygCfXXTs tdHl+GoLCkd9mKhx97s+ivI= =ctsg -END PGP SIGNATURE- Accepted: memchan_2.3-2.debian.tar.gz to main/m/memchan/memchan_2.3-2.debian.tar.gz memchan_2.3-2.dsc to main/m/memchan/memchan_2.3-2.dsc tcl-memchan-dev_2.3-2_i386.deb to main/m/memchan/tcl-memchan-dev_2.3-2_i386.deb tcl-memchan_2.3-2_i386.deb to main/m/memchan/tcl-memchan_2.3-2_i386.deb -- 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/e1sam8r-0006sg...@franck.debian.org
Accepted opencv 2.4.0+dfsg-0exp1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 23 May 2012 12:42:17 +0900 Source: opencv Binary: opencv-doc libcv-dev libcv2.4 libhighgui-dev libhighgui2.4 libcvaux-dev libcvaux2.4 libopencv-dev libopencv-core-dev libopencv-core2.4 libopencv-ml-dev libopencv-ml2.4 libopencv-imgproc-dev libopencv-imgproc2.4 libopencv-video-dev libopencv-video2.4 libopencv-objdetect-dev libopencv-objdetect2.4 libopencv-highgui-dev libopencv-highgui2.4 libopencv-calib3d-dev libopencv-calib3d2.4 libopencv-flann-dev libopencv-flann2.4 libopencv-features2d-dev libopencv-features2d2.4 libopencv-legacy-dev libopencv-legacy2.4 libopencv-contrib-dev libopencv-contrib2.4 libopencv-ts-dev libopencv-ts2.4 libopencv-photo-dev libopencv-photo2.4 libopencv-videostab-dev libopencv-videostab2.4 libopencv-stitching-dev libopencv-stitching2.4 python-opencv Architecture: source all amd64 Version: 2.4.0+dfsg-0exp1 Distribution: experimental Urgency: low Maintainer: Debian Science Team debian-science-maintain...@lists.alioth.debian.org Changed-By: Nobuhiro Iwamatsu iwama...@debian.org Description: libcv-dev - Translation package for libcv-dev libcv2.4 - computer vision library - libcv* translation package libcvaux-dev - Translation package for libcvaux-dev libcvaux2.4 - computer vision library - libcvaux translation package libhighgui-dev - Translation package for libhighgui-dev libhighgui2.4 - computer vision library - libhighgui translation package libopencv-calib3d-dev - development files for libopencv-calib3d libopencv-calib3d2.4 - computer vision Camera Calibration library libopencv-contrib-dev - development files for libopencv-contrib libopencv-contrib2.4 - computer vision contrib library libopencv-core-dev - development files for libopencv-core libopencv-core2.4 - computer vision core library libopencv-dev - development files for opencv libopencv-features2d-dev - development files for libopencv-features2d libopencv-features2d2.4 - computer vision Feature Detection and Descriptor Extraction libra libopencv-flann-dev - development files for libopencv-flann libopencv-flann2.4 - computer vision Clustering and Search in Multi-Dimensional spaces libopencv-highgui-dev - development files for libopencv-highgui libopencv-highgui2.4 - computer vision High-level GUI and Media I/O library libopencv-imgproc-dev - development files for libopencv-imgproc libopencv-imgproc2.4 - computer vision Image Processing library libopencv-legacy-dev - development files for libopencv-legacy libopencv-legacy2.4 - computer vision legacy library libopencv-ml-dev - development files for libopencv-ml libopencv-ml2.4 - computer vision Machine Learning library libopencv-objdetect-dev - development files for libopencv-objdetect libopencv-objdetect2.4 - computer vision Object Detection library libopencv-photo-dev - development files for libopencv-photo2.4 libopencv-photo2.4 - computer vision photo library libopencv-stitching-dev - development files for libopencv-stitching libopencv-stitching2.4 - computer vision stitching library libopencv-ts-dev - development files for libopencv-ts2.4 libopencv-ts2.4 - computer vision ts library libopencv-video-dev - development files for libopencv-video libopencv-video2.4 - computer vision Video analysis library libopencv-videostab-dev - development files for libopencv-videostab2.4 libopencv-videostab2.4 - computer vision video stabilization library opencv-doc - OpenCV documentation and examples python-opencv - Python bindings for the computer vision library Closes: 671377 Changes: opencv (2.4.0+dfsg-0exp1) experimental; urgency=low . * New upstream release. (Closes: 671377) - Add stitching, ts, videostab and photo packages. - Remove gpu package. * Update debian/control. - Bumped Standards-Version to 3.9.3. No changes needed. - Update Homepage field. * Update debian/rules. - Remove unnecessary option of build config. * Update patches. - 0005-build-static-libs.patch - 0007-typos-in-strings-docs.patch - 0013_drop_asm_types_h_kfreebsd.patch Checksums-Sha1: 40338d9e399be3b80ac64719bbb5d14ab4ea57c1 4875 opencv_2.4.0+dfsg-0exp1.dsc ac3434d06516fc16a4c2154bd3ede8a2f0685476 51291854 opencv_2.4.0+dfsg.orig.tar.gz 46a6265621bcc780cc6b6e29a50d13d44ed04e4f 24450 opencv_2.4.0+dfsg-0exp1.debian.tar.gz 807e1fce18fe37c9ba828563cc984669657b1b31 15550160 opencv-doc_2.4.0+dfsg-0exp1_all.deb 74474fd8c4f94f6442c75fec79fa891c171c70ec 12996 libcv-dev_2.4.0+dfsg-0exp1_amd64.deb 59d82d8f2b193f208d8aaa444bd543bb784fe912 10584 libcv2.4_2.4.0+dfsg-0exp1_all.deb b10425bebf59aee74d7bd0d4f74dbce2ffd0816e 11572 libhighgui-dev_2.4.0+dfsg-0exp1_amd64.deb ea5fc1dca525df2a59c23f470cb010b50d8c5b9b 10534 libhighgui2.4_2.4.0+dfsg-0exp1_all.deb 9f7eb52b7ee942901728cf97ebcc2060463d250b 11838 libcvaux-dev_2.4.0+dfsg-0exp1_amd64.deb 1bf93a48fdfa11a1db8037e15b1ef761d264fa29 10590 libcvaux2.4_2.4.0+dfsg-0exp1_all.deb
Accepted subversion 1.6.17dfsg-3.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 15:49:32 +0200 Source: subversion Binary: subversion libsvn1 libsvn-dev libsvn-doc libapache2-svn python-subversion subversion-tools libsvn-jni libsvn-java libsvn-perl libsvn-ruby1.8 libsvn-ruby Architecture: source all amd64 Version: 1.6.17dfsg-3.1 Distribution: unstable Urgency: low Maintainer: Peter Samuelson pe...@p12n.org Changed-By: Ondřej Surý ond...@debian.org Description: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-jni - Java native interface bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion Closes: 621460 624810 629952 669494 670034 Changes: subversion (1.6.17dfsg-3.1) unstable; urgency=low . * Non-maintainer upload * Disable test-suite which was broken by apr 1.4.6 update (Closes: #669494) * Also rescue on Errno::EINVAL (Closes: #624810, #629952) * Split libsvn-java to libsvn-java and libsvn-jni (Closes: #670034) * Depend on generic libdb-dev and db-util (Closes: #621460) * Install java files prior to dh_install -i call * Declare proper relationships between -jni and -java packages Checksums-Sha1: b741a5119ce4f2e43cc9c0430545d55e806aad37 2352 subversion_1.6.17dfsg-3.1.dsc 28c520f1bcda99df5f705a9b6c790cfc1fd5d775 106881 subversion_1.6.17dfsg-3.1.diff.gz 995a678b6656e447cef3437413742981a3dddfcd 2079854 libsvn-doc_1.6.17dfsg-3.1_all.deb 8100330be6da9433a36b849282f72da44b88708c 221490 subversion-tools_1.6.17dfsg-3.1_all.deb 4b80b89c0baa7568ec959c94ac86504e04a14a38 210936 libsvn-java_1.6.17dfsg-3.1_all.deb 1ff8a7fe37b3d5448883ee7f8ae077ea97cfb0c6 762 libsvn-ruby_1.6.17dfsg-3.1_all.deb 79be13ad6161f2de173bdd5eb2054f366a3e4e89 1318218 subversion_1.6.17dfsg-3.1_amd64.deb 31b2a18b7d6758f9b41e079abc4b3659486ee10e 1001166 libsvn1_1.6.17dfsg-3.1_amd64.deb 8d700dcd5a9498d3f5566c50c12e94df81d6a257 1504288 libsvn-dev_1.6.17dfsg-3.1_amd64.deb a525e91156e38d2ed10540fe306f9c596988deeb 173008 libapache2-svn_1.6.17dfsg-3.1_amd64.deb 6998d5a8320c57fa02d002af36fe8347c27b078d 1340762 python-subversion_1.6.17dfsg-3.1_amd64.deb 2179c4d02a04ed0564cfab04f9b3427f8f1fd8f9 192914 libsvn-jni_1.6.17dfsg-3.1_amd64.deb fedc5f944eac3e0dab66a77bee997c1823026f16 1081228 libsvn-perl_1.6.17dfsg-3.1_amd64.deb dbcf678db9d304f635c74d0191c60da66d0851a8 627152 libsvn-ruby1.8_1.6.17dfsg-3.1_amd64.deb Checksums-Sha256: a63d6756fa36fe23e62b2e4d49e9ee077b548fa4bdff3c7710d7a3d2348483cb 2352 subversion_1.6.17dfsg-3.1.dsc 78a39ca1c21a6a8b36b9073ca397d9026485dfcb4109fb7ec60bb724b85266eb 106881 subversion_1.6.17dfsg-3.1.diff.gz f8b6265e389bab50fd81afb91f3628a2f033b7b5e62fe59273ffdac94946c481 2079854 libsvn-doc_1.6.17dfsg-3.1_all.deb 75b8a27f0217a0c573343b33110e35781e3233bbffac1412ab1cf02a9bff2cae 221490 subversion-tools_1.6.17dfsg-3.1_all.deb 2230f722917a1ecc986bd11978619e4006e43be53e3d67f866c31a19f2b96cb8 210936 libsvn-java_1.6.17dfsg-3.1_all.deb 274ab71a65abe07c57a77c319c0768466473637fb83a47fed91b7b74f5f2d175 762 libsvn-ruby_1.6.17dfsg-3.1_all.deb ff76ff045776d0ea436d477d53752bd68347e77d09ee42e993aa6becc3918b7f 1318218 subversion_1.6.17dfsg-3.1_amd64.deb 9f55a686fbf70b71402c37097dfec1cc8021b1b0f1f53e06eb0e3f30b5262bea 1001166 libsvn1_1.6.17dfsg-3.1_amd64.deb 5e2ea8426e2370bf297d1fed3c93c88b905c96d93cbc11f992c9372970464e1b 1504288 libsvn-dev_1.6.17dfsg-3.1_amd64.deb 6e9fc7a606fca4848e7e50976f55bf1edf951fe22b4a7e07d4e9c2efb85c270f 173008 libapache2-svn_1.6.17dfsg-3.1_amd64.deb 0d7930345d85bba1341e84256fbcd535c8b3d2923644f10f6126f245abbefd08 1340762 python-subversion_1.6.17dfsg-3.1_amd64.deb b5c6e4fd74a6c90f23257c18561b70b1e1efdccc29865b1556aea534d63dba83 192914 libsvn-jni_1.6.17dfsg-3.1_amd64.deb cea36ab0c7442ffa971859e6266fed1b7a9d7d09f04ffa1708441fc0e1b5253c 1081228 libsvn-perl_1.6.17dfsg-3.1_amd64.deb 8c6db78e130b0bb08c35cf56b8477febbf06257cae9c707acea61071ff21a6fd 627152 libsvn-ruby1.8_1.6.17dfsg-3.1_amd64.deb Files: d088f9b99e4978955f23783146b21b4f 2352 vcs optional subversion_1.6.17dfsg-3.1.dsc a341e41ce8f41c2c4475fb9f9f29f573 106881 vcs optional subversion_1.6.17dfsg-3.1.diff.gz 82c8ea6733f7c415eae0e30f2b499d0c 2079854 doc extra libsvn-doc_1.6.17dfsg-3.1_all.deb 363f3f23a4f8c3035389648e4fe0e90d 221490 vcs extra subversion-tools_1.6.17dfsg-3.1_all.deb 8b604aa77ce8ff6faa20d4ccacc3539a 210936 java optional libsvn-java_1.6.17dfsg-3.1_all.deb 585dd1195a12f2e80d5c3ffe85dfb437 762 ruby optional libsvn-ruby_1.6.17dfsg-3.1_all.deb 3f462556dc5b23f303ed7545365d36b3 1318218 vcs optional
Accepted texlive-extra 2012.20120529-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 19:19:02 +0900 Source: texlive-extra Binary: texlive-bibtex-extra texlive-extra-utils texlive-font-utils texlive-formats-extra texlive-generic-extra texlive-math-extra texlive-plain-extra texlive-latex-extra texlive-fonts-extra texlive-music texlive-games texlive-pstricks texlive-publishers texlive-humanities texlive-science texpower pdfjam texlive-latex3 texlive-fonts-extra-doc texlive-humanities-doc texlive-latex-extra-doc texlive-pstricks-doc texlive-publishers-doc texlive-science-doc Architecture: source all Version: 2012.20120529-1 Distribution: unstable Urgency: low Maintainer: Debian TeX Maintainers debian-tex-ma...@lists.debian.org Changed-By: Norbert Preining prein...@debian.org Description: pdfjam - TeX Live: transitional dummy package texlive-bibtex-extra - TeX Live: Extra BibTeX styles texlive-extra-utils - TeX Live: TeX auxiliary programs texlive-font-utils - TeX Live: Graphics and font utilities texlive-fonts-extra - TeX Live: Extra fonts texlive-fonts-extra-doc - TeX Live: Documentation files for texlive-fonts-extra texlive-formats-extra - TeX Live: Extra formats texlive-games - TeX Live: Games typesetting texlive-generic-extra - TeX Live: Extra generic packages texlive-humanities - TeX Live: Humanities packages texlive-humanities-doc - TeX Live: Documentation files for texlive-humanities texlive-latex-extra - TeX Live: LaTeX supplementary packages texlive-latex-extra-doc - TeX Live: Documentation files for texlive-latex-extra texlive-latex3 - TeX Live: transitional dummy package texlive-math-extra - TeX Live: Advanced math typesetting texlive-music - TeX Live: Music typesetting texlive-plain-extra - TeX Live: Plain TeX supplementary packages texlive-pstricks - TeX Live: PSTricks packages texlive-pstricks-doc - TeX Live: Documentation files for texlive-pstricks texlive-publishers - TeX Live: Support for publishers, theses, standards, conferences, texlive-publishers-doc - TeX Live: Documentation files for texlive-publishers texlive-science - TeX Live: Typesetting for natural and computer sciences texlive-science-doc - TeX Live: Documentation files for texlive-science texpower - TeX Live: transitional dummy package Closes: 673797 Changes: texlive-extra (2012.20120529-1) unstable; urgency=low . * new upstream checkout * add transitional dummy texlive-latex3 package to upgrade to texlive-latex-recommended (Closes: #673797) * don't ship STIX fonts, but link from fonts-stix and depend on it Checksums-Sha1: 775a98f0253541097c5dc29a3ae5c88f4f846ba4 2668 texlive-extra_2012.20120529-1.dsc e39a9f348858f46f4f44488781b1f166747eac2b 740989492 texlive-extra_2012.20120529.orig.tar.xz b0b2208df46a40ec0c47782cee1a460318e3312f 153833 texlive-extra_2012.20120529-1.debian.tar.gz fbf2a1435dc7b5c98b1a1eb06ed3a6cfa28e91af 25443214 texlive-bibtex-extra_2012.20120529-1_all.deb df091f8a3cab935dce3c7cc0b2c77757c2f93bea 2547666 texlive-extra-utils_2012.20120529-1_all.deb 2de428c02c65cb7c61ce64ab33bd391e79a5365d 1696182 texlive-font-utils_2012.20120529-1_all.deb 7a1fe4d2ce31969207ca8d7a7160395add6089c4 1945186 texlive-formats-extra_2012.20120529-1_all.deb 6aa4a42357f436311c366a847670f1b4ed6d9ae0 7232784 texlive-generic-extra_2012.20120529-1_all.deb 17caab3df2c66ead6351c53ffcc218bcfb62b6cb 11720230 texlive-math-extra_2012.20120529-1_all.deb bf9428a8264387ac40c699c2c36ab71fa89d1b05 2738544 texlive-plain-extra_2012.20120529-1_all.deb 72986679397e5fd7e6daa61f4398495ce34d08d7 6380468 texlive-latex-extra_2012.20120529-1_all.deb 302a8f7007818a55e001c925876f885b2ce3c4a8 129639652 texlive-fonts-extra_2012.20120529-1_all.deb 02b15305c46125d19c957821a818f723262101bf 6749984 texlive-music_2012.20120529-1_all.deb 23c1014e29e28a22627baec1ef953e7f7f07d3d1 3108856 texlive-games_2012.20120529-1_all.deb 9bdce1612e1f1acbe9ba070e30ffab5456b4f3e3 25478776 texlive-pstricks_2012.20120529-1_all.deb efa113f95622ac1af1238cab835d639e5f71cd50 1567154 texlive-publishers_2012.20120529-1_all.deb ca64912089ae4de7cd4aaf1101c2d2b7414dc9fe 316016 texlive-humanities_2012.20120529-1_all.deb a1c45dceb4033b0de6bd638046aaeaeb0dfea01b 2059418 texlive-science_2012.20120529-1_all.deb 26f9363634e56d5b90d63ccd7fbe55ecb2e4dc71 50168 texpower_2012.20120529-1_all.deb 1b54d59ff49dd1be85b516fc59583391fea8b1b7 50162 pdfjam_2012.20120529-1_all.deb fb536c44a8b791f2e260a8fd6e3787007eed0fec 50158 texlive-latex3_2012.20120529-1_all.deb 4ac5e2530ef2a3df2197a2c3339ffb7054c2b919 57292688 texlive-fonts-extra-doc_2012.20120529-1_all.deb 9cf33a44c4114c98a31bad0a3118514a4d5c7dbe 10821498 texlive-humanities-doc_2012.20120529-1_all.deb f4b9efc33dd0e177948a8de36c3ab5be96cf5315 292156304 texlive-latex-extra-doc_2012.20120529-1_all.deb 0f6a5133fc7daf93014d1985ef048cd9200b1689 69893286 texlive-pstricks-doc_2012.20120529-1_all.deb 2087fc281ab33b12728f46cd0b02107fbe5197dc 49773716
Accepted xml-light 2.2-13 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 May 2012 15:17:26 +0200 Source: xml-light Binary: libxml-light-ocaml-dev libxml-light-ocaml Architecture: source amd64 Version: 2.2-13 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org Changed-By: Mehdi Dogguy me...@debian.org Description: libxml-light-ocaml - mininal XML parser and printer for OCaml (runtime package) libxml-light-ocaml-dev - mininal XML parser and printer for OCaml (development package) Closes: 647299 Changes: xml-light (2.2-13) unstable; urgency=low . * Provide a .cmxs plugin in libxml-light-ocaml-dev (Closes: #647299). Thanks to Benjamin Sigonneau for the patch. * Convert source package to 3.0 (quilt) format. - Fixes build-depends-on-obsolete-package (dpatch) - Fixes debian-rules-uses-deprecated-makefile (dpatch.mk) * Bump Standards-Version to 3.9.2, no changes needed. * Add libxml-light-ocaml, needed to ship .cmxs files. - libxml-light-ocaml Breaks/Replaces the old binary package libxml-light-ocaml-dev ( 2.2-13). Checksums-Sha1: ab70c4ef83d49bf967f271e12949a21b1996b36f 1773 xml-light_2.2-13.dsc b7302ced471b30cdbffcc51df20529593b834335 5206 xml-light_2.2-13.debian.tar.gz 000c4a4a92b73a64f627c6a78d4a8ad96167f869 62048 libxml-light-ocaml-dev_2.2-13_amd64.deb d86980cac44d1c6d2f955596d2f1c278db7e9ae3 52638 libxml-light-ocaml_2.2-13_amd64.deb Checksums-Sha256: f451fa8db13c6723afd0e8e7c14543ca54e7a924118f93aab2731ca401dd02a4 1773 xml-light_2.2-13.dsc 68afe8156537e163ae1c6e286a8ec7e85b47785d03e3b90f8b1fa9d1c698e33d 5206 xml-light_2.2-13.debian.tar.gz 9a4ea4819beef635b491a77ff47901fa374a7601847697fd4544f49a1b8efd46 62048 libxml-light-ocaml-dev_2.2-13_amd64.deb 34f41b28e2a880854b05cd91144f7fee5932d3052276dd21fb0565ef881a92ca 52638 libxml-light-ocaml_2.2-13_amd64.deb Files: 454031a76bb61fb7cf347e6d2c895e97 1773 ocaml optional xml-light_2.2-13.dsc 8e0020109d82b0f2afab0991ab802541 5206 ocaml optional xml-light_2.2-13.debian.tar.gz b77aae4c13f8e7a3b95d2ef03342e67b 62048 ocaml optional libxml-light-ocaml-dev_2.2-13_amd64.deb b641512385e40d2bc8796ee10a07ad3e 52638 ocaml optional libxml-light-ocaml_2.2-13_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJPxOb9AAoJEDe1GR0FRlJoajYH/3Qr2zShKghTcpc5rXHcVa6X WDNFKe2e7AaZb/3PruYurotWiPysB6X53NwFxYlU4SZOXqPDXhirJeyzHQmUJKo5 JVxV9UFsL36Kq0k1iWx/aA0uLkSxvhF4e0yNtyZzRv3HAroIM++TgGhvieVdwLp+ //6uCMZxF7pyuWXf/r4T+i5lbGycgNmbSyyQ+E4PG1RWNkUhhMRfdg9Gos36Ki7u FeMKSMftVWn39S4kxLa336J6gF67R4q6PzahClztkVnyqgdPX/QbMosojRXzk7/a pdS5morOvWWCeST0S2zLLQJN9GjvXNuk7CMCdR4knabJq0/KsY2uH+NeFNejHg4= =5Gzy -END PGP SIGNATURE- Accepted: libxml-light-ocaml-dev_2.2-13_amd64.deb to main/x/xml-light/libxml-light-ocaml-dev_2.2-13_amd64.deb libxml-light-ocaml_2.2-13_amd64.deb to main/x/xml-light/libxml-light-ocaml_2.2-13_amd64.deb xml-light_2.2-13.debian.tar.gz to main/x/xml-light/xml-light_2.2-13.debian.tar.gz xml-light_2.2-13.dsc to main/x/xml-light/xml-light_2.2-13.dsc -- 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/e1samcg-0007ym...@franck.debian.org
Accepted atlas 3.8.4-4~exp9 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 31 May 2012 19:55:12 +0200 Source: atlas Binary: libatlas3-base libatlas3gf-base libatlas-base-dev libatlas-dev libatlas-test libatlas-doc Architecture: source all amd64 Version: 3.8.4-4~exp9 Distribution: experimental Urgency: low Maintainer: Debian Science Team debian-science-maintain...@lists.alioth.debian.org Changed-By: Sylvestre Ledru sylves...@debian.org Description: libatlas-base-dev - Automatically Tuned Linear Algebra Software, generic static libatlas-dev - Automatically Tuned Linear Algebra Software, C header files libatlas-doc - Automatically Tuned Linear Algebra Software, documentation libatlas-test - Automatically Tuned Linear Algebra Software, test programs libatlas3-base - Automatically Tuned Linear Algebra Software, generic shared libatlas3gf-base - Transitional package to libatlas3-base Changes: atlas (3.8.4-4~exp9) experimental; urgency=low . * Drop the old conflict on libblas-3.so Checksums-Sha1: 5d1e8c3cff3a0e1a862f2565687b1647e15c1448 1762 atlas_3.8.4-4~exp9.dsc b70e958f3ad19c8c401f504ed9f19da18de08dfc 32487 atlas_3.8.4-4~exp9.debian.tar.gz 21c683edf6b5a803ee29d37d09811f44f0ff5a2a 42274 libatlas-dev_3.8.4-4~exp9_all.deb d96b370396464738a6c82bcdc5ccd14d3a961fd2 1128200 libatlas-doc_3.8.4-4~exp9_all.deb 840e39991e73461472262670336fa17c7ce6cd3a 7324330 libatlas3-base_3.8.4-4~exp9_amd64.deb 24bdaae69f3107bd9d420d81910f07dacd7509c4 33414 libatlas3gf-base_3.8.4-4~exp9_amd64.deb 5ec4d48412708af649c6e8fb264491cbdf56c1b9 8680772 libatlas-base-dev_3.8.4-4~exp9_amd64.deb 05a98283ec32dc4ec48a11d9125565b40a1f8c9f 15278026 libatlas-test_3.8.4-4~exp9_amd64.deb Checksums-Sha256: 126466f77c27d5f9ee0a536d7949e3e3d39cb5e990464627f81c26e554bb9ab3 1762 atlas_3.8.4-4~exp9.dsc 0d5648b34a587a2b7c9cafeb1f84680f31bef5083c8dd526fc604ac98430ffc4 32487 atlas_3.8.4-4~exp9.debian.tar.gz dfcdf6f0f19a08f11c065fcaf1c981441be2ed6fb6f1bd2f96d89314a937fe7c 42274 libatlas-dev_3.8.4-4~exp9_all.deb fe85e13c55082a6fa071bdbdfb1cda7d3b33fa5541d6e46158542e6086ea7ffc 1128200 libatlas-doc_3.8.4-4~exp9_all.deb a737619d7ea15a7d939032ae9c6fb04c12b96ca89ad412d0626b800d637cc661 7324330 libatlas3-base_3.8.4-4~exp9_amd64.deb df68e2d51e910040dbb3eb3b8c233fcc2498dac57ab5cf45be41ff249eee8a04 33414 libatlas3gf-base_3.8.4-4~exp9_amd64.deb 885151c349be44f3d6310b9ecfc909c226aa201e8fd5880acd5950e34ffa629e 8680772 libatlas-base-dev_3.8.4-4~exp9_amd64.deb 72a100e73329cd1d6bc3157f98a0784462ad8cc1a91f0a4fe1eb87b5c9d0fa7d 15278026 libatlas-test_3.8.4-4~exp9_amd64.deb Files: e58a064cf4dee1b8303b530f0d21b693 1762 devel optional atlas_3.8.4-4~exp9.dsc 3be7cc94b12067721e3ec3dc8b41cb80 32487 devel optional atlas_3.8.4-4~exp9.debian.tar.gz f8427d83cbf161bed3e36bd0b2722495 42274 libdevel optional libatlas-dev_3.8.4-4~exp9_all.deb cfcf866648ba11000787feaa8b323071 1128200 doc optional libatlas-doc_3.8.4-4~exp9_all.deb f7782da451f523ee6c83814da3305099 7324330 libs optional libatlas3-base_3.8.4-4~exp9_amd64.deb 35882b3819aa3471b9fed27cb54119b4 33414 libs optional libatlas3gf-base_3.8.4-4~exp9_amd64.deb 16fc2b8611050d7be55e5c3083088684 8680772 libdevel optional libatlas-base-dev_3.8.4-4~exp9_amd64.deb e8dfb08bcfdbca08d70ac11fe811f74b 15278026 devel optional libatlas-test_3.8.4-4~exp9_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/IbKQACgkQiOXXM92JlhC/JwCfT4esCN68E+ESBMI37C6Ubtzg l5YAoJ2arJCzn9lhz1DA4IssCmySpcno =bN8h -END PGP SIGNATURE- Accepted: atlas_3.8.4-4~exp9.debian.tar.gz to main/a/atlas/atlas_3.8.4-4~exp9.debian.tar.gz atlas_3.8.4-4~exp9.dsc to main/a/atlas/atlas_3.8.4-4~exp9.dsc libatlas-base-dev_3.8.4-4~exp9_amd64.deb to main/a/atlas/libatlas-base-dev_3.8.4-4~exp9_amd64.deb libatlas-dev_3.8.4-4~exp9_all.deb to main/a/atlas/libatlas-dev_3.8.4-4~exp9_all.deb libatlas-doc_3.8.4-4~exp9_all.deb to main/a/atlas/libatlas-doc_3.8.4-4~exp9_all.deb libatlas-test_3.8.4-4~exp9_amd64.deb to main/a/atlas/libatlas-test_3.8.4-4~exp9_amd64.deb libatlas3-base_3.8.4-4~exp9_amd64.deb to main/a/atlas/libatlas3-base_3.8.4-4~exp9_amd64.deb libatlas3gf-base_3.8.4-4~exp9_amd64.deb to main/a/atlas/libatlas3gf-base_3.8.4-4~exp9_amd64.deb -- 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/e1samcy-0007fd...@franck.debian.org
Accepted wxwidgets2.8 2.8.12.1-11 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 01 Jun 2012 05:08:47 + Source: wxwidgets2.8 Binary: libwxbase2.8-0 libwxbase2.8-dev libwxbase2.8-dbg libwxgtk2.8-0 libwxgtk2.8-dev libwxgtk2.8-dbg python-wxgtk2.8 python-wxgtk2.8-dbg python-wxversion python-wxtools wx-common wx2.8-headers wx2.8-i18n wx2.8-doc wx2.8-examples libwxmsw2.8-dev libwxmsw2.8-dbg wx2.8-headers-msw Architecture: source amd64 all Version: 2.8.12.1-11 Distribution: unstable Urgency: low Maintainer: wxWidgets Maintainers freewx-ma...@lists.alioth.debian.org Changed-By: Olly Betts o...@survex.com Description: libwxbase2.8-0 - wxBase library (runtime) - non-GUI support classes of wxWidgets t libwxbase2.8-dbg - wxBase library (debug) - non-GUI support classes of wxWidgets too libwxbase2.8-dev - wxBase library (development) - non-GUI support classes of wxWidge libwxgtk2.8-0 - wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime) libwxgtk2.8-dbg - wxWidgets Cross-platform C++ GUI toolkit (GTK+ debug) libwxgtk2.8-dev - wxWidgets Cross-platform C++ GUI toolkit (GTK+ development) libwxmsw2.8-dbg - wxMSW mingw32msvc-cross (debug) libwxmsw2.8-dev - wxMSW mingw32msvc-cross python-wxgtk2.8 - wxWidgets Cross-platform C++ GUI toolkit (wxPython binding) python-wxgtk2.8-dbg - wxWidgets Cross-platform C++ GUI toolkit (wxPython binding, debug python-wxtools - wxWidgets Cross-platform C++ GUI toolkit (wxPython common files) python-wxversion - wxWidgets Cross-platform C++ GUI toolkit (wxPython version select wx-common - wxWidgets Cross-platform C++ GUI toolkit (common support files) wx2.8-doc - wxWidgets Cross-platform C++ GUI toolkit (documentation) wx2.8-examples - wxWidgets Cross-platform C++ GUI toolkit (examples) wx2.8-headers - wxWidgets Cross-platform C++ GUI toolkit (header files) wx2.8-headers-msw - Extra wxWidgets headers for mingw32msvc-cross wx2.8-i18n - wxWidgets Cross-platform C++ GUI toolkit (i18n support) Closes: 242737 Changes: wxwidgets2.8 (2.8.12.1-11) unstable; urgency=low . * It looks like upstream may not make another 2.8 release, and if they do it's unlikely to happen before the freeze, so backport several simple but useful patches from upstream's 2.8 SVN branch: . + ico-saving-buffer-overrun.patch + richtextxml-fix.patch + slider-label-update.patch + wxclipboard-getdata.patch + wxvlistboxcombopopup-wxcbsort.patch + wxstatictext-rtl-alignright.patch + improve-bmp-decoding.patch + fix-aui-dock-crash.patch + wxdatetime-chained.patch (Closes: #242737) + Update Italian and Hungarian i18n. + Add Tamil and Arabic i18n. . * Fix typo in package descriptions. Checksums-Sha1: b68fb84494436125d317c771e96a9011da1d1bd7 3261 wxwidgets2.8_2.8.12.1-11.dsc f35262fafa7dcfd50d6ddde7c053416233740cd1 240511 wxwidgets2.8_2.8.12.1-11.debian.tar.gz 0424eb67f55a048c3c52765b5cbebd11703075b4 677780 libwxbase2.8-0_2.8.12.1-11_amd64.deb 4e82728f95ca4f507ed9cca8f8cfb55591707b67 106560 libwxbase2.8-dev_2.8.12.1-11_amd64.deb 6ff0277ff2082f9c90c6a9ed970055e563f86c3f 3317816 libwxbase2.8-dbg_2.8.12.1-11_amd64.deb f135b12ba4f33c4702a39abf564000b7bf470c1b 3410726 libwxgtk2.8-0_2.8.12.1-11_amd64.deb ee25af8fda923a572a4933d24e5cead953841b8a 106940 libwxgtk2.8-dev_2.8.12.1-11_amd64.deb 362bb9d314b081546d3763999b34a7747ed83d3d 21840592 libwxgtk2.8-dbg_2.8.12.1-11_amd64.deb 53c574a509f11486ad8c9818f572f220b7dd6938 8577630 python-wxgtk2.8_2.8.12.1-11_amd64.deb 626d90775b706ead24e9e027c3e08df039817433 53244482 python-wxgtk2.8-dbg_2.8.12.1-11_amd64.deb 17809959b8db801c0e532c3f1eb8a66c6c9b2704 128848 wx-common_2.8.12.1-11_amd64.deb f5544e27f41245731efff829ce045942c559793e 1556400 wx2.8-headers_2.8.12.1-11_amd64.deb 1d4731445bae973d95dc0fb994e22bdb2f3e27c9 91726 python-wxversion_2.8.12.1-11_all.deb 94265f46e8abd6647c8d68892fd98ceb21561a2b 92946 python-wxtools_2.8.12.1-11_all.deb bc914086bdcdac4256340ebbf4695185f0a88048 864502 wx2.8-i18n_2.8.12.1-11_all.deb e34042d8576d0c920eaf376240ab2a2358085f80 1992228 wx2.8-doc_2.8.12.1-11_all.deb 88571d7fc9f16950eb6ff0673ccc29ce3e94d2ad 8045814 wx2.8-examples_2.8.12.1-11_all.deb Checksums-Sha256: fcf4b646af262ce229dd335aa36eb6f6d5dd25807ce1e729e25d096dcbaafebc 3261 wxwidgets2.8_2.8.12.1-11.dsc 70d82f9ce9a2b0c0b3277c5089ca1a087cb8c508eb7b10605343608081a0f51b 240511 wxwidgets2.8_2.8.12.1-11.debian.tar.gz 7da7dd767246159d12982919503443edca9cdaba938e40d0d84103ee59db4418 677780 libwxbase2.8-0_2.8.12.1-11_amd64.deb e8a8b21a91c5a502cd75ff21f13d4639323823bf026cc74728224b4548206eb5 106560 libwxbase2.8-dev_2.8.12.1-11_amd64.deb 7891ff470fac25523cfffcd5fac261dec5a7e46ca170b7bb11e0349854ba57ca 3317816 libwxbase2.8-dbg_2.8.12.1-11_amd64.deb 5f739d786d98da92d48fe2b17cfb48ca6ee794b0fc25dcec35ff46753e8940b3 3410726 libwxgtk2.8-0_2.8.12.1-11_amd64.deb 9ce037485da4fa15a947506c50aaae200f083980c2a18e3f3ecdce43105401cc 106940 libwxgtk2.8-dev_2.8.12.1-11_amd64.deb
Accepted biosig4c++ 1.3.0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 24 May 2012 09:22:13 -0400
Source: biosig4c++
Binary: libbiosig1 libbiosig1-dbg libbiosig-dev biosig-tools python-biosig
octave-biosig
Architecture: source amd64
Version: 1.3.0-1
Distribution: unstable
Urgency: low
Maintainer: NeuroDebian Team t...@neuro.debian.net
Changed-By: Yaroslav Halchenko deb...@onerussian.com
Description:
biosig-tools - format conversion tools for biomedical data formats
libbiosig-dev - I/O library for biomedical data - development files
libbiosig1 - I/O library for biomedical data - dynamic library
libbiosig1-dbg - I/O library for biomedical data - debug symbols
octave-biosig - Octave bindings for BioSig library
python-biosig - Python bindings for BioSig library
Changes:
biosig4c++ (1.3.0-1) unstable; urgency=low
.
* Fresh upstream release
- libbiosig now SOVERSION 1, thus libbiosig1{,-dbg} to replace
libbiosig0
* debian/copyright: updated for DEP5
* debian/patches:
- added up_memcpy_str_cast (sent upstream)
- removed up_for_loop_initial (upstreamed)
- removed up_*oct* (no hardcoded octave version information in
upstream Makefile any longer), deb_link_dynamically_python
- removed deb_link_dynamically in favor of specifying LIBEXT=so to
calls to make
- removed deb_use_borrowed_eventcodes: now debian/upstream-extern
provides needed extra external files (from biosig) and gets symlinked
as extern at build time
- refreshed deb_no_mex_copy_upstairs,deb_no_locals
* upstream-files/eventcodes.txt -- refreshed from online
* debian/control:
- new build-depends: gawk, libxml2-dev
- boosted policy to 3.9.3 -- no further changes
Checksums-Sha1:
a9bf97b94f45a3faaebfeaaf80894abd3bb988ed 1671 biosig4c++_1.3.0-1.dsc
7bdb8f08c92197fa8e24005df2098e8e2cf4341f 606359 biosig4c++_1.3.0.orig.tar.gz
78f380e6310aa987470e4ec79c216939c273364f 14731 biosig4c++_1.3.0-1.debian.tar.gz
f5a3ad2e27903895e96a4f381451c0b249ec04c3 325024 libbiosig1_1.3.0-1_amd64.deb
5899df393fefec9585c68e83dcee71f65034c0f3 97708 libbiosig1-dbg_1.3.0-1_amd64.deb
5eef43af4211d1da1115f71635265a599f9b1cd8 406180 libbiosig-dev_1.3.0-1_amd64.deb
c33b07663ed63172fbf86fbb32a46da4dec0f9de 202226 biosig-tools_1.3.0-1_amd64.deb
1989f85efa9d12fe6334ce4c657758cea8df3ad3 39724 python-biosig_1.3.0-1_amd64.deb
882b24d356e768e725c32d0d97ecb84f0a8ea474 24072 octave-biosig_1.3.0-1_amd64.deb
Checksums-Sha256:
94e860a24dca58442e08f96047d0639f58ed2aa280678f1cb865fda598e46019 1671
biosig4c++_1.3.0-1.dsc
120fafa120cb42251593823901e6961d890aadeb7c1547f531d8e9a5a0abe092 606359
biosig4c++_1.3.0.orig.tar.gz
55fd86ad687ef159ecc097c8a0a6fd9b8821766555ecdb20c23542499d9e43c9 14731
biosig4c++_1.3.0-1.debian.tar.gz
8e5a9e8b9b2c19e828acbbf09500f5e490b864f702b0559c4775aa3de78b6f35 325024
libbiosig1_1.3.0-1_amd64.deb
58d04508bc0cf2962ed461fbef445a00fd39d3bcde25b21d3dae921e1827c9ae 97708
libbiosig1-dbg_1.3.0-1_amd64.deb
63564bc7084886c5785108fe243c71b90c8e54bda2b165392c5c41b2bf24ca9d 406180
libbiosig-dev_1.3.0-1_amd64.deb
428408227d541a2aeb028c816daf77527ca876a277ff6c01334bd4730c0f8d10 202226
biosig-tools_1.3.0-1_amd64.deb
9f116092426c20d153a30e9bf2e2575a206a276960e86bf922354674ea9bffde 39724
python-biosig_1.3.0-1_amd64.deb
86d9009915a572f07148b1cae6019fd10a9af2467ecc9d5406a6cb24bce062ab 24072
octave-biosig_1.3.0-1_amd64.deb
Files:
a4e3f0b28dd6129e45df216c736b9c4c 1671 science extra biosig4c++_1.3.0-1.dsc
8083091baa0e635ffa09b3fb3802f9bd 606359 science extra
biosig4c++_1.3.0.orig.tar.gz
f6679eebb7568688ed20127789c07a22 14731 science extra
biosig4c++_1.3.0-1.debian.tar.gz
5f41918b56005b22e81fc9c89d8b38e0 325024 libs extra libbiosig1_1.3.0-1_amd64.deb
bfaf0a5257ade13be453bae8652baf75 97708 debug extra
libbiosig1-dbg_1.3.0-1_amd64.deb
9a5f55f4948d658a4d4aae3ae980ead5 406180 libdevel extra
libbiosig-dev_1.3.0-1_amd64.deb
ae0e9a2916ae2f31b4fc5b955d8f957a 202226 science extra
biosig-tools_1.3.0-1_amd64.deb
5ada01c019595f03645fab049269ab68 39724 python extra
python-biosig_1.3.0-1_amd64.deb
1708bb0c92c078302839b339083062e1 24072 science extra
octave-biosig_1.3.0-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk/G4hgACgkQjRFFY3XAJMi/aQCfd9sQe+l9Tw4asW3J36Jw30N1
lR4An0lIdNZW+LQZtjO9LEVGedHy7Cqt
=k5xy
-END PGP SIGNATURE-
Accepted:
biosig-tools_1.3.0-1_amd64.deb
to main/b/biosig4c++/biosig-tools_1.3.0-1_amd64.deb
biosig4c++_1.3.0-1.debian.tar.gz
to main/b/biosig4c++/biosig4c++_1.3.0-1.debian.tar.gz
biosig4c++_1.3.0-1.dsc
to main/b/biosig4c++/biosig4c++_1.3.0-1.dsc
biosig4c++_1.3.0.orig.tar.gz
to main/b/biosig4c++/biosig4c++_1.3.0.orig.tar.gz
libbiosig-dev_1.3.0-1_amd64.deb
to main/b/biosig4c++/libbiosig-dev_1.3.0-1_amd64.deb
libbiosig1-dbg_1.3.0-1_amd64.deb
to main/b/biosig4c++/libbiosig1-dbg_1.3.0-1_amd64.deb
libbiosig1_1.3.0-1_amd64.deb
to main/b/biosig4c++/libbiosig1_1.3.0-1_amd64.deb
Accepted colord 0.1.21-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 30 May 2012 17:16:15 +1000 Source: colord Binary: libcolord-dev libcolord1 libcolord-gtk1 libcolord-gtk-dev colord gir1.2-colord-1.0 Architecture: source amd64 Version: 0.1.21-1 Distribution: unstable Urgency: low Maintainer: Christopher James Halse Rogers r...@ubuntu.com Changed-By: Christopher James Halse Rogers r...@ubuntu.com Description: colord - system service to manage device colour profiles -- system daemon gir1.2-colord-1.0 - GObject introspection data for the colord library libcolord-dev - system service to manage device colour profiles -- development fi libcolord-gtk-dev - system service to manage device colour profiles -- runtime libcolord-gtk1 - system service to manage device colour profiles -- runtime libcolord1 - system service to manage device colour profiles -- runtime Changes: colord (0.1.21-1) unstable; urgency=low . * New upstream version * debian/patches/01_fix_colord_sane.diff: - Drop; included in new upstream version * debian/rules: * debian/control: * debian/libcolord-dev.install: * debian/libcolord-gtk1.install: * debian/libcolord-gtk1.symbols: * debian/libcolord-gtk-dev.install - Add libcolord-gtk1 library * debian/libcolord1.symbols: - Update for new upstream * debian/rules: - Enable hardning flags * debian/rules: - Enable parallel builds * debian/cd-fix-profile.1: * debian/colord.manpages: - Drop local manpage; now shipped upstream Checksums-Sha1: 2be4848080d1815796059ff6de0d9e80e302ce7a 2420 colord_0.1.21-1.dsc dbf981beec70e81c45cf46b150f426fc1eb56c24 553424 colord_0.1.21.orig.tar.xz feb5d8d45a9751ec757f4034a1c642828dcefafa 7314 colord_0.1.21-1.debian.tar.gz 3976171fb96c9c52b865784fdfbb2f951e0c14c0 94274 libcolord-dev_0.1.21-1_amd64.deb 2817c6eb9a14f30c8863a2e09579797334810fa2 116128 libcolord1_0.1.21-1_amd64.deb 675735b30a664d6e89247e4f38c70b56eb1f1b15 68618 libcolord-gtk1_0.1.21-1_amd64.deb 9ccba094385dedd51c32341c11619c1fdbee4100 63256 libcolord-gtk-dev_0.1.21-1_amd64.deb 8c9e4a68831aed4eb132f67cace8b80a65b56121 239194 colord_0.1.21-1_amd64.deb 5831a944d39d2c3319882ca8aef8df9337a5df8f 72622 gir1.2-colord-1.0_0.1.21-1_amd64.deb Checksums-Sha256: 7a77a933388568017dbff811c8fd81f0a2d8188b90ac6aeb4d5b542296a714a2 2420 colord_0.1.21-1.dsc 360b896b0d2a35970a0cd42e448ea327d789f309ff95022190c4d33bb8b02c30 553424 colord_0.1.21.orig.tar.xz 0f7a6fda288affd3311f0b65aeec210750af7e7799fde41eb6f237ff94a0b407 7314 colord_0.1.21-1.debian.tar.gz dc05d88bab5e32c053f911398584feba118cfcd8bb6d9ccffeb886ec5059fbae 94274 libcolord-dev_0.1.21-1_amd64.deb 26167e81755a3ea4e0ef6256b6af8b420c1b7b182fc5a7e3238a3ce5890a7ae7 116128 libcolord1_0.1.21-1_amd64.deb e404b8f858d7e36773b658295a47c46c89142ede90dfdd18e85c9054a858b031 68618 libcolord-gtk1_0.1.21-1_amd64.deb 79e5d85ac7360ec139c5d723984cd88e2db51368e98db3e01a977e7d06cab2cf 63256 libcolord-gtk-dev_0.1.21-1_amd64.deb 34b21a96827ba9697b23654f112aaebaf82ae67f2153434314049d5282dee937 239194 colord_0.1.21-1_amd64.deb 24a32537c10750b1896b621072fbc78218129604f2d7d48c25128459faf52ca1 72622 gir1.2-colord-1.0_0.1.21-1_amd64.deb Files: 106155167e2937f2865dc02b1b9152e0 2420 graphics optional colord_0.1.21-1.dsc 8028ac0d078efb2584602e7931dd06b2 553424 graphics optional colord_0.1.21.orig.tar.xz db5b8499e065673db9963d70fb08bd4c 7314 graphics optional colord_0.1.21-1.debian.tar.gz cf66f83dd80c55ad9836ce493125e4c3 94274 libdevel optional libcolord-dev_0.1.21-1_amd64.deb d74c3e9c2fe81b7ef9ec2985fb3a5869 116128 libs optional libcolord1_0.1.21-1_amd64.deb be2d856a242b3d5d70d4a4fe4f2a0509 68618 libs optional libcolord-gtk1_0.1.21-1_amd64.deb 14d0448718a206e07b3d408da9cc4c39 63256 libdevel optional libcolord-gtk-dev_0.1.21-1_amd64.deb 4bddc26484a1e84eee6d162074bc82e7 239194 graphics optional colord_0.1.21-1_amd64.deb 8f360fd9309cf36c8a9c69d8d2c4aad4 72622 introspection optional gir1.2-colord-1.0_0.1.21-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPxwJAAAoJEPmIJawmtHuf/J0P/3Y3jh9+IuTby4CDJQcFbI5s H0YlJ1R+nAiI7K9ESmi6XsPVs61Gf/Ez9WZshZNF5U/INok4VgbSbtQ8T/O5xwDG 2r9h09NsTb8yysRqLn7TSgBcyCZHDBmfer2ldrC36qNIvbkC+mrNYRABiHF4j0lC tpb6kbdkIQwNyWxRsJynctz68NH+eDMtyyg7eogvKuTyu6SiCIKYU6u4o+bDIZpK c0CnadX42MwwwNf3XC2O1OW5VLbrXDUTK6idztlh1ZfqVFXC9M2/dGouIvQBgJQb gnZSRjYFUB4ozpysshft+3IS2ZOHlA/Ia0Tac0PfJFMpfm3H6hqFDUNfRzfYxr61 aQKVrqhjAwd8n5FS7oAKglsKdxvHhs0hPCFirjSWTvRwjgKvjim+OqNgFTlu951W hEm2vWmp2M0cz79GVIDOufaKepHALCsGC6ZQ0slNIXGDQh1+nTxCCWyq/fchl7Pf mXaU87na6M0IG69/+0SC209EPMzTYbWnFhfgnT1+6kE0nbwPhoy3n3QfDvJwx0Vz BlUPtU9TL5d1oYO5wEZMe2ENogTLvNNy33jZuguJdQPr/lOsszvN/GizloLicY90 Bh50es+TXSc5P1RCWQ26g5s1M3asHKND8F2j7UU6vzepKLMdXuhkFpW57uf2RWJM 8m4Xqvwx5uFF3Q56SAE7 =Fjsq -END PGP SIGNATURE- Accepted: colord_0.1.21-1.debian.tar.gz to main/c/colord/colord_0.1.21-1.debian.tar.gz colord_0.1.21-1.dsc to
Accepted haskell-options 0.1.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 21 May 2012 18:27:52 -0700 Source: haskell-options Binary: libghc-options-dev libghc-options-prof libghc-options-doc Architecture: source all amd64 Version: 0.1.1-1 Distribution: unstable Urgency: low Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org Changed-By: John Millikin jmilli...@gmail.com Description: libghc-options-dev - Haskell library for parsing command-line options libghc-options-doc - Haskell library for parsing command-line options; documentation libghc-options-prof - Haskell library for parsing command-line options; profiling libra Closes: 673916 Changes: haskell-options (0.1.1-1) unstable; urgency=low . [ John Millikin ] * Initial release. (closes: #673916) . [ Joachim Breitner ] * Depend on ghc-ghci, to avoid FTBFS on arches without Template Haskell Checksums-Sha1: 3967d4a8e753ba70a9baf2a1cf80d70d3106e7a5 1995 haskell-options_0.1.1-1.dsc 9da19454a944e70cd9db073e8bcbbacb976738ce 24464 haskell-options_0.1.1.orig.tar.xz 0464158615550ddeed5c4089ff99d64751cf2adb 2046 haskell-options_0.1.1-1.debian.tar.gz 8ddf3a99298afa38dcca68c273cd109defe40c84 79072 libghc-options-doc_0.1.1-1_all.deb f460b3d1283af3c0bc9d09d495e9a656605891e8 311054 libghc-options-dev_0.1.1-1_amd64.deb 6cddef06b3b79e9ac1277ee8d330b0b205020474 295210 libghc-options-prof_0.1.1-1_amd64.deb Checksums-Sha256: 4eabb10f1156aeefb06a0c05566a841a105ed56d76c12b0afc62f0834b224e60 1995 haskell-options_0.1.1-1.dsc a61b5bc1a6568422ebecf306f5540e8fadbb342c72d7f541d0a361de029e7bf0 24464 haskell-options_0.1.1.orig.tar.xz d76171842366c9088d9e5e00f898d3f22ba9c1d61bc9c7897c7e84f99bb1bbea 2046 haskell-options_0.1.1-1.debian.tar.gz 8e05cd0d6adfb0da22eeb5dd2cec46b6bd6e2f8de75d452b5f012fbb27e125c6 79072 libghc-options-doc_0.1.1-1_all.deb 3f91e7fd0c336863a36b5e7e1ffc8ac974e52fac653cb3e08cef254ccf5bc81d 311054 libghc-options-dev_0.1.1-1_amd64.deb 17ecdd09d8117755a4971a53ea3e3a3d6d31becc64e6fc41c032279da4a2514a 295210 libghc-options-prof_0.1.1-1_amd64.deb Files: f7d7525a4d1ae8963deac2abf85aa5c2 1995 haskell optional haskell-options_0.1.1-1.dsc 88f55c9920b41574bdb69011b05ac134 24464 haskell optional haskell-options_0.1.1.orig.tar.xz b55c273865954b8ad55dd6d31ad97a18 2046 haskell optional haskell-options_0.1.1-1.debian.tar.gz 92e0886c4a3df9a9d55ba00033ff901f 79072 doc optional libghc-options-doc_0.1.1-1_all.deb c19173fc8651a76623d22a1b3fe91e07 311054 haskell optional libghc-options-dev_0.1.1-1_amd64.deb b0a73f77c93b5c024a493df1074312a3 295210 haskell optional libghc-options-prof_0.1.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/D3DYACgkQ9ijrk0dDIGxKrACfRdg7kQzoKF5kzxJ4lY0bZ6yI MVUAoLkgauRN7SkQowOIoZ3mXbha5ZgF =JP4f -END PGP SIGNATURE- Accepted: haskell-options_0.1.1-1.debian.tar.gz to main/h/haskell-options/haskell-options_0.1.1-1.debian.tar.gz haskell-options_0.1.1-1.dsc to main/h/haskell-options/haskell-options_0.1.1-1.dsc haskell-options_0.1.1.orig.tar.xz to main/h/haskell-options/haskell-options_0.1.1.orig.tar.xz libghc-options-dev_0.1.1-1_amd64.deb to main/h/haskell-options/libghc-options-dev_0.1.1-1_amd64.deb libghc-options-doc_0.1.1-1_all.deb to main/h/haskell-options/libghc-options-doc_0.1.1-1_all.deb libghc-options-prof_0.1.1-1_amd64.deb to main/h/haskell-options/libghc-options-prof_0.1.1-1_amd64.deb -- 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/e1samlg-0001ll...@franck.debian.org
Accepted libcorona-perl 0.1004-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Mon, 28 May 2012 23:18:30 +0400 Source: libcorona-perl Binary: libcorona-perl Architecture: source amd64 Version: 0.1004-1 Distribution: unstable Urgency: low Maintainer: Dmitry E. Oboukhov un...@debian.org Changed-By: Dmitry E. Oboukhov un...@debian.org Description: libcorona-perl - Coro based PSGI web server Closes: 674982 Changes: libcorona-perl (0.1004-1) unstable; urgency=low . * Init debian release, closes: #674982. Checksums-Sha1: 002b7d67579bc36461ca0c4970d7fd3cdad8f3df 1231 libcorona-perl_0.1004-1.dsc 4bb496a5554813c07644744d73349734e0bcf236 22408 libcorona-perl_0.1004.orig.tar.gz 9d3b5b8d767eebfc2291d1a66e794df57585c759 2012 libcorona-perl_0.1004-1.debian.tar.gz 5f0ef7a41d54468d561ea11c80adc2004f5475fc 11890 libcorona-perl_0.1004-1_amd64.deb Checksums-Sha256: add89b21e3a26c963366485307539f2780304044f66f1f73ae02c21b183e6d76 1231 libcorona-perl_0.1004-1.dsc 865f12921d83145f6370b178992d7e9124ad49807f67c5ba281cd5f2521327f5 22408 libcorona-perl_0.1004.orig.tar.gz 2a84d742041aa7ba39e2ae754a53282fb8dff34bb91faa94715c2da2c8edbde7 2012 libcorona-perl_0.1004-1.debian.tar.gz af2f49948e78afc21097b7451c86fcce544afddc32ef6113a6d7e44733080cdf 11890 libcorona-perl_0.1004-1_amd64.deb Files: 5f484904b4484146d0e248020ad42d7f 1231 perl extra libcorona-perl_0.1004-1.dsc f7c1484ad059dd65226bc824fdf35b70 22408 perl extra libcorona-perl_0.1004.orig.tar.gz 0b4f2d4ee2ee80f65c2bab571f0bc9a4 2012 perl extra libcorona-perl_0.1004-1.debian.tar.gz 7786ebd3014e6266ba90189bfc8a6f0a 11890 perl extra libcorona-perl_0.1004-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREDAAYFAk/EYV8ACgkQq4wAz/jiZTc43ACgn52VCQHV5azGXzM/HA4pk1xd dX4AoKW5oCU/LdGchbPp6D9+qYg/QgUq =BZat -END PGP SIGNATURE- Accepted: libcorona-perl_0.1004-1.debian.tar.gz to main/libc/libcorona-perl/libcorona-perl_0.1004-1.debian.tar.gz libcorona-perl_0.1004-1.dsc to main/libc/libcorona-perl/libcorona-perl_0.1004-1.dsc libcorona-perl_0.1004-1_amd64.deb to main/libc/libcorona-perl/libcorona-perl_0.1004-1_amd64.deb libcorona-perl_0.1004.orig.tar.gz to main/libc/libcorona-perl/libcorona-perl_0.1004.orig.tar.gz -- 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/e1samlr-0001nd...@franck.debian.org
Accepted libexttextcat 3.3.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 30 May 2012 15:07:51 +0200 Source: libexttextcat Binary: libexttextcat-1.0-0 libexttextcat-dev libexttextcat-data createfp Architecture: source all amd64 Version: 3.3.1-1 Distribution: experimental Urgency: low Maintainer: Rene Engelhard r...@debian.org Changed-By: Rene Engelhard r...@debian.org Description: createfp - Language detection library - fingerprint generation utility libexttextcat-1.0-0 - Language detection library libexttextcat-data - Language detection library - data files libexttextcat-dev - Language detection library - development files Changes: libexttextcat (3.3.1-1) experimental; urgency=low . * New upstream release Checksums-Sha1: eebc761a3b7548f244881f6109f8bb954d045918 1958 libexttextcat_3.3.1-1.dsc a65ce43becd7b4ad265fd96a5c81a549538656f9 1088522 libexttextcat_3.3.1.orig.tar.bz2 627981610cf22d01f93497ba2b7063f7aaa43e8e 7158 libexttextcat_3.3.1-1.debian.tar.gz df246e47fdc95d11fe770c06689606ab090c246c 192510 libexttextcat-data_3.3.1-1_all.deb f10022c913a2dc9c29fd777c3d5f8f5da2b40e3b 17530 libexttextcat-1.0-0_3.3.1-1_amd64.deb f0c8064d1718bff95aeaa0e1d2936a2f5c542c77 20768 libexttextcat-dev_3.3.1-1_amd64.deb 64d0d7c09ec3e17e59de10cff4da9657eb8f1e20 10458 createfp_3.3.1-1_amd64.deb Checksums-Sha256: bc5575dc1e83c3f625c063371f8c6c7034bd53a204eb6a6d602cc85f475f766e 1958 libexttextcat_3.3.1-1.dsc ae12a40ebc03843bca8fdf4fe0d6376375d499d51ba34fa7d25d9c7344dfe69e 1088522 libexttextcat_3.3.1.orig.tar.bz2 e771a0c796d9453fb40850758985c575a2bd0bdba4604d2277f4610b33dd36c7 7158 libexttextcat_3.3.1-1.debian.tar.gz a142509d13aad0e05a1e926112ce458a7fbae9a3e7dc6d5470e236dc5ac16d94 192510 libexttextcat-data_3.3.1-1_all.deb 3dee939e343599edf27d91702aa6ab52942cb911fac5213b9f1598a0c8aec76d 17530 libexttextcat-1.0-0_3.3.1-1_amd64.deb ff11e671c2c14c0aefc54c3b8cbe9a1cb6e635a86265d41f8d112f37514b12f5 20768 libexttextcat-dev_3.3.1-1_amd64.deb 2a828c6395e1e61ed796bf9cf3f1b1dccdc49ce47d1ccfa3f875a163b1aa99aa 10458 createfp_3.3.1-1_amd64.deb Files: 91d60daeac511d0a38e6b55b0363c52e 1958 libs optional libexttextcat_3.3.1-1.dsc 6097739c841f671cb21332b9cc593ae7 1088522 libs optional libexttextcat_3.3.1.orig.tar.bz2 7ad5e984905a5f4bdbb7fda23a1ea1f6 7158 libs optional libexttextcat_3.3.1-1.debian.tar.gz 0d387025614315a69e3423c9be58ec1a 192510 text optional libexttextcat-data_3.3.1-1_all.deb 5ed21c69d7e73bc05c6748c7dac60310 17530 libs optional libexttextcat-1.0-0_3.3.1-1_amd64.deb 01949d0e9b74e436defff9da0da4aa8d 20768 libdevel optional libexttextcat-dev_3.3.1-1_amd64.deb 274b16d81c33e2e3b91060f93df3bdec 10458 utils optional createfp_3.3.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPxo29AAoJEAqgRXHQPj5wyCkP/j7EvxbPAbyCB62oJ068bY1B 7OtakIP8oCSWrwvjgSgDoKBowxzXqqWasij43c6IXBO63nnTTu2EVjC37O9KSMZh 1qvCBRGtMuW2lSODRZ63sVFVt6U48An+iRIiwSZOJzfnD3BwasUXOXSb0sG1mWDH XTJrsxkycGXyF8xLAV65JA7H9WIHvogDUDNLx/i6Ev2+MsfMI9tyR4wIKdzC/Eap 8FsqN6fsyN4/Xdx2N2pD+VbaWdqN2rvh+FZtlB9PTLiPs4lIJaukRwkBg2pMsyod 2528yO7WyIFpJZXD7KP2Ou1BOhCowc/FgKK/4OmcENVLZXW9Y0eK2+uuTUDkYZtd Q2+dqgBjP7o23yGh2Tt63Tu356wxLL61fPBUUzD+ey2DH7E5t4i0IWQ6j2Hhy1W6 V2/0ACiAS2cuHYe1LyR2AlGRpUrgHcjqw5AbieJGEMCxy5abEbkhtxYYdhuo0S+m bnS187FM7QzCKPR4EHGnuPIYKh0/X9Ei9nhZqW1tg1a22zh/VN4Et/lKaHF2tDKP hZQ66+I6GdTGUc4tRyENfKS7Pv4pImirSYXzA0OrfjED3QLADMGYj1TSKXNdyoFp tnZ0zCKYEAvRnn9E4fGR5u1yvY1yatkaCi1ZISiWX/QGq+XoNjHHV9aHUvRhZq8Y FTiAj3uFk26LQLeLeEIv =70ni -END PGP SIGNATURE- Accepted: createfp_3.3.1-1_amd64.deb to main/libe/libexttextcat/createfp_3.3.1-1_amd64.deb libexttextcat-1.0-0_3.3.1-1_amd64.deb to main/libe/libexttextcat/libexttextcat-1.0-0_3.3.1-1_amd64.deb libexttextcat-data_3.3.1-1_all.deb to main/libe/libexttextcat/libexttextcat-data_3.3.1-1_all.deb libexttextcat-dev_3.3.1-1_amd64.deb to main/libe/libexttextcat/libexttextcat-dev_3.3.1-1_amd64.deb libexttextcat_3.3.1-1.debian.tar.gz to main/libe/libexttextcat/libexttextcat_3.3.1-1.debian.tar.gz libexttextcat_3.3.1-1.dsc to main/libe/libexttextcat/libexttextcat_3.3.1-1.dsc libexttextcat_3.3.1.orig.tar.bz2 to main/libe/libexttextcat/libexttextcat_3.3.1.orig.tar.bz2 -- 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/e1samm4-0001vz...@franck.debian.org
Accepted libexttextcat 3.3.1-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 31 May 2012 00:42:38 +0200 Source: libexttextcat Binary: libexttextcat-1.0-0 libexttextcat-dev libexttextcat-data createfp Architecture: source all amd64 Version: 3.3.1-2 Distribution: experimental Urgency: low Maintainer: Rene Engelhard r...@debian.org Changed-By: Rene Engelhard r...@debian.org Description: createfp - Language detection library - fingerprint generation utility libexttextcat-1.0-0 - Language detection library libexttextcat-data - Language detection library - data files libexttextcat-dev - Language detection library - development files Changes: libexttextcat (3.3.1-2) experimental; urgency=low . * Brown paper bag release. . * fix typo in .links to get libexttextcat.so - libexttextcat-1.0.so link right... Checksums-Sha1: 07e855775930f3a4451f84fde58a48453d17e831 1958 libexttextcat_3.3.1-2.dsc 6740ec06004fd68d4a7d1d24596a739dfc0832e0 7287 libexttextcat_3.3.1-2.debian.tar.gz a0f9e07130968b70292452a68acd0f2f4b594f3d 194650 libexttextcat-data_3.3.1-2_all.deb 49dbd9e5a2bf57eb9b27b48885568b47af33af3e 19688 libexttextcat-1.0-0_3.3.1-2_amd64.deb aa55cdd476b98f1898be63d9fd60e2534d222e9e 22974 libexttextcat-dev_3.3.1-2_amd64.deb b3101c4777e6b0c2c2151731e3ebddf2106bff29 12592 createfp_3.3.1-2_amd64.deb Checksums-Sha256: db81f42a70ad557fbc5db610aab169af32b233123b1efb7ff8b8dc3e92166bf9 1958 libexttextcat_3.3.1-2.dsc 94e5392caf043bf9d4eac0f07092a0d36f4f593768e5dc6b051ee88d5e371881 7287 libexttextcat_3.3.1-2.debian.tar.gz ab89822b4ae59952cd74d6e8730980c882656fd75f4b890fc3f5991c227c6443 194650 libexttextcat-data_3.3.1-2_all.deb 2fb8cc80c8f2618c25b42763c9b4121ad67ba2b76102ec602dc9c8daff77b4ad 19688 libexttextcat-1.0-0_3.3.1-2_amd64.deb 99b59f7be00db5cda64fba49cfa4301e2b4e65081c228247f6c5e6e346869b80 22974 libexttextcat-dev_3.3.1-2_amd64.deb a5c4b1f1bb4e70f09b852cecf3ed6f0488a89fcf69f2253ae0a474c1b43b353c 12592 createfp_3.3.1-2_amd64.deb Files: 6b4b09a4c570161b40c7eee549bb3728 1958 libs optional libexttextcat_3.3.1-2.dsc 8f98c2fd5bae0a50c521fa77165732c7 7287 libs optional libexttextcat_3.3.1-2.debian.tar.gz 6b0573da0ee4d825ab05d6dfe8662776 194650 text optional libexttextcat-data_3.3.1-2_all.deb 624a28b05c53305833dede7f7051f06e 19688 libs optional libexttextcat-1.0-0_3.3.1-2_amd64.deb b7b09253c58f775e841557d6446a1c49 22974 libdevel optional libexttextcat-dev_3.3.1-2_amd64.deb d2c19e01f5fdf7138f51c51dbc48d878 12592 utils optional createfp_3.3.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPxqNFAAoJEAqgRXHQPj5wmAEQALuGZOZ3YlsnvweQS63H2zJW puPL6E2xmvQoh/4TBDnVD+WU16vT2EIvgAxyh2H1ikovL8GT9yaLpO59uxI7zoiK ep8VAmj33IG2TF9jsJiAYXlvaFsLGlSU/mlsVUjoCelxXXRlwmu3MEd/2i1k1+fI xMqJJZ1GEyRRJ7QzHje2z5sP3ZI0j07OIf8SVVfVhklW2Av5A4wwr7CKh0FXws// IxM+njddsO30N91gqnrM04nrTBroAh+qAura3izJuJZhmK0Dt0HQkIXIY4A4eknt 97OX4k1A0HsdUc3vo5SKJtFCD+8XPasEdyKcW2M/avmLold51ggBJYPGRlPg0mhi 3sMTM+gMXjP3/STEQZWI0py6f8x70xRHbUWJFEqPtcW37e9jhUCoil4w259RGfoH x44U/tEvPeNlsv9hegJ8Vr/EQ1/5upiM9l24Vczj3SAs5Zp6LrM8pjwTrgMlC+Z6 sl9a43vwrX2usaV5xirXFFSApuTtPM3FzJm+dUm634bREB//th9R0Bw2uRudfqsh jHp4HBAgwIxwpeuXfKMEPWj14ZlqLhY+o5zYylsybKQeOpdTCtNyrsqfHwStuRpf +sFQFHTLGQBJB6JZoBXvN1YF1YOF+LKeGFQbtPflvg6cWxEvGPXC+8vtZyU+NCJn zj5SI2RMxOo4ftQ0Gk58 =jRS2 -END PGP SIGNATURE- Accepted: createfp_3.3.1-2_amd64.deb to main/libe/libexttextcat/createfp_3.3.1-2_amd64.deb libexttextcat-1.0-0_3.3.1-2_amd64.deb to main/libe/libexttextcat/libexttextcat-1.0-0_3.3.1-2_amd64.deb libexttextcat-data_3.3.1-2_all.deb to main/libe/libexttextcat/libexttextcat-data_3.3.1-2_all.deb libexttextcat-dev_3.3.1-2_amd64.deb to main/libe/libexttextcat/libexttextcat-dev_3.3.1-2_amd64.deb libexttextcat_3.3.1-2.debian.tar.gz to main/libe/libexttextcat/libexttextcat_3.3.1-2.debian.tar.gz libexttextcat_3.3.1-2.dsc to main/libe/libexttextcat/libexttextcat_3.3.1-2.dsc -- 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/e1sammh-0001we...@franck.debian.org
