Annonce d'un nouveau paquet guppy5.deb Ubuntu - Debian
Bonjour à tous, Nouveau sur cette liste et également dans le développement de paquet .deb, c'est en effet le premier que je tente de développer. Le paquet en question concerne le CMS GuppY en version 5.0.xx. A ce jour 5.0.08. Mon gros problème est que je ne maîtrise pas l'anglais et je fais donc cette annonce sur les listes en français. Ce n'est probablement pas la meilleure solution et je sollicite donc votre aide. J'ai commencé le développement sur une Ubuntu 14.04 LTS et je fais des tests en parallèle sur une Debian 7. Dois-je faire l'annonce de guppy5.deb sur la liste debian-devel-announce ou sur une autre liste ? Et puis-je utiliser le français sur cette liste ou sur d'autres qui sont en principe prévues pour l'anglais ?. En ce qui concerne les questions techniques afférentes à mon paquet je posterai sous peu. Merci. -- Cordialement, Jean Millet (JeandePeyrat) http://www.freeguppy.org http://asso.freeguppy.org --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Re: Let's abandon debian-devel.
David == David L Craig dlc@gmail.com writes: David On 14Nov10:2154+0100, Gergely Nagy wrote: You do realize topic lists are public too, right? David Yes, but most Debian users don't even know about David them nor do they need to since the traditional David lists have been doing their jobs for quite a David while. If you shut them down, I expect most of David the public will not find the topic lists. Most Debian users need not concern themselves with development lists, like they usually do not subscribe to debian-devel@ either. If they do want to find a list for a particular topic, it is not rocket science to do so. They will find it. -- |8] signature.asc Description: PGP signature
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. -vote should be limited to people with voting rights though. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014085158.ga25...@belkar.wrar.name
release browser-related packages to stable?
Since 2013, Debian has allowed new browser versions to enter stable[1] even though most other package versions are frozen The security team announcement mentions that some Xul extensions currently packaged in the Debian archive are not compatible and that a solution to that is still being worked out. There are similar consequences for some server-side content, e.g. jessie will include various WebRTC JavaScript libraries. The packages asterisk, jssip, jscommunicator and sipml5 closely follow this emerging standard. There have already been some occasions where changing browser technology (e.g. Chrome changing from SDES to DTLS-SRTP encryption) has caused these other packages to become unusable for periods of time. Has there already been any further discussion about the solution for Xul extensions packaged in Debian? With the freeze for jessie having just started, should the freeze guidelines be amended to make it easier for packages closely related to the browser to be updated to new versions at any time during the freeze if the browser version itself changes? Are there people who would object to such updates? 1. https://lists.debian.org/debian-security-announce/2013/msg00107.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5461d85b.4020...@pocock.pro
Aw: Let's abandon debian-devel.
Hi Charles, after unsubscribing from debian-vote, I had a bit of a thought about debian-devel, which is hard to follow now, and suddenly I saw something very clear. This year's freeze seems of an excellent quality and promises to be brief. Is that thanks to debian-devel ? Not much. Excellent work is being done on the Installer and is that thanks to debian-devel ? Not much. In 2010 when I was candidate to become DPL, I wrote that Debian was in growth crisis. I think that it never has been so true. Places like debian-devel, which can be instrumental in smaller projects, are very toxic in larger ones. From now on I will try to see if I can give to Debian the same quality of contribution without being subscribed to debian-devel. And I invite you to think about it and *not* to discuss it on this list. With most of the work done on topic mailing lists, trolls lose the lever effect they have when feasting on debian-devel or debian-vote. Let's make our project stronger by reducing thr attack surface for troublemakers. To me, the Blends of Debian and the many pkg-xyz lists are a bit of an answer. Those are full with positive vibes, over time and with the help of sprints we often came to know each other personally, too. Debian-devel came to have problems. I personally found the answer in asking my geographically local (and, admittedly, 20 years younger) hackers environment about the issues that Debian is discussing, thinking that any vote in Debian should also have me a bit as a representative of my surroundings whenever I feel undecided. This was quite curative (I suggest to everyone take that medicine yourselves) and somewhat also returns the strenghts to find the gems in debian/devel again. Best, Steffen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/trinity-fd49eeea-cf51-4c93-8402-779c4e2ce46e-1415702045107@3capp-gmx-bs59
Re: Removing duplication: Word lists of common words in languages
On 10/11/14 23:16, Ben Finney wrote: To avoid duplicating these “the N most common words, ranked by frequency, for language FOO” For a password generator you ideally want the word-list to be sorted alphabetically, so that it's trivial to verify by eye that there are no duplicates. Duplicate entries would reduce the entropy of the generated passwords, without anything being obviously wrong. (Idea stolen from Diceware, for which it is essential, because the word list is designed to be usable without a computer; for online password generators it's less important, because you can compare wc -l with sort -u | wc -l to confirm that there are no duplicates.) It's probably also a good idea to have a power-of-2 wordlist size, to make it trivial to pick one without bias using bytes from /dev/[u]random. (Diceware uses a power-of-6 wordlist size for analogous reasons, because it's based on rolling dice.) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5461e839.5030...@debian.org
Blends in D-I tasksel selection? (Was: Filed Bug#758096: tasksel: Allow to select specific packages during installation - just DE, Web server, Mail server is NOT enough)
Hi, I guess the sad news that Joey Hess leaves Debian has spread also to Debian Blends list. The direct consequence for Blends is that Joey will not work on this bug (#758096) and will also most probably not rise any opinion on it any more but we somehow need to move on. I realised that the changelog says: ... tasksel (3.23) unstable; urgency=medium ... * Added a Parent field, which results in a simple nested hierarchy display. (Currently only one level deep, and not collapsible since debconf doesn't have an appropriate widget.) ... * Removed mail-server, dns-server, database-server, file-server tasks, which were not well enough defined to be useful and whose menu space will be better used for blends or openstack tasks. Closes: #604100 ... which according to Git (git://git.debian.org/git/tasksel/tasksel.git) relates to this commit. commit 9e2290b531e414ffb16e89b50cf5c44413fa71b8 Author: Joey Hess j...@kitenet.net Date: Sun Sep 7 22:45:02 2014 -0400 hierarchical tasks, desktop selection, and general massive changes ... * Added a Parent field, which results in a simple nested hierarchy display. (Currently only one level deep, and not collapsable since debconf doesn't have an appropriate widget.) ... * Removed mail-server, dns-server, database-server, file-server tasks, which were not well enough defined to be useful and whose menu space will be better used for blends or openstack tasks. ... This again shows Joey's great way to deal with things by simply working at something rather than doing a lot of talk. I really appreciate this - another thanks to Joey. As far as I can see without testing this means regarding the display of Blends in D-I (#758096) that we only need to *decide* and in case we want to do this add the needed bits of data. Any opinions regarding a decision? Kind regards Andreas. PS: I'll be AFK from 19. Nov to 3. Dez. -- 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: https://lists.debian.org/2014105955.gn13...@an3as.eu
Re: free choice in installer?
On Mon, Nov 10, 2014 at 11:15:12AM +0100, Michael Ole Olsen wrote: If there was a choice in the installer for Init system and boot loader there would be nobody complaining. People only complain when there isn't a choice and they are forced to use something new. From what research are you taking this generalisation? All non-IT experts I know (proof by counter-example) would be really happy to have no choice but rather one single option which works. You might also like to think about all those Win+OSX users who have no problem to accept what they get. I admit regarding init system I feel like them and prefer also one solution that works without any need to spend time into a decision making process (feel free to blame me about this). So please be careful to do generalised statements about people by assuming that all people are thinking like you. 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: https://lists.debian.org/2014111906.gp13...@an3as.eu
Re: Let's abandon debian-devel.
Hi, Andrey Rahmatullin: On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. (We could also auto-approve if too much time has passed without moderator activity.) -vote should be limited to people with voting rights though. +1 -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Let's abandon debian-devel.
Andrey Rahmatullin w...@debian.org writes: On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. But all Debian Contributors have their OpenPGP key in the project's keyring. No? -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oasec73i@benfinney.id.au
Re: Let's abandon debian-devel.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-11-11 12:25, Ben Finney wrote: But all Debian Contributors have their OpenPGP key in the project's keyring. No? Most certainly not. Parts where many people who is not DD nor DM takes part include docs, web, translations and graphics. - -- brother http://sis.bthstudent.se -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJUYfYuAAoJEJbdSEaj0jV74ZUH/3pxK2deT3jz63ZJrCCtoy8D wXXe+5zicV+n5UNuJPgGI60fIjkvY/F/DwGzlx8FXcc08W9Ze11Xzk9H48BVLniQ Qd/YglBOafCMlwe2WZCR+qla0IHmkLL6OqkA1r9MlB26F6KDwpndv2NMIBk6QWxf P1QWjQs+KzvZ3obU267ArthNzbRLlTmwuu/08RE5MMRdmDv6NTouu4X4CyTctqvJ I6VLpiYps/4vxHhG9f7v95J+VuNclYKA8yUfjIxU+M6Dc+ogIEDy3/F5zbImyng1 vWpVipZ4L3sykF3Y98XzZ4jGWeKiSqeBwFk/3UomTIQzGpURLvtNhlKsHYxCAr4= =gh9m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5461f62e.2090...@bsnet.se
Re: Removing duplication: Word lists of common words in languages
Simon McVittie s...@debian.org writes: On 10/11/14 23:16, Ben Finney wrote: To avoid duplicating these “the N most common words, ranked by frequency, for language FOO” For a password generator you ideally want the word-list to be sorted alphabetically, so that it's trivial to verify by eye that there are no duplicates. Duplicate entries would reduce the entropy of the generated passwords, without anything being obviously wrong. It's already trivial to test a wordlist, regardless of its existing order, to check whether it has duplicates: $ ( sort | uniq -d | wc -l ) /usr/share/dict/american-english 0 What's impossible is to go from an alphabetically-ordered list of unique words to a frequency-ordered one, without introducing the frequency information from outside. (Idea stolen from Diceware, for which it is essential, because the word list is designed to be usable without a computer Well, I don't think we need to cater for “use without a computer” for programs in Debian. Unless I'm misunderstanding something? An important property of a “N most common” wordlist ordered by frequency in the language, is that it's trivial to get a “X most common” wordlist (where X N) by simply truncating the list. This is a property lacking in a wordlist not ordered by frequency. Where is a good authoritative source of such words, by frequency, for various natural languages, suitable for inclusion in Debian as a data package? -- \ “Anything that we scientists can do to weaken the hold of | `\religion should be done and may in the end be our greatest | _o__) contribution to civilization.” —Steven Weinberg | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85k332c61b@benfinney.id.au
Re: free choice in installer?
On Tue, Nov 11, 2014 at 12:19:06PM +0100, Andreas Tille wrote: From what research are you taking this generalisation? All non-IT experts I know (proof by counter-example) would be really happy to have no choice but rather one single option which works. You might also like Of course, but the problem is that they don’t share the same opinion about the working solution. Or we wouldn’t have different editors, window managers, desktop environments, monitoring tools, etc. to think about all those Win+OSX users who have no problem to accept what they get. I admit regarding init system I feel like them and Well, that’s the reason why I’m using Linux because I don’t accept what I get with Windows. And if you have noticed the complains about the ribbon in Office or the Win8 GUI then you’ll see that Windows users don’t always accept what they get. So please be careful to do generalised statements about people by assuming that all people are thinking like you. If you don’t want choices you can stay with Windows. There is no reason to make Linux like Windows. 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
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 10:25:05PM +1100, Ben Finney wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. But all Debian Contributors have their OpenPGP key in the project's keyring. No? Not all Debian contributors are Debian Contributors whatever that means. Lots of people without keys somewhere in official keyrings are doing useful work. Some of them are even maintaining packages. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014114409.ga29...@belkar.wrar.name
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 12:22:53PM +0100, Matthias Urlichs wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email unless I'm misunderstanding the anybody who signs their email with a key in our keyring part. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014114522.gb29...@belkar.wrar.name
Re: Let's abandon debian-devel.
On 11 Nov 22:25, Ben Finney wrote: Andrey Rahmatullin w...@debian.org writes: On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote: I'd be in favor of a different approach: moderate debian-devel. Not the content, but the list of people allowed to post. Pre-seed it with the email adresses in our keyring and auto-add anybody who signs their email with a key in our keyring. Not all Debian contributors are DDs. But all Debian Contributors have their OpenPGP key in the project's keyring. No? Correct, no, they don't. Think translators, and other such contributions. -- Brett Parker -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014114123.GN906@miranda
Re: Let's abandon debian-devel.
+++ Charles Plessy [2014-11-10 23:25 +0900]: Hi all, From now on I will try to see if I can give to Debian the same quality of contribution without being subscribed to debian-devel. And I invite you to think about it and *not* to discuss it on this list. Just a data-point: I joined d-devel when I joined debian. It was noisy and after a while I unsubscribed. And it stayed that way for several years. I did my stuff in my little corner and that worked, but I had almost no idea what was going in in Debian generally and was often surprised by events/changes. At some point I tried joining up again and have since become much more involved, at least partly due to having some feel for what is currently going on. So -devel is noisy and sometimes unhelpful, but at least for me being subscribed is definitely more useful than not being subscribed. Possibly the same effect could be achieved by joining -project. I've never tried that... So if your purpose is just to work on your packages, then yes ignore -devel - you will get a quieter life. But it does disconnect you noticeably. Perhaps that is less true than it was, as there are more alternatives (such as planet). Just some (anecdotal) data. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014122711.gd28...@stoneboat.aleph1.co.uk
Re: Let's abandon debian-devel.
Hi, Andrey Rahmatullin: I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email Moderating (some) emails to d-d implies delaying those emails until a human moderator looks at them. To me at least. Therefore I didn't think of explicitly mentioning that; sorry if that was unclear. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote: Andrey Rahmatullin: I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email Moderating (some) emails to d-d implies delaying those emails until a human moderator looks at them. To me at least. Therefore I didn't think of explicitly mentioning that; sorry if that was unclear. My concern would be around /which/ human moderator does this. The project passed a GR about declassifying -private, for example, and this had never been achieved because the people who are willing to put the work in don't exist. Neil -- signature.asc Description: Digital signature
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 12:42:38PM +0100, Martin Bagge / brother wrote: But all Debian Contributors have their OpenPGP key in the project's keyring. No? Most certainly not. Parts where many people who is not DD nor DM takes part include docs, web, translations and graphics. I think there were some numbers about percentage of packages (or uploads?) maintained by people not in keyrings. Nobody should think they are negligible. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014122515.ga31...@belkar.wrar.name
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote: I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email Moderating (some) emails to d-d implies delaying those emails until a human moderator looks at them. To me at least. Therefore I didn't think of explicitly mentioning that; sorry if that was unclear. That's not the same as delaying only the first email though :) -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123410.ga31...@belkar.wrar.name
Re: Let's abandon debian-devel.
On Tuesday, November 11, 2014 12:41:12 PM Neil McGovern wrote: On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote: Andrey Rahmatullin: I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email Moderating (some) emails to d-d implies delaying those emails until a human moderator looks at them. To me at least. Therefore I didn't think of explicitly mentioning that; sorry if that was unclear. My concern would be around /which/ human moderator does this. The project passed a GR about declassifying -private, for example, and this had never been achieved because the people who are willing to put the work in don't exist. I'd be willing to help out. Scott K signature.asc Description: This is a digitally signed message part.
Re: Let's abandon debian-devel.
Hi, Scott Kitterman: On Tuesday, November 11, 2014 12:41:12 PM Neil McGovern wrote: On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote: Andrey Rahmatullin: I know. So? If the first email of a non-DD gets delayed for a few hours, that's an acceptable price to pay IMHO. Nothing about delays wasn't mentioned in your previous email Moderating (some) emails to d-d implies delaying those emails until a human moderator looks at them. To me at least. Therefore I didn't think of explicitly mentioning that; sorry if that was unclear. My concern would be around /which/ human moderator does this. The project passed a GR about declassifying -private, for example, and this had never been achieved because the people who are willing to put the work in don't exist. I'd be willing to help out. So would I. Declassifying -private is different because (apparently) nobody wants to spend a block of time wading through old -private emails, most of which are now irrelevant. In contrast, a quick decision about whether to whitelist an email, when I'm scanning my mails anyway, doesn't have the same impact. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014125957.gf23...@smurf.noris.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Mon, 10 Nov 2014 11:08:38 +, Simon McVittie wrote: On 10/11/14 02:59, Christian Hofstaedtler wrote: I vaguely remember PolicyKit being involved in the daemon situation, when mpd tries to talk to a pulseaudio server which magically gets spawned PolicyKit is typically (only?) used when a less-privileged process, typically a user interface, communicates with a more-privileged service. It's possible that something PK-related is going on, but I can't immediately see any reason why either mpd or PulseAudio would want to interact with it: both normally run with an ordinary user's privileges. The typical scenario is: * I tell NetworkManager to connect to a wireless network (or tell some other privileged service to do some other action) * NetworkManager (or other privileged service) asks PolicyKit is it OK to let smcv do this? * PolicyKit consults its sysadmin-, distro- or upstream-supplied policies, checks the facts relevant to those policies (I am in some groups, I am actively logged-in locally), optionally asks me for my password to confirm that I am actually present, and replies yes or no I'm not sure if it is PolicyKit or a related service (old documentation suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ * get ACLs added for the currently logged in users: % getfacl /dev/snd/controlC0 getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:felipe:rw- group::rw- mask::rw- other::--- Thus any user (not on the audio group) process will not have access to the audio device until that user is on a physical terminal. AFAICT, pulseaudio does not talk directly to polkitd. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3t1gp$77d$1...@ger.gmane.org
Re: REISSUED CfV: General Resolution: Init system coupling
Santiago Vila writes (Re: REISSUED CfV: General Resolution: Init system coupling): On Mon, Nov 10, 2014 at 06:12:46PM +, Ian Jackson wrote: I have a half-written series to make it cope with lettered, rather than numbered, options. Would it be worth my while finishing that off (in my CFT) ? The voting process is already complex enough. If it is going to be like this: GR Proposal: Option A. Amendment A: Option B. Amendment B: Option C. we might better stick with numbered options. *rotfl*. I'm hoping the Secretary could avoid that and that we could instead have GR Proposal: Option A. Amendment B: Option B. Amendment C: Option C. or GR Proposal: Option Y. Amendment A: Option A. Amendment B: Option B. or something. Personally I find the current arrangements extremely confusing - particularly, the way that devotee often provides transposed information, which is quite hard to notice. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.2772.916501.616...@chiark.greenend.org.uk
Re: Let's abandon debian-devel.
Hi, On Dienstag, 11. November 2014, Matthias Urlichs wrote: I'd be willing to help out. So would I. me too, should this road be chosen. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Removing duplication: Word lists of common words in languages
Ben Finney writes (Re: Removing duplication: Word lists of common words in languages): Where is a good authoritative source of such words, by frequency, for various natural languages, suitable for inclusion in Debian as a data package? I had roughly this question in 2013, and found the answer. Here is probably the best starting point: http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git;a=blob;f=lemma.al-permission.mbox Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.3533.32160.657...@chiark.greenend.org.uk
Should fast-evolving packages be backports-only?
It has been recently stated [0-1] that backports is enabled by default in Jessie. 1. Does that mean that if pkgX is in jessie-backports but not jessie, apt-get install pkgX will install it from -backports? 2. If so, when (if ever) is it appropriate to deliberately invoke that behaviour by removing pkgX from jessie? Possible candidates: a. Packages that work closely with hardware, where old versions don't work with new hardware (example: beignet) b. Packages that implement fast-evolving file formats or network protocols, where you need the same version as the people you are communicating with (possible example: jscommunicator [2]) c. Packages that are generally rapidly improving, and are typically used where this improvement is more important than stability The advantage of doing so (over having both the old version in jessie and the new one in jessie-backports) is that non-technical users (who may not know that backports exists) get the new version they probably want; the disadvantage is that users who explicitly want stability can no longer choose it (except by pinning or using snapshot.debian.org, which also block security updates of that package). In the long run it may be a better idea to have these packages suggest upgrading to -backports in their this hardware/protocol version/option not supported error message, or on startup if there is no easy way to identify attempts to use the newer features, but it is too late to do this for jessie. (Release team have already ruled that a. (#767961) and b. (#768933) are not valid reasons for freeze exceptions; I guess this would also forbid stable updates) [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html [1] My own sources.list has # jessie-backports, previously on backports.debian.org # Line commented out by installer because it failed to verify: #deb http://ftp.uk.debian.org/debian/ jessie-backports main but https://lists.debian.org/debian-user/2014/09/msg01174.html reports getting one with that line uncommented [2] https://lists.debian.org/debian-release/2014/11/msg00866.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54620f78.4040...@zoho.com
Re: Let's abandon debian-devel.
On Tue, Nov 11, 2014 at 02:13:20PM +0100, Holger Levsen wrote: On Dienstag, 11. November 2014, Matthias Urlichs wrote: I'd be willing to help out. So would I. me too, should this road be chosen. Excellent. In that case, my position is now meh :) Neil -- signature.asc Description: Digital signature
Re: REISSUED CfV: General Resolution: Init system coupling
On 11/11/2014 02:10 PM, Ian Jackson wrote: Santiago Vila writes (Re: REISSUED CfV: General Resolution: Init system coupling): The voting process is already complex enough. If it is going to be like this: GR Proposal: Option A. Amendment A: Option B. Amendment B: Option C. we might better stick with numbered options. *rotfl*. I'm hoping the Secretary could avoid that and that we could instead have GR Proposal: Option A. Amendment B: Option B. Amendment C: Option C. Or even simpler Proposal A: Option A Proposal B: Option B Proposal C: Option C I'm not sure why there is a need to treat the initial proposal and later ones in a different way. As a related question, I also don't understand why the proposer of the initial proposal and of later amendments are treated differently in the constitution, e.g. in A.1.5. Ian suggested this might just be a bug[1]? (I'm also wondering if there is a difference between original proposer as used in A.1.4 and proposer of a resolution in A.1.5.) Ansgar [1] https://lists.debian.org/debian-vote/2014/10/msg00309.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546216fb.1090...@debian.org
Re: Should fast-evolving packages be backports-only?
On 11/11/14 14:30, Rebecca N. Palmer wrote: It has been recently stated [0-1] that backports is enabled by default in Jessie. 1. Does that mean that if pkgX is in jessie-backports but not jessie, apt-get install pkgX will install it from -backports? 2. If so, when (if ever) is it appropriate to deliberately invoke that behaviour by removing pkgX from jessie? Possible candidates: a. Packages that work closely with hardware, where old versions don't work with new hardware (example: beignet) b. Packages that implement fast-evolving file formats or network protocols, where you need the same version as the people you are communicating with (possible example: jscommunicator [2]) c. Packages that are generally rapidly improving, and are typically used where this improvement is more important than stability Maybe also d. packages that the security team decide to support by using upstream releases (in other words, should the browsers be distributed through backports only?) One big question that arises then (and what I asked in a separate thread about the browser-related packages but it is relevant to other classes of package too) is compatibility - if package foo is allowed to change, do all packages broken by the change (e.g. browser plugins) get to be uploaded again too? - if some package hides the complexity of the change and the maintainer has kept the API stable so that dependent packages don't break should it be looked on more favorably and allowed to be updated in stable too? Personally, I feel that having backports enabled by default is only part of the solution to the challenges with volatile packages but it may be a step in the right direction. I also feel that this is something that impacts each maintainer and each user differently. Some people are working in parts of the system where the freeze concept really is the most important thing. Other people are working on applications where network compatibility is the most important thing (as it is with communications) and people simply won't use the package or won't be able to use it successfully if is not updated. Ultimately, with more and more packages being in this category as the world becomes more networked/cloudified, this impacts Debian's relevance for whole groups of users. The advantage of doing so (over having both the old version in jessie and the new one in jessie-backports) is that non-technical users (who may not know that backports exists) get the new version they probably want; the disadvantage is that users who explicitly want stability can no longer choose it (except by pinning or using snapshot.debian.org, which also block security updates of that package). In the long run it may be a better idea to have these packages suggest upgrading to -backports in their this hardware/protocol version/option not supported error message, or on startup if there is no easy way to identify attempts to use the newer features, but it is too late to do this for jessie. (Release team have already ruled that a. (#767961) and b. (#768933) are not valid reasons for freeze exceptions; I guess this would also forbid stable updates) [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html [1] My own sources.list has # jessie-backports, previously on backports.debian.org # Line commented out by installer because it failed to verify: #deb http://ftp.uk.debian.org/debian/ jessie-backports main but https://lists.debian.org/debian-user/2014/09/msg01174.html reports getting one with that line uncommented [2] https://lists.debian.org/debian-release/2014/11/msg00866.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54621b37.4040...@pocock.pro
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 11/11/14 13:04, Felipe Sateler wrote: I'm not sure if it is PolicyKit or a related service (old documentation suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ * get ACLs added for the currently logged in users Yes, that's exactly what I said a couple of mails ago :-) It is indeed systemd-logind that does this now. It's a 2-stage process: udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices that should be user-accessible with the uaccess tag during device discovery (and sysadmin-written rules can presumably override the defaults to remove that tag if necessary). Later, systemd-logind looks for any devices with that tag and puts appropriate ACLs on them. Older versions of udev and ConsoleKit cooperated to do something similar with a udev-acl tag. PolicyKit is not involved here. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54621ffd.4090...@debian.org
Re: Should fast-evolving packages be backports-only?
On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock dan...@pocock.pro wrote:
On 11/11/14 14:30, Rebecca N. Palmer wrote:
It has been recently stated [0-1] that backports is enabled by default
in Jessie.
1. Does that mean that if pkgX is in jessie-backports but not jessie,
apt-get install pkgX will install it from -backports?
2. If so, when (if ever) is it appropriate to deliberately invoke that
behaviour by removing pkgX from jessie?
One big question that arises then (and what I asked in a separate thread
about the browser-related packages but it is relevant to other classes
of package too) is compatibility
- if package foo is allowed to change, do all packages broken by the
change (e.g. browser plugins) get to be uploaded again too?
- if some package hides the complexity of the change and the maintainer
has kept the API stable so that dependent packages don't break should it
be looked on more favorably and allowed to be updated in stable too?
maybe a crazy idea, but maybe build in some easy way to apt-pin
package (and dependencies) to testing in apt/dpkg? This way we can
leverage all of the existing transition infrastructure and essentially
provide backports for all packages with no extra work?
possibly lots of unintended consequences, and someone will mess up
their machine by pulling in tons of libraries from the future, but it
will essentially perform the same function for those users that need
the up-to-date leaf packages while keeping the stable core. testing is
pinned by default to 100
$ apt-get install-updated ${PACKAGE}
where install-updated will pin ${PACKAGE} to testing and do $ apt-get
install ${PACKAGE} -t testing This will pull in the package from
testing and dependencies from testing that are missing from stable.
Not a good idea for jessie, maybe something to think about for future.
Either way, I think you have excellent points in your final paragraph,
thank you Rebecca and Daniel for bringing this up.
On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock dan...@pocock.pro wrote:
I also feel that this is something that impacts each maintainer and each
user differently. Some people are working in parts of the system where
the freeze concept really is the most important thing. Other people are
working on applications where network compatibility is the most
important thing (as it is with communications) and people simply won't
use the package or won't be able to use it successfully if is not
updated. Ultimately, with more and more packages being in this category
as the world becomes more networked/cloudified, this impacts Debian's
relevance for whole groups of users.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cang8-dbkbdzghr-vvkc7x9g0f6c1quaz9j3kgvbsdsusent...@mail.gmail.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Tue, 11 Nov 2014 14:41:01 +, Simon McVittie wrote: On 11/11/14 13:04, Felipe Sateler wrote: I'm not sure if it is PolicyKit or a related service (old documentation suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ * get ACLs added for the currently logged in users Yes, that's exactly what I said a couple of mails ago :-) Oops :) It is indeed systemd-logind that does this now. It's a 2-stage process: udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices that should be user-accessible with the uaccess tag during device discovery (and sysadmin-written rules can presumably override the defaults to remove that tag if necessary). Later, systemd-logind looks for any devices with that tag and puts appropriate ACLs on them. Older versions of udev and ConsoleKit cooperated to do something similar with a udev-acl tag. PolicyKit is not involved here. Thanks for the clarification. I'll just that the relevant file is /lib/udev/rules.d/70-uaccess.rules for systemd systems, and /l/u/r/70-udev-acl.rules for consolekit systems. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3t858$8no$1...@ger.gmane.org
r-base-core upload to unstable does not respect freeze policy
Hi, Freeze policy[1] says: Uploads to unstable === Since many updates (hopefully, the vast majority) will be via unstable, changes there can be disruptive if they would be unsuitable for Jessie. Please be mindful of this, particularly if you maintain a library or key package. which is not respected by r-base-core: $ LC_ALL=C apt-cache policy r-base-core r-base-core: Installed: 3.1.1-1 Candidate: 3.1.1-1+b2 Version table: 3.1.2-2 0 50 http://http.debian.net/debian/ unstable/main amd64 Packages 3.1.1-1+b2 0 501 http://http.debian.net/debian/ testing/main amd64 Packages *** 3.1.1-1 0 100 /var/lib/dpkg/status I was close to trap into the pitfall to uploaded an RC bug fix built in an unstable chroot which would not be able to migrate to testing since the R cdbs helper injects a Depends: r-base-core (= version_in_your_chroot) So I used a testing chroot but I would like to issue a warning to those who might need to fix RC bugs in R packages as well. I remember we had similar migration trouble in Wheezy freeze time. Dirk, it would have been better to upload version 3.1.2 to experimental. Kind regards Andreas. [1] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html -- 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: https://lists.debian.org/2014153337.ga3...@an3as.eu
Re: r-base-core upload to unstable does not respect freeze policy
Andreas Tille writes (r-base-core upload to unstable does not respect freeze policy): [stuff] I don't want to take away from what you've said, but: So I used a testing chroot perhaps we should in general make more use of testing chroots for RC bugfixes to testing during the freeze. This is particularly relevant if one is NMUing, and therefore might have less knowledge of the dependency implications etc. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.12651.670584.160...@chiark.greenend.org.uk
Re: r-base-core upload to unstable does not respect freeze policy
On Tue, Nov 11, 2014 at 03:55:23PM +, Ian Jackson wrote: So I used a testing chroot perhaps we should in general make more use of testing chroots for RC bugfixes to testing during the freeze. This is particularly relevant if one is NMUing, and therefore might have less knowledge of the dependency implications etc. ACK. There was no real harm done in my case. I just wanted to make other people aware. I only noticed since I wanted to install the resulting package on a testing machine - which I'd recommend even more than to use a testing chroot for building. 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: https://lists.debian.org/2014160202.ga4...@an3as.eu
Re: r-base-core upload to unstable does not respect freeze policy
Hi Andreas, 2014-11-11 16:33 GMT+01:00 Andreas Tille andr...@an3as.eu: I was close to trap into the pitfall to uploaded an RC bug fix built in an unstable chroot which would not be able to migrate to testing since the R cdbs helper injects a Depends: r-base-core (= version_in_your_chroot) So I used a testing chroot I think this is not enough, as packages being built by the buildd network will pick up the R in unstable anyway :/ From https://buildd.debian.org/status/fetch.php?pkg=r-cran-epiarch=i386ver=1.1.67-3stamp=1415721806 r-cran-epi_1.1.67-3_i386.deb [...] Depends: libc6 (= 2.4), r-base-core (= 3.1.2-2) Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadk7b0opwvqeeaw9kmpoz2f8ys5mj0nd6ugqt0w_v7rte5r...@mail.gmail.com
Re: r-base-core upload to unstable does not respect freeze policy
On 11/11/14 15:55, Ian Jackson wrote: perhaps we should in general make more use of testing chroots for RC bugfixes to testing during the freeze. For build-time dependencies, I'm not sure that actually helps very much: the buildds for unstable take build-dependencies from unstable. If you intend to ask the release team for permission and then upload to testing-proposed-updates, then I think those do take build-dependencies from unstable; but they also get virtually no testing, which is why the release team are more restrictive about what they'll accept via t-p-u. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546233e3.7000...@debian.org
Re: r-base-core upload to unstable does not respect freeze policy
On 11 November 2014 at 10:02, Dirk Eddelbuettel wrote: | | There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. Bah. Obviously wrong order: 8.6 instead of 8.5. D. | No more, no less -- and I complied. | | This nothing to do with wheezy transition issue. I would have thought | you knew better. | | Dirk | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.13514.201495.508...@max.nulle.part
Re: r-base-core upload to unstable does not respect freeze policy
There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. No more, no less -- and I complied. This nothing to do with wheezy transition issue. I would have thought you knew better. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.13097.266733.759...@max.nulle.part
Re: r-base-core upload to unstable does not respect freeze policy
Simon McVittie writes (Re: r-base-core upload to unstable does not respect freeze policy): On 11/11/14 15:55, Ian Jackson wrote: perhaps we should in general make more use of testing chroots for RC bugfixes to testing during the freeze. For build-time dependencies, I'm not sure that actually helps very much: the buildds for unstable take build-dependencies from unstable. This is a good point. (Although if your package has only arch:all debs you can build them all yourself against testing.) Perhaps the buildds should be reconfigured, during the freeze, to build against testing ? Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.14030.572571.128...@chiark.greenend.org.uk
Re: r-base-core upload to unstable does not respect freeze policy
Dirk Eddelbuettel writes (Re: r-base-core upload to unstable does not respect freeze policy): There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. No more, no less -- and I complied. This nothing to do with wheezy transition issue. I would have thought you knew better. Did you see Andreas's comment about cdbs-generated dependencies ? Is that just a bug in cdbs ? Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21602.14104.380204.489...@chiark.greenend.org.uk
Re: r-base-core upload to unstable does not respect freeze policy
On 2014-11-11 16:02, Dirk Eddelbuettel wrote: There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. No more, no less -- and I complied. This nothing to do with wheezy transition issue. I would have thought you knew better. It's *everything* to do with transitions to testing. r-base 3.1.2-2 does not meet the requirements for a freeze exception and as such will not be in jessie. Due to the way your automatic depenency generation works, any package building against that version of r-base will also not be eligible for transition. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/35ea6cdb01be500bfd3c1a55aac4d...@mail.adsl.funky-badger.org
Re: r-base-core upload to unstable does not respect freeze policy
On 2014-11-11 16:24, Adam D. Barratt wrote: On 2014-11-11 16:02, Dirk Eddelbuettel wrote: There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. No more, no less -- and I complied. This nothing to do with wheezy transition issue. I would have thought you knew better. It's *everything* to do with transitions to testing. r-base 3.1.2-2 does not meet the requirements for a freeze exception and as such will not be in jessie. Due to the way your automatic depenency generation works, any package building against that version of r-base will also not be eligible for transition. I missed that the dependency generation is for CDBS-using packages. I'm not sure what proportion of R packages that is. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d5f43cc31b2a510e0f8bb0239f4c2...@mail.adsl.funky-badger.org
Re: r-base-core upload to unstable does not respect freeze policy
Quoting Ian Jackson (2014-11-11 17:19:36) Dirk Eddelbuettel writes (Re: r-base-core upload to unstable does not respect freeze policy): There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6. No more, no less -- and I complied. This nothing to do with wheezy transition issue. I would have thought you knew better. Did you see Andreas's comment about cdbs-generated dependencies ? Is that just a bug in cdbs ? A bug in some CDBS-compatible snippet, I suspect - not CDBS itself. - 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: signature
Re: Should fast-evolving packages be backports-only?
Rebecca N. Palmer rebecca_pal...@zoho.com (2014-11-11): It has been recently stated [0-1] that backports is enabled by default in Jessie. Yes, and that's a bug. See #764982. 1. Does that mean that if pkgX is in jessie-backports but not jessie, apt-get install pkgX will install it from -backports? Yes. And that's the reason why I'm going to disable jessie-backports by default when I process my todo list. Mraw, KiBi. signature.asc Description: Digital signature
Re: r-base-core upload to unstable does not respect freeze policy
On Nov 11, 2014 10:34 AM, Andreas Tille andr...@an3as.eu wrote: I was close to trap into the pitfall to uploaded an RC bug fix built in an unstable chroot which would not be able to migrate to testing since the R cdbs helper injects a Depends: r-base-core (= version_in_your_chroot) This looks like more fallout from #704805 not being fixed. A similar discussion happened last freeze in the thread starting at https://lists.debian.org/20824.26651.775823.264...@max.nulle.part.
Re: Should fast-evolving packages be backports-only?
On Tue, 11 Nov 2014, Rebecca N. Palmer wrote: Possible candidates: a. Packages that work closely with hardware, where old versions don't work with new hardware (example: beignet) b. Packages that implement fast-evolving file formats or network protocols, where you need the same version as the people you are communicating with (possible example: jscommunicator [2]) c. Packages that are generally rapidly improving, and are typically used where this improvement is more important than stability We used to have the volatile archive for software that absolutely needs to be updated very often (like virus scanners). We now have the stable-updates archive for this. https://wiki.debian.org/StableUpdates If packages are taking too long to go from stable-proposed-updates to stable-updates, that's something we could talk to the release managers about. Although, I am *sure* lack of widespread use (and therefore testing) of stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one of the reasons. However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. backports seem like a better solution for this case. However, we'd need to add further requirements: packages not built from the same source package cannot depend on such never-for-stable packages, and we must tag them somehow so that they never get released to stable... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014173015.gb2...@khazad-dum.debian.net
Re: r-base-core upload to unstable does not respect freeze policy
On Tue, Nov 11, 2014 at 04:28:25PM +, Adam D. Barratt wrote:
It's *everything* to do with transitions to testing.
r-base 3.1.2-2 does not meet the requirements for a freeze exception
and as such will not be in jessie. Due to the way your automatic
depenency generation works, any package building against that version
of r-base will also not be eligible for transition.
I missed that the dependency generation is for CDBS-using packages.
I'm not sure what proportion of R packages that is.
All R packages are building with
include /usr/share/R/debian/r-cran.mk
which contains:
rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
...
## support ${R:Depends} via debian/${package}.substvars
echo R:Depends=r-base-core (= ${rversion})
debian/$(package).substvars
which is IMHO to strict which was discussed previously (for instance
here [1]). The package does only require a certain API and not
necessarily the latest available r-base-core. While the strict
dependency does not harm in general it potentially does in situations
like this specific one. (However, even the relaxed dependency in [1]
would have not helped in the current case.)
Kind regards
Andreas.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#15
--
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: https://lists.debian.org/2014173027.gb4...@an3as.eu
Re: Should fast-evolving packages be backports-only?
On November 11, 2014 12:22:57 PM EST, Cyril Brulebois k...@debian.org wrote: Rebecca N. Palmer rebecca_pal...@zoho.com (2014-11-11): It has been recently stated [0-1] that backports is enabled by default in Jessie. Yes, and that's a bug. See #764982. 1. Does that mean that if pkgX is in jessie-backports but not jessie, apt-get install pkgX will install it from -backports? Yes. And that's the reason why I'm going to disable jessie-backports by default when I process my todo list. As long as apt prefers a version from stable over a version from backports when both are available (unless instructed to install from backports) why is this a problem? It seems more user friendly to me for a package that's been specifically ask for to end up installed rather than not. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e8f87680-99dc-4fa5-8fc2-754d48d57...@kitterman.com
Re: r-base-core upload to unstable does not respect freeze policy
Hi Jonas, On Tue, Nov 11, 2014 at 06:11:42PM +0100, Jonas Smedegaard wrote: Quoting Ian Jackson (2014-11-11 17:19:36) Did you see Andreas's comment about cdbs-generated dependencies ? Is that just a bug in cdbs ? A bug in some CDBS-compatible snippet, I suspect - not CDBS itself. ACK. As I wrote in my other mail it is not particularly a bug. The resulting dependency is IMHO a bit to strict but was choosen that way by the maintainer. Everything would work as expected if new upstream version of r-base-core would have been uploaded to experimental rather than to unstable. 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: https://lists.debian.org/2014173917.gd4...@an3as.eu
Re: release browser-related packages to stable?
Has there already been any further discussion about the solution for Xul extensions packaged in Debian? I haven't looked for the official discussion, but extensions have been updated in stable (to a new upstream version if necessary) when a browser update would otherwise break them: see e.g. #744730. Also, clients for interacting with a single online service (eg. ttyter, #721921) have been updated in stable when that service changes its API. Those cases have in common that there is a clearly-defined right version: a browser and its extensions are on the same machine so can be tied together by the normal dependency system, and a one-service client needs to match its only server. This isn't the case for a server intended for public (i.e. with non-Debian clients) use. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462466c.1030...@zoho.com
Re: r-base-core upload to unstable does not respect freeze policy
On Tue, 11 Nov 2014, Ian Jackson wrote: Simon McVittie writes (Re: r-base-core upload to unstable does not respect freeze policy): On 11/11/14 15:55, Ian Jackson wrote: perhaps we should in general make more use of testing chroots for RC bugfixes to testing during the freeze. For build-time dependencies, I'm not sure that actually helps very much: the buildds for unstable take build-dependencies from unstable. This is a good point. (Although if your package has only arch:all debs you can build them all yourself against testing.) Perhaps the buildds should be reconfigured, during the freeze, to build against testing ? That has some nasty implications as well. If this needs to be addressed, the likely safest answer would be to have t-p-u built on buildds with up-to-date[1] testing chroots. [1] If you even have to ask why something like this needs to be explicitly stated, well, you're a lucky one... AFAIK, the whole policy of not updating to unstable something that is not supposed to migrate to testing during a freeze is a way to cope with the extremely non-trivial cost of deploying and managing a fully independent t-p-u (which is more than an entire new set of autobuilder instances). This reminds me that, AFAIK, we still don't have a good answer to this scenario: what do I do when I notice the toolchain was generating broken code, which actually means we should binNMU everything that was built with the broken toolchain, as well as anything that lifted code from the broken binaries (static linking, etc). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014174412.gc2...@khazad-dum.debian.net
Re: Should fast-evolving packages be backports-only?
Scott Kitterman deb...@kitterman.com (2014-11-11): As long as apt prefers a version from stable over a version from backports when both are available (unless instructed to install from backports) why is this a problem? It seems more user friendly to me for a package that's been specifically ask for to end up installed rather than not. As I probably wrote in the mentioned bug report, it seems more friendly, safe, and honest to stick to stable packages on a stable system instead of silently stuff from backports. It's not like uncommenting a line in sources.list should be a huge burden anyway (having to figure out which line to add, depending on the target suite, wasn't too trivial when backports moved from backports.d.o to the archive; but we're way past that now). Mraw, KiBi. signature.asc Description: Digital signature
Re: Should fast-evolving packages be backports-only?
On 11/11/14 18:30, Henrique de Moraes Holschuh wrote: On Tue, 11 Nov 2014, Rebecca N. Palmer wrote: Possible candidates: a. Packages that work closely with hardware, where old versions don't work with new hardware (example: beignet) b. Packages that implement fast-evolving file formats or network protocols, where you need the same version as the people you are communicating with (possible example: jscommunicator [2]) c. Packages that are generally rapidly improving, and are typically used where this improvement is more important than stability We used to have the volatile archive for software that absolutely needs to be updated very often (like virus scanners). We now have the stable-updates archive for this. https://wiki.debian.org/StableUpdates If packages are taking too long to go from stable-proposed-updates to stable-updates, that's something we could talk to the release managers about. Although, I am *sure* lack of widespread use (and therefore testing) of stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one of the reasons. However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. backports seem like a better solution for this case. However, we'd need to add further requirements: packages not built from the same source package cannot depend on such never-for-stable packages, and we must tag them somehow so that they never get released to stable... That is not so easy though or it may have side effects For example, if a library changes implementation details but the public API and ABI does not change and no other dependent packages need to be recompiled then it should be OK for those dependent packages to live in stable. Does that mean the maintainer has to put their libfoo-dev in stable while keeping their volatile libfoo1 in backports? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54624ca0.80...@pocock.pro
Re: r-base-core upload to unstable does not respect freeze policy
Hi Luca, On Tue, Nov 11, 2014 at 05:04:55PM +0100, Luca Falavigna wrote: Hi Andreas, 2014-11-11 16:33 GMT+01:00 Andreas Tille andr...@an3as.eu: I was close to trap into the pitfall to uploaded an RC bug fix built in an unstable chroot which would not be able to migrate to testing since the R cdbs helper injects a Depends: r-base-core (= version_in_your_chroot) So I used a testing chroot I think this is not enough, as packages being built by the buildd network will pick up the R in unstable anyway :/ From https://buildd.debian.org/status/fetch.php?pkg=r-cran-epiarch=i386ver=1.1.67-3stamp=1415721806 r-cran-epi_1.1.67-3_i386.deb [...] Depends: libc6 (= 2.4), r-base-core (= 3.1.2-2) Hmmm, this is what I missed. :-( I guess the only chance is to upload to t-p-u, right? 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: https://lists.debian.org/2014181210.ge4...@an3as.eu
Re: Should fast-evolving packages be backports-only?
On Tue, 11 Nov 2014, Daniel Pocock wrote: On 11/11/14 18:30, Henrique de Moraes Holschuh wrote: On Tue, 11 Nov 2014, Rebecca N. Palmer wrote: Possible candidates: a. Packages that work closely with hardware, where old versions don't work with new hardware (example: beignet) b. Packages that implement fast-evolving file formats or network protocols, where you need the same version as the people you are communicating with (possible example: jscommunicator [2]) c. Packages that are generally rapidly improving, and are typically used where this improvement is more important than stability We used to have the volatile archive for software that absolutely needs to be updated very often (like virus scanners). We now have the stable-updates archive for this. https://wiki.debian.org/StableUpdates If packages are taking too long to go from stable-proposed-updates to stable-updates, that's something we could talk to the release managers about. Although, I am *sure* lack of widespread use (and therefore testing) of stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one of the reasons. However, candidate packages due to reason (c) above really are a problem, IMHO they shouldn't be in stable in the first place. backports seem like a better solution for this case. However, we'd need to add further requirements: packages not built from the same source package cannot depend on such never-for-stable packages, and we must tag them somehow so that they never get released to stable... That is not so easy though or it may have side effects For example, if a library changes implementation details but the public API and ABI does not change and no other dependent packages need to be recompiled then it should be OK for those dependent packages to live in stable. Does that mean the maintainer has to put their libfoo-dev in stable while keeping their volatile libfoo1 in backports? Looks like a let's not go there kind of deal. Make it simple, so that it has a non-zero chance of flying and all that. After we have some experience with it in practice, we revisit the issue. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014184244.gd2...@khazad-dum.debian.net
Re: Should fast-evolving packages be backports-only?
❦ 11 novembre 2014 12:29 -0500, Scott Kitterman deb...@kitterman.com : As long as apt prefers a version from stable over a version from backports when both are available (unless instructed to install from backports) why is this a problem? The user may expect the same characteristics than for packages in stable, like stability (not upgrading to a new upstream version each month). -- Let the data structure the program. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Re: Let's abandon debian-devel.
On 2014-11-11 12:25, Ben Finney wrote: But all Debian Contributors have their OpenPGP key in the project's keyring. No? Most certainly not. Parts where many people who is not DD nor DM takes part include docs, web, translations and graphics. FWIW, when I first started running sid nearly ten years ago, it was recommended that users doing so subscribe to debian-devel so as to be aware of any breakages, etc. While there is no reason why I should now be able to post here without at least passing through a moderation queue, it would probably be a good idea to make sure there are no places left on the web instructing users to subscribe if they are going to be discouraged from posting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415731000.5108.1.ca...@speakeasy.net
Re: r-base-core upload to unstable does not respect freeze policy
Hi Andreas, 2014-11-11 19:12 GMT+01:00 Andreas Tille andr...@an3as.eu: Depends: libc6 (= 2.4), r-base-core (= 3.1.2-2) Hmmm, this is what I missed. :-( I guess the only chance is to upload to t-p-u, right? That could be an option. You have to coordinate with Release Team, though, as I can't speak for it. Obviously, fixes to any R package should go through t-p-u, which could be a pain to handle. I wonder whether the version in unstable can be reverted to 3.1.1... Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0NKQS_VmtXreSY+e4etB6KwMc2e=Dw1FJ_=77uumpg...@mail.gmail.com
Re: Removing duplication: Word lists of common words in languages
Ian Jackson ijack...@chiark.greenend.org.uk writes: I had roughly this question in 2013, and found the answer. Here is probably the best starting point: http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git;a=blob;f=lemma.al-permission.mbox Great! That asks for permission to redistribute the corpus under free-software terms, and documents the response in the affirmative. Vital for an eventual ‘debian/copyright’. Thank you. In that exchange, you also mention you're planning to distribute the data in a program. Is that online somewhere, and what's the URL? -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__)development, 2002 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857fz1cxzo@benfinney.id.au
Bug#769159: ITP: citeproc-py -- Python implementation of a CSL (Citation Style Language) citation processor
Package: wnpp Severity: wishlist Owner: Daniel Stender deb...@danielstender.com * Package name: citeproc-py Version : 0.3.0 Upstream Author : Brecht Machiels bre...@mos6581.org * URL : https://github.com/brechtm/citeproc-py * License : BSD-2-Clause Programming Lang: Python Description : Python implementation of a CSL (Citation Style Language) citation processor This is a Python citation processor [1] for the XML based Citation Style Language (CSL) [2], which puts out formatted citations and bibliographies from different bibliographical database formats, so far it supports Json and BibTeX, according to citation styles written in CSL [3]. The latest upstream tarball appeared a couple of days ago, and there is active development going on. The development status of citeproc-py is still 3-Alpha, but it would like to package it already because this is very promising. The binaries of Python modules would be python-citeproc and python3-citeproc. Daniel Stender [1] http://en.wikipedia.org/wiki/CiteProc [2] http://citationstyles.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014201234.8915.3665.report...@varuna.fritz.box
Bug#769162: ITP: aegean -- integrated genome analysis toolkit
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss sa...@tetrinetsucht.de * Package name: aegean Version : 0.10.2 Upstream Author : Daniel Standage daniel.stand...@gmail.com * URL : http://standage.github.io/AEGeAn/ * License : ISC Programming Lang: C Description : integrated genome analysis toolkit The AEGeAn Toolkit is designed for the Analysis and Evaluation of Genome Annotations. The toolkit includes a variety of analysis programs, e.g. for comparing distinct sets of gene structure annotations (ParsEval), computation of gene loci (LocusPocus) and more. In particular, the ParsEval software tool is very fast and convenient and highly useful for bioinformaticians working on the task of genome annotation, allowing for easy evaluation of results e.g. compared against a reference. The ParsEval publication was quickly marked as being highly accessed (http://www.biomedcentral.com/1471-2105/13/187), confirming its usefulness for the bioinformatics community. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014195125.7264.38007.reportbug@renard
Re: r-base-core upload to unstable does not respect freeze policy
On Tue, 11 Nov 2014, Luca Falavigna wrote: 2014-11-11 19:12 GMT+01:00 Andreas Tille andr...@an3as.eu: Depends: libc6 (= 2.4), r-base-core (= 3.1.2-2) Hmmm, this is what I missed. :-( I guess the only chance is to upload to t-p-u, right? That could be an option. You have to coordinate with Release Team, though, as I can't speak for it. Obviously, fixes to any R package should go through t-p-u, which could be a pain to handle. I wonder whether the version in unstable can be reverted to 3.1.1... No, you cannot revert anything once installed, but you can supersede it. If this issue can be fixed through build-depends/conflicts, a new upload to unstable with those changes would be a way to address the issue. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014202039.gh2...@khazad-dum.debian.net
RFC: DEP-14: Recommended layout for Git packaging repositories
Hello, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). Are there things that are missing? Here's the draft: Title: Recommended layout for Git packaging repositories DEP: 14 State: DRAFT Date: 2014-11-04 Drivers: Raphael Hertzog hert...@debian.org URL: http://dep.debian.net/deps/dep14 Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn Abstract: Recommended naming conventions in Git repositories used to maintain Debian packages Introduction This is a proposal to harmonize the layout of Git repositories used to maintain Debian packages. The goals are multiple: * making it easier for Debian and its derivatives to build upon their respective Git repositories (with the possibility to share a common one in some cases) * make it easier to switch between various git packaging helper tools. Even if all the tools don't implement the same worflow, they could at least use the same naming conventions for the same things (Debian/upstream release tags, default packaging branch, etc.). Scope = This proposal defines naming conventions for various Git branches and Git tags that can be useful when doing Debian packaging work. The hope is that maintainers of git packaging helper tools will adopt those naming conventions (in the default configuration of their tools). Generic principles == Vendor namespaces - Each vendor uses its own namespace for its packaging related Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and so on. Helper tools should usually rely on the output of `dpkg-vendor --query vendor` to find out the name of the current vendor. The retrieved string must be converted to lower case. This allows users to override the current vendor by setting `DEB_VENDOR` in their environment (provided that the vendor information does exist in `/etc/dpkg/origins/`). If `dpkg-vendor` is not available, then they should assume debian is the current vendor. Helper tools can also offer a command-line option to override the current vendor if they desire. Version mangling When a Git tag needs to refer to a specific version of a Debian package, the Debian version needs to be mangled to cope with Git's restrictions. The colon (`:`) needs to be replaced with a percent (`%`), and the tilde (`~`) needs to be replaced with an underscore (`_`). Packaging branches and tags === Packaging branches should be named according to the codename of the target distribution. In the case of Debian, that means for example `debian/sid`, `debian/jessie`, `debian/experimental`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? The helper tools that do create those repositories should use a command like `git symbolic-ref HEAD refs/heads/debian/sid` to update HEAD to point to the desired branch. When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. For example, a Debian maintainer releasing a package with version 2:1.2~rc1-1 would create a tag named `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should point to the exact commit that was used to build the corresponding upload. Managing upstream sources = Importing upstream release tarballs in Git -- If the Git workflow in use imports the upstream sources from released tarballs, this should be done under the upstream namespace. By default, the latest upstream version should be imported in the `upstream/latest` branch and when packages for multiple upstream versions are maintained concurrently, one should create as many upstream branches as required. Their name should be based on the major upstream version tracked: for example when upstream maintains a
Bug#769173: RFA: libmusicbrainz5 -- Library to access the MusicBrainz.org database
Package: wnpp X-Debbugs-CC: debian-devel@lists.debian.org, pkg-multimedia-maintain...@lists.alioth.debian.org, a...@gently.org.uk, tjaal...@ubuntu.com https://tracker.debian.org/pkg/libmusicbrainz5 libmusicbrainz5 is pulled into many GNOME desktops as a dependency, hence the high popcon stats: https://qa.debian.org/popcon.php?package=libmusicbrainz5 There is currently an RC bug, a couple of non-free files crept in at some point, upstream has removed them but had to make API changes. Somebody adopting the package may need to consider a transition. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749698 This package relies on a web service API from MusicBrainz and somebody familiar with that may be able to support the package more easily. I think this is a very worthwhile package, it is part of the eco-system of open source alternatives to cloud-based music services. I originally helped with this package to support the packaging of flactag. However, I have a large portfolio of other packages where I have more in-depth experience and ongoing development work hence I'm putting this one up for adoption in the hope that somebody will focus on it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462804c.5090...@pocock.pro
Re: r-base-core upload to unstable does not respect freeze policy
On Tue, 11 Nov 2014, Andreas Tille wrote:
All R packages are building with
include /usr/share/R/debian/r-cran.mk
which contains:
rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
...
## support ${R:Depends} via debian/${package}.substvars
echo R:Depends=r-base-core (= ${rversion})
debian/$(package).substvars
So, would this patch to the current r-base package improve things if
applied to the version in unstable?
diff --git a/debian/r-cran.mk b/debian/r-cran.mk
index e366f6b..0550173 100644
--- a/debian/r-cran.mk
+++ b/debian/r-cran.mk
@@ -60,7 +60,7 @@ endif
#rversion := $(shell zcat /usr/share/doc/r-base-dev/changelog.Debian.gz |
\
# dpkg-parsechangelog -l- --count 1 | \
# awk '/^Version/ {print $$2}')
-rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
+rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev | perl -ne
'print /([0-9]\.[0-9])/')
## we use these results for the to-be-installed-in directory
debRlib:= $(CURDIR)/debian/$(package)/$(debRdir)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.11.142217280.11...@cantor.unex.es
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, Nov 11, 2014 at 10:26:24PM +0100, Raphael Hertzog wrote: Hello, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). […] Packaging branches and tags === Packaging branches should be named according to the codename of the target distribution. In the case of Debian, that means for example `debian/sid`, `debian/jessie`, `debian/experimental`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). I find this paragraph confusing. With gbp, this is where new Debian developments are made, and new upstream versions are sent to upstream/xxx. Or do you mean something else here? QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Interesting. Assuming a normal Debian package that has just a few backports (as opposed to every sid release being backported), and which imports only upstream tarballs/snapshots (not the whole history), I expect that a high proportion of the commits would happen on this branch. In which case, why not make it 'master', without debian/ ? Is it (only) in order to cleanly support multiple vendors? thanks, iustin signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Raphael Hertzog wrote: following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). ... The Git repository listed in debian/control's `Vcs-Git` field should usually have its HEAD point to the branch corresponding to the distribution where new upstream versions are usually sent. For Debian, it will usually be `debian/sid` (or sometimes `debian/experimental`). QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Please allow debian/master as an alternative. It fits with the general git usage of master, it fits with the workflow of several packages, where you do experimental-unstable, and it is not going to surprise anyone that has even a passing knowledge of the usual git conventions. In fact, I was quite non-amused by the initial versions of this idea, but reading this latest version, I must say I *like* it. Well done! I am especially happy about the way it respects the usual git usage conventions, this will ease its adoption a lot. It does fail to mention security, and stable-proposed branches. We can just leave those to maintainer's discretion, of course. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014215152.gb13...@khazad-dum.debian.net
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Iustin Pop wrote: QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Interesting. Assuming a normal Debian package that has just a few backports (as opposed to every sid release being backported), and which imports only upstream tarballs/snapshots (not the whole history), I expect that a high proportion of the commits would happen on this branch. In which case, why not make it 'master', without debian/ ? Is it (only) in order to cleanly support multiple vendors? This way DEP-14 can support upstream work being done in the main namespace (master branch, unprefixed or v-prefixed release tags, etc), while downstream/distro/vendor work is done on the vendor branches. Which is the natural way it will happen when you have upstream and downstream packaging being done by the same person, or by the same team. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014220220.gc13...@khazad-dum.debian.net
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote: Here's the draft: Thanks for getting this started. I think it will help considerably to get some standardization here. I would think that as more teams adopt git, they will eventually just refer to DEP 14, perhaps with some additional team-based deviations if necessary. One question: when this gets adopted, will individual maintainers or teams have to know which of the git packaging helpers a particular repository is using? IOW, what happens if I were to use gbp-pq on a package that someone else had used git-dpm on? Do we need some kind of convention to detect which helper is being used? I wouldn't want to restrict choice by defining a standard Debian-wide (but it's okay within the context of a team). I just want someone who walks up to a git repo to at least easily know which tools to use. Vendor namespaces - Each vendor uses its own namespace for its packaging related Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and so on. My question is whether the vendor namespaces are overkill for the majority of packages, where there probably will be just one vendor (i.e. Debian). Should DEP 14 allow for a simplified layout such as master, pristine-tar, upstream when there is no other vendor involved? Allowing for master as an alternative to debian/sid or debian/master might simplify the common case. However, I'll also note that for pycurl, I'm currently using master to be the Debian unstable branch, and ubuntu to be a small set of deltas on top of that, for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? It makes some sense to allow this as an alternative, but then my question about using 'master' as an even simpler alternative for the common case should also be asked. When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. For example, a Debian maintainer releasing a package with version 2:1.2~rc1-1 would create a tag named `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should point to the exact commit that was used to build the corresponding upload. Agreed. Tag namespaces certainly make a lot of sense. If the Git workflow in use imports the upstream sources from released tarballs, this should be done under the upstream namespace. By default, the latest upstream version should be imported in the `upstream/latest` branch and when packages for multiple upstream versions are maintained concurrently, one should create as many upstream branches as required. Similarly, is 'upstream' okay for the upstream branch? It's a little simpler than upstream/latest, especially if you don't anticipate importing an other upstream branches. Again thanks. After Jessie is released, I hope to restart this discussion over in Debian Python, for that team's transition to git. Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Raphael Hertzog: Title: Recommended layout for Git packaging repositories DEP: 14 Thank you! QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Personally I'd prefer `debian/master`. About pristine-tar -- If the package maintainers use the pristine-tar tool to efficiently store a byte-for-byte copy of the upstream tarballs, this should be done in the `pristine-tar` branch. Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tuesday, November 11, 2014 22:26:24 Raphael Hertzog wrote: Hello, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. I have left one question where I have had conflicting feedback and I'm not sure what's best. Thus I will welcome a larger set of opinions on this specific question (search for QUESTION in the text). Are there things that are missing? Who's going to do patches to existing tools (e.g. git-dpm is the one I use and care about) so they comply with this and similarly scripts to convert existing git repos to match this recommendation? It doesn't make much sense to have an standard unless there's also a plan to implement using it. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16276435.4WkQ4eyy62@scott-latitude-e6320
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Matthias Urlichs matth...@urlichs.de writes: Raphael Hertzog: About pristine-tar -- If the package maintainers use the pristine-tar tool to efficiently store a byte-for-byte copy of the upstream tarballs, this should be done in the `pristine-tar` branch. Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. I strongly disagree with this advice. pristine-tar is hugely helpful, and is something we should continue to support, advocate, maintain, and use. -- 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: https://lists.debian.org/87egt91d6c@hope.eyrie.org
Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support
Package: general Severity: normal I use Virtualbox to run test environments for the packages I maintain (just a few really). I install virtualbox-guest-utils in my guest installations to adjust system clock after hibernation. In Jessie, there seem to be a problem with the virtualbox guest service. It fails to start and, as usual, I look in the system log for clues. Now, as a DD I am of course very much aware of the highly debated change in Jessie to a new default init process. I have had no strong feelings about this so far, other than that in general, as a user, I very much value the freedom of choice. That is why I choose to use free and open source software when available in the first place. Any way, back to the failed start of the virtualbox service. I went to the system log for clues, in this case using 'journalctl -x'. To my surprise, where ever there was a problem reported, there was also a reference to systemd-devel mailing list at FreeDesktop.ORG for support. In my particular case it looked like this: // log extract begins nov 10 01:36:47 debian-systemd sudo[1429]: tomfa : TTY=pts/0 ; PWD=/home/tomfa ; USER=root ; COMMAND=/usr/sbin/service virtualbox-guest-utils start nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session opened for user root by tomfa(uid=0) nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: Starting VirtualBox AdditionsNo suitable module for running kernel found ... failed! nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: failed! nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session closed for user root nov 10 01:36:47 debian-systemd systemd[1]: virtualbox-guest-utils.service: control process exited, code=exited status=1 nov 10 01:36:47 debian-systemd systemd[1]: Failed to start LSB: VirtualBox Linux Additions. -- Subject: Unit virtualbox-guest-utils.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit virtualbox-guest-utils.service has failed. -- -- The result is failed. nov 10 01:36:47 debian-systemd systemd[1]: Unit virtualbox-guest-utils.service entered failed state. // log extract ends I don't understand why there should be a reference to an external support entity when the issue obviously is Debian related and should be reported as such in Debian-related forums. My specific issue has nothing to do with systemd or FreeDesktop.ORG. I want the external reference removed. If it stays it will only create confusion and misunderstanding. Thank you, Tomas Fasth -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110011332.1314.27239.report...@debian-systemd.malforsdata.se
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Russ Allbery wrote: Please discourage the use of pristine-tar. The format is fragile and can suffer from bit rot. I strongly disagree with this advice. pristine-tar is hugely helpful, and is something we should continue to support, advocate, maintain, and use. Unfortunately it is so broken, that too often orig tarballs cannot be recreated. Especially with pristinetar data generated in a stable system one is often lost. I used pristinetar for years, and now try to move away from it, as it turned out to be too unstable, and too dependent on tar's internalities. But I agree, that the *idea* of pristinetar is great, only that it does not work as it is now. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112003120.gd19...@auth.logic.tuwien.ac.at
Re: A concerned user -- debian Guidelines
On Monday, 10 de November de 2014 08:57:50 Nathael Pajani escribió: [...] You certainly heard about debianfork (http://debianfork.org/) and from a user point of view this is a tragedy. A derivative and a fork are different things. A Derivative happens when a different project is started using the codebase of the first, with different goals, and both projects cross-pollinize each other. Both become stronger, if nough manpower is available. A fork happens when angry developers start a copy of the first project and abandon it, because it is unworkable. Ubuntu is a derivative. XOrg is a fork (and XFee86 was almost abandoned). If Debianfork is a fork, it will be sad, as you say. But it seems to me that (if realized) it will become a derivative. Maybe an angry derivative with small cross-help, but a derivative anyway. From my point of view (or from a user's point of view) what is about to happen is a breach in Debian Social Contract. Debian Social Contract states as point 4 : Our priorities are our users and free software From my point of view, users are ignored, and what we can read here and there is that the decision is up to (put bluntly) those who spend time in the project (the Debian developers). Agreed. But since Debian is a volunteer's project, it makes sense that the people who works on it (not *for* it) works on the topics they prefer. In my view, forcing systemd is a bad election, while choosing it as default for new installs is a good one. And that second decision was taken with the users as a priority, since it improves the user experience for our less technically suited users which just want to install that Linux thing and have Word and a browser, since systemd makes Gnome work better. The first decision is the one we are actually discussing (or arguing about): whether to force init switch on upgrade. Ability to install a different than default init system has been raised as a concern as well. But systemd IS our default. But the project exists because thousands of other people use it and contribute to other free software - those 20K free software which makes Debian such a rich Distribution. Not necesarily. The project exists because some people devotes time on it. Systemd itself, as an example at hand, was developed mainly at Red Hat quarters. And we use it. It does not depend on Debian in order to contribute to Debian. Same for tons of other projects. Even, some users contribute directly to Debian, by filling bug reports, speaking about Debian, buying goodies, and many many other ways. True. Some of them will enjoy systemd, some actually hate it with no reason, and some want systemd-free systems for good reasons. And still some do not care. And the hard point is to give figures for those sets. When a (big ?) pool of users is not happy to the point of suggesting to fork because of a decision taken (or about to be taken) by the project developers, then (I think) that the Debian developers are not doing their job right. You'll notice that the fork has not been started yet, as (I think) many still hope this can end the right way, with USERS taken into account. All of them. Agreed that all users must be taken into account, by our Constitution. But somebody must do the work. Remember that the issue is not about the default. That wave passed time ago. It is about exact meaning of some words like default itself. AND, if the worst thing happens here and Debianfork starts in the most hateing way, Debian will still be a great community (not so big, but still great) with the best non-company Linux distribution available. And with time hate will disappear and most probably Debianfork will become some kind of Debian Blend. [...] Remember Ian Murdock's intention : Ian intended Debian to be a distribution which would be made openly, in the spirit of Linux and GNU. And it is. This very thread and the GRs and the CTTE decisions are proof that it is made openly. It just happens that some developers have excess of love for their init system project, and that that project is engulfing other things and that it has binary logs and a lot of other issues... but the decision was taken openly. Still from my point of view, this means that the user can choose between alternatives for almost everything when there is a choice. Let's cite a few to make it evident : Vim/emacs, KDE/Gnome/All/the/others/ones, Debian kernel/custom kernel, There is option to use other init systems on Jessie. It has been shown how to install them. Maybe Release Notes need extra work. Do you volunteer? Surely Debian Installer needs a lot of extra work and testing. Do you volunteer? Sure as hell Debian will benefit for a new, shiny, well-designed init system in the UNIX principles tradition. Will you write it? [...] Especially when this breaks so many of my systems. Of course I could spend time to learn the new init, a change all of my
Processed: Re: Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support
Processing control commands: reassign -1 src:systemd Bug #769187 [general] general: Entries in system log for failed services refer to FreeDesktop.ORG for support Bug reassigned from package 'general' to 'src:systemd'. Ignoring request to alter found versions of bug #769187 to the same values previously set Ignoring request to alter fixed versions of bug #769187 to the same values previously set -- 769187: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769187 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b769187.14157524452863.transcr...@bugs.debian.org
Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support
Control: reassign -1 src:systemd On Mon, 2014-11-10 at 02:13 +0100, Tomas Fasth wrote: Package: general Severity: normal I use Virtualbox to run test environments for the packages I maintain (just a few really). I install virtualbox-guest-utils in my guest installations to adjust system clock after hibernation. In Jessie, there seem to be a problem with the virtualbox guest service. It fails to start and, as usual, I look in the system log for clues. [...] // log extract begins nov 10 01:36:47 debian-systemd sudo[1429]: tomfa : TTY=pts/0 ; PWD=/home/tomfa ; USER=root ; COMMAND=/usr/sbin/service virtualbox-guest-utils start nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session opened for user root by tomfa(uid=0) nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: Starting VirtualBox AdditionsNo suitable module for running kernel found ... failed! nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: failed! nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session closed for user root nov 10 01:36:47 debian-systemd systemd[1]: virtualbox-guest-utils.service: control process exited, code=exited status=1 nov 10 01:36:47 debian-systemd systemd[1]: Failed to start LSB: VirtualBox Linux Additions. -- Subject: Unit virtualbox-guest-utils.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel The 'LSB:' prefix indicates the systemd unit was defined by an init script with LSB headers. The support URL is generated by systemd's generic support for init scripts, which could easily be changed. However, native systemd unit definitions can and probably will also specify their own uptream support URL. -- Unit virtualbox-guest-utils.service has failed. -- -- The result is failed. nov 10 01:36:47 debian-systemd systemd[1]: Unit virtualbox-guest-utils.service entered failed state. // log extract ends I don't understand why there should be a reference to an external support entity when the issue obviously is Debian related and should be reported as such in Debian-related forums. My specific issue has nothing to do with systemd or FreeDesktop.ORG. I want the external reference removed. If it stays it will only create confusion and misunderstanding. This is useful for third-party packages and unpackaged software but I agree that for packaged software systemd error logging should clearly refer to both Debian and upstream sources for support. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?
Hello all, since 1. I need signatures on my all new fresh key 0x29774B39 and 2. I would love to meet all the local Debianistas would any of you come and sign my key when in Zürich/SH/Winti? Anybody interested in going out for a beer? We could also have a bugfixing evening. Wink, *t -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5462c30f.3090...@sourcepole.ch
Re: Should fast-evolving packages be backports-only?
On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place.
Does this mean that I should ask for the removal of youtube-dl from testing?
It will certainly bitrot in a stable release, as it supports downloading
from many sites, the target sites are moving too fast (that's the nature
of the web) and there's no chance that I will be hunting minimal patches
to fix breakage of multiple sites, as upstream generally refactors the
whole thing constantly and as multiple sites may get broken, the pile of
patches would sometimes be larger than the code to extract data from
some simpler sites.
I am, though, very happy to upload newer upstream versions.
Cheers,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m3toeh$ja3$1...@ger.gmane.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 11, Raphael Hertzog hert...@debian.org wrote: QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? Whatever the decision will be on debian/master, I think that master should be at the very least an option. When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. For example, a Debian maintainer I am attaching the simple git debtag command that I use on my packages, in the hope that somebody will find a good home for it. :-) If the Git workflow in use imports the upstream sources from released tarballs, this should be done under the upstream namespace. By default, the latest upstream version should be imported in the `upstream/latest` branch and when packages for multiple upstream versions are maintained concurrently, one should create as many upstream branches as required. I do not think that concurrently importing multiple upstream versions is the common case, so just the simple upstream that many packages are currently using should be allowed as well. -- ciao, Marco #!/bin/sh -e VER=$(dpkg-parsechangelog --show-field Version) if [ -z $VER ]; then echo Could not parse the changelog! 2 exit 1 fi VER=$(echo $VER | sed -e 's/~/_/g' -e 's/:/%/g') # is there a simple and reliable way to determine if a package is native? if git tag | grep -q '^debian/'; then TAG=debian/$VER else TAG=v$VER fi exec git tag -s -m version $VER $TAG pgpkZQ01qZCZ0.pgp Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
2014-11-11 22:26 GMT+01:00 Raphael Hertzog hert...@debian.org: Hello, Hello Raphael, following the initial discussion we had in August (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have written a first draft of the Debian Enhancement Proposal that I suggested. It's now online at http://dep.debian.net/deps/dep14 and also attached below so that you can easily reply and comment. Thanks for this much-needed DEP! [...] QUESTION: some people have argued to use debian/master as the latest packaging targets sometimes sid and sometimes experimental. Should we standardize on this? Or should we explicitly allow this as an alternative? I prefer as much standardization as possible. debian/sid should not be a particular case. [...] A paragraph about repacked upstream is needed. A lot of packages are currently stripped for minified JS, non-free additions, included RFCs, ... What would the upstream/1.x branch be then? Maybe add an upstream/1.x+debian branch? Also, the vendor/* branches heads should be at a descendent commit of the corresponding upstream branch, diffing only by the debian dir. Regards -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAFX5sbzieQ75nT8xBa3GMw-gzd-uGFy2fzSmx5A=R=1uzfs...@mail.gmail.com
Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?
On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote: would any of you come and sign my key when in Zürich/SH/Winti? In case folks from these places aren't reading this list, some possibilities: https://db.debian.org/search.cgi?country=chdosearch=Search https://wiki.debian.org/Keysigning/Offers#CH https://wiki.debian.org/LocalGroups#Switzerland http://debian.ch/ This info brought to you by DebianLocations: https://wiki.debian.org/DebianLocations -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HDv4oZ8=9gxxBJDSYrqjkgmj=q1vaoaeyccaky6xn...@mail.gmail.com
Re: r-base-core upload to unstable does not respect freeze policy
Hi Santiago,
On Tue, Nov 11, 2014 at 10:24:11PM +0100, Santiago Vila wrote:
include /usr/share/R/debian/r-cran.mk
which contains:
rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
...
## support ${R:Depends} via debian/${package}.substvars
echo R:Depends=r-base-core (= ${rversion})
debian/$(package).substvars
So, would this patch to the current r-base package improve things if
applied to the version in unstable?
diff --git a/debian/r-cran.mk b/debian/r-cran.mk
index e366f6b..0550173 100644
--- a/debian/r-cran.mk
+++ b/debian/r-cran.mk
@@ -60,7 +60,7 @@ endif
#rversion:= $(shell zcat /usr/share/doc/r-base-dev/changelog.Debian.gz |
\
#dpkg-parsechangelog -l- --count 1 | \
#awk '/^Version/ {print $$2}')
-rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
+rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev | perl -ne
'print /([0-9]\.[0-9])/')
## we use these results for the to-be-installed-in directory
debRlib := $(CURDIR)/debian/$(package)/$(debRdir)
While this would create a versioned dependency relation which would
allow to migrate r-cran-epi to testing I'm personally lacking the
technical knowledge whether this is the correct solution. From my point
of view the correct approach would be to create an r-base-core package
which declares a stable ABI and packages should depend from the ABI
version. However, its way to late for implementing this in Jessie and
the R maintainer is not willing to do this anyway (at least he was not
when we discussed this in Wheezy freeze time[1]).
Kind regards
Andreas.
[1] https://lists.debian.org/debian-devel/2013/04/msg00074.html
https://lists.debian.org/debian-devel/2013/04/msg00281.html
(and more in this thread and the according bug reports)
--
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: https://lists.debian.org/20141112061758.ga22...@an3as.eu
Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?
On 12/11/14 06:59, Paul Wise wrote: On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote: would any of you come and sign my key when in Zürich/SH/Winti? In case folks from these places aren't reading this list, some possibilities: https://db.debian.org/search.cgi?country=chdosearch=Search https://wiki.debian.org/Keysigning/Offers#CH https://wiki.debian.org/LocalGroups#Switzerland http://debian.ch/ This info brought to you by DebianLocations: https://wiki.debian.org/DebianLocations Even better - there is monthly beersigning near the main railway station Zurich HB, look for the Debian Treff: http://www.lugs.ch/lugs/termine/ I'm not far from Zurich myself, may be up there again Saturday, please email on the debian.ch list or try #debian.ch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54630469.9040...@pocock.pro
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Raphael == Raphael Hertzog hert...@debian.org writes: Raphael Packaging branches and tags Raphael === [...] Raphael The Git repository listed in debian/control's `Vcs-Git` field should Raphael usually have its HEAD point to the branch corresponding to the Raphael distribution where new upstream versions are usually sent. For Debian, Raphael it will usually be `debian/sid` (or sometimes `debian/experimental`). Raphael QUESTION: some people have argued to use debian/master as the latest Raphael packaging targets sometimes sid and sometimes experimental. Should we Raphael standardize on this? Or should we explicitly allow this as an alternative? I'd suggest not standardizing on this, but having a list of recommendations instead, without naming one single name as THE recommended one. For different use cases, different HEAD makes sense. Also, I like to name my branches according to the distribution that it will target, which means I prefer debian/unstable over debian/sid. For me, that makes more sense, at least in the case of unstable and experimental. For anything else, codenames it is. Raphael When releasing a Debian package, the packager should create and push Raphael a signed tag named `vendor/version`. For example, a Debian maintainer Raphael releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael point to the exact commit that was used to build the corresponding upload. Mmm... I disagree here too. I think following upstream tagging conventions would be the way to go here. So if upstream uses `package-version` tags, then debian releases would be tagged like `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael Other recommendations Raphael = [...] Raphael What to store in the Git repository Raphael --- Raphael It is recommended that the packaging branches contain both the upstream Raphael sources and the Debian packaging. Users who have cloned the repository Raphael should be able to run `dpkg-buildpackage -b -us -uc` without doing Raphael anything else (assuming they have the required build dependencies). Raphael It is also important so that contributors are able to use the tool of their Raphael choice to update the debian/patches quilt series: multiple helper tools Raphael need the upstream sources in Git to manage this patch series as a Git Raphael branch. I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. For the record, I used to hate that style, and was an advocate for storing upstream sources in the repo too. Then I started maintaining ~6 packaging branches: three upstream versions, two packaging branch variants of each. The overlay style proved to be far superior in this case. In short, I'd suggest having the DEP document both layouts, and recommend using one of them, while also recommending to document it in debian/README.source. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6EyPLx+zdfbKwhfEescL=ynqSfZ4ANfAqGX=4pkiv+...@mail.gmail.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, Nov 11, 2014 at 11:38 PM, Paul Wise p...@debian.org wrote: On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote: I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. Personally I wouldn't use anything other than debian-only repos, at least for those where I have a choice. I also actively avoid contributing to packages that don't use such repos. +1 Most of my collab-maint repos still use svn largely because svn encourages debian-only repos (and also because of inertia, I guess), not because I don't want to use git. Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tDnwCHxScaqGqKarT=pd5qaxkyodtcto3uklec9rhv...@mail.gmail.com
Accepted guake 0.5.0-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 10 Nov 2014 16:52:50 -0500 Source: guake Binary: guake Architecture: source amd64 Version: 0.5.0-2 Distribution: unstable Urgency: low Maintainer: Sylvestre Ledru sylves...@debian.org Changed-By: Daniel Echeverry epsilo...@gmail.com Description: guake - Drop-down terminal for GNOME Desktop Environment Closes: 761430 Changes: guake (0.5.0-2) unstable; urgency=low . * debian/patches + fix_floating_point_exception.diff patch + floating point exception when system fixed font set. Closes: #761430 Checksums-Sha1: 841e50b044c94e4145a03542d5e25f683203a1f1 2031 guake_0.5.0-2.dsc e3d3e1ae372105c93ed6c34465bd08d667a6eab6 6276 guake_0.5.0-2.debian.tar.xz 4776cbd79c51e7b36192bc70631f078ba7f7b13b 245052 guake_0.5.0-2_amd64.deb Checksums-Sha256: a841ab7ddaf8cbda5c8cc73964aa9cfd5ba80b89f23985e7d83e6f41771798e8 2031 guake_0.5.0-2.dsc 411cd78cafd8ead8deac200962ffe445058c9a39f01f3d2e9adab856bbe92b8a 6276 guake_0.5.0-2.debian.tar.xz 8055dc4f330eda745f861d7e92c03120efc38940f4dc3368d9798451f5f8c14f 245052 guake_0.5.0-2_amd64.deb Files: 5cd42bb3e0b9a499f4b1dd3afee471b8 2031 x11 optional guake_0.5.0-2.dsc 005b65926b85f3382ddcbebf4c4ba1fc 6276 x11 optional guake_0.5.0-2.debian.tar.xz 72d52997b1f4039130a2e58b47837c59 245052 x11 optional guake_0.5.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYc13AAoJEH5lKNp1LxvhWzQP/2dkPMmQiulJ0Rl8PFX8tPhb Q76B9z3tZYvKBTAhWXuJigoVLnIwg1qaFXfOA3JApGPt1JGwormwUbBLsi6cNPDp vsy3rqDnxpqcLaYtC0w3MRSOSJXDsT8krKD8X4grer5QlKhSmth7KNpCcy0kGQ8R Hh2pTy99GUrTfqwJPHdtYtg+odNo7YcXUWpb4Kb+s6Bxl1JJdpqlPyavThQTTABZ yQ77DkS+lsoki4Noeh+Z1t+l+rVNnFoFQcybRFpbS7NYcB8VAu0nXTOF2FTNCLiB 76UNFZg7ScP+wsT2QIro9EwjGEP3ye8R44/61bfAgmBw2FuScaXg9avkynAdM66c W4se5Ws+KG8c/YhyOgPaYFvHgY33qVM4Mx8HphqXBBMWAEKEY6GDWykx/b5d+FBJ waRQh8Qo7DfCkjqrACqU0c/0OEPOfdMLL1eSSzOupxaOug1h5X0fhX2e4LfHnV8N DrMJcUO6wZnrlFQSD3Zfb8jUcbkybq/NwSOi3BuJdwK9OFQTZROqbJp9gJ8lYI9E llMJSCTh4W0X4u6E01ZWvtxHYgUU+IXHZXQ40+hOf0UYXftZeT1gzK2wfzaPMqtg DqDrNz2SMS4fc8oTt5md1u+Lnj0OkoBNb+LDV1zi50Lqmn1JPBMxTdc/F5dGxQL4 xbdQZ4kjxOmMA82vw13r =MNdK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xo7dq-0005ka...@franck.debian.org
Accepted freeipa 4.0.5-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Nov 2014 10:38:52 +0200 Source: freeipa Binary: freeipa-server freeipa-server-trust-ad freeipa-client freeipa-admintools freeipa-tests python-freeipa Architecture: source amd64 Version: 4.0.5-1 Distribution: unstable Urgency: medium Maintainer: Debian FreeIPA Team pkg-freeipa-de...@lists.alioth.debian.org Changed-By: Timo Aaltonen tjaal...@debian.org Description: freeipa-admintools - FreeIPA centralized identity framework -- admintools freeipa-client - FreeIPA centralized identity framework -- client freeipa-server - FreeIPA centralized identity framework -- server freeipa-server-trust-ad - FreeIPA centralized identity framework -- AD trust installer freeipa-tests - FreeIPA centralized identity framework -- tests python-freeipa - FreeIPA centralized identity framework -- Python modules Closes: 768122 768187 768294 769037 Changes: freeipa (4.0.5-1) unstable; urgency=medium . * New upstream release - Fix CVE-2014-7828. (Closes: #768294) * control: Update my email address. * fix-bind-conf.diff, add-debian-platform.diff: Fix bind config template to use Debian specific paths, and replace named.conf not named.conf.local. (Closes: #768122) * rules, -server.postinst: Create /var/cache/bind/data owned by bind user. * rules: Fix /var/lib/ipa/backup permissions. * Add non-standard-dir-perm to server lintian overrides. * copyright: Fix a typo. * control: Bump dependency on bind9-dyndb-ldap to 6.0-4~. * control: Move dependency on python-qrcode and python-yubico from server to python-freeipa and drop python-selinux which belongs to pki-server. * control: Relax libxmlrpc-core-c3-dev buil-dep and 389-ds-base dep for easier backporting. * control: Add python-dateutils to server, and python-dbus and python- memcache to python-freeipa dependencies. (Closes: #768187) * platform: Handle /etc/default/nfs-common and /etc/default/autofs, drop NSS_DB_DIR since it's inherited already. (Closes: #769037) * control: Bump policy to 3.9.6, no changes. Checksums-Sha1: e7a21e9a8dea3987c587aba764228acfadb73a59 2980 freeipa_4.0.5-1.dsc 1b690aae94b34e81a612363a4624994f14ffd79f 4730699 freeipa_4.0.5.orig.tar.gz 5ab3c24b7f22416ea617df4c0956d2425e55b9f8 21684 freeipa_4.0.5-1.debian.tar.xz 976d0a4ffad604489e97c40c15fd435337aac2f8 688738 freeipa-server_4.0.5-1_amd64.deb fc09721587cfb64e853ce387d2ba08801d6084fe 77262 freeipa-server-trust-ad_4.0.5-1_amd64.deb 1272261305649c9e3b19e3544f2314ec1b16a68d 82428 freeipa-client_4.0.5-1_amd64.deb 9cdd08fa42330b40ef01f6685fe2be08167cd4fb 12868 freeipa-admintools_4.0.5-1_amd64.deb 20ca014e840ced292f777699250ef6016084a286 220542 freeipa-tests_4.0.5-1_amd64.deb 2ced9c8ce071da6f7100c92dac0f3f5d5312aa0d 518254 python-freeipa_4.0.5-1_amd64.deb Checksums-Sha256: 4bf6e4f2ee06991e4bd4d0d77150ab389a097133c3b27efe708d13da517a1891 2980 freeipa_4.0.5-1.dsc fa95de2b99d242a4a794d316bc272333e954eefd2857ebdac7380ceabca5c8cd 4730699 freeipa_4.0.5.orig.tar.gz cd54f522ae95050554ad7bdf3504b9458e7d1cdadd63057f0b331ec7ea603137 21684 freeipa_4.0.5-1.debian.tar.xz c7712b2450baf8a025a9829fd71f4c86fede2f0294403b11916308ae95af4a91 688738 freeipa-server_4.0.5-1_amd64.deb 05d1cb3246c044a918df23ce06787fbedae1614d8d92c4797a7a6175203b8a6e 77262 freeipa-server-trust-ad_4.0.5-1_amd64.deb 27466c1f5dc229b3299b6b313f3aae4974539e1af82e14a9866b36fd25622954 82428 freeipa-client_4.0.5-1_amd64.deb 27eadd5d8e294b9cfdb6c91315d50c99b20224b0cba88deae2c6e0c27fdafc05 12868 freeipa-admintools_4.0.5-1_amd64.deb ef35c88419a3bd44b59e05c37e9ec8e63a11198b31addf6724ac8053150b98b2 220542 freeipa-tests_4.0.5-1_amd64.deb 8701f101ecd732f16ca023ce6c80e920d02fe957eb79097cd8ce6c4cbcdf88aa 518254 python-freeipa_4.0.5-1_amd64.deb Files: b889c3f60a7cb9221a89a1182d5e0752 2980 net extra freeipa_4.0.5-1.dsc dc0ebfe24a20bd850641df05ff0a7268 4730699 net extra freeipa_4.0.5.orig.tar.gz 838a684bfb35a1e1dfd41a5a26a72399 21684 net extra freeipa_4.0.5-1.debian.tar.xz 6d521796b4d68c75fedc04309e5ebe8b 688738 net extra freeipa-server_4.0.5-1_amd64.deb be5b4c8830e6edc2a7e817fd9b9db454 77262 net extra freeipa-server-trust-ad_4.0.5-1_amd64.deb 1ad855f09aea880f4cdfafbb0f8c63be 82428 net extra freeipa-client_4.0.5-1_amd64.deb 83aa40f0d87636f3a75da16afdf738da 12868 net extra freeipa-admintools_4.0.5-1_amd64.deb 516b26954182ea806ef45a06806c0f34 220542 net extra freeipa-tests_4.0.5-1_amd64.deb 79694996af91154771312f6b278141a7 518254 python extra python-freeipa_4.0.5-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUYdDaAAoJEMtwMWWoiYTcJA4P/RDRgVa8cY/47FVfEwim5YPz pLWn4BjOk3yO8e7rM9C8HPz+z79b9nZiTiagLvjLwzFy/1in+xMWld61HGwwILhB RO8mEGMHCtJqHxYrvq9s16t86qws5NWIAwvExgqbcSVbCIvX948/8cbWycUe5FBB iNYBT1FGQi6gFKGQCqWWAFewSPuZg+PBiZlk2aN5hhklmaN5oKd7MHVeCjEstmQ6 J0gxdEfRVFo31zOGeU3Aib87iDoYbN0DYYHLQUGzGjBebWPmk24JaEEXdTgbCH4b
Accepted libreoffice 1:4.3.3-1 (all source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 09 Nov 2014 21:17:06 +0100 Source: libreoffice Binary: libreoffice libreoffice-l10n-za libreoffice-l10n-in libreoffice-core libreoffice-common libreoffice-java-common libreoffice-writer libreoffice-calc libreoffice-impress libreoffice-draw libreoffice-math libreoffice-base-core libreoffice-base libreoffice-style-crystal libreoffice-style-oxygen libreoffice-style-tango libreoffice-style-hicontrast libreoffice-style-sifr libreoffice-style-galaxy libreoffice-gtk libreoffice-gtk3 libreoffice-gnome python-uno python3-uno libreoffice-officebean openoffice.org-dtd-officedocument1.0 libreoffice-script-provider-python libreoffice-script-provider-bsh libreoffice-script-provider-js libreoffice-pdfimport libreoffice-avmedia-backend-gstreamer libreoffice-avmedia-backend-vlc libreoffice-sdbc-firebird libreoffice-sdbc-hsqldb libreoffice-base-drivers libreoffice-l10n-af libreoffice-l10n-ar libreoffice-l10n-as libreoffice-l10n-ast libreoffice-l10n-be libreoffice-l10n-bg libreoffice-l10n-bn libreoffice-l10n-br libreoffice-l10n-bs libreoffice-l10n-ca libreoffice-l10n-cs libreoffice-l10n-cy libreoffice-l10n-da libreoffice-l10n-de libreoffice-l10n-dz libreoffice-l10n-el libreoffice-l10n-en-gb libreoffice-l10n-en-za libreoffice-l10n-eo libreoffice-l10n-es libreoffice-l10n-et libreoffice-l10n-eu libreoffice-l10n-fa libreoffice-l10n-fi libreoffice-l10n-fr libreoffice-l10n-ga libreoffice-l10n-gd libreoffice-l10n-gl libreoffice-l10n-gu libreoffice-l10n-he libreoffice-l10n-hi libreoffice-l10n-hr libreoffice-l10n-hu libreoffice-l10n-id libreoffice-l10n-is libreoffice-l10n-it libreoffice-l10n-ja libreoffice-l10n-ka libreoffice-l10n-kk libreoffice-l10n-km libreoffice-l10n-ko libreoffice-l10n-kmr libreoffice-l10n-lt libreoffice-l10n-lv libreoffice-l10n-mk libreoffice-l10n-mn libreoffice-l10n-ml libreoffice-l10n-mr libreoffice-l10n-nb libreoffice-l10n-ne libreoffice-l10n-nl libreoffice-l10n-nn libreoffice-l10n-nr libreoffice-l10n-nso libreoffice-l10n-oc libreoffice-l10n-om libreoffice-l10n-or libreoffice-l10n-pa-in libreoffice-l10n-pl libreoffice-l10n-pt libreoffice-l10n-pt-br libreoffice-l10n-ro libreoffice-l10n-ru libreoffice-l10n-rw libreoffice-l10n-si libreoffice-l10n-sk libreoffice-l10n-sl libreoffice-l10n-sr libreoffice-l10n-ss libreoffice-l10n-st libreoffice-l10n-sv libreoffice-l10n-ta libreoffice-l10n-te libreoffice-l10n-tg libreoffice-l10n-th libreoffice-l10n-tn libreoffice-l10n-tr libreoffice-l10n-ts libreoffice-l10n-ug libreoffice-l10n-uk libreoffice-l10n-uz libreoffice-l10n-ve libreoffice-l10n-vi libreoffice-l10n-xh libreoffice-l10n-zh-cn libreoffice-l10n-zh-tw libreoffice-l10n-zu libreoffice-presenter-console libreoffice-presentation-minimizer libreoffice-emailmerge libreoffice-l10n-ku libreoffice-help-en-us libreoffice-help-ca libreoffice-help-cs libreoffice-help-da libreoffice-help-de libreoffice-help-dz libreoffice-help-el libreoffice-help-en-gb libreoffice-help-es libreoffice-help-et libreoffice-help-eu libreoffice-help-fi libreoffice-help-fr libreoffice-help-gl libreoffice-help-hi libreoffice-help-hu libreoffice-help-it libreoffice-help-ja libreoffice-help-km libreoffice-help-ko libreoffice-help-nl libreoffice-help-om libreoffice-help-pl libreoffice-help-pt libreoffice-help-pt-br libreoffice-help-ru libreoffice-help-sk libreoffice-help-sl libreoffice-help-sv libreoffice-help-tr libreoffice-help-vi libreoffice-help-zh-cn libreoffice-help-zh-tw uno-libs3 ure browser-plugin-libreoffice libreoffice-ogltrans libreoffice-wiki-publisher libreoffice-report-builder libreoffice-report-builder-bin fonts-opensymbol libreoffice-dbg uno-libs3-dbg ure-dbg libreoffice-dev libreoffice-dev-doc libreoffice-kde libreoffice-sdbc-postgresql libreoffice-mysql-connector libreoffice-evolution libreoffice-subsequentcheckbase libreoffice-librelogo Architecture: all source Version: 1:4.3.3-1 Distribution: unstable Urgency: medium Maintainer: Debian LibreOffice Maintainers debian-openoff...@lists.debian.org Changed-By: Rene Engelhard r...@debian.org Description: browser-plugin-libreoffice - office productivity suite -- Mozilla plugin fonts-opensymbol - OpenSymbol TrueType font libreoffice-avmedia-backend-gstreamer - GStreamer backend for LibreOffice libreoffice-avmedia-backend-vlc - VLC backend for LibreOffice libreoffice-base-core - office productivity suite -- shared library libreoffice-base-drivers - Database connectivity drivers for LibreOffice libreoffice-base - office productivity suite -- database libreoffice-calc - office productivity suite -- spreadsheet libreoffice-common - office productivity suite -- arch-independent files libreoffice-core - office productivity suite -- arch-dependent files libreoffice-dbg - office productivity suite -- debug symbols libreoffice-dev-doc - office productivity suite -- SDK documentation libreoffice-dev - office productivity suite -- SDK libreoffice-draw - office
Accepted binutils 2.24.90.20141111-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Nov 2014 07:55:51 +0100 Source: binutils Binary: binutils binutils-dev binutils-multiarch binutils-multiarch-dev binutils-hppa64 binutils-doc binutils-source Architecture: source all amd64 Version: 2.24.90.2014-1 Distribution: unstable Urgency: medium Maintainer: Matthias Klose d...@debian.org Changed-By: Matthias Klose d...@debian.org Description: binutils - GNU assembler, linker and binary utilities binutils-dev - GNU binary utilities (BFD development files) binutils-doc - Documentation for the GNU assembler, linker and binary utilities binutils-hppa64 - GNU assembler, linker and binary utilities targeted for hppa64-li binutils-multiarch - Binary utilities that support multi-arch targets binutils-multiarch-dev - GNU binary utilities that support multi-arch targets (BFD develop binutils-source - GNU assembler, linker and binary utilities (source) Changes: binutils (2.24.90.2014-1) unstable; urgency=medium . * Snapshot, taken from the 2.25 branch 2014. - Update .MIPS.abiflags to support MIPS R6. * gold: Misc updates for the AArch64 backend, taken from the trunk. * Mention some CVE issues, fixed in the 20141104 snapshot: - CVE-2014-8484 (PR binutils/17509). - CVE-2014-8485, CVE-2014-8504 (PR binutils/17510). - CVE-2014-8501, CVE-2014-8502, CVE-2014-8503 (PR binutils/17512). * Fix some lintian warnings. Checksums-Sha1: 9b3b757db24ab51a883562cdc29eaac8e0d7a362 1810 binutils_2.24.90.2014-1.dsc a61f8835f7c7353c4564ae92aa28bbb5c09057b8 29865415 binutils_2.24.90.2014.orig.tar.gz 554298cee31b2392d9d1394e853a03b8355be229 120571 binutils_2.24.90.2014-1.diff.gz 4cc591c27a02b2edaef61f91e79313a7cc4af16f 501116 binutils-doc_2.24.90.2014-1_all.deb 463863a6493937c4bfb3c8f30dba328234ec689a 17105754 binutils-source_2.24.90.2014-1_all.deb 2783c6a004d6124b5cd7ea559a224acd2c0b2402 3478252 binutils_2.24.90.2014-1_amd64.deb 115c554003482770f6511cd839d14a301a9cfb1d 1909368 binutils-dev_2.24.90.2014-1_amd64.deb 281596c7137eb9c1e4499a3945210c4b7f903618 1640608 binutils-multiarch_2.24.90.2014-1_amd64.deb c98b92bdde67f8f729b6c5f0370ccc13ec0820fe 1376 binutils-multiarch-dev_2.24.90.2014-1_amd64.deb Checksums-Sha256: 407a58abe8ad7f487c677b720b59dd9f1e788f68c4c6f50534c16227d83eb86b 1810 binutils_2.24.90.2014-1.dsc 98b84babfd03d60366f17dc6769801017ba931f6df6fe8e3f98c36bead2c3b2a 29865415 binutils_2.24.90.2014.orig.tar.gz 788d94be2feeb11f3f11ddae743f9ce08baddbe0b0690299076ec35162cec4ab 120571 binutils_2.24.90.2014-1.diff.gz dd8dfd4282ebe25c386678df5fd2958611009bf9dea858a59b902a3d82ce7c9a 501116 binutils-doc_2.24.90.2014-1_all.deb c3905d8f3b8f0071e5357f2ebd08ed035e61d88fa9fada8091b3a153b7657ecc 17105754 binutils-source_2.24.90.2014-1_all.deb 8f5d0ecfb512c8430d628bd74f521f65960c30f96b4f7caa69381eb24559fb44 3478252 binutils_2.24.90.2014-1_amd64.deb d732eebebf98edd7080323ce63c8926ec58dfdfff39b92369c493fc17f39b0a3 1909368 binutils-dev_2.24.90.2014-1_amd64.deb c9b78012f99f01ec22f8c08e0c4bf0a289fb38852e2e747148aa6ebe01cc78bd 1640608 binutils-multiarch_2.24.90.2014-1_amd64.deb 0036899f8dfa69f28f44c90390231d90f7f325cb347b8aeb1a8bf061431a6dfd 1376 binutils-multiarch-dev_2.24.90.2014-1_amd64.deb Files: 4c17d754fa864855a922bda8420de5f0 1810 devel optional binutils_2.24.90.2014-1.dsc b205f833eee1cbd9b2faf8e02153666e 29865415 devel optional binutils_2.24.90.2014.orig.tar.gz 9a1ff69e3ef1b023d411f060c1d3d2b3 120571 devel optional binutils_2.24.90.2014-1.diff.gz 1a1e5d7b284a4be13b3dbe07a83bad32 501116 doc optional binutils-doc_2.24.90.2014-1_all.deb bb1ce3da86dd63975a1c179d6d1ae30c 17105754 devel optional binutils-source_2.24.90.2014-1_all.deb 8610826bac16832aae3917b03d3c5045 3478252 devel optional binutils_2.24.90.2014-1_amd64.deb cac35d7572bb881802829d8b8ad382a1 1909368 devel extra binutils-dev_2.24.90.2014-1_amd64.deb f826a0e1a87555b585234eb69835d4d3 1640608 devel extra binutils-multiarch_2.24.90.2014-1_amd64.deb 7997b006d08c629ff686c38c40d0e21e 1376 devel extra binutils-multiarch-dev_2.24.90.2014-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRh0EAACgkQStlRaw+TLJy8kACgqwmTl899ERhV4qCCAjndbmWR IagAmwa1rSFq/0D+PLoSiW5ry3u003zv =fBEd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xo8yl-0006re...@franck.debian.org
Accepted binutils 2.24.90.20141111-2 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Nov 2014 11:10:27 +0100 Source: binutils Binary: binutils binutils-dev binutils-multiarch binutils-multiarch-dev binutils-hppa64 binutils-doc binutils-source Architecture: source all amd64 Version: 2.24.90.2014-2 Distribution: unstable Urgency: medium Maintainer: Matthias Klose d...@debian.org Changed-By: Matthias Klose d...@debian.org.org Description: binutils - GNU assembler, linker and binary utilities binutils-dev - GNU binary utilities (BFD development files) binutils-doc - Documentation for the GNU assembler, linker and binary utilities binutils-hppa64 - GNU assembler, linker and binary utilities targeted for hppa64-li binutils-multiarch - Binary utilities that support multi-arch targets binutils-multiarch-dev - GNU binary utilities that support multi-arch targets (BFD develop binutils-source - GNU assembler, linker and binary utilities (source) Closes: 769067 Changes: binutils (2.24.90.2014-2) unstable; urgency=medium . * Fix ld -r abort in _bfd_elf_write_section_eh_frame, taken from the trunk. Closes: #769067. Checksums-Sha1: b0c8c89f87235c7912c315d017e5d2082f8a034c 1810 binutils_2.24.90.2014-2.dsc c8e6c7c39d3deb53aba6f5eb1965459773bede56 121259 binutils_2.24.90.2014-2.diff.gz d4ea2ebb6b325344532d599e1e357418ddbe8fd6 501164 binutils-doc_2.24.90.2014-2_all.deb 091acead195b9ab2de5d6a45f7b2614f8b19c385 17112340 binutils-source_2.24.90.2014-2_all.deb 1a695c41268c267eb86862dc4be260f3863246aa 3478854 binutils_2.24.90.2014-2_amd64.deb bddf7e96156dd9c10aae004df6b69b7d62906659 1907552 binutils-dev_2.24.90.2014-2_amd64.deb 5d3fb56732b643ada2e71de68189bcb8fbd48be0 1633850 binutils-multiarch_2.24.90.2014-2_amd64.deb 0295ee0e1b3f342d6c6459fdc8e35b3a0d9827a1 1376 binutils-multiarch-dev_2.24.90.2014-2_amd64.deb Checksums-Sha256: 56221a5418981960ab8706eab6f6fead707dd2b41712e21212dd7c21ec3d14d6 1810 binutils_2.24.90.2014-2.dsc bcd088978015a8c635cbec7debe80718639df6d250c9fc134e509e3cf883f27f 121259 binutils_2.24.90.2014-2.diff.gz 19b9269f6a70938f29221027af2da724cbcba63ebd13ce8c4c14d47697c061c8 501164 binutils-doc_2.24.90.2014-2_all.deb dbeb0925cdbf503ff9c8f9846c1b8e5c55d41b62a1a9ab2c187b1be2a0d14f55 17112340 binutils-source_2.24.90.2014-2_all.deb d4304c9cba67e6d567ebfa024961d2998776434b4f9d35b1a6c878427783dca8 3478854 binutils_2.24.90.2014-2_amd64.deb 12be80e4277208a9fafeada16df8fc46ae905f72427be829b6973a98a2b5ccbc 1907552 binutils-dev_2.24.90.2014-2_amd64.deb dd7bc7a55788701691186bf0171b12a38679bb9689768e3049825a2979323a71 1633850 binutils-multiarch_2.24.90.2014-2_amd64.deb cbbbc604d69da6ee4dbe9d330c794b3d6f78f2e350254806c98adf5a7bbfb9c9 1376 binutils-multiarch-dev_2.24.90.2014-2_amd64.deb Files: 69808f22e7055e9f599b4eba85ef619a 1810 devel optional binutils_2.24.90.2014-2.dsc a758dfd39b5d9da5522749d184a17aa5 121259 devel optional binutils_2.24.90.2014-2.diff.gz e56aad1d2ec8114f56d9cf11037db538 501164 doc optional binutils-doc_2.24.90.2014-2_all.deb 3964276a251df1a2e94a1e873829a461 17112340 devel optional binutils-source_2.24.90.2014-2_all.deb 1182f31a1ddc1db12797ee11b0b3468e 3478854 devel optional binutils_2.24.90.2014-2_amd64.deb 1281b22b7e7306ec1115a3894dd132c9 1907552 devel extra binutils-dev_2.24.90.2014-2_amd64.deb 2d395033a9ca13eff7a15b2a15ac767c 1633850 devel extra binutils-multiarch_2.24.90.2014-2_amd64.deb e36651e31de9d9883050f7e443f7a335 1376 devel extra binutils-multiarch-dev_2.24.90.2014-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRh5IIACgkQStlRaw+TLJwuXACfZ67A4Pxx3sRARVZ8eIzpkU3L 92oAn2UyhlMWpbqvvikxgxvfY+nYgHiD =WTuM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xo8mb-0004cb...@franck.debian.org
Accepted libtuxcap 1.4.0.dfsg2-2.2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 06 Nov 2014 10:16:34 + Source: libtuxcap Binary: libtuxcap-dev libtuxcap4.0 libtuxcap4.0-dbg Architecture: source amd64 Version: 1.4.0.dfsg2-2.2 Distribution: unstable Urgency: medium Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Colin Watson cjwat...@debian.org Description: libtuxcap-dev - framework for developing 2D games - development files libtuxcap4.0 - framework for developing 2D games - runtime libraries libtuxcap4.0-dbg - framework for developing 2D games - debugging symbols Closes: 747908 Changes: libtuxcap (1.4.0.dfsg2-2.2) unstable; urgency=medium . * Non-maintainer upload. * Use pkg-config to get ImageMagick build flags (closes: #747908). Checksums-Sha1: 13ad094660666c5df087b35f76e23c2e542a031c 2283 libtuxcap_1.4.0.dfsg2-2.2.dsc e9b69481a315d80e56d4c8ab45c59fc7709a887e 10863 libtuxcap_1.4.0.dfsg2-2.2.diff.gz 2f0578e6227a3ee4a4f8c01e3553bbc4947bc6c0 788624 libtuxcap-dev_1.4.0.dfsg2-2.2_amd64.deb 0a7e74cc3e7febbd2a681cc093dd19672d10afb7 473866 libtuxcap4.0_1.4.0.dfsg2-2.2_amd64.deb b8e6bb6d5f3f210c64ce130a99141c200a03392c 107114 libtuxcap4.0-dbg_1.4.0.dfsg2-2.2_amd64.deb Checksums-Sha256: 9c412d3e015daf2025aaee7cff835f99ebca11c147c98155052c1b4df8524086 2283 libtuxcap_1.4.0.dfsg2-2.2.dsc 43c4d50e47f2ea7813dd9a71446ed27440f4c9b1c901fe36f64951f9b0259d93 10863 libtuxcap_1.4.0.dfsg2-2.2.diff.gz a9dac3f6a398f4e3f15129e66b4eb5971bac5cf997bb42ecb4fb749c7adfe547 788624 libtuxcap-dev_1.4.0.dfsg2-2.2_amd64.deb e279f6ceb27eb728923f6180c5cb88b2232ce2c69f2e3f61dba30f4654240546 473866 libtuxcap4.0_1.4.0.dfsg2-2.2_amd64.deb 1dc0fbee6b311b3c8b0bc8f0b8184ce9308ac81f16f54f27a2295ab876c2d49a 107114 libtuxcap4.0-dbg_1.4.0.dfsg2-2.2_amd64.deb Files: fcb063043ea3db97d8eb19380aaa08ce 2283 libs optional libtuxcap_1.4.0.dfsg2-2.2.dsc 104b47fdfb832ab5c28ad7b183784308 10863 libs optional libtuxcap_1.4.0.dfsg2-2.2.diff.gz 383a5dc58dcc98671bf106ee9231 788624 libdevel optional libtuxcap-dev_1.4.0.dfsg2-2.2_amd64.deb 072569c5c6be24e57141489c275d1e66 473866 libs optional libtuxcap4.0_1.4.0.dfsg2-2.2_amd64.deb dc168bc376369e7c40ad0cac4057c9d2 107114 debug extra libtuxcap4.0-dbg_1.4.0.dfsg2-2.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Colin Watson cjwat...@debian.org -- Debian developer iQIVAwUBVFtRgzk1h9l9hlALAQiGyg/+PcVqaR0IWZ+MZT90fq8oNvWlR+zrBLcj dWWo3EZwDJ8XXzvzZOdH9XyrVkX04BEdzwj/2AtjuTYcmgo3rI/twzd2F98myb2j AcMdcYabRwgNQiDtS71lyhelvGxKUe1mW594RxTG0cNhDWk1An+J4PkZC0T3HZRv 8Fp2Wlhm1wMtfAq0Zh2mLGlSPeUKYS7LQ776HSZ0W9Hj0c8YKI1UtBGMY8XCnBx6 TO9TRfYmV6vFxqtJQdJwH1sKffv8K+7uxpGSTT8q3LAXMEFym+37E/KUOxygtc6q vrnU8E6wOah2fs1W5No9E6AnDRHoJSMU0+9yfVPKPEpRoGmwC+StwYc+IdZUBSPD UnZ/PMLNNg9lX1nnQfnviXzp0QOFodf5i0is6StzVQFD5gc9tQTSWPth2wEU+LRT 7RewLqcGm+Pzxbev1lrGBT4Mx7bhI8vf05+g1g9nMjXrM3/a+jau5tc+Ejz+Kaa7 OlNS5OnQRkuyhd1wgT5RhEVtWvTLlOGi/wxwLnpFH6TYTC9/LPxC0YCFArLO5kvt BQxCRgffoxfBJ12oSt4HTsI+bxBvcxZxLhI7H/5bA1dM+cohz3cRvmkXkbUkX6CY 1m8TtuvbJQI+dBDt4LrD2iLLCgQ7iao67w4yiovF6pYGPcisTqxox7abb98aRGzk PolE3M64QXo= =PZQ4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xo9tu-00027r...@franck.debian.org
Accepted openvpn 2.3.4-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 07 Nov 2014 13:59:54 +0100 Source: openvpn Binary: openvpn Architecture: source amd64 Version: 2.3.4-4 Distribution: unstable Urgency: medium Maintainer: Alberto Gonzalez Iniesta a...@inittab.org Changed-By: Alberto Gonzalez Iniesta a...@inittab.org Description: openvpn- virtual private network daemon Closes: 768384 768411 Changes: openvpn (2.3.4-4) unstable; urgency=medium . * Use dh-systemd in order to enable the service unit. (Closes: #768411) * Add comment on /etc/default/openvpn file about options not supported on systemd. (Closes: #768384) Checksums-Sha1: 72f957dde44efd37234a0fe04d392557d4f46260 2005 openvpn_2.3.4-4.dsc 039bf4e8425312df569d0e31f9572139a4c987d5 106856 openvpn_2.3.4-4.debian.tar.xz 71b1611074051d2f4af29e65348bb2fbdee2a407 467678 openvpn_2.3.4-4_amd64.deb Checksums-Sha256: d6be2df64196c2ecebaa26307d184aa0e40c308d2e139fe6d2bf8bda7022053b 2005 openvpn_2.3.4-4.dsc 41962bc5d8cb0f0b9878eeba225963e4f80f17ae0182f3a8eddd8c622463468d 106856 openvpn_2.3.4-4.debian.tar.xz 47e6dc54c5e62d31b52d05717113f14eddb8d094eaad71a8232ab6e12832cbf2 467678 openvpn_2.3.4-4_amd64.deb Files: aa696d761de03193b3904238b5cf2b49 2005 net optional openvpn_2.3.4-4.dsc bb1d3cdabb25c26aba21f8aefd5748fb 106856 net optional openvpn_2.3.4-4.debian.tar.xz 59a92b283b4da160a793d7844d095346 467678 net optional openvpn_2.3.4-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYe6iAAoJEACbM3VrmqpVn8MP/i24PmJauWixbxcV/I6/4zCQ QVNZIw0S/Dt0a25NxofhwvCRFLdttcy0M+7tDQ2qZoc993LvtGcQ5snGP6RWHzzd O18GrwK8lM9/3oTljN416pBAWRKdVWnED5du8b7iMTGyFRifyQOH1ILnpsHJFPkp y32f8AY51IKxzhGX1Le8yAcs4nGkXxNVTGncML868G7zFfusCm8vGNtaMO6Ugf3I FUuG1ZlPdA8Utrhz6doD4baYNWIZLMOlCRVtjTleNOumun1PLJt5wl0OMWhhoxV5 r0doVb5IfX6DvdsXkHePwyPxMeJIuKUdNgw2EnRdGTojVXwIwpHK/ezB0c5XoBAN ou89EHIYGuwMspiJmYCpF3/xpwZv7INpRKnSZkqpREaS1d+y6lxXdoqCLLw3KlX3 9HQiGc6wSUb9eQMhD3zoW6CC5uXNbNiNEFcv6in5qw9jjsrXXK8TE92b/52rt+2Y ACEna6sHbycefrua7fAhs+Q1+nNS8urnJ6CeoZR722+E72pqb/ghZYqECWlx1fZ1 Tvw1f9erAs7FfUpyr99DCXEzIKpt9+JDO6Bh7aLX0nd06Le3sFOpKUCjgLp2eYdd o/cDwhACHlldyn/Uvo9evKn4seBO2xPJoSdBLKTPyzmWYpE8RyBmHmLx7+EPe3Tm w42ahfhE8utPEe35xlXz =Wmto -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xo9hl-0006y9...@franck.debian.org
Accepted isl 0.14-1 (source amd64) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Nov 2014 12:24:42 +0100 Source: isl Binary: libisl-dev libisl-dbg libisl13 Architecture: source amd64 Version: 0.14-1 Distribution: experimental Urgency: medium Maintainer: Debian GCC Maintainers debian-...@lists.debian.org Changed-By: Matthias Klose d...@debian.org Description: libisl-dbg - manipulating sets and relations of integer points bounded by line libisl-dev - manipulating sets and relations of integer points bounded by line libisl13 - manipulating sets and relations of integer points bounded by line Changes: isl (0.14-1) experimental; urgency=medium . * New upstream release. Checksums-Sha1: 1e924fbd01c790ae290ae066881a20a23455c8ae 1214 isl_0.14-1.dsc 259678a0b1d12f8bc45b9aaeaa14feded9d5b3e1 1247052 isl_0.14.orig.tar.xz e7e83f91e1a17b272b652be66d62e81ade0c7c1b 18540 isl_0.14-1.debian.tar.xz faeacecac4de0f791add4d43032bd548558ee342 484510 libisl-dev_0.14-1_amd64.deb 1f38cb08fd4a94480807aa9504b3874857ea139e 955110 libisl-dbg_0.14-1_amd64.deb e47f7af17a5bdecc59c82a37dedf49e36479bbb2 470176 libisl13_0.14-1_amd64.deb Checksums-Sha256: 5d93bd71e91051925c66d6224bfb9b3f19e26d6d8d2a008362dbba2116111d7e 1214 isl_0.14-1.dsc b1044f02819da0708fc7071fa2a558ce5d3c29d6676c8cb113caaedd5903ff03 1247052 isl_0.14.orig.tar.xz b39691cec6a0220f73d08da4457e6c180643d99cba4deb0616281ea5364b9256 18540 isl_0.14-1.debian.tar.xz d28beef184f94c04aba1eec991f04df97156e93e9708a5231ad8650546bce060 484510 libisl-dev_0.14-1_amd64.deb 637746c7cdc630a2bb2478e1f51371920b5f7081dee93506c19cf927fb46812e 955110 libisl-dbg_0.14-1_amd64.deb c7d11859408644f508f14b80456d48a0fc861e02b427948eaa33cab960383648 470176 libisl13_0.14-1_amd64.deb Files: b945bf8174792b139860ff410bbf2dfa 1214 libs optional isl_0.14-1.dsc 3d6b6a1cddd165fae2af5487c5531b09 1247052 libs optional isl_0.14.orig.tar.xz bea5a278a572366db0afd57070b72bf4 18540 libs optional isl_0.14-1.debian.tar.xz 0764ca81f2b9f9ee18da4a26d9987b18 484510 libdevel optional libisl-dev_0.14-1_amd64.deb bb49a21372cedcb73c585cd0f5eb3942 955110 debug extra libisl-dbg_0.14-1_amd64.deb 17911709f55676a257ab9fe24763a896 470176 libs optional libisl13_0.14-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRh+b4ACgkQStlRaw+TLJyUIQCgpKa2nu8sdeLYOVlT87c9XWGu sqkAoL7WklFLrQfMXXX7urCgzdoyUCsJ =lpmF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xoaau-0008cy...@franck.debian.org
Accepted tix 8.4.3-6 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 11 Nov 2014 12:10:19 +0100 Source: tix Binary: tix tix-dev Architecture: source amd64 Version: 8.4.3-6 Distribution: unstable Urgency: medium Maintainer: Georges Khaznadar georg...@debian.org Changed-By: georg...@debian.org Description: tix- Tix library for Tk -- runtime package tix-dev- Tix library for Tk -- development package Changes: tix (8.4.3-6) unstable; urgency=medium . * upgraded Standards-Version to 3.9.6 * removed build-dependencies and dependencies on tcl/tk 8.5, replaced them with dependencies on tcl/tk 8.6 * added a patch to fix interp-result bugs; this construct was deprecated in tcl8.5 and removed from tcl8.6; however the patch is just a workaround for now, since it adds #define USE_INTERP_RESULT 1 before the #include tcl.h * changed the variable tk_version in debian/rules, to fit tk8.6 * removed Conflicts clauses about packages which no longer exist Checksums-Sha1: 50e2f571593f4cb98f49cf28d509450de4cfe921 1687 tix_8.4.3-6.dsc 15d86b58173aee02f82d518f47ab6608d6e7006c 64360 tix_8.4.3-6.debian.tar.xz 1dc2b4bb69bd4f31a3140a6c217f6a8bf1c61adf 280806 tix_8.4.3-6_amd64.deb 1d0eb90b4205656a302bf704d76b9b43297d95b2 502632 tix-dev_8.4.3-6_amd64.deb Checksums-Sha256: ea2f393d3a5b771bf0b827507e5981c501fc4e50477c141bb5c99b9aab32eb5b 1687 tix_8.4.3-6.dsc 9b917b3aae4843639763af7c838812cbe15d8eb09a48f18c6953a0850f347e9a 64360 tix_8.4.3-6.debian.tar.xz 9690ae1146b8974b8de9357ac6e05957939623c40e02df7f13e1a4af16cbb85f 280806 tix_8.4.3-6_amd64.deb 5d0d6a9375c6910dcab9f37132dd76d32d8ffc99b4ec8bbcf55b415491c5b96a 502632 tix-dev_8.4.3-6_amd64.deb Files: f7a5edee87a383f6242153d43dfdcbb0 1687 libs optional tix_8.4.3-6.dsc 2d8720b6915277f3db736d30ba0ebb7f 64360 libs optional tix_8.4.3-6.debian.tar.xz b3f4b8bcda7b5526fd11016ee9e386bd 280806 libs optional tix_8.4.3-6_amd64.deb 618493e48258db4277518850c009d9fe 502632 devel optional tix-dev_8.4.3-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIVAwUBVGH3YhwoFpBxNq45AQhoBA//Tgx2K4ylm++FnVf+8I+ey7qul+E4f/Dp BiwN6+DZX3J+BEccrqyCy4NemaWzsyIhN2NO6ZZwtsuxP4X8leaxXDfjlTnH1hsQ Klui6H0twTFoF3zxnl2wbY/X7OWEJssJKxoDbSo4dbNmkD/6FA63hRQMBT285pyE JgOf9Fz7gM7uA1alC4vV0GTy08dBpzsHnatNicwYlrvfQIVhFYQYetxHDFiAYV7B gihZTkpSedTDmRyBip3Xt5IgBW+9HK90ga2LAI+HC3pI7oXUtC5xwWooCWSCREtQ qxiTb4RkTcAWiJTTHbl2DCAGBNqYsMyUhl37lyrLAu4VdC0V1NnwV9EwjuiGGcrw uhDbSaDJwukk1lPywtuQTMnRCVzt7oNvqSS0NZKYh6UdZAhMKO5Vu5UohT2KiibN N8riKMh7os6O1IwZN2z1fnDmZT/XPf6+iG8YoiPgxQbSgK5C1rTU6OpdU4tKCgB5 zNopsVbePqb9bV5fuurH2zDObvEZqcNJ/zPZ8YbkijFFZZwLozXeW1SwieTN6koE iWnojiLN0HkctBl/uEVuqrWvKb+xuqSN0h1ncWZwVVhtkRVv21a6qUS3yPzyL1Sz n/7ETLYWR+LUzo4NI80hRnIEQh9QsTiurHn2Imr8n/kjuWYWjIXioJaQJigRJ84o uSx1URxAVvY= =vvfJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xoabh-0008mq...@franck.debian.org
Accepted paulstretch 2.2-2-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 11 Nov 2014 13:33:39 +0100 Source: paulstretch Binary: paulstretch Architecture: source Version: 2.2-2-3 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Sebastian Ramacher sramac...@debian.org Description: paulstretch - Extreme sound time-stretch Closes: 768729 Changes: paulstretch (2.2-2-3) unstable; urgency=medium . * Team upload. * debian/rules: - Also link with vorbis and ogg. (Closes: #768729) - Build in override_dh_auto_build and not in override_dh_auto_install. Checksums-Sha1: f6e6001d8f5d2971dd343b8ac5661255bea7f506 2257 paulstretch_2.2-2-3.dsc f13679d98fb6fe7a64b14ca4dc019bb7eabdce15 3696 paulstretch_2.2-2-3.debian.tar.xz Checksums-Sha256: e046bf8c00e2112b4bdf3ccbcc39406fbc5261860c36b15ac4ef52ff73ea23fd 2257 paulstretch_2.2-2-3.dsc 2e52cc9c8d7b23597e3c135d31a37eeac93e9b6dc3438bb1f1b354feba76f958 3696 paulstretch_2.2-2-3.debian.tar.xz Files: 97123aa634612f989c2c301785adf5f0 2257 sound optional paulstretch_2.2-2-3.dsc 7e035fd6c85274fe7bfb70ea68afcac5 3696 sound optional paulstretch_2.2-2-3.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUYgKqAAoJEGny/FFupxmT0KYQAL5A8VV7D6fbQLMDthBeZ1Ni kotDHQfzNNWllnC4Al6Qw+RYKitkT6ZWL5FZNoTZSwf0dDSu1NjbtJJNDMfRA23W Ttnc2O2XW2AFHuZ5lgQ2I2fF9hJGFmQbKzcOJLiviYu670vtfeU33iTb3C4+3QkT T+Zl7MkWOiidxl0WDzvPbAF6b/0i2EhJBUSQJVA43R02sTLCHot6JcuK7GP0zvG7 4wF6kAIBmBOO+XmTBUEw1YxHbyeauR/CaexddVY8IcV9R5AdKR9oMtvSjV0v/3FT y3aHmKWVxf/aZobJbMd2PSc7ODmHk0U8WudkTSg/EsSG/lV0xD3VV7cbGaL8SeEc 0U1XHeDVnvTl97WntHrfieGUpqKk5+l8mSAtb3YRRhcGdWsPR3Nssna5FTAhiyJ9 cENO49/YfU2wG7WByFaH1ywGb++IiTcTjUwJROLJYk0p0vdKpuQqu6cwGqhXbiaY Iof+fFVmn5iveauOUO6dBfnp5TjnBDZf1SwYCGFp0B2WVU0tHJmZBYH9lV2pTJsn yEkkhPvORI4RyZ+I3ycTL3sCRV3Y+wQi0ekaQpFjE2kcIDzPO+/1+cd4i3lFVtdQ vtRBUjj/gZ3pmW8yGjXy+vQEnbKlQeNtofaNXhwYRrrpgAKmtoscdg+H4QNfVUtI MWmWVOFfV3JUMwZQt3Q+ =MUeC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xoast-0008jx...@franck.debian.org
