Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Ian Jackson: Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. I disagree with half of this but agree with the other half. I think that the divided workflow should be documented in this DEP. But I agree that those who like the divided workflow should be the ones to write it up. I see that Simon (for example) is actively engaging in the discussion. Thanks; this is a good way to proceed. -- -- 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/20141113080504.gk23...@smurf.noris.de
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
[ I skip the more detailed discussions on naming conventions to concentrate on your higher level questions for now ] On Thu, 13 Nov 2014, Ron wrote: Sure, I understood those were your goals. What I haven't seen, and what I'm asking for, is an actual detailed rationale describing the actual detailed problem(s) that you think these goals will be a remedy for. Problem 1: the derivatives -- So I am a Kali Linux contributor. We use git repos to maintain all our packages and we use git-buildpackage. Most of the Kali contributors are not long-term Debian contributors, I write documentation so that they can contribute to Kali (while basing our work on Debian). To make this manageable I opted to always use a workflow based on git-import-orig. Even when Debian has its own git repo, we start from the released source packages because that's the only level of uniformity that we can rely on. And it's a pity because if we could build on Debian's git repo, it also means that our work would be easier to merge for the Debian maintainer. They could add the Kali repo as a remote (without fearing any conflict in terms of tags, branch names) and just merge or cherry-pick as appropriate. And we could also build on work in progress that has not yet been released as a source package. Right now, the only packages where we build on top of the Debian git repositories are some native packages (like debian-installer). I can't afford to document all the possible ways Debian is maintaining their package but if I can write a documentation that covers the common case and if I can tell them when you see those branches, you can follow the instructions below, then we have made some real progress. Problem 2: interoperability between the tools - I am part of the Python Modules team who wants to switch to git but not all contributors are using the same git helper tools and yet we would like to all work together on the same repositories without forcing everybody to use the same helper tool (habits are hard to change). We can't just let each maintainer use the default layout suggested by his preferred helper tool and the defaul tagging scheme, we have to define some common layout for the whole team. Then it matters less if people are using git-buildpackage or git-dpm or gitpkg. It might be awkward at times but at least there is some consistency among the team, and the few problems that will arise will be occasions to improve the tools. But we have to define the common layout to use and this discussion should hopefully solve this too. Problem 3: making it easier for new contributors - While I can appreciate the versatility of gitpkg, new contributors are looking for guidance and clear instructions. It's difficult to give those when we have zero common ground on how we manage our git repositories within our project. While I don't see us converging on any single helper tool right now, it's important to start taking steps that brings them closer so that we can give more useful explanations to newcomers. and so that they can get started Likewise, it's not clear to me that tools other than gitpkg are actually interchangeable, because they weren't designed to be from the outset and rely on magic being committed into the repo to work. I don't really see how some naming conventions can fix that either. Naming conventions won't fix that but it's still a pre-requisite to be able to fix the tools that (unlike gitpkg) voluntarily set (by default) more constraints on the expected layout of the repository. Maybe if you start by detailing the problems, we will be able to see some better solutions that actually achieve your real goals and result in real improvements to the tools that created them. Let's see! Fine if the other tools do not need anything like that. But who knows, maybe you will want to enhance git-debcherry to not only update debian/patches/ but also store the corresponding git branch for long-term storage. In which case, you will already have a recommended tag name for this purpose :-) Why would you want to do that? To share them with upstream in a form ready for merge (or more practical for review/analysis, etc.). I am a bit curious about what patches you think you're going to need to make to make things comply with this plan? For gitpkg? I don't know. See above, maybe it's just documentation update. I meant for the other tools. You said you thought they were going to need patching for this and were planning to help with that. Well git-buildpackage obviously needs quite some update: - it complains when you're trying to build as soon as you're not in a branch named master (that can be overridden with --git-ignore-branch or setting --git-debian-branch) - it hardcodes the debian/ prefix for tags instead of retrieving it dynamically - it uses the upstream branch
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
I think you need to be more explicit about the implications for `3.0 (quilt)' format packages. Something like: If the git tree contains debian/format specifying `3.0 (quilt)', the git tree must also contain debian/patches/series and all the patch files contained within it. Furthermore, the tree should be in the `patches applied' state. (This means that every change to upstream files is represented twice: once in the contents of that very file in the git tree, and once as a hunk in one of the debian/patches. These two representations must be in step.) And you should add: The packaging branch should not contain a `.pc' directory. Maybe I got the above wrong: you mean patch applied after e.g quilt push -a ? I think, removing .pc then would be a bad idea as quilt would be confused? -- tobi -- 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/4afd0ddf4225fa49db35803d91c5a451.squir...@isengard.geekcommandos.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Raphael Hertzog wrote: First, I'm a fan of trying to ease the workflow for all by having some standardisation / best-practice recommendation/documentation. Kudos to the initiattors! 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? Given the feedback received, and the case of derivatives that don't have a stable name for their development releases, I propose to update the Packaging branches and tags section with the content below. Does that sound like an improvement? Packaging branches and tags === In general, packaging branches should be named according to the codename of the target distribution. We differentiate however the case of development releases from other releases. For development releases Packages uploaded to the current development release should be prepared in a `vendor/master` branch. However, when multiple development releases are regularly used (for example `unstable` and `experimental` in Debian), it is also accepted to name the branches according to the codename or the suite name of the target distribution (aka `debian/sid` or `debian/unstable`, and `debian/experimental`). Those branches can be short-lived (i.e. they exist only until they are merged into `vendor/master` or until the version in the associated repository is replaced by the version in `vendor/master`) or they can be permanent (in which case `vendor/master` should not exist). NOTE: The Git repository listed in debian/control's `Vcs-Git` field should have its HEAD point to the branch where new upstream versions are being packaged (that is one of the branches associated to a development release). The helper tools that do create those repositories should use a command like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD to point to the desired branch. For stable releases --- When a package targets any release that is not one of the usual development releases (i.e. stable releases or a frozen development release), it should be prepared in a branch named with the codename of the target distribution. In the case of Debian, that means for example `debian/jessie`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid suite names because those tend to evolve over time (stable becomes oldstable and so on). Security updates and stable updates are expected to be handled on the branch of the associated distribution. For example, in the case of Debian, uploads to `wheezy-security` or `wheezy-proposed-updates` are prepared on the `debian/wheezy` branch. Shall there be a need to manage different versions of the packages in both repositories, then the branches `debian/wheezy-security` and `debian/wheezy-updates` can be used. Tagging package releases 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. One point came to my mind: NMUs Can we maybe add some words what would be best practice to handle NMUs? I think just applying them to debian/sid (or whatever we call it) won't work in every case, as the packaging repository might have already (not-for-NMUs-suitableable) commits. I saw even new upstream releases sitting there, with an maintainer (pseudo)MIA*. So it is not guaranteed that NMUs can be directly applied to debian/sid and worst case lots of stuff needs to be reverted before one can start on the NMU and maybe restored later, rinse-repeat on a later NMU. And if the NMU is cancelled, there will be lots of noise in the commit log for non-existing releases. For the maintainer ack'ing the NMU could be then simple as an merge. So may I propose to have some procedure recommended for NMUs? (or at least for such case where it is not easy possible to work directly with debian/sid) Maybe add the intended NMU-version to it. This branch could also be short-lived. * responsive in email, but still non acting 6months -- 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/a8868548708f26ab17b0f2eda6b61ade.squir...@isengard.geekcommandos.com
Re: Second call for votes: GR - Init system coupling
On Wed, Nov 12, 2014 at 10:29:07AM +, Neil McGovern wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 57dd4d7c-3e92-428f-8ab7-10de5172589e [ 4 ] Choice 1: Packages may not (in general) require a specific init system [ 1 ] Choice 2: Support for other init systems is recommended, but not mandatory [ 2 ] Choice 3: Packages may require specific init systems if maintainers decide [ 4 ] Choice 4: General Resolution is not required [ 3 ] Choice 5: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
2014-11-12 10:28 GMT+01:00 Raphael Hertzog hert...@debian.org: On Wed, 12 Nov 2014, Mathieu Parent wrote: OK. Makes sense. The unstripped upstream can then live in an non-namespaced branch if needed (this is not my usual workflow but should be possible). On Wed, 12 Nov 2014, Mathieu Parent wrote: Maybe a short note would be good then? (but I don't know how to write it). I suggest this: --- a/web/deps/dep14.mdwn +++ b/web/deps/dep14.mdwn @@ -230,6 +230,17 @@ non-patchable data), you can do so but you should then document this in `debian/README.source` along with some explanations of the tool to use to build the package. +About repacked upstream sources +--- + +When the upstream sources needs to be repacked (for example to drop some +non-DFSG compliant files), then the branches and tags under the +`upstream/` prefix should actually contain the repacked sources. + +How the problematic files are pruned does not matter. What matters is that +what is stored in the `upstream/*` namespace are the sources that package +maintainers are effectively using. + Managing debian/changelog - Does this meet your expectation? Cheers, Should we add a word or two (some warning/reminder) how to handle removing non-free content, especially if (Debian thinks) that the removed files are not distributeable? To avoid that we actucally distribute them in some branch without recognizing. -- tobi -- 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/4dafed01424b46f00229d4e894002d66.squir...@isengard.geekcommandos.com
Being part of a community and behaving
Dear Josselin, I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html I would like to ask you to resist the temptation of publishing similar posts. It makes fun of part of our community which you are well aware of and it also shows corpses which probably did not ring a bell in you. None of those show good taste and by having it aggregated on planet.debian.org it shows the whole project in bad light, too. Thanks in advance, Balint -- 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/cak0odpxmkyqxinuc+l+35x0gole04ye37wwv5ug3ynsz4sm...@mail.gmail.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Le 12/11/2014 12:25, Raphael Hertzog a écrit : Hi, On Wed, 12 Nov 2014, Thibaut Paumard wrote: I see nothing about whether the debian branch should contained the unpacked or the unpacked *and* patched sources, and whether to ship the .pc directory. That's a volunteer choice at this stage. We have different workflows that are worth supporting and they differ at this level of details. Dear Raphaël, I see that some people feel very strongly that the source should be in patch-applied state. Some tools require it. I am very strongly of the opposite opinion (for reasons detailed below). You are right that this DEP should not mandate one over the other (actually this DEP is a best practices document, so strictly speaking it doesn't mandate anything). However, we should perhaps strongly recommend that this choice be documented in debian/README.sources. Not that it's very relevant, to each his own, but since I see advocacies for the patch-applied state. I'm not trying to convince anyone, but here is why I chose patch-unapplied: We have a very nice source package format with 3.0 (quilt). In this format, we simply have the pristine upstream source, with an additional debian directory that contains all the packaging stuff. Features are nicely separated as feature patches. I think the only workflow that newcomers and NMUers should be required to learn is the one that involves quilt, they should not be expected to learn (e.g.) dgit in addition. Also, we need to document the debian/patches à la DEP3. So the way our modifications to the upstream source are stored should be in debian/patches/, independent on whether we use the tar.gz archives or svn or git. If these modifications are stored already in debian/patches, representing them also in git in the upstream code is a pointless duplication of the same information. With the patch-unapplied scheme, I can do: git diff upstream master and check that there is nothing changed above the debian/ directory. Likewise, I can do git diff debian/1.0.0-1 debian/1.0.0-2 and check the changes that will be represented in the source package. So to me, the patch-unapplied scheme is easier to understand and less error prone. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote: [..snip..] Well git-buildpackage obviously needs quite some update: - it complains when you're trying to build as soon as you're not in a branch named master (that can be overridden with --git-ignore-branch or setting --git-debian-branch) - it hardcodes the debian/ prefix for tags instead of retrieving it dynamically - it uses the upstream branch by default in git-import-orig while it should use upstream/latest if we follow the current version of the DEP This mostly means changing the defaults to things we already recommend in the gbp manual in a similar spirit though not using the exact same branch names yet as well as using the output of dpkg-vendor --query Vendor for the tag prefix. Cheers, -- Guido -- 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/20141113101016.ga2...@bogon.m.sigxcpu.org
Re: Bad weather in testing?
Le mercredi 12 novembre 2014 à 18:42 +0800, Paul Wise a écrit : On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote: This is a bug, I’ve seen this affect buildd dependency resolution, and anyway, if it’s not installable everywhere, why is it arch:all? I would guess that uninstallable arch:all things happens when they depend on non-portable things. For example pixbros/pixfrogger depend on fenix. Indeed. As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. Jérémy. -- 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/1415874379.10001.4.ca...@melix.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Thibaut Paumard writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): [patches applied vs unapplied] However, we should perhaps strongly recommend that this choice be documented in debian/README.sources. I think it would be better to document this by the use of different branch names. It is, after all, possible to make both patches-applied and patches-unapplied branches for the same package. For example, if a package's maintainer team use patches-unapplied, a dgit user will still see patches-applied. A note in README.sources is (a) in the wrong place because it attaches not to the particular git branch but to the whole contents and (b) not machine-readable. I think the only workflow that newcomers and NMUers should be required to learn is the one that involves quilt, they should not be expected to learn (e.g.) dgit in addition. [...] I certainly don't think people should be expected to learn dgit in addition to other tools. I am trying to get to the point where 1. they can learn dgit _instead_ of _all_ other tools[1] 2. no-one else needs to know that this is going on unless they decide to start using dgit too. [1] I'm assuming they know git already, and that they're trying to do NMUs or be a derivative (public or private). 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/21604.34838.928787.815...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Tobias Frost writes (Re: RFC: DEP-14: Recommended layout for Git packaging repositories): [Ian:] And you should add: The packaging branch should not contain a `.pc' directory. Maybe I got the above wrong: you mean patch applied after e.g quilt push -a ? I think, removing .pc then would be a bad idea as quilt would be confused? dpkg-source seems to cope all right. I think that .pc-less patches-applied branches are not intended to be manipulated with quilt. We're trying to document best practice. Does anyone have .pc-ful patches-applied branches (not counting dgit, which is going to change) ? 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/21604.34985.432393.608...@chiark.greenend.org.uk
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, Thibaut Paumard: We have a very nice source package format with 3.0 (quilt). IMHO this format is very nice if you have some opaque upstream, and a debian/ directory that's under your control. This restriction does not apply to a DVCS like git. Moreover, git already has built-in mechanisms to do all of this. People who are used to otherwise working with git may not see any sense in learning another way of doing essentially the same thing. If these modifications are stored already in debian/patches, representing them also in git in the upstream code is a pointless duplication of the same information. No. The git representation is a strict superset of the information in debian/patches, as it includes patch history that can be actually reasoned about. Likewise, I can do git diff debian/1.0.0-1 debian/1.0.0-2 If this includes a changed patch, the result of this command is a patch-of-a-patch, which I find to be completely unreadable. and check the changes that will be represented in the source package. If your changes are applied to the git tree instead of being stored in debian/patches, this command will do the exact same thing (other than patch-of-a-patch changes). -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#769397: ITP: nfstrace -- NFS tracing/monitoring/capturing/analyzing tool
Package: wnpp Severity: wishlist Owner: Andrew Shadura andre...@debian.org * Package name: nfstrace Version : 0.3.0 Upstream Author : EPAM Systems (multiple authors) * URL : https://github.com/epam/nfstrace/ * License : GPL-2 Programming Lang: C++ Description : NFS tracing/monitoring/capturing/analyzing tool nfstrace captures live NFS traffic and performs filtering, statistical analysis, visualisation and more. It also provides an API for custom pluggable analysis modules. . nfstrace currently supports the following protocols: . - Ethernet - IPv4, IPv6 - UDP, TCP - NFSv3, NFSv4 -- 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/20141113111356.19800.96011.reportbug@localhost.localdomain
Re: Bad weather in testing?
On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. I think you meant dependency, a build-dependency would not achieve that. -- 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/caktje6gfhc09nqwwei45kropwafxbnm3kxg9h6jnqefws_n...@mail.gmail.com
Re: veto?
This one time, at band camp, Daniel Pocock said: It is very sad to see that contributors sometimes feel that the only option for them is to resign. Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? Would this be better than people leaving outright? I veto this idea. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: veto?
Hi, Stephen Gran: This one time, at band camp, Daniel Pocock said: Would it be worthwhile giving people another option, for example, allowing a percentage of DDs to formally veto decisions? I veto this idea. I agree. If you want to block a change, convince the rest of us that it's a bad idea (how to do that is left as an exercise for the esteemed reader; hint: diatribes about the change being The End Of Debian | Linux | Unix | Civilization aren't going to work), and/or vote Further Discussion. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: veto?
Hi, On Donnerstag, 13. November 2014, Matthias Urlichs wrote: I veto this idea. I agree. I don't. I veto the idea that this idea is dead, I think we should discuss it some more. cheers, Holger, who might have forgotten to indicate sarcasm... signature.asc Description: This is a digitally signed message part.
Re: Being part of a community and behaving
On Thu, 13 Nov 2014, Bálint Réczey wrote: I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html You lack any sense of humor, really! Although I am a strong opponent of systemd, I had to laugh out loud on that one, actually love it. Sad to see people like you that are complete bare of any acceptance for ironic, sarcastic humor. 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/20141113122331.gc22...@auth.logic.tuwien.ac.at
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Thursday, November 13, 2014 01:32:04 Sam Hartman wrote: Hi. I've read the original proposal and believe it is generally going in the right direction. things I liked: * didn't pick between dgit/git-dpm/git-pq; documented the common parts * Seemed to really focus on one clear scope. * Discouraged overlay packaging. I've tried to read the arguments, and I'm unconvinced that should be a recommended practice. I'd prefer to simply rule it out of scope: this proposal describes how to package debian and upstream sources together. It does not apply to other cases and does not forbid or recommend them. It doesn't apply to svn. It doesn't apply to overlay packaging. If the scope is narrower than Debian as a whole, then the title of the DEP needs to change. Maybe: Recommended layout for Git packaging repositories which also contain upstream sources 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/2509218.QQGvL7qbEk@scott-latitude-e6320
Re: Being part of a community and behaving
Hi Norbert, 2014-11-13 13:23 GMT+01:00 Norbert Preining prein...@logic.at: On Thu, 13 Nov 2014, Bálint Réczey wrote: I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html You lack any sense of humor, really! I clearly sensed the humor as I wrote in the part you cut. Although I am a strong opponent of systemd, I had to laugh out loud on that one, actually love it. Sad to see people like you that are complete bare of any acceptance for ironic, sarcastic humor. I love irony and sarcasm, but I don't think planet.debian.org is the right place for the mentioned content. 9gag for sure. Cheers, Balint -- 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/CAK0OdpxUtKLt-K6E_YOBZkwNGQPHClN=qzhhym19rqov+...@mail.gmail.com
Re: veto?
On 13/11/14 13:16, Holger Levsen wrote: Hi, On Donnerstag, 13. November 2014, Matthias Urlichs wrote: I veto this idea. I agree. I don't. I veto the idea that this idea is dead, I think we should discuss it some more. If veto is dead, what would the FTP masters do when somebody decides to upload something before checking it is 100% free? -- 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/5464ac26.5030...@pocock.pro
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 09:23:31PM +0900, Norbert Preining wrote: On Thu, 13 Nov 2014, Bálint Réczey wrote: I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html You lack any sense of humor, really! Although I am a strong opponent of systemd, I had to laugh out loud on that one, actually love it. Sad to see people like you that are complete bare of any acceptance for ironic, sarcastic humor. There are 2 parts of it. Its fun - but you can read between the lines. I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. Sometimes this lead to better approaches to see the light e.g. udev. This has changed - Debian has changed. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 02:19:41PM +0100, Florian Lohoff wrote: I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. Sometimes this lead to better approaches to see the light e.g. udev. This has changed - Debian has changed. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. Uhm, systemd was uploaded to debian first in 2010. Are you saying 4 years is too much of a rush? What would be your view of a reasonable schedule? Riku -- 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/20141113133432.ga20...@afflict.kos.to
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 02:19:41PM +0100, Florian Lohoff wrote: I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. It has been around for multiple years across various distributions. I don't think waiting is what you want? It is not by waiting things automatically improve? At least the -devel and -vote discussions seem low signal to noise. The more interesting stuff seems to happen in bugreports and separate discussions. Sometimes this lead to better approaches to see the light e.g. udev. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. It has been talked about for at least 12 months or so, no? Mostly curious about your view on above. -- Regards, Olav -- 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/20141113133630.ga5...@bkor.dhs.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote: [ I skip the more detailed discussions on naming conventions to concentrate on your higher level questions for now ] Agreed, if we solve the tricky problems, that part is mostly just yak shaving (and if we can't, it's probably mostly irrelevant ...) On Thu, 13 Nov 2014, Ron wrote: Sure, I understood those were your goals. What I haven't seen, and what I'm asking for, is an actual detailed rationale describing the actual detailed problem(s) that you think these goals will be a remedy for. Problem 1: the derivatives -- So I am a Kali Linux contributor. We use git repos to maintain all our packages and we use git-buildpackage. I guess the first question there is what were the arguments put forward for deciding to 'standardise' on gbp? If there wasn't one, maybe that's an argument you should have (and if there was, maybe it's one to revisit :) If you have a clearer idea now of the problems you are facing, it might make properly evaluating things that avoid those problems easier. Most of the Kali contributors are not long-term Debian contributors, I write documentation so that they can contribute to Kali (while basing our work on Debian). To make this manageable I opted to always use a workflow based on git-import-orig. Even when Debian has its own git repo, we start from the released source packages because that's the only level of uniformity that we can rely on. And it's a pity because if we could build on Debian's git repo, it also means that our work would be easier to merge for the Debian maintainer. That's not a totally terrible way to kick off a new repo when there isn't an existing one. I wrote git-debimport to build a history from just existing Debian source packages when that's all you have, and debsnap (in devscripts) originally got written for use with it to collect the whole set from snapshot when you didn't already have them. And you can fairly easily splice a repo created with it to a real upstream one to continue maintenance in a more sensible way from there. But it is a kind of terrible way to continue maintaining them if there is a repo. Unfortunately I think that if you make uniformity the overarching consideration here, you've basically doomed yourself to failure from the outset. Even if everyone did stick to the conventions already discussed (which in reality, they won't) there's still far too many degrees of (quite necessary) freedom to really approach a just follow these three easy steps kind of uniformity. And even if you got close to achieving that for the debian branches, the (again necessary) variability between upstream repos is going to be even greater. I think at some point you're going to have to rely on real human intelligence to be able to look at a repo and form their own understanding of its structure. Most really aren't all that complicated (however much they vary between each other), and in the worst case you can always actually ask the 'upstream' maintainer to explain anything that is unclear. That's going to get annoying really fast if someone new asks me really basic questions something like that every week. But if you do this right it's also something that in the worst case someone should only need to ever ask once, because they can document what they learned for the next person if there are no 'dedicated' maintainers for individual packages, and this is a needed thing. I don't think I've ever had to ask an upstream how does your repo work though. So you possibly could also handle this internally with a few knowledgeable mentors too. They could add the Kali repo as a remote (without fearing any conflict in terms of tags, branch names) and just merge or cherry-pick as appropriate. All that said, this part however is not a problem at all. If you've branched your repo off the 'upstream' one (so you share its history) then there's never going to be a conflict between branch names. You can have a Kali repo, cloned from a Debian repo, cloned from an upstream repo, and *all* of those repos could have their own separate and distinct branch called master, and still there would be no conflict. git is already going to namespace them so when you add the remotes the branch refs will be (for remotes named upstream, debian, kali): remotes/upstream/master remotes/debian/master remotes/kali/master What you name those branches if you check them out locally is totally up to you. The local names need to be unique, but you can: $ git checkout -t debian/master -b debian-master $ git checkout -t kali/master -b master And that will work just fine. Tag names aren't quite so forgiving. But realistically, even if you simply name your tags v$version in all of upstream, debian, and kali, then if you actually have conflicting names you were already in deep trouble anyway, because now you have a kali package with *exactly* the same version as
Re: veto?
Hi, Daniel Pocock: If veto is dead, what would the FTP masters do when somebody decides to upload something before checking it is 100% free? That's a different sort of veto. That's what they do, and they've got a mandate to do exactly that. The veto we're talking about here is more along the lines of * DD A has an idea * DD B…Y think it's OK * DD Z think it's complete bulls**t and states I veto this * therefore the idea is not adopted Ostensibly, this would encourage consensus because, well, we take into account not only the stated reasons for Z's veto but also all the other semi-rational stuff that comes with Being Human, and talk about it until we all arrive at a conclusion we all can live with. In reality, this will not work. One major reason for this is that the evolution of Being Human proceeds in _slightly_ longer timeframes than the emergence of e-mail and IRC communication. For confirmation, look at any flame war where people write things they would (hopefully) never say to the recipient's face. :-/ -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#769421: ITP: python-pygit2 -- bindings for libgit2
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-pygit2 Version : 0.21.4 Upstream Author : J. David Ibáñez jdavid@gmail.com * URL : https://github.com/libgit2/pygit2 * License : GPLv2-with-linking-exception Programming Lang: Python Description : bindings for libgit2 The Pygit2 module provides a set of Python bindings to the libgit2 shared library. libgit2 implements the core of Git. Pygit2 works with Python 2.7, 3.2, 3.3, 3.4 and pypy. -- 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/20141113142917.15900.81406.report...@buzig.gplhost.com
Bug#769427: ITP: python-pygit2 -- bindings for libgit2
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-pygit2 Version : 0.21.4 Upstream Author : J. David Ibanez jdavid@gmail.com * URL : https://github.com/libgit2/pygit2 * License : GPLv2-with-linking-exception Programming Lang: Python, C Description : bindings for libgit2 The Pygit2 module provides a set of Python bindings to the libgit2 shared library. libgit2 implements the core of Git. Pygit2 works with Python 2.7, 3.2, 3.3, 3.4 and pypy. This is a component needed by parts of the OpenStack Fuel CI. -- 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/20141113145059.16497.19060.report...@buzig.gplhost.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi, I think the only workflow that newcomers and NMUers should be required to learn is the one that involves quilt, they should not be expected to learn (e.g.) dgit in addition. [...] I certainly don't think people should be expected to learn dgit in addition to other tools. I am trying to get to the point where 1. they can learn dgit _instead_ of _all_ other tools[1] 2. no-one else needs to know that this is going on unless they decide to start using dgit too. I whole-heartedly agree - I still think quilt is obscure, and since I only maintain few packages with little upstream activity, I doubt I will ever learn it enough to stop reading the manpage each time I need it. On the other hand, git is already widely known in the open source and free software community. So being able to use dgit and nothing else, would significantly reduce the barrier of entry. Once there is a version that DMs can use, I'll give it a try :) Kind regards, Ralf -- 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/5464c6df.2090...@ralfj.de
Re: veto the veto?
On 13/11/14 15:25, Matthias Urlichs wrote: Hi, Daniel Pocock: If veto is dead, what would the FTP masters do when somebody decides to upload something before checking it is 100% free? That's a different sort of veto. That's what they do, and they've got a mandate to do exactly that. and they do a fine job of it too The veto we're talking about here is more along the lines of * DD A has an idea * DD B…Y think it's OK * DD Z think it's complete bulls**t and states I veto this * therefore the idea is not adopted Ostensibly, this would encourage consensus because, well, we take into account not only the stated reasons for Z's veto but also all the other semi-rational stuff that comes with Being Human, and talk about it until we all arrive at a conclusion we all can live with. In reality, this will not work. One major reason for this is that the evolution of Being Human proceeds in _slightly_ longer timeframes than the emergence of e-mail and IRC communication. For confirmation, look at any flame war where people write things they would (hopefully) never say to the recipient's face. :-/ That is a worst case scenario but there is no system of decision making that doesn't have edge cases However, I think people are missing the point. It is not just about people participating in the decision, it is about revealing the percentage of people willing to actually execute the action that is decided upon, do nothing, or execute some other action, such as resigning. Veto is probably the crudest term to use when looking at such a problem, even if it is not a perfect solution, it is relevant. If DD Z in your example is a volunteer he/she doesn't have to do anything if he doesn't like the decision anyway. Maybe he will even choose to resign or work on another part of Debian. Fine, that is what a voluntary organization is all about. The current GR process doesn't show how many people will end up in such situations. In fact, they are hidden from view unless you go looking through all the posts on debian-devel to see if they have shown their hand. If veto is a no go (if you'll excuse the pun), are there other ways that we can quantitatively and concisely let people reveal how they will or won't act in relation to a certain choice or decision? -- 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/5464cc5e.40...@pocock.pro
Switching to systemd - statistics Was: Being part of a community and behaving
On Thu, Nov 13, 2014 at 03:34:32PM +0200, Riku Voipio wrote: On Thu, Nov 13, 2014 at 02:19:41PM +0100, Florian Lohoff wrote: I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. Sometimes this lead to better approaches to see the light e.g. udev. This has changed - Debian has changed. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. Uhm, systemd was uploaded to debian first in 2010. Are you saying 4 years is too much of a rush? What would be your view of a reasonable schedule? Released to our users in mid 2013 without most of the controversal bloat we are talking about now. Installation with either You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] or with systemd can be installed alongside sysvinit and will not change the behaviour of the system out of the box. This is intentional. To test systemd, add: init=/bin/systemd How many users actually did this? https://qa.debian.org/popcon-graph.php?packages=systemd before 2014 and the begin of the debate - less than 1000 Less than 1000 while sysvinit beeing at 170k is 0.5%. Compare that to the exim4 vs. postfix debate - We have postfix at 30K constantly growing since 2007 and exim4 at 120K - thats 25% - And still we dont switch to postfix by default. I dont get it. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: veto?
On Wed, Nov 12, 2014 at 01:41:33PM +0100, Daniel Pocock wrote: On 12/11/14 13:12, zlatan wrote: Please no. We need less and not more layers of governance/'political' complexity in project. Lets stop acting like government and more like community. If a veto facility is created effectively, then it will deter people from complexity and force people back to looking for consensus If it is too easy to veto something though then I agree that would slow the project down You have a goverance problem. You think, I know, I'll fix it by introducing vetos!. Now you have two governance problems. Michael -- 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/20141113160749.gl4...@raptor.chemicalconnection.dyndns.org
Re: Being part of a community and behaving
Florian Lohoff f...@zz.de writes: I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. We waited two years, during which positions hardened, people got angrier and angrier, and there were increasing demands to force the issue. Serious question: how much longer were we realistically going to wait with zero sign of forward progress? What do you think we should have done instead? debian-devel was becoming the standing debian-canonical-is-evil vs. debian-systemd-sucks standing flamewar. (I think people are already forgetting the whole Canonical is evil flamewar that was happening at the same time, with the same degree of vitriol that is now being levelled at systemd.) Tons of influential, respected project members were requesting that the TC make some sort of decision. There was widespread relief at the time that we were just going to pick something and be done with it. That didn't happen, obviously. But don't lose sight of the fact that we were already in a really bad place. This has changed - Debian has changed. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. If you think waiting two years to make a decision is rushing matters, I'm not sure what your idea of moving slowly is. I think people have an idealistic notion here that consensus will always emerge eventually, and it's easy at this point in the process to sugar-coat the past and forget how bad it was. Please, make a concerted effort to put yourself into the mindset the project was in during the fall of 2013. It's always easy to see, in hindsight, the cost of the option that was taken; it's harder to see the cost of the option that was not taken. Personally, I strongly suspect that we could have waited until 2020 and there still wouldn't be any consensus. And that has its own risk. -- 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/87r3x7f4oa@hope.eyrie.org
Re: Being part of a community and behaving
On Thu, 13 Nov 2014, Bálint Réczey wrote: I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html You lack any sense of humor, really! Although I am a strong opponent of systemd, I had to laugh out loud on that one, actually love it. Sad to see people like you that are complete bare of any acceptance for ironic, sarcastic humor. Sometimes, a joke is just inappropriate, regardless how funny it may seem. Sometimes, a joke is better not made, regardless how funny it is. We have enough bad karma these days, no need to pour gasoline on the fires. I assume we're all adults after all. Thanks. :( -- 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/cd66e9d688918358da236a9354731d97.squir...@isengard.geekcommandos.com
Re: Being part of a community and behaving
On Thu, 2014-11-13 at 08:25 -0800, Russ Allbery wrote: Florian Lohoff f...@zz.de writes: I meanwhile see the systemd issue as a social problem within debian. There are design issues which are REALLY controversial. In the past Debian did good by delaying adoption of controversial technical issues e.g. devfs and waited in a conservative way until dust settled and there was roughly a consensus. We waited two years, during which positions hardened, people got angrier and angrier, and there were increasing demands to force the issue. Serious question: how much longer were we realistically going to wait with zero sign of forward progress? The Canonical license arguments was maybe the tipping weight that pushed Debian towards systemd, right. That didn't happen, obviously. But don't lose sight of the fact that we were already in a really bad place. This has changed - Debian has changed. It seems we need to rush in all interesting stuff without looking forward past some months - Today systemd might be THE solution to some peoples problems. Is it tomorrow? I doubt it. If you think waiting two years to make a decision is rushing matters, I'm not sure what your idea of moving slowly is. Isn't it so that systemd has changed a lot since the decision was made in February this year, and the rate of changes will not stop. In the meanwhile no stable API is defined and more and more functionality is integrated in the systemd software, effectively shutting off alternatives. When CoreOS is fully developed, there will a diminishing market for other distributions. Let's hope that Debian at least don't completely rules out (abandons) alternate init systems. When things are seen in a perspective, a few years from now, this might have saved Debian from disappearing (and even obtain new desktop and server users coming from the not-happy-with-systemd people). -- 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/1415897759.11764.44.ca...@g3620.my.own.domain
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 08:25:57AM -0800, Russ Allbery wrote: What do you think we should have done instead? debian-devel was becoming the standing debian-canonical-is-evil vs. debian-systemd-sucks standing flamewar. (I think people are already forgetting the whole Canonical is evil flamewar that was happening at the same time, with the same degree of vitriol that is now being levelled at systemd.) That doesn't match my perception of the history; but part of this may have been that the vitriol level escalated significantly once the TC announced they were going involve itself in the debate, and it doesn't look like it has gotten any better ever since. That being said, I am sure that the TC got involved with the best intentions, and most of the DD's involved in the discussions were all united in their passion for wanting the best for Debian (even if they agreed on very little else, at least on the systemd mail threads :-). If only everyone could really internalize this belief; I think it would make these discussions much less painful. I think people have an idealistic notion here that consensus will always emerge eventually, and it's easy at this point in the process to sugar-coat the past and forget how bad it was. Please, make a concerted effort to put yourself into the mindset the project was in during the fall of 2013. It's always easy to see, in hindsight, the cost of the option that was taken; it's harder to see the cost of the option that was not taken. Personally, I strongly suspect that we could have waited until 2020 and there still wouldn't be any consensus. And that has its own risk. I have a different belief about the future, but (a) there was no way to know whether things would have gotten worse back in Fall 2013, and (b) there's no way any of us can know for sure what the future will bring, or what would have happened if we had taken an alternate path. All we can do is to go forward, as best as we can. Because regardless of how this GR is settled, it doesn't really answer the question about the use of all of the other pieces of systemd; or at least, I don't think that any of the options are the equivalent of a blank check adoption of systemd-*, whether it be systemd-networkd, systemd-resolved, systemd-consoled, etc. And it sure would be nice if we don't have the same amount of pain as each of these components get proposed. (My personal hope is that if they are optional, as opposed made mandatory because GNOME, network-manager, upower, etc. stops working if you don't use the latest systemd-*, it won't be that bad going forward.) Regards, - Ted -- 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/20141113171127.ga26...@thunk.org
Re: Being part of a community and behaving
On 13/11/14 18:11, Theodore Ts'o wrote: And it sure would be nice if we don't have the same amount of pain as each of these components get proposed. (My personal hope is that if they are optional, as opposed made mandatory because GNOME, network-manager, upower, etc. stops working if you don't use the latest systemd-*, it won't be that bad going forward.) The last one that I read is that udev is going to stop working on non-systemd systems: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html signature.asc Description: OpenPGP digital signature
Re: Switching to systemd - statistics Was: Being part of a community and behaving
How many users actually did this? I did! And aster not getting in serious trouble with it, I completely changed to it. https://qa.debian.org/popcon-graph.php?packag aes=systemd before 2014 and the begin of the debate - less than 1000 Less than 1000 while sysvinit beeing at 170k is 0.5%. Compare that to the exim4 vs. postfix debate - We have postfix at 30K constantly growing since 2007 and exim4 at 120K - thats 25% - And still we dont switch to postfix by default. Yes, and this is the real freedom: choose whaterver software you want and take all by default installed sopftware as a suggestion. Populary-contest might change it from release to release, but you can use any software you personally prefer. How cool is that? I dont get it. Me, too. Sigh. Flo Hans signature.asc Description: This is a digitally signed message part.
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 13, Raphael Hertzog hert...@debian.org wrote: I am part of the Python Modules team who wants to switch to git but not all contributors are using the same git helper tools and yet we would like to all work together on the same repositories without forcing everybody to use the same helper tool (habits are hard to change). I do not understand this focus on helper tools: most of my packages have a debian/gbp.conf file, but I never use gbp except sometimes for importing a new upstream release and everything still works fine. I just build my packages with debuild as usual. -- ciao, Marco pgp7AthHJH1tI.pgp Description: PGP signature
Re: Being part of a community and behaving
Hi, Isn't it so that systemd has changed a lot since the decision was made in February this year, and the rate of changes will not stop. In the meanwhile no stable API is defined http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ and more and more functionality is integrated in the systemd software, effectively shutting off alternatives. How does having yet another NTP client shut off existing NTP clients? How does having yet another way to configure your network shut off existing alternatives? Even syslog is still working! And so are cron and lxc. When CoreOS is fully developed, there will a diminishing market for other distributions. You seem to think that CoreOS will be so great that all users rush to change there. That Debian would be unable to compete. I do not know what you base this belief on, but I certainly think that Debian will continue to stay relevant when yet another distribution emerges. Kind regards Ralf -- 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/5464f146.6000...@ralfj.de
Re: Being part of a community and behaving
Theodore Ts'o ty...@mit.edu writes: That doesn't match my perception of the history; but part of this may have been that the vitriol level escalated significantly once the TC announced they were going involve itself in the debate, Yes, we have very different recollections. My recollection is that the vitriol level actually dropped quite a bit when the TC first started getting involved, rose (but largely on the TC list) during the argument, and fell considerably after the decision. Then started to rise again, and now is worse than it was originally. That being said, I am sure that the TC got involved with the best intentions, and most of the DD's involved in the discussions were all united in their passion for wanting the best for Debian (even if they agreed on very little else, at least on the systemd mail threads :-). If only everyone could really internalize this belief; I think it would make these discussions much less painful. +1. I have a different belief about the future, but (a) there was no way to know whether things would have gotten worse back in Fall 2013, and (b) there's no way any of us can know for sure what the future will bring, or what would have happened if we had taken an alternate path. All we can do is to go forward, as best as we can. In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? Several people commenting here seem to still be stuck on trying to find some solution that will make everyone happy. Maybe someone will find some breakthrough, but I have to say that, over the past three years, we've cut this problem from every different direction and failed to find this. Some of the attempted compromises have actually made the problem worse. I am highly dubious that some consensus position is going to emerge. Because regardless of how this GR is settled, it doesn't really answer the question about the use of all of the other pieces of systemd; or at least, I don't think that any of the options are the equivalent of a blank check adoption of systemd-*, whether it be systemd-networkd, systemd-resolved, systemd-consoled, etc. Certainly not. Why would we ever say we were going to adopt all upstream work without even looking at it? We don't do that in any other area of the distribution. But one thing that's making this discussion hard is the assumption that people who *did* take a deep look at a particular component and decided to use it knowing its advantages and weaknesses somehow were tricked or fooled by a marketing campaign into doing so and didn't know what they were doing. I find this insulting, and I suspect some of our upstreams also find this insulting. Many of the systemd components that you're talking about are, as I understand it, emerging from work on building lightweight containers, where it's nice to have an easy-to-deploy minimal stack that can bootstrap out of nothing, providing just enough support to spawn a process in a stripped-down, minimal container environment that doesn't need first-class OS services. That may or may not be the right approach for containers; I have no strong opinion, having not delved deeply into that space. It's surely quite a stretch to think that we would adopt components written for that environment as components on which to build a full-featured OS installation unless they expand beyond that role and offer clear advantages and compelling benefits over other components. Maybe they will, maybe they won't. And it sure would be nice if we don't have the same amount of pain as each of these components get proposed. Indeed. Which is, among other things, going to require taking people's arguments at face value and extending the assumption of good will that people proposing technical solutions are doing so because they thought about the problem and thought the solution was superior, not because of a marketing campaign. -- 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/87bnobf04v@hope.eyrie.org
ITP? Sponsors of eudev, consolekit2, uselessd?
Hi, I'm currently looking into packaging eudev, consolekit2, uselessd for Debian. If doing so, is anybody interested in sponsoring uploads of these packages? It would be great to know, before digging into the details. If you wish, please reply to me privately. Thanks! -- 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/1415902621.11764.51.ca...@g3620.my.own.domain
Bug#769453: ITP: python-xmlbuilder -- create xml/(x)html files
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-xmlbuilder Version : 1.0 Upstream Author : Kostiantyn Danylov aka koder koder.m...@gmail.com * URL : https://pypi.python.org/pypi/xmlbuilder * License : LGPL-3 Programming Lang: Python Description : create xml/(x)html files XMLBuilder is tiny library build on top of ElementTree.TreeBuilder to make xml files creation more pythonomic. XMLBuilder use with statement and attribute access to define xml document structure. -- 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/20141113183403.22716.46887.report...@buzig.gplhost.com
Re: veto?
On 11/13/2014 05:03 AM, Daniel Pocock wrote: On 13/11/14 13:16, Holger Levsen wrote: Hi, On Donnerstag, 13. November 2014, Matthias Urlichs wrote: I veto this idea. I agree. I don't. I veto the idea that this idea is dead, I think we should discuss it some more. If veto is dead, what would the FTP masters do when somebody decides to upload something before checking it is 100% free? Veto != policy. -- 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/5464fb3b.7020...@alvarezp.ods.org
Re: ITP? Sponsors of eudev, consolekit2, uselessd?
Am 13.11.2014 um 19:17 schrieb Svante Signell: Hi, Hi, I'm currently looking into packaging eudev, consolekit2, uselessd for Debian. If doing so, is anybody interested in sponsoring uploads of these packages? It would be great to know, before digging into the details. If you wish, please reply to me privately. the correct list for such requests is debian-ment...@lists.debian.org, much fun and luck! -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.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/5464fa56.80...@debian.org
Bug#769455: ITP: ckeditor3 -- WYSIWYG HTML Editor
Package: wnpp Severity: wishlist Owner: Mathieu Parent sath...@debian.org Package name: ckeditor3 Version : 3.6.x Upstream Author : Frederico Knabben URL : http://ckeditor.com/ License : GPL2+ Programming Lang: JS Description : WYSIWYG HTML Editor Unfortunately, CKeditor 4 doesn't work with Horde's IMP (#769031). THis packages will have version3. WIP at: http://anonscm.debian.org/cgit/pkg-horde/PEAR/ckeditor3.git 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/20141113190811.25190.22932.report...@ultrathieu.sathieu.net
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Raphael Hertzog hert...@debian.org [14 22:26]: 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/`). Is using the vendor you use git on a good default for the vendor code you are currently working on? In my experience those two are quite unrelated. 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 (`_`). Is there a previous case of encoding colons with percent signs? If it is inventing a third way instead of using on of the existing ones, is sounds like a bad idea. Packaging branches and tags === 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 think this should alternatively allow for Vcs pointing to that branch instead. It sometimes makes sense to put the debian package development branches in the same repository as the upstream branch, where HEAD might be reserved for the upstream branch. When releasing a Debian package, the packager should create and push a signed tag named `vendor/version`. I'd advocate s/signed/(possibly signed)/, as I'm not ready to sign such a wildcard with any valuable key and getting another very-low-security key just to have signed keys to match this proposal sounds like waste. Tags are only based on versions are also quite hard to shuffle around. I'd strongly suggest adding the name of the source package to those, otherwise accessing multiple packages in on repository causes a big mess. (git keeps branches in the per-origin remote namespace when fetching stuff, tags only have one global namespace, local and remote). 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 stable 1.2 branch and releases 1.2.x minor releases in that branch, those releases should be imported in a `upstream/1.2.x` branch (the .x suffix makes it clear that we are referring to a branch and not to the tag corresponding the upsteam 1.2 release). If the upstream developers use codenames to refer to their releases, the upstream branches can be named according to those codenames. Helper tools should detect when the upstream version imported is lower than the latest version available in `upstream/latest` and should offer either to create a new branch (based on the highest version available in the history that is still smaller than the imported version) or to pick another pre-existing upstream branch. I'm very sceptical about this part. I'm not sure it is worth standardizing and it seems quite a lot of work to implement something like that (which I expect I'll have to override more often than not if using such an helper). Importing upstream releases from Git tags - When the packaging branches are directly based on the upstream Git branches, upstream usually also provide proper Git tags that can be reused for official releases. If helper tools have to identify the upstream commit corresponding to a given upstream release, they should be able to find it out by looking up the following Git tags: `upstream/version`, `version` and `vversion`. The `upstream/version` tag would be created by the package maintainer when needed: for example when it does a release based on a Git snapshot or when the tag naming scheme used by upstream is not following the above rules. That lacks possibility three: importing tar content on top of upstream branches. And again adding the source package name in there would be nice. Native packages === The above conventions mainly cater to the case of non-native packages, that is when the upstream developers and the package maintainers are not the same set of persons. When upstream is Debian (or one of its derivative), the upstream vendor
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote: In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? What ever happened to letting the system evolve naturally? Rather than force change on the users, let the quality and utility of the software the user *wants* to run manage the timetable to change the foundational elements of the system. This sounds great on the surface, but the general principle is hard to apply to the current situation for a couple of reasons. First, several of our upstreams have, from their perspective, already gone through this natural evolution process and have landed on a new set of software, which they are now requiring as a prerequisite. This is, in one sense, a normal thing for upstreams to do. It happens all the time with new shared libraries or new ABIs of existing shared libraries. However, this time, it's rather unusual, since it's unusually hard (although not completely impossible) to provide both the old and new mechanisms at the same time. It's not unheard of, though; we have retired old stacks before even though some users wanted to use them because they weren't supported upstream. I'm remembering the last GNOME and KDE major release transitions, for instance. (And, in the GNOME case, a team stepped up to maintain a fork, and as a result the previous version is being reintroduced in the archive under a different name.) Again, you can have many different opinions about these decisions, and I know people do, but the fact remains that the people who are making those decisions are independent citizens of the free software community with the right to make their own decisions. We don't get to tell them what to do; it would be extremely rude of us to do so, not to mention completely ineffective as we are not their bosses or owners. The alternative is what it always is in free software: if you don't like a project direction and can't convince the current maintainers that you're right, you either have to put up enough resources to maintain a fork or live with it. Second, our users are just as split as the developers are. Some users have already gone through the process you describe and are eager for the new software. Others are pretty leery or even actively opposed. If we can maintain both in parallel, this is not a problem, but it seems like everyone is dubious about the project's ability to maintain both, so one side is arguing for investing our time into supporting sysvinit rather than systemd, and the other side is arguing for investing our time into supporting systemd instead of sysvinit, both making essentially zero-sum tradeoff assumptions. The question of whether we can support both as first-class citizens is exactly one of the points of severe and apparently irreconcilable disagreement. In particular, one group feels like we should effectively force support for sysvinit as a prerequisite for having one's package included in Debian or remaining in Debian, even for packages where both upstream and Debian maintainer have already gone through the process you describe and are ready to move on to something else, and without a clear picture of who is going to be doing that work. And another group is uninterested in continuing to support sysvinit beyond the jessie release, because they don't believe the effort is warranted, are not interested in doing the work, and are dubious that the resources to do so will materialize. Change from the status quo should be done when there is a compelling reason to do so - and then with great care and consideration of the consequences. And there are lots of people in Debian who have gone through this thought process and who believe that they are doing exactly this. And there are lots of other people who disagree. So, again, we return to the governance question. We're at loggerheads no matter how you cut it, including the way that you're trying to cut it. Do we wait for unanimity? Is that the right default decision? Unanimity in a project of 1,000 people is a long time. If we waited for unanimity, we'd still be shipping KDE 3. Would that have been the right decision? -- 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/87wq6yeweo@hope.eyrie.org
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote: In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? What ever happened to letting the system evolve naturally? Rather than force change on the users, let the quality and utility of the software the user *wants* to run manage the timetable to change the foundational elements of the system. Change from the status quo should be done when there is a compelling reason to do so - and then with great care and consideration of the consequences. Yes, this approach leads to painfully slow transitions sometimes. If you are really concerned about the speed of change implementation, you probably shouldn't be working on an open-source collaborative project founded on the bazaar model. Pat -- 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/20141113185852.gc16...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 01:58:23PM +0100, Bálint Réczey wrote: acceptance for ironic, sarcastic humor. I love irony and sarcasm, but I don't think planet.debian.org is the right place for the mentioned content. I'm afraid you misunderstand the purpose of planet Debian. If you want an aggregator with more rules about content, please set one up. -- 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/20141113200927.ga3...@chew.redmars.org
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). The current systemd / GR issue would not be happening if the project had not said the default init system shall be init system. Had the project said we have the following init systems available: list of init systems and let the other package dependencies drive the user's selection then users would fell there was a little more choice in the matter. Right now, GNOME seems to be the primary driver for requiring systemd. If you don't use a graphical environment, you don't need systemd but you are forced to at least install it on a new build. Various people were discussing the installer experience elsewhere, and whether enough users care about this to warrant making a sysvinit install an option directly in the installer. I don't think this is any sort of fudamental decision we've already made; it's a debate over UI experiences. In other words, I don't think this is anywhere near as central to the argument as you seem to think. If I'm wrong, that's great news -- if all of this argument could go away by just tweaking the installer UI, that would be fantastic. But I'm dubious. If there are two opposing sides, then there are two maintainers willing to maintain the packages. If there are not, the package without a maintainer looses by default. Ah, see, I also believe this, which is exactly why I'm so upset about the current GR. The proposed GR (the first option) is exactly about overriding the normal practice that the package without a maintainer loses by default, and about *forcing* the people who aren't using sysvinit to work on maintaining it. This is one of the fundamental divisions in the project right now. Of course, proponents of it probably even disagrees with my characterization of it, because we're *also* fundamentally disagreeing over even what the proposed GR actually does. It really is deep disagreements all the way down. I don't recall Debian every saying we will support package package forever and ever. Exactly, and that's why some of us are aghast at a GR that basically says that about sysvinit, except cast in terms to try to make it seem like that's not what it actually says. Waiting implies lack of movement - this is not what I was saying. I say allow the natural evolution to play out. GNOME wants to require systemd and someone packages systemd - great - allow it AS AN OPTION, NOT A REQUIREMENT for all. Similarly with sysvinit - it has maintainers, allow it as an option. This means that you and I are basically in agreement, and I suspect you'll find that you're basically in agreement with most of the people on the systemd side. That's pretty much the position that I've been arguing, and the position that I believe the current GR is trying to reverse by forcing GNOME, and every other package in Debian, to support sysvinit. The only remaining thing about which we may disagree is that I think the installer needs to pick *something* that gets installed by default, and that the average user isn't going to care or know enough to pick something. (I would like to see the inability to select sysvinit via such install methods as debootstrap fixed before the release; I think that's just a bug.) The issue we should be tackling is not which init system to force on the users, but the higher level what is the minimum functionality and API a Debian init system MUST provide to allow it to declare Provides: init-system in its control file. That sounds like a great discussion to have, from my perspective, and the discussion that I was hoping we could have following the TC (and that I was then unable to try to drive due to a lot of non-Debian life stuff on my part). But I don't think that's the discussion that the GR is having, or that most of the systemd arguments are focused on. -- 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/87lhneeq53@hope.eyrie.org
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:24:31AM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote: In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? What ever happened to letting the system evolve naturally? Rather than force change on the users, let the quality and utility of the software the user *wants* to run manage the timetable to change the foundational elements of the system. This sounds great on the surface, but the general principle is hard to apply to the current situation for a couple of reasons. First, several of our upstreams have, from their perspective, already gone through this natural evolution process and have landed on a new set of software, which they are now requiring as a prerequisite. This is, in one sense, a normal thing for upstreams to do. It happens all the time with new shared libraries or new ABIs of existing shared libraries. However, this time, it's rather unusual, since it's unusually hard (although not completely impossible) to provide both the old and new mechanisms at the same time. It's not unheard of, though; we have retired old stacks before even though some users wanted to use them because they weren't supported upstream. I'm remembering the last GNOME and KDE major release transitions, for instance. (And, in the GNOME case, a team stepped up to maintain a fork, and as a result the previous version is being reintroduced in the archive under a different name.) Again, you can have many different opinions about these decisions, and I know people do, but the fact remains that the people who are making those decisions are independent citizens of the free software community with the right to make their own decisions. We don't get to tell them what to do; it would be extremely rude of us to do so, not to mention completely ineffective as we are not their bosses or owners. The alternative is what it always is in free software: if you don't like a project direction and can't convince the current maintainers that you're right, you either have to put up enough resources to maintain a fork or live with it. We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. The current systemd / GR issue would not be happening if the project had not said the default init system shall be init system. Had the project said we have the following init systems available: list of init systems and let the other package dependencies drive the user's selection then users would fell there was a little more choice in the matter. Right now, GNOME seems to be the primary driver for requiring systemd. If you don't use a graphical environment, you don't need systemd but you are forced to at least install it on a new build. Second, our users are just as split as the developers are. Some users have already gone through the process you describe and are eager for the new software. Others are pretty leery or even actively opposed. If we can maintain both in parallel, this is not a problem, but it seems like everyone is dubious about the project's ability to maintain both, so one side is arguing for investing our time into supporting sysvinit rather than systemd, and the other side is arguing for investing our time into supporting systemd instead of sysvinit, both making essentially zero-sum tradeoff assumptions. If there are two opposing sides, then there are two maintainers willing to maintain the packages. If there are not, the package without a maintainer looses by default. I don't recall Debian every saying we will support package package forever and ever. So, again, we return to the governance question. We're at loggerheads no matter how you cut it, including the way that you're trying to cut it. Do we wait for unanimity? Is that the right default decision? Waiting implies lack of movement - this is not what I was saying. I say allow the natural evolution to play out. GNOME wants to require systemd and someone packages systemd - great - allow it AS AN OPTION, NOT A REQUIREMENT for all. Similarly with sysvinit - it has maintainers, allow it as an option. The issue we should be tackling is not which init system to force on the users, but the higher level what is the minimum functionality and API a Debian init system MUST provide to allow it to declare Provides: init-system in its control file. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 01:39:52PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). By making it the new default, and causing apt-get dist-upgrade to install systemd (which is what happened to one of my systems) in place of sysvinit we most certainly are. Did the system implode in a fiery pool - no, but I was forced to deal with the unexpected aftermath. There was some breakage, and some things did not work as expected. (Sure, people would say I shouldn't be following unstable or SID but then I wouldn't have development environments.) By not having a meta-package init-system provided by an actual package, we are forcing anyone who upgrades to also change init systems unless they take special precautions to not do so. For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. Pat -- 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/20141113215610.gg16...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, 2014-11-13 at 13:39 -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). See #765803. That bug report is about making the user aware of/alerted to an init switch when upgrading, nothing else. And that issue has not yet been resolved by the ctte, due to the GR. Hopefully when the GR result is published, the ctte can decide on this. (assuming the outcome is a non-gr issue? what happens if not?) Ah, see, I also believe this, which is exactly why I'm so upset about the current GR. The proposed GR (the first option) is exactly about overriding the normal practice that the package without a maintainer loses by default, and about *forcing* the people who aren't using sysvinit to work on maintaining it. This is one of the fundamental divisions in the project right now. Maybe I'm misunderstanding, but my interpretation is _not_ the above? 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/1415916206.11764.71.ca...@g3620.my.own.domain
Re: Being part of a community and behaving
2014-11-13 22:56 GMT+01:00 Patrick Ouellette poue...@debian.org: On Thu, Nov 13, 2014 at 01:39:52PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). By making it the new default, and causing apt-get dist-upgrade to install systemd (which is what happened to one of my systems) in place of sysvinit we most certainly are. Did the system implode in a fiery pool - no, but I was forced to deal with the unexpected aftermath. There was some breakage, and some things did not work as expected. (Sure, people would say I shouldn't be following unstable or SID but then I wouldn't have development environments.) When upgrading your OS, you should *always* expect that you might have to learn things - systemd is just one detail, but a lot of other applications have changes too which force people to re-learn things they took for granted before. So nothing new here... By not having a meta-package init-system provided by an actual package, we are forcing anyone who upgrades to also change init systems unless they take special precautions to not do so. Previously on Debian, you didn't have any choice in init-systems: Sysvinit was the only option. Now, we provide a init metapackage, which ensures an init system is installed. We make systemd default here and switch older installations over to it currently. If you want to stick with a different initsystem, you have the *choice* to choose any other one the init package depends on, and even pre-select it on upgrade. This should pretty much make everyone happy, those who care about which PID1 they are running, and those who don't. For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. Rsyslog is srill installed by default (and I guess that won't change soon), so you now have even better textlogs. The binary logs are great for quick searching (just run systemctl status on a service) and provide some extra benefits for working with logs (I, for example, love the ability to group entries by priority), but that's not something someone is forced to work with. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- 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/CAKNHny9B14=d9djbcoxn6a_8ex-a06g0hspgsct9zmprgxe...@mail.gmail.com
Re: Being part of a community and behaving
On 14 November 2014 04:20, Carlos Alberto Lopez Perez clo...@igalia.com wrote: The last one that I read is that udev is going to stop working on non-systemd systems: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html I don't read anything in that post that says this. Am guessing you a referring to the Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far quote. Which would suggest that udev might stop supporting the userspace-to-userspace netlink-based transport in the future. However, unless I am mistaken, I don't think this means it will no longer work on non-systemd systems. -- Brian May br...@microcomaustralia.com.au
Re: Bad weather in testing?
Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. I think you meant dependency, a build-dependency would not achieve that. Ha damn, i never got this right, then what's the correct approach for solving https://bugs.debian.org/725363 ? Jérémy. -- 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/1415917157.25276.7.ca...@melix.org
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. Rsyslog is srill installed by default (and I guess that won't change soon), so you now have even better textlogs. The binary logs are great for quick searching (just run systemctl status on a service) and provide some extra benefits for working with logs (I, for example, love the ability to group entries by priority), but that's not something someone is forced to work with. Matthias, I did not ask for evangelization about how wonderful binary logs are, nor for a lesson on how to get the info out of systemd with the systemctl command. I am glad you like them and they work for you. For me they add another level of obfuscation, a speed bump and a potential point of failure. All of which are unnecessary. Cat logfile, more logfile less logfile, grep term logfile -- all worked well and continue to do so for my text file logs. Awk, emacs, vi, all work on them too. My log management tools all expect my old plain text formatted logs. If we can agree to disagree on this all is well. If you feel it necessary to convert me or help me see the light then, well, we're going to have a problem ;-) Pat -- 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/20141113222533.gi16...@flying-gecko.net
Re: Being part of a community and behaving
Tobias Frost dijo [Thu, Nov 13, 2014 at 05:22:18PM +0100]: I have just noticed your blog post on planet.debian.org: https://np237.livejournal.com/34598.html You lack any sense of humor, really! Sometimes, a joke is just inappropriate, regardless how funny it may seem. Sometimes, a joke is better not made, regardless how funny it is. We have enough bad karma these days, no need to pour gasoline on the fires. I assume we're all adults after all. Thanks. Thanks, Tobias. And thanks, Bálint. I agree with you. Humor in Debian is most often funny and welcome. But this specific topic has gone so bitter that any bit of attempted humor can be read as a personal attack. Joss, I don't think you meant ill by posting this message, but it could not have had any possitive replies anyway! -- 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/20141113222818.gj91...@gwolf.org
Re: Being part of a community and behaving
On Fri, 2014-11-14 at 09:16 +1100, Brian May wrote: On 14 November 2014 04:20, Carlos Alberto Lopez Perez clo...@igalia.com wrote: Which would suggest that udev might stop supporting the userspace-to-userspace netlink-based transport in the future. However, unless I am mistaken, I don't think this means it will no longer work on non-systemd systems. From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? Things evolve with time -- 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/1415917825.11764.74.ca...@g3620.my.own.domain
Re: Being part of a community and behaving
Hi Pat, On Thu, Nov 13, 2014 at 4:25 PM, Patrick Ouellette poue...@debian.org wrote: On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. That's a loaded statement. Rsyslog is srill installed by default (and I guess that won't change soon), so you now have even better textlogs. I did not ask for evangelization about how wonderful binary logs are, nor for a lesson on how to get the info out of systemd with the systemctl command. You shouldn't be surprised that there is dialogue surrounding it. -m -- 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/CAOLfK3XTG3ZT-AQHaem+kbsS7OueuCiSwgYZoYt+T=2qpgdB=g...@mail.gmail.com
Re: Being part of a community and behaving
On 14 November 2014 09:30, Svante Signell svante.sign...@gmail.com wrote: From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? Assuming that report is accurate, to me it sounds like a bug that should get fixed, as opposed to a clear indication that udevd is going to stop supporting non-systemd systems. -- Brian May br...@microcomaustralia.com.au
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, Nov 11, 2014 at 10:51 PM, Henrique de Moraes Holschuh h...@debian.org wrote: 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. [...] 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. Not much to add here. +1 Richard -- 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/CAD77+gSVO8=lospehnra+0jn5287eb166rb3+iclpu7tmym...@mail.gmail.com
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 4:04 AM, Marco d'Itri m...@linux.it wrote: Whatever the decision will be on debian/master, I think that master should be at the very least an option. I.e. a debian-only repo? That's what pabs also seems to prefer so it probably makes sense to support/allow both. FWIW, I strongly disagree with putting any packaging into master as this makes upstreaming different packaging branches a tad harder, but each to their own. Richard -- 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/cad77+grzh1dvh1sebb3ppnp0pcn6hsh3h_aojqxyvwcjjny...@mail.gmail.com
Re: Being part of a community and behaving
On Fri, 2014-11-14 at 09:46 +1100, Brian May wrote: On 14 November 2014 09:30, Svante Signell svante.sign...@gmail.com wrote: From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? Assuming that report is accurate, to me it sounds like a bug that should get fixed, as opposed to a clear indication that udevd is going to stop supporting non-systemd systems. The problem is that udevd is part of systemd, i.e. non-systemd systems are not actively supported (and will not be in due time, I wonder when?). -- 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/1415919265.11764.78.ca...@g3620.my.own.domain
Re: Bad weather in testing?
On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote: Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. I think you meant dependency, a build-dependency would not achieve that. Ha damn, i never got this right, then what's the correct approach for solving https://bugs.debian.org/725363 ? That appears to be an arch:any package not an arch:all one so your current Build-Depends/Depends workaround is correct. Checking the packages with debbindiff --html, I see that the .debs are identical between architectures, except for the architecture name and the timestamps, so it should be arch:all instead. The rest of this post is about arch:all node-* packages only... The correct approach would be to fix the portability issues in nodejs but looking at the buildd page I see this is mostly caused by libv8 and I guess Google doesn't care much about browser portability so this is unlikely to get fixed. An easy workaround if that isn't possible is to make every node-* package arch any and Build-Depend on nodejs, this is what happened this with node-xmlhttprequest but personally I would not recommend it. A more socially responsible workaround would be to patch dak/reprepro/etc so that some arch:all packages are not present in the Packages files on some architectures. This could be a hard problem, especially when you consider that all node-* arch:all packages should become available on platforms where nodejs is newly ported to (for example ppc64el is probably going to be a popular cloud platform at some point). Another fix to dak/dpkg we need in this is something like linux-all, for example iotop is written in Python but only supports the I/O monitoring interfaces of the Linux kernel, so the architecture restriction cannot be expressed by Depends. Personally I would just use arch:all for node-* packages, drop the Build-Depends: nodejs (since it is false AFAIK), keep the Depends: nodejs and otherwise ignore the issue, it doesn't cause much of a problem IMO. -- 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/caktje6edztf-c9qxpf6cswd4gyvqfajwfxr_f1gqo6beuov...@mail.gmail.com
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:30:25PM +0100, Svante Signell wrote: From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? This is #767363 aka #754987 aka ~1e38 others. For now, you can sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces although there's a patch by Ben Hutchings that's said to work. All praise Ben! -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20141113230716.ga22...@angband.pl
Re: Being part of a community and behaving
On Fri, 2014-11-14 at 09:16 +1100, Brian May wrote: On 14 November 2014 04:20, Carlos Alberto Lopez Perez clo...@igalia.com wrote: The last one that I read is that udev is going to stop working on non-systemd systems: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html I don't read anything in that post that says this. Am guessing you a referring to the Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far quote. Which would suggest that udev might stop supporting the userspace-to-userspace netlink-based transport in the future. However, unless I am mistaken, I don't think this means it will no longer work on non-systemd systems. They will need something else to configure kdbus, though. I don't even know how initramfs-tools will continue working after that point. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
debian installer, install listofpackages.txt in CD root dir after end install?
It would be very cool if the debian installer had a listofpackages.txt and that listofpackages.txt could be edited by the user then we would be getting customized debian installs some people would edit and tell it to auto install: - zsh - lilo instead of grub - lukssetup (crypt thing) - ext3 instead of ext4 - Xfree86 instead of Xorg - systemX instead of systemY etc. :-) would be very cool if this was possible it is hard to do everyone right in the installer so most people will have to install afterwards but not if this was possible they could make their own perfect debian install cd would be a sysadm's dream.. also the geeks dream of course there is debootstrap too, but it would be cool if the debian installer could be made like this too just dragdrop a list of installpackages.txt into base of debian install CD then the CD finds that list and replaces grub with lilo in end of install if needed and sysX with sysY if specificed in list would be the ultimate customization, we would get wikis filled with packagelists for custom debian cds the biggest problem is we would get nonsupported debian dists, could be a big problem people claiming they use official debian, but then own packages in installer still think it would be very cool... debootstrap can provide this, but debian installer can't do this easily only if you are a debian programmer do you know how to do it probably... until then I prefer to use debootstrap, I don't like to use the installer because it forces me to use certain packages i.e. it installs grub and newest kernel for me, which I might not want or it installs sysX instead of SysY I know I am picky... and lazy I do really like the ssh connection to the installer though this is just a last suggestion, would make perfect debian installers if this was possible override all packages after end install if custompackages.txt exists in CD directory of if it exists on a usbstick on the pc that gets automounted unlimited configuration possibilities! I could tell it to install an old kernel, a custom compiled kernel etc. I often use custom kernels... would have to install those manually after installing as it is now many sysadms use custom kernels they have compiled for debian themselves as it is now they have to debootstrap or install normal debian dist then copy it over afterwards with this im suggesting they could make their own debian installer with their custom kernel on custom bootloader etc. custom kernel is ALSO just a simple .deb package to install! lilo bootloader is too so that listofpackages.txt should just contain .deb filenames to install after end of installation! would be very unique to the debian installer if this was possible all people would stop complaining, almost ;) we would be getting : debian-simplified debian-for-sysadms debian-for-geeks debian-for-lilousers debian-for-sysV-users and many more custom installers (custompackage lists in wikis) On Thu, 13 Nov 2014, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). The current systemd / GR issue would not be happening if the project had not said the default init system shall be init system. Had the project said we have the following init systems available: list of init systems and let the other package dependencies drive the user's selection then users would fell there was a little more choice in the matter. Right now, GNOME seems to be the primary driver for requiring systemd. If you don't use a graphical environment, you don't need systemd but you are forced to at least install it on a new build. Various people were discussing the installer experience elsewhere, and whether enough users care about this to warrant making a sysvinit install an option directly in the installer. I don't think this is any sort of fudamental decision we've already made; it's a debate over UI experiences. In other words, I don't think this is anywhere near as central to the argument as you seem to think. If I'm wrong, that's great news -- if all of this argument could go away by just tweaking the installer UI, that would be fantastic. But I'm dubious. If there are two opposing sides, then there are two maintainers willing to maintain the packages. If there are not, the package without a maintainer looses by default. Ah, see, I also believe this, which is exactly why I'm so upset about the current GR. The proposed GR (the first option) is exactly about overriding the normal practice
Re: Being part of a community and behaving
On Fri, 2014-11-14 at 00:07 +0100, Adam Borowski wrote: On Thu, Nov 13, 2014 at 11:30:25PM +0100, Svante Signell wrote: From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? This is #767363 aka #754987 aka ~1e38 others. For now, you can sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces although there's a patch by Ben Hutchings that's said to work. All praise Ben! Yes, all praise Ben. But your proposal is a workaround, not a solution, if we are being strict :( -- 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/1415920836.11764.81.ca...@g3620.my.own.domain
Re: Being part of a community and behaving
❦ 13 novembre 2014 23:30 +0100, Svante Signell svante.sign...@gmail.com : Which would suggest that udev might stop supporting the userspace-to-userspace netlink-based transport in the future. However, unless I am mistaken, I don't think this means it will no longer work on non-systemd systems. From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? Things evolve with time What an accurate bug report. Could you please stop the FUD? From such a short statement, this could just be the udevadm settle needed when the init does not handle events. It just waits for everything to come here. With systemd, this is not needed since everything is expected to react to various events. -- panic (No CPUs found. System halted.\n); 2.4.3 linux/arch/parisc/kernel/setup.c signature.asc Description: PGP signature
arch all node modules should not build-depend nodejs (was Re: Bad weather in testing? on -devel)
Le vendredi 14 novembre 2014 à 07:03 +0800, Paul Wise a écrit : On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote: Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. I think you meant dependency, a build-dependency would not achieve that. Ha damn, i never got this right, then what's the correct approach for solving https://bugs.debian.org/725363 ? That appears to be an arch:any package not an arch:all one so your current Build-Depends/Depends workaround is correct. Checking the packages with debbindiff --html, I see that the .debs are identical between architectures, except for the architecture name and the timestamps, so it should be arch:all instead. The rest of this post is about arch:all node-* packages only... The correct approach would be to fix the portability issues in nodejs but looking at the buildd page I see this is mostly caused by libv8 and I guess Google doesn't care much about browser portability so this is unlikely to get fixed. An easy workaround if that isn't possible is to make every node-* package arch any and Build-Depend on nodejs, this is what happened this with node-xmlhttprequest but personally I would not recommend it. A more socially responsible workaround would be to patch dak/reprepro/etc so that some arch:all packages are not present in the Packages files on some architectures. This could be a hard problem, especially when you consider that all node-* arch:all packages should become available on platforms where nodejs is newly ported to (for example ppc64el is probably going to be a popular cloud platform at some point). Another fix to dak/dpkg we need in this is something like linux-all, for example iotop is written in Python but only supports the I/O monitoring interfaces of the Linux kernel, so the architecture restriction cannot be expressed by Depends. Personally I would just use arch:all for node-* packages, drop the Build-Depends: nodejs (since it is false AFAIK), keep the Depends: nodejs and otherwise ignore the issue, it doesn't cause much of a problem IMO. That makes sense to me, cc-ing this clear explanation to pkg-javascript-devel, thank you. Jérémy. -- 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/1415920941.25276.9.ca...@melix.org
Re: Being part of a community and behaving
On Fri, Nov 14, 2014 at 12:20:36AM +0100, Svante Signell wrote: On Fri, 2014-11-14 at 00:07 +0100, Adam Borowski wrote: On Thu, Nov 13, 2014 at 11:30:25PM +0100, Svante Signell wrote: From an irc:(16:06:44) xxx: udevd starts very slowly without systemd... any chance i can speed it up? This is #767363 aka #754987 aka ~1e38 others. For now, you can sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces although there's a patch by Ben Hutchings that's said to work. All praise Ben! Yes, all praise Ben. But your proposal is a workaround, not a solution, if we are being strict :( Yes it is, it makes sense only on desktops and servers. You see, there's a reason we keep Ben around... -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20141113233046.gb22...@angband.pl
Re: Being part of a community and behaving
Patrick == Patrick Ouellette poue...@debian.org writes: Patrick On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: Patrick I did not ask for evangelization about how wonderful binary Patrick logs are, nor for a lesson on how to get the info out of Patrick systemd with the systemctl command. Patrick I am glad you like them and they work for you. For me they Patrick add another level of obfuscation, a speed bump and a Patrick potential point of failure. All of which are Patrick unnecessary. Cat logfile, more logfile less logfile, Patrick grep term logfile -- all worked well and continue to do Patrick so for my text file logs. Awk, emacs, vi, all work on them Patrick too. My log management tools all expect my old plain text Patrick formatted logs. I'm confused. Are you saying that cat logfile isn't working for you with systemd on jessie? I'm honestly asking for information here. As best I can tell on my system everything that gets logged gets logged to text log files. Some of it also gets logged to the journal. --Sam -- 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/0149ab9e4869-9d59ba6d-53db-4de0-a43c-841cef1c93bc-000...@email.amazonses.com
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: By making it the new default, and causing apt-get dist-upgrade to install systemd (which is what happened to one of my systems) in place of sysvinit we most certainly are. The point that I'm making is that those are two separate things. Yes, both of those happened for jessie, but the only one the *project* decided (via the TC) was the first one. The second was decided by some of the maintenance teams involved, other people disagree, there's a big discussion about that at present, and I don't think the state for the release is settled at this point. By not having a meta-package init-system provided by an actual package, Er: Package: init Source: init-system-helpers Version: 1.21 Essential: yes Installed-Size: 29 Maintainer: pkg-systemd-maintainers pkg-systemd-maintain...@lists.alioth.debian.org Architecture: amd64 Pre-Depends: systemd-sysv | sysvinit-core | upstart Description-en: System-V-like init utilities - metapackage This package is an essential metapackage which allows you to select from three available init systems in Debian (systemd, sysvinit, upstart) while ensuring that one of these is available on the system at all times. Description-md5: e52554c23609041bfbca72fe27a132f9 Section: metapackages Priority: required Filename: pool/main/i/init-system-helpers/init_1.21_amd64.deb Size: 4634 MD5sum: a3844c4fe9eef9e8976803cebc33ab68 SHA1: caad9e2284c37cd25ef7ca58e23d243a37d5cc24 SHA256: ff7cd1f757d5ab178c666892caa05559f8dce2817528ab677fe778655f70e11d I don't think the nature of the problem is quite what you think it is. For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. I'm sorry that you've been misled about this. systemd logs as plain text by default in Debian. In fact, the plain text logs are much better than what we get from sysvinit, since they include stdout and stderr of daemons. That plain-text logging was replaced with binary logging is another piece of inaccurate FUD that's been going around. At least on debian-user, this information is being spread intentionally by trolls who know that it's a lie, just to make people angry unnecessarily. -- 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/87d28qehs8@hope.eyrie.org
Work-needing packages report for Nov 14, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 613 (new: 8) Total number of packages offered up for adoption: 140 (new: 1) Total number of packages requested help for: 57 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: dctrl-tools (#768834), orphaned 4 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs autodep8 botch debci debian-goodies debtree dh-lua dlocate haskell-devscripts javahelper (6 more omitted) Installations reported by Popcon: 19431 debmirror (#768532), orphaned 5 days ago Description: Debian partial mirror script, with ftp and package pool support Reverse Depends: argonaut-fai-mirror goto-fai-backend Installations reported by Popcon: 1355 github-backup (#768991), orphaned 3 days ago Description: backs up data from GitHub Installations reported by Popcon: 117 jetring (#768525), orphaned 5 days ago Description: gpg keyring maintenance using changesets Installations reported by Popcon: 131 moreutils (#768529), orphaned 5 days ago Description: additional Unix utilities Reverse Depends: ikiwiki-hosting-web Installations reported by Popcon: 3088 mpdtoys (#768518), orphaned 5 days ago Description: small command line tools and toys for MPD Installations reported by Popcon: 125 pdmenu (#768527), orphaned 5 days ago Description: simple console menu program Installations reported by Popcon: 298 ticker (#768528), orphaned 5 days ago Description: configurable text scroller Installations reported by Popcon: 23 605 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: soundconverter (#769372), offered today Description: GNOME application to convert audio files into other formats Installations reported by Popcon: 3178 139 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1746 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 77242 athcool (#278442), requested 3670 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 43 awstats (#755797), requested 113 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4141 balsa (#642906), requested 1145 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 736 cardstories (#624100), requested 1298 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 11 chromium-browser (#583826), requested 1628 days ago Description: Chromium browser Reverse Depends: chromedriver chromium-dbg chromium-l10n design-desktop-web mozplugger Installations reported by Popcon: 25820 cups (#532097), requested 1986 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (64 more omitted) Installations reported by Popcon: 143786 debtags (#567954), requested 1746 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2337 developers-reference (#759995), requested 75 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15045 ejabberd (#767874), requested 10 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 847 fbcat (#565156), requested 1765 days ago Description: framebuffer grabber Installations reported by Popcon: 158 freeipmi (#628062), requested 1267 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools libfreeipmi-dev libfreeipmi16
Re: Being part of a community and behaving
On Fri, Nov 14, 2014 at 12:05:17AM +, Sam Hartman wrote: I'm confused. Are you saying that cat logfile isn't working for you with systemd on jessie? I'm honestly asking for information here. As best I can tell on my system everything that gets logged gets logged to text log files. Some of it also gets logged to the journal. Sam, I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. (Obvoiusly if a program manages its own logging, those are not affected by the change.) If the journal file is not supposed to be in a binary format, then my system didn't get that configuration update Pat -- 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/20141114013921.ga10...@flying-gecko.net
Re: Being part of a community and behaving
On Fri, Nov 14, 2014 at 9:39 AM, Patrick Ouellette wrote: I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. journald forwards to rsyslog etc, which logs to /var/log/syslog so cat /var/log/syslog etc still works. Personally I have found journalctl much more flexible and useful than cat etc. -- 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/CAKTje6HF6Chq+NkGdtRcv0RZwORS=olssh7_poc27stcdjv...@mail.gmail.com
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. If that's happening on your system, that's a bug. It's definitely not happening on mine. Could you provide more information, such as an example that's not in /var/log/syslog where you expect it but ended up in the journal, and what program is involved? -- 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/87a93u5yca@hope.eyrie.org
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 06:07:33PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. If that's happening on your system, that's a bug. It's definitely not happening on mine. Could you provide more information, such as an example that's not in /var/log/syslog where you expect it but ended up in the journal, and what program is involved? Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Pat -- 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/20141114021510.ga12...@flying-gecko.net
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. -- 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/8761ei5xsb@hope.eyrie.org
Re: Being part of a community and behaving
El jue, 13 de nov 2014 a las 6:15 , Patrick Ouellette poue...@debian.org escribió: On Thu, Nov 13, 2014 at 06:07:33PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. If that's happening on your system, that's a bug. It's definitely not happening on mine. Could you provide more information, such as an example that's not in /var/log/syslog where you expect it but ended up in the journal, and what program is involved? Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Apparently newer versions of systemd-journald do not forward to syslog by default; that has to be explicitly configured (although rsyslog already reads the journal and collects the logs). Not sure if 215 is affected by that behavior, will have to look it up later. What syslog implementation are you running? Thanks, -- Cameron Norman
Re: Being part of a community and behaving
Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote: Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. -- 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/87vbmi4hnu@hope.eyrie.org
Re: Being part of a community and behaving
El jue, 13 de nov 2014 a las 6:53 , Russ Allbery r...@debian.org escribió: Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote: Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. Apparently this is a known issue, and another person has experienced it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 Cheers, -- Cameron Norman
Re: Being part of a community and behaving
El jue, 13 de nov 2014 a las 6:57 , Cameron Norman camerontnor...@gmail.com escribió: El jue, 13 de nov 2014 a las 6:53 , Russ Allbery r...@debian.org escribió: Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote: Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. Apparently this is a known issue, and another person has experienced it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 Arg. I read to quickly; this appears to be something quite different. Nevermind. -- Cameron Norman
Re: Being part of a community and behaving
On 13/11/14 23:16, Brian May wrote: On 14 November 2014 04:20, Carlos Alberto Lopez Perez clo...@igalia.com wrote: The last one that I read is that udev is going to stop working on non-systemd systems: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html I don't read anything in that post that says this. Am guessing you a referring to the Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far quote. Which would suggest that udev might stop supporting the userspace-to-userspace netlink-based transport in the future. However, unless I am mistaken, I don't think this means it will no longer work on non-systemd systems. Once they replace the netlink transport with kdbus, udev will effectively require kdbus to work. And for kdbus to work (with the current implementation) some user space daemon has to set up the system bus and configure it. This is not a trivial task, and the only daemon that currently does that is systemd (pid 1). signature.asc Description: OpenPGP digital signature
systemd / syslog issue (was Re: Being part of a community and behaving)
On Thu, Nov 13, 2014 at 06:53:09PM -0800, Russ Allbery wrote: Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. ● syslog-ng.service - System Logger Daemon Loaded: loaded (/etc/systemd/system/syslog-ng.service; disabled) Active: active (running) since Thu 2014-11-13 21:36:20 EST; 18min ago Docs: man:syslog-ng(8) Main PID: 13370 (syslog-ng) CGroup: /system.slice/syslog-ng.service └─13370 /usr/sbin/syslog-ng -F So it claims the syslog-ng service is disabled. Pat -- 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/20141114030316.gc12...@flying-gecko.net
Re: systemd / syslog issue (was Re: Being part of a community and behaving)
Patrick Ouellette poue...@debian.org writes: ● syslog-ng.service - System Logger Daemon Loaded: loaded (/etc/systemd/system/syslog-ng.service; disabled) Active: active (running) since Thu 2014-11-13 21:36:20 EST; 18min ago Docs: man:syslog-ng(8) Main PID: 13370 (syslog-ng) CGroup: /system.slice/syslog-ng.service └─13370 /usr/sbin/syslog-ng -F So it claims the syslog-ng service is disabled. My guess is failure to sync status properly at some point during the upgrade process, so the fact the init system was enabled somehow didn't translate into enabling the unit file. This is the work that deb-systemd-helper is supposed to do. systemctl enable syslog-ng should fix the problem on that system permanently. It's going to be trickier to figure out where the problem was introduced, sadly. :/ Now I'm wondering if some of the folks thinking that systemd implies binary logging are getting bitten by the same bug that you're getting bitten by and just didn't realize it wasn't intentional. -- 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/87k32y4gqf@hope.eyrie.org
Re: Being part of a community and behaving
Patrick == Patrick Ouellette poue...@debian.org writes: I think this is a bug. On my system things get logged both to the journal and to /var/log/syslog. My understanding talking to systemd folks is that the behavior I'm seeing is intended and that unless you went out of your way to configure something different you should still see stuff logged to text files. So, you might want to ask on #debian-systemd and/or report a bug. --Sam -- 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/0149ac2c2d41-09d0ce56-a56f-4658-8bc5-853515c63387-000...@email.amazonses.com
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Pat -- 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/20141114024043.gb12...@flying-gecko.net
Bug#769499: syslog-ng-core fails to enable systemd service unit
package: syslog-ng-core severity: important version:3.3.5-4 justification: does not enable systemd unit. syslog-ng-core's postinst does not enable its syslog unit. I'm guessing that including systemd in the dh sequence is not quite doing enough to actually turn it on. Unfortunately dh-systemd is under-documented so I cannot tell where the bug is but I bet an explicit call to dh_systemd_enable will make your users happy. Attached is the buggy postinst #! /bin/sh set -e if [ $1 = triggered ]; then invoke-rc.d syslog-ng stop || exit $? invoke-rc.d syslog-ng start || exit $? exit 0 fi dpkg-trigger register-syslog-ng-plugin # Automatically added by dh_installinit if [ -x /etc/init.d/syslog-ng ]; then update-rc.d syslog-ng defaults 10 90 /dev/null || exit $? fi # End automatically added section exit 0 -- 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/tslppcqmoet.fsf...@mit.edu
Re: Being part of a community and behaving
Cameron == Cameron Norman camerontnor...@gmail.com writes: OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. Cameron Apparently this is a known issue, and another person has experienced Cameron it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are closely related, and will be fixed in the next syslog-ng upload (likely early next week). I know how to fix both, but lacked the time to implement said fixes so far. -- |8] signature.asc Description: PGP signature
Re: debian installer, install listofpackages.txt in CD root dir after end install?
You can do this using a preseed file: https://www.debian.org/releases/wheezy/amd64/apb.html.en in particular: d-i pkgsel/include string htop vim tree zsh Cheers, Fabrice 2014-11-14 0:19 GMT+01:00 Michael Ole Olsen g...@gmx.net: It would be very cool if the debian installer had a listofpackages.txt and that listofpackages.txt could be edited by the user then we would be getting customized debian installs some people would edit and tell it to auto install: - zsh - lilo instead of grub - lukssetup (crypt thing) - ext3 instead of ext4 - Xfree86 instead of Xorg - systemX instead of systemY -- 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/CACfjVBa_uoq6_0NfPA5bsg+cc=dE7d=llvlr7g3z3gckeq_...@mail.gmail.com
Accepted python-magcode-core 1.4.7-3 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 13 Nov 2014 22:12:42 +1300 Source: python-magcode-core Binary: python3-magcode-core Architecture: source amd64 Version: 1.4.7-3 Distribution: unstable Urgency: medium Maintainer: Matthew Grant m...@mattgrant.net.nz Changed-By: Matthew Grant m...@mattgrant.net.nz Description: python3-magcode-core - MAG Code python3 core module of common utility code. Closes: 769001 Changes: python-magcode-core (1.4.7-3) unstable; urgency=medium . * Build-depend on python-setuptools Really fix #769001 (Closes: #769001) Checksums-Sha1: 71cce38fa57b6c32b0e67f7ef908f96d42587154 1988 python-magcode-core_1.4.7-3.dsc 85bda4b6a17d0c1137a0dd9babcd53a17c4bc02a 4136 python-magcode-core_1.4.7-3.debian.tar.xz a547201af90c7260469439f75476e581cf233345 36734 python3-magcode-core_1.4.7-3_amd64.deb Checksums-Sha256: 51cf63bb02be4cbaad961c6451a8ddd0f01a1074f5f8bd20381c690a3e41ead3 1988 python-magcode-core_1.4.7-3.dsc 566bd32d37ca49c3f1973cba7a295849a53d5f2b31fde7298a82f6dd4a3e3d9f 4136 python-magcode-core_1.4.7-3.debian.tar.xz c2b014768674997845a9449e432b7001f903104e18edd2f750e0434bcdffe356 36734 python3-magcode-core_1.4.7-3_amd64.deb Files: 966fb8c267842bbe91cee7b4abe9fddb 1988 python extra python-magcode-core_1.4.7-3.dsc 955acc0d32f5b8afb8b1f910fdccd876 4136 python extra python-magcode-core_1.4.7-3.debian.tar.xz 58b356733d1a21c9357b1b8636b9c101 36734 python extra python3-magcode-core_1.4.7-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUZHaCAAoJEMROX/wTNcOiSxsQAIYQvJm8Quq7qexyTHnhjO/S 1+b00WwmtYEOTPtMfmWaXpSUJuTTDmVffE/qE2kLYY9oxOxZVRrdPXAE+XISLAv1 APcZGcQ4hBlIObf+KQgvfncWtIOT3F078fuE/D1XfMdLckN5u2CPCEQCtwPrcdIS CwdBzeuWJ6NcWk0XWwoeeAnpkCuFCKnRNme2AHeyO8hrwAZEuM+P+IK2jB3qOYX+ L3ZjtAGg/2beXMyCY3DywOueisiM0zHSJUO4thAaSYQpUHieuE5UxtSGe7gVvPAI U6z2UhL8HNC3xE2Cj6T1wfPyHxVJ9ugVq3Sk/U367cF9qKdsuwkwQ/7vnlSt/SSg z9KPcQtffVCsiq7CxrFK3CQTjMb163aHz6JOlrYJ5L6//12yt3p0oGrOpR/9Fk2R 2tqCODeMu20nU0ZPpi19h49uF2zJhh/hgn06EcQIZH/jCvghY+PFIdG4+3Xp3nUb LizAa7pG2PqDqWyvvb25hCZ+PI8NdD513ZvgpPBSUWqFpjR7JfF2Wo9+Mx1yGYQn V+aCztCzk5JG+5Ivfd/L9yybIAOmd957jm6PtgtyIlVz3aI+60AX4IgDZRgfyWGm w5WFQBI4a2ZqG1aMpOx9FxwhUopnh7RogdH68L2Ex+TL2PBYs5eEULSXumXifRWJ dbTN/Xl4eD5KIxUOlcSh =hnHd -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/e1xoqyu-0003pw...@franck.debian.org
Accepted ejabberd 14.07-3 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 13 Nov 2014 10:59:18 +0100 Source: ejabberd Binary: ejabberd Architecture: source amd64 Version: 14.07-3 Distribution: unstable Urgency: medium Maintainer: Konstantin Khomoutov flatw...@users.sourceforge.net Changed-By: Philipp Huebner debala...@debian.org Description: ejabberd - distributed, fault-tolerant Jabber/XMPP server written in Erlang Closes: 764974 767535 768462 Changes: ejabberd (14.07-3) unstable; urgency=medium . * Don't depend on /usr/share/doc during postinst (Closes: #764974) * Added patch for CVE-2014-8760 (Closes: #767535) * Don't let reopen-log command rotate logs and disable ejabberd's internal log rotation in default cofiguration (Closes: #768462) * (Re-)Enable TLS by default but disable SSLv3 Checksums-Sha1: d2da1b72e8bfbd917339c015f8bcbd32e390bd74 2405 ejabberd_14.07-3.dsc 2c83e949aacbdaddb5c152c3d86af9bd73d0f5f6 49072 ejabberd_14.07-3.debian.tar.xz 9874ac995cb6c4bd2ae9c7c3a57d3a0ebccaf95c 4149326 ejabberd_14.07-3_amd64.deb Checksums-Sha256: a1c0fedcfda52ebd9efb29dc446ba626afab9b3b0505520f5bfcd715752d0185 2405 ejabberd_14.07-3.dsc 364bc62c73963d2e262e445b24f00196468cc6f3f877c80a2cd852b0461d97d3 49072 ejabberd_14.07-3.debian.tar.xz 42becce7b1da94e1a19111c5deb96a2a79e926ff0f92b7e4315eab69783c0aa8 4149326 ejabberd_14.07-3_amd64.deb Files: a73544fa2e910eef32dbb9e7f68c25e0 2405 net optional ejabberd_14.07-3.dsc 0abc11a650ea8dea2db462b9c716c8c3 49072 net optional ejabberd_14.07-3.debian.tar.xz 0606e7af9ad677606a4ef58313d4c63e 4149326 net optional ejabberd_14.07-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUZIXGAAoJEOXKjEkl5CBf6OIQAILvSF9fapPif/dg8ZyXxSGO TxVAms4RtA6Guy9Ss+o4/2lIOHWPXmOB56LLSJ2LbTPn+zX7OvNP6l2D0VF4wT1J jZB9QfgK4q7WVTrN2itXYnM/rseGzpJ+RIz9SHWUKNvMtq6IPPtazpf8z2KdAOnt dWoMpRfYFvtMEe+YP8xyUhPS1WNUzSk2JAyEoNgkt7IcPSs872OWSfJvE5/HE3b2 /K92t4otsK4mjXomRfhDbdiGzzConjH9JyDlpow4u/sm/QZxKlaucS/oZeYC32v9 0mW1S+Za6QSchJ58jLZHsH7dvqwkrwEsJUUgjPFM22mnEWP4fv+cKQpI8OBYwSMc ExeZKa7igQ8ae6skoFkzPC5Ye4uhsqK9z/m1iqh72tU0w3A5A6l8u8Os6H7/DLU5 83Wi+jld9na3K9LKNP7UfFr8ls+FyQ3P0Lgz1l+tCNh2r/ixVunlDZxWUi7rgnz5 FY3HUQoxMaWbvWTja1tdtLSDBZ1t9HuopfeiMBwCC/Lf40ytEKat0jfve9hDrV4v iURT4qiEBfknCI3AxsS/U/kq2+4dPF5+MebMZDLkbvQoeffjwdAr8WD1un2guKp1 OkBQiRAbgJHt0ie84WcfxsFClySnXcDqe2S8nPp92snxuGd/hX8zWcsGDEE1vXZK g3vuTMrFnrCvE4KkRDYn =uGk3 -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/e1xorjo-0002b5...@franck.debian.org
Accepted libmemcached 1.0.18-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 12 Nov 2014 07:49:47 +0100 Source: libmemcached Binary: libmemcached11 libmemcached-dev libmemcached-dbg libmemcachedutil2 libhashkit2 libhashkit-dev libmemcached-tools Architecture: source amd64 Version: 1.0.18-4 Distribution: unstable Urgency: medium Maintainer: Michael Fladischer fladischermich...@fladi.at Changed-By: Michael Fladischer fladischermich...@fladi.at Description: libhashkit-dev - libmemcached hashing functions and algorithms (development files) libhashkit2 - libmemcached hashing functions and algorithms libmemcached-dbg - Debug Symbols for libmemcached libmemcached-dev - C and C++ client library to the memcached server (development fil libmemcached-tools - Commandline tools for talking to memcached via libmemcached libmemcached11 - C and C++ client library to the memcached server libmemcachedutil2 - library implementing connection pooling for libmemcached Closes: 768688 Changes: libmemcached (1.0.18-4) unstable; urgency=medium . * Add move-ax_confix_aux_dir.patch to move AC_CONFIG_AUX_DIR up a few lines so autofoo can find it (Closes: #768688). * Bump Standards-Version to 3.9.6. * Update Vcs-Browser field. * Move main license entry to top in d/copyright. Checksums-Sha1: 53d095b96c98c58d812ecb02fe17799c3e2a4be2 2371 libmemcached_1.0.18-4.dsc 63600b6b408cb67da70ca66ce54fad8892aca0f3 11964 libmemcached_1.0.18-4.debian.tar.xz c8b275a8558eb7000942376b67beaa363305f826 95248 libmemcached11_1.0.18-4_amd64.deb 0d5a9e94d8dda7af12f031f64631e9f147cadc9e 253360 libmemcached-dev_1.0.18-4_amd64.deb cd84b59002d94844d3767f8de599a4b0fa6bd0bb 782594 libmemcached-dbg_1.0.18-4_amd64.deb cfd450854e9547ca95c7ba974c8ed2c2c427b3da 22320 libmemcachedutil2_1.0.18-4_amd64.deb de33c1105dbf47d30e038ff8ac094f03cb7e1388 46948 libhashkit2_1.0.18-4_amd64.deb 6841fcda18eef1772815e017406e817e293bcaaa 37278 libhashkit-dev_1.0.18-4_amd64.deb 37cfb75bbe1a379cbd4a998f0c858fd42883c3b9 85848 libmemcached-tools_1.0.18-4_amd64.deb Checksums-Sha256: 75979e654b956f8f3ecb820cb626a3e3de432dc3ade588578904e8a73f44f70c 2371 libmemcached_1.0.18-4.dsc 2d1dcf6fa4e93d64490783db352bc136483dfe4ccb365ce269e4d66a89bc0cd0 11964 libmemcached_1.0.18-4.debian.tar.xz 7353232cbee34f1e52aeef960a2bfec2ff4a04b8a45b86ff89ded8f5785ee378 95248 libmemcached11_1.0.18-4_amd64.deb d3794d331b04761d5399852a5926664da375692a018f2e809046c86d4597bcc6 253360 libmemcached-dev_1.0.18-4_amd64.deb 5b135598b4da1b847760dac00f541769e01149f7cc4e9bdfec45aa2be2f61deb 782594 libmemcached-dbg_1.0.18-4_amd64.deb 3676173bacc6ca3410634a7549a9bdbf2c694ad80be779c275cd8d13fe986c77 22320 libmemcachedutil2_1.0.18-4_amd64.deb 1efe62c7debbeaf19a2737c13bbb2e47a99c0247b3c3b9940a6a03425d127dd0 46948 libhashkit2_1.0.18-4_amd64.deb 39480928e7a67b44c5b4adba65ac608a2703907d08f03d6cabbeb0ba60e20e27 37278 libhashkit-dev_1.0.18-4_amd64.deb 539b83e57bf863a7df958e5364f9dc1d7be20ad988b2d0001791ab72a94fec52 85848 libmemcached-tools_1.0.18-4_amd64.deb Files: 1dcc223df18f22e7ff28b6d545e864f2 2371 libs optional libmemcached_1.0.18-4.dsc 1dec1642c45a1880d0e93e7f4b866da5 11964 libs optional libmemcached_1.0.18-4.debian.tar.xz 0d75e739f0fec311b532b009a66d79f6 95248 libs optional libmemcached11_1.0.18-4_amd64.deb dadb4ec0bda8a2e826466fa23f800d90 253360 libdevel optional libmemcached-dev_1.0.18-4_amd64.deb 18376945b4e9e43aba13acd0289528f2 782594 debug extra libmemcached-dbg_1.0.18-4_amd64.deb 2fd47c6d606fd83922d18b6b29e2b76d 22320 libs optional libmemcachedutil2_1.0.18-4_amd64.deb 9ef2a3720208169e2cd6c7c032cc2af8 46948 libs optional libhashkit2_1.0.18-4_amd64.deb 18911aa306654ad5508c121a3389510c 37278 libdevel optional libhashkit-dev_1.0.18-4_amd64.deb b12281c732577aded24933abea4bf76e 85848 utils optional libmemcached-tools_1.0.18-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUZIYeAAoJEBLZsEqQy9jkNQQP/0dMyMgYLUQM+yEeLOtWagIv pG/QElTb3V3G5J8VKoqQF+4ye0qrMl3ETKQLf7/KYYGtBxUlfVsORsE5R5x9TvRF zwrM+HqDOGMIMi8UliU+7gWGLnR1vsidUm7bNLpJWCOald4+rDZGOOVhGESgq9Zc 5zZC0oe5mvABJ0lZ4z6S7fEv7RGjK9bO6YKuIe4T6ZBNDlWps1QjZZnd7GJzGh06 o/cQwEuwjPtSh8DEo1+ZX4a8Ia+My++KLfPBYgKEc7sgbFtX0EbalfpBiri9I7yG v/TZ22Sz1ILC+atgfOBl0KM7bQ4MnA9qu3//2h5OyzKJaKMriL+97Ro4s3hGUvty v97i2miqE4sTIFDEAFKdik+DMUGz8cTvckgNwGmRO3rrN9xpgzXG6JSS+qiaBZK6 Wu3HMG0wQm5KGoUxRWCs2e3yIUCzasG74neCt5tyAaCLT7EiVlAkpBZyEV315jwv XbUS/h20xSzIZL2aJO1w0olADyAcbmf+rVEQ6mf9Ok8uiBlZ3HgkhNX3OqBwdJZd FTAC/NJ5Zc50rm9N+NOiDFPhkeu2/Ny+TNuwzgrmir1ishK41D9025mz5qCQzEKo ICe8kqDHT2Er4TZ2SGx0gwqDe7cl3EGBu+To/son3Kuv0hts/w6YZbcCUP0uBykh z2vSTO+cvL/tFltXEwU3 =ojxA -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/e1xorjc-0002nj...@franck.debian.org
Accepted stress-ng 0.02.27-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 13 Nov 2014 10:49:00 + Source: stress-ng Binary: stress-ng Architecture: source amd64 Version: 0.02.27-1 Distribution: unstable Urgency: medium Maintainer: Colin King colin.k...@canonical.com Changed-By: Colin King colin.k...@canonical.com Description: stress-ng - tool to load and stress a computer Changes: stress-ng (0.02.27-1) unstable; urgency=medium . * Makefile: bump version * stress-utime: use also utime and make futimes linux only * stress-fault: use posix_fallocate instead of fallocate * stress-fault: clarify negation on boolean expression * stress-hdd: close file on error exit path * Use PATH_MAX for filename sizes * stress-hdd: use temp filename helper * stress-fallocate: use temp filename helper * stress-inotify: use temp filename helper * stress-flock: open using S_IRUSR | S_IWUSR * stress-fault: open using S_IRUSR | S_IWUSR * stress-denty: open using S_IRUSR | S_IWUSR * stress-dir: use temp filename helper * stress-link: use temp filename helper * stress-rename: use temp filename helper * stress-utime: use temp filename helper * stress-sendfile: use temp filename helper * stress-flock: use temp filename helper * stress-fault: use temp filename helper * stress-dentry: use temp filename helper * Add stress_temp_filename for standard temp filename building * stress-dentry: include instance number in filename * Catch a range of signals and handle termination better * Re-work process wait by re-writing this with a helper * Fix build issues on Arch * Man page: tweak width for cpu methods to work on wide ttys * Only print out page fault stats to debug * Correctly wait for all running processes to terminate * Remove redundant exit check * Add page fault stressor * Remove -g flag from Makefile * Add lsearch stressor * Add tsearch stressor * Ensure we allocate in multiples of 8 elements * Add bsearch stressor * stress-poll: set data in correct place, fixes verify failures * Make hyperbolic cpu test more demanding * Make trig cpu test more demanding * Add 3 more hash cpu stressors Checksums-Sha1: c280c58f2c5ec2c288bcb1977795bb0bc0e518f5 1724 stress-ng_0.02.27-1.dsc f0b061495575fda214c99e0d0cd3d85415609948 75231 stress-ng_0.02.27.orig.tar.gz c9b1732f8d01abb178502a5cc846764dbd5ee14a 8708 stress-ng_0.02.27-1.debian.tar.xz 5f56c5f33a62dce6552eeaefd5e97d157a609927 64844 stress-ng_0.02.27-1_amd64.deb Checksums-Sha256: dae74434de5578de27470bb36df4796a988bd2146c7adbf321e13f1d9b72fd91 1724 stress-ng_0.02.27-1.dsc 61a2e2237c63d5348ad6848fc97b6b479c818cb0055b1bb0d40a53907bfdd470 75231 stress-ng_0.02.27.orig.tar.gz 9727fc49251f408317fe70a4adad32d5765873bd7c1de1c6612506a0d26f9562 8708 stress-ng_0.02.27-1.debian.tar.xz ed1450a73af926443fd54be7653730bbd526622683ced0f4df109baf1cf3f254 64844 stress-ng_0.02.27-1_amd64.deb Files: ba91c99ef0f5dadc7a910515d355d481 1724 devel optional stress-ng_0.02.27-1.dsc 16bb56634a4bc796668129a9b58f05c9 75231 devel optional stress-ng_0.02.27.orig.tar.gz 9b5f622e15aacd8f573b62b20ee6398d 8708 devel optional stress-ng_0.02.27-1.debian.tar.xz 9b4ed9c68febcc8703d8994e2306b244 64844 devel optional stress-ng_0.02.27-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUZJE0AAoJEGjCh9/GqAImBtgP+gK5N1Piw+ZxRLypWSNuTRXH 6s3mm8RCt0pcZJpulrK+Fv4LSSY2zcqgrFZG7ka3Cyhzc4IW8sTCa2dxs+uAyDLn dJZ6u0q2n+295LX2EpsU/pMVGvI/0vQz/aTrhwNfNxtBB9GIhT4O3ccMhLZ/ZB/r CjED6senDJ2qmvd+i4j4H6JR+AclIhYOtRa9uosWbPbqCrugjKAIpVzNgGXGzj+d OaXcdIsQqAZUUiIo/v5yKVjccahesHjzD4VcGJcyHCKFmHaoP3ji79cMs+v50WaP kbfPh9j5r10eyD2K7urqnrLD+izXx/YM0dHshwhSSHbE3mQjWk7qnd441Am2vp+b Ok/wMGr3ky2sQLzUm6asxRmfMzgY/1sOYwvFHHcraSSLuJeLJ8dcCbYGMIZ0NyJv 6lWbgLOdUZaiiR4SzYkpqpKYV387ahHbDwHXbFQrua8v0ZE5bZ1LJehlI9F34YPn 3b5c+kFACV8sAMPEshIIkpBgubNYYo3AZgxvibGp2SC7QdL0sqmukk6pLKdm9tZk g2acKr54FjRpWVQEPMLZvXK+V21Vup0Vx8m0D7mbqzVVVxWpfCdey1QnnPn4bwyQ VZXmzrtxuiCJZYX6tCium3MxaFYU4J2SOV3RcJxxZm/aZ+e7aCzpy20OnYNJChNU lXCJgWkfM8hDrV90MDln =nzuA -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/e1xosqx-0008ek...@franck.debian.org
Accepted mako 1.0.0+dfsg-0.1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Nov 2014 12:39:18 +0100 Source: mako Binary: python-mako python3-mako python-mako-doc Architecture: source all Version: 1.0.0+dfsg-0.1 Distribution: unstable Urgency: medium Maintainer: Piotr Ożarowski pi...@debian.org Changed-By: Ivo De Decker iv...@debian.org Description: python-mako - fast and lightweight templating for the Python platform python-mako-doc - documentation for the Mako Python library python3-mako - fast and lightweight templating for the Python 3 platform Closes: 722265 Changes: mako (1.0.0+dfsg-0.1) unstable; urgency=medium . * Non-maintainer upload. * Remove minified javascript files from upstream source. They are not used in the build process. Closes: #722265 Checksums-Sha1: ff52e7024261f8c52b6b9e413d5c8fe9471f32bf 2321 mako_1.0.0+dfsg-0.1.dsc 8324c81879714113d3287171ac159d95a66afb71 420406 mako_1.0.0+dfsg.orig.tar.gz c0d54be186029891bb99e404a0545019b2aec923 10428 mako_1.0.0+dfsg-0.1.debian.tar.xz 2989194e70347b5d45576d570f9c00c7053d71c2 61384 python-mako_1.0.0+dfsg-0.1_all.deb e6c9159dbe8b6cde5ebf91b9274117b1489075d5 59724 python3-mako_1.0.0+dfsg-0.1_all.deb ddaec7f5bbed5163564fe9ec73a8b7eeba19e9c7 178532 python-mako-doc_1.0.0+dfsg-0.1_all.deb Checksums-Sha256: 1b6075a4f91d70eb6de9d46b0361e9f27e28afbf09cc3f78cd10a4c0d0e1d16d 2321 mako_1.0.0+dfsg-0.1.dsc ba17aaa6b44b3642d1d9cfaf643daa54c0991fe7152eedada05ca7311e2520f3 420406 mako_1.0.0+dfsg.orig.tar.gz 90341cd8594c7650479b91697ac1df57a09ee73bc4a1076eb15711f006bb0a9d 10428 mako_1.0.0+dfsg-0.1.debian.tar.xz 4078155394061adb67afc3d55c2fe8f3274927decbaffea5b2bf7faede4c3189 61384 python-mako_1.0.0+dfsg-0.1_all.deb 06d045a2a9fc0dc7885c5eb221fbb0bf231d15f9f16a969dcb0df92ecec69499 59724 python3-mako_1.0.0+dfsg-0.1_all.deb 4447e7efd8647e7e087377446017d70dbd57a93598cc6a4851ce7f133e5056ec 178532 python-mako-doc_1.0.0+dfsg-0.1_all.deb Files: 431b436fbd0c0ba55140c63e2ff3f177 2321 python optional mako_1.0.0+dfsg-0.1.dsc 519f12039014c959f3920564f3209e7c 420406 python optional mako_1.0.0+dfsg.orig.tar.gz 4395fb55dcf23953ab8acad4ea03ef6a 10428 python optional mako_1.0.0+dfsg-0.1.debian.tar.xz b19082c846ced0a82b5f10a04ed381b6 61384 python optional python-mako_1.0.0+dfsg-0.1_all.deb 75f14643aa01112f7e30959906db87f3 59724 python optional python3-mako_1.0.0+dfsg-0.1_all.deb 2c7d02967272478da8c5ceccb7f7a63b 178532 doc extra python-mako-doc_1.0.0+dfsg-0.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJUYfb3AAoJEKxAu1iXBOr8X/YQAIvauyUB+iXbCg2Se5bquYzS JXy/vFOenOgp3ml0X7B0b6JsdpY2fr6D45r3sBlUJT0IFJ2+SCgBmxbRhPA3Dc6e iEkbIPmLGSFoRnCi2lvDUNfsnOvpKER+Ew/bOED8SIZUzZOnWPfEorGoYJySFE7J ptmFoLxNhYSR9Tm7IgpaUXs9qOheqRWuL82iK0nP9ObpjAVSatx4+gdXqLJel14O I9yRKT0fcqPWtC+fdqixa0ZPyUGw+2uluFH5Me0ork/b0ZUH1fvwF3sSRcsp9fJt W2JGpAYOB/nONuy2u5u8cZAMry46uXHO7JL8mJJXTTjPg5UnrdHJ8LHXuPCJmp2/ DDz5b+ls77cIIS75ac4RClumay6R5UdYAr8G3UIBvPyuumwyGl5iqq0YxdWEePT3 OfZSRQOOJSXey6aFElu/WfSAOKgaCZHmTWPNQQzLRf9bDc3f7OKU1hVSWuUFIx55 V6QAS2LLgXnd+fyGNZ2XzfYAHT9e2xH1ovai4jIP/zjx2QdOHaTUSuYgXEQ4QivL gE5PzaS8eU0gDIxI0DGFv8KnpSeNbzrVI0clp4cFLmAq01nWCU6rMnPSJb3VX54Y djpcHZtiWUa5g8L9DoQDOkcBOxEOdEx3PEckwFuGuSrgb6hJPI6/XxltPUjgCPV6 nZVrF1XMCdzMFnzWet1w =PfLT -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/e1xot80-0004rg...@franck.debian.org
Accepted coinutils 2.9.15-3 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 13 Nov 2014 20:18:22 +0800 Source: coinutils Binary: coinor-libcoinutils3 coinor-libcoinutils-dev coinor-libcoinutils-doc coinor-libcoinutils3-dbg Architecture: source amd64 all Version: 2.9.15-3 Distribution: unstable Urgency: medium Maintainer: Debian Science Team debian-science-maintain...@lists.alioth.debian.org Changed-By: Aron Xu a...@debian.org Description: coinor-libcoinutils-dev - Coin-or collection of utility classes (developer files) coinor-libcoinutils-doc - Coin-or collection of utility classes (documentation) coinor-libcoinutils3 - Coin-or collection of utility classes (binaries and libraries) coinor-libcoinutils3-dbg - Coin-or collection of utility classes (debug symbols) Closes: 768753 Changes: coinutils (2.9.15-3) unstable; urgency=medium . * Team upload. * Add liblapack-dev for coinor-libcoinutils-dev to make sure -llapack and -lblas exist as required in the pkgconfig file (Closes: #768753) Checksums-Sha1: 045d113cbd01bdfe808db634a890c5026a01f775 1951 coinutils_2.9.15-3.dsc 21548f4a1f2cd0979be4dc33f22187cc83e6b468 8368 coinutils_2.9.15-3.debian.tar.xz 847f819532446a062fd3018a48608e0082d1a06a 476620 coinor-libcoinutils3_2.9.15-3_amd64.deb adb46c473081e3b1ca020aa5aaa077594eabf8a7 792118 coinor-libcoinutils-dev_2.9.15-3_amd64.deb 3155f097fc879b2d5901979b713151eff6b0cb34 8915324 coinor-libcoinutils-doc_2.9.15-3_all.deb 59b45f7e05aeebf7b94bb9c664982f905e1d4622 2305620 coinor-libcoinutils3-dbg_2.9.15-3_amd64.deb Checksums-Sha256: 44918ee4c809b9041c578fd07ae54c1ea1421731324393ac37f033ee64b149d0 1951 coinutils_2.9.15-3.dsc c1ad448fc76ed100f24794692645206363ed0c372c3556bf7b51fa081db6b43d 8368 coinutils_2.9.15-3.debian.tar.xz f56555fb3bf957d7ec4c690bbfa53ac8d2d760af0a158b11d548da54f16b54dc 476620 coinor-libcoinutils3_2.9.15-3_amd64.deb d723fa057fa1bb8ee32111b560fe643b6e191190feed5ebb68893c24e0884ead 792118 coinor-libcoinutils-dev_2.9.15-3_amd64.deb eb7ee9ff29eab23beb2720d3112c690e7b40e507cc95ac5ae988d5353c751f3b 8915324 coinor-libcoinutils-doc_2.9.15-3_all.deb fcd16b3f0c3e390de97f08a2614245df127b7d9e5e92abb02b92394588b816cd 2305620 coinor-libcoinutils3-dbg_2.9.15-3_amd64.deb Files: 79ecab5b8e0eb65d9ce822405bdaf321 1951 science extra coinutils_2.9.15-3.dsc 66e5f00c433527bbff0738d1591abca0 8368 science extra coinutils_2.9.15-3.debian.tar.xz 4d6667f0b3768f731d84b6c58214e54b 476620 science extra coinor-libcoinutils3_2.9.15-3_amd64.deb 2ebbadcb95347caed020da05dc4d5992 792118 libdevel extra coinor-libcoinutils-dev_2.9.15-3_amd64.deb 755a4dde442fdc2ca4d72516b83852c7 8915324 doc extra coinor-libcoinutils-doc_2.9.15-3_all.deb 6380478ea02915ba34775c3f9019b804 2305620 debug extra coinor-libcoinutils3-dbg_2.9.15-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJUZKOTAAoJEGa1A/2e4BN5CD4H/jiDo6k97E+PrCCk0cFFK2Yh GnMF8GlU6AFR7ciWKV/EOm3OjA80Py4Jxe93ZFLCRlwnRHDigj40JlAT+rNaXaRd LCwyyxANe54jOKzcGtwfx2jSsirmoSOFSC20+laiGQvI5bCAAPSAUtv/7Ihw0Q30 vK15hwFIxiCjEKU+I7y/ayCyvGlZPH9/8K21O1jnu7JBqdK9xmxgt+2nfmJr5B4/ 8wQpq/CNf1JcaNkFfK5pPj1CF1/nmgsxC/rarLT2LRbrvpvXXkMZXRPy2U/uOpbu FzxkrnHF+qcplfIhyGPyYp45dxG5saFPyzdp1UBWoVkGCVJrBHEIWHYi3iFdnYg= =Fx3B -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/e1xotau-0005oh...@franck.debian.org
