Bug#831847: nmu: dovecot-antispam_2.0+20150222-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Could you please schedule a binnmu for dovecot-antispam, in order for it to be built against dovecot 2.2.25? Thanks, Apollon nmu dovecot-antispam_2.0+20150222-1 . ANY . unstable . -m "Rebuild against newer dovecot" dw dovecot-antispam_2.0+20150222-1 . ANY . unstable . -m "dovecot-dev (>= 1:2.2.25-1)"
Processed: Re: Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
Processing control commands:
> reopen -1
Bug #831699 {Done: Julien Cristau } [release.debian.org]
release.debian.org: urgency is sticky across dists - low urgency on sid upload
ignored after previous experimental medium-urgency upload
Bug reopened
Ignoring request to alter fixed versions of bug #831699 to the same values
previously set
> clone -1 -2
Bug #831699 [release.debian.org] release.debian.org: urgency is sticky across
dists - low urgency on sid upload ignored after previous experimental
medium-urgency upload
Bug 831699 cloned as bug 831834
> reassign -2 ftp.debian.org
Bug #831834 [release.debian.org] release.debian.org: urgency is sticky across
dists - low urgency on sid upload ignored after previous experimental
medium-urgency upload
Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'.
Ignoring request to alter found versions of bug #831834 to the same values
previously set
Ignoring request to alter fixed versions of bug #831834 to the same values
previously set
> retitle -2 [dak] Include suite information in UrgencyLog
Bug #831834 [ftp.debian.org] release.debian.org: urgency is sticky across dists
- low urgency on sid upload ignored after previous experimental medium-urgency
upload
Changed Bug title to '[dak] Include suite information in UrgencyLog' from
'release.debian.org: urgency is sticky across dists - low urgency on sid upload
ignored after previous experimental medium-urgency upload'.
> block -1 by -2
Bug #831699 [release.debian.org] release.debian.org: urgency is sticky across
dists - low urgency on sid upload ignored after previous experimental
medium-urgency upload
831699 was not blocked by any bugs.
831699 was not blocking any bugs.
Added blocking bug(s) of 831699: 831834
--
831699: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831699
831834: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831834
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
Control: reopen -1 Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 [dak] Include suite information in UrgencyLog Control: block -1 by -2 On Tue, Jul 19, 2016 at 07:53:00PM +, Niels Thykier wrote: > Adam D. Barratt: > > On Tue, 2016-07-19 at 15:40 +0200, Goswin von Brederlow wrote: > >> On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote: > > [...] > >>> Testing has 2016.0.0+dfsg-1, which was followed by > >>> [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) > >>> [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) > >>> [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) > >>> > >>> britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium > >>> urgency and chose to consider this urgency for sid->testing migration. > > [...] > >> Does it remember or does it parse the changelog and use the highest > >> priority since the version in testing? The hugin changelog contains > >> the urgency=medium entry so this seems a valid urgency to use. > > > > britney knows nothing about changelogs. The input is a strictly > > chronological (in terms of when dak accepted the package) list of source > > package name, version and urgency tuples for all uploads to the main > > archive. > > > > Regards, > > > > Adam > > > > For the people interested, the input data is available from [1]. If you > want it changed, it will need to be fixed in dak (producer) and Britney > (as the consumer). I think that's the proper fix for this and I would prefer to avoid adding even more special-casing code to dch. > From my PoV: Patches welcome and will gladly help people, who are > interested in it. I don't expect to have time to fix it myself any time > soon - but as I said; I will gladly help people getting started. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB signature.asc Description: PGP signature
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
Adam D. Barratt: > On Tue, 2016-07-19 at 15:40 +0200, Goswin von Brederlow wrote: >> On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote: > [...] >>> Testing has 2016.0.0+dfsg-1, which was followed by >>> [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) >>> [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) >>> [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) >>> >>> britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium >>> urgency and chose to consider this urgency for sid->testing migration. > [...] >> Does it remember or does it parse the changelog and use the highest >> priority since the version in testing? The hugin changelog contains >> the urgency=medium entry so this seems a valid urgency to use. > > britney knows nothing about changelogs. The input is a strictly > chronological (in terms of when dak accepted the package) list of source > package name, version and urgency tuples for all uploads to the main > archive. > > Regards, > > Adam > For the people interested, the input data is available from [1]. If you want it changed, it will need to be fixed in dak (producer) and Britney (as the consumer). From my PoV: Patches welcome and will gladly help people, who are interested in it. I don't expect to have time to fix it myself any time soon - but as I said; I will gladly help people getting started. Thanks, ~Niels [1] https://ftp-master.debian.org/britney/urgencies/
Bug#831810: transition: libmicrohttpd
On 19/07/16 19:01, Bertrand Marc wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > Please allow the transition from libmicrohttpd10 to libmicrohttpd12. > libmicrohttpd12 (0.9.50-1) is currently in experimental. The auto tracker > seems correct [1]. > With this new version libmicrospdy goes away (dead upstream, no r-deps), so > does the libssl-dev build-dependency. This could avoid some conflicts with > the openssl transition. > > Among the reverse build-dependencies I was able to build: > - gnunet > - libjson-rpc-cpp > - opensips > - psensor > - yubikey-server-c > - bfgminer > > Since I use a quite old laptop, I had difficulties to build (both with > libmicrohttpd10 and libmicrohttp12): > - systemd > - kodi > - ola (sid only) > - pcp > - varnish-agent (sid only) > Do you know if I could have access to a testing build infrastructure ? You can ask someone (your sponsor) to request access to a porterbox for you. Other than that, I don't know. In lack of that, do you know how much the ABI changed? Cheers, Emilio
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
On Tue, 2016-07-19 at 15:40 +0200, Goswin von Brederlow wrote: > On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote: [...] > > Testing has 2016.0.0+dfsg-1, which was followed by > > [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) > > [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) > > [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) > > > > britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium > > urgency and chose to consider this urgency for sid->testing migration. [...] > Does it remember or does it parse the changelog and use the highest > priority since the version in testing? The hugin changelog contains > the urgency=medium entry so this seems a valid urgency to use. britney knows nothing about changelogs. The input is a strictly chronological (in terms of when dak accepted the package) list of source package name, version and urgency tuples for all uploads to the main archive. Regards, Adam
Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
On Tue, 2016-07-19 at 16:56 +, Gianfranco Costamagna wrote: > >Who are these "quite a few users"? Where are they being confused? > > > because they used to have an iceweasel package, and now they have a firefox > instead > (different desktop file, different branding) You're answering a different question, namely "why". I was asking for some information / pointers as to how you know they're being confused. Presumably there are several mailing list posts, IRC conversations, etc. > >> With this in stable, we can say to anyone who wants to keep Iceweasel: > >> "Run this command: > >> sudo apt-get install xul-ext-iceweasel-branding" > >> > >> Without bothering about backports. > > > >I understand the idea. I'm just not sure why this package is so special > >that they shouldn't "bother with backports". > > > the change iceweasel/firefox is in proposed-updates, so I proposed to have > the package in the same suite It's only in proposed-updates because it was in stable-security. This is not a change that was made via p-u. > >The relevant bits of that bug appear to be confused between the security > >archive, proposed-updates and stable-updates, which is unfortunate. > >(e.g. there is no firefox or iceweasel package in jessie-updates, nor > >has there ever been one.) > > > I'm not sure I follow here, but I tried to call rmadison on my machine > (I might have given the wrong command, sorry in advance) > > son -u debian firefox-esr > firefox-esr | 45.2.0esr-1~deb8u1 | proposed-updates | source, amd64, arm64, > armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x > firefox-esr | 45.2.0esr-1| testing | source, amd64, arm64, > armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x > firefox-esr | 45.2.0esr-1| unstable | source, amd64, arm64, > armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, > ppc64el, s390x You've just agreed with me. :-) The log for #815006 includes "I see esr is in wheezy-updates and jessie-updates, not backports." which your paste has clearly demonstrated is incorrect. (It's in security.d.o:wheezy/updates, security.d.o:jessie/updates and as a side-effect of the latter also in jessie-proposed-updates. It's in neither of wheezy-updates or jessie-updates.) > so, my proposal was to upload firefox-branding-iceweasel to proposed-updates > > (security is OT here, and I don't want to discuss that suite here) I don't see how it can possibly be off-topic. You're discussing a package that's intended to allow users to revert changes made in a package that _was released via the security archive_. > >I suspect we disagree as to whether this is a "bug" to begin with. > > > >It was an intentional choice on the part of the maintainers and the > >security team, and was announced in the corresponding DSA. Are there > >really users who aren't reading DSAs but are happy to install software > >as root just because you told them to? > > > there might be users that wants their name back, not sure who they are, > I don't want to have to answer here, but I still think giving users the choice > is something sane that might avoid troubles or complains. Sure. As I said, I'm not disagreeing with the concept, just whether p-u is the right means of delivering it. (and, no, "the change is in p-u" isn't an argument, as above - the change is in security, it just happens to be copied to p-u.) Regards, Adam
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
On 2016-07-19 Julien Cristau wrote: > On Mon, Jul 18, 2016 at 18:51:33 +0100, Adam D. Barratt wrote: > > On Mon, 2016-07-18 at 19:41 +0200, Andreas Metzler wrote: [...] >>> britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium >>> urgency and chose to consider this urgency for sid->testing migration. >>> >>> I think that is a bug, especially as dch uses medium by default for >>> uploads to experimental. [...] > Closing as not a bug. Hello, Ok, I will accept this, seems there is a judgement call involved. It seemed crystal clear to me that testing propagation using the priority of uploads to experimental was a bug. Simply because uploads to experimental *never* are subject to testing propagation, testing propagation checking only starts with the sid upload. I will try to get dch changed to use low priority for experimental uploads. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
Hi, >If they're interested, they can follow the bug. They don't all need to >be CCed on every message. Indeed, I follow the bug :) and I propose to drop the cc in the next message >Who are these "quite a few users"? Where are they being confused? because they used to have an iceweasel package, and now they have a firefox instead (different desktop file, different branding) >> With this in stable, we can say to anyone who wants to keep Iceweasel: >> "Run this command: >> sudo apt-get install xul-ext-iceweasel-branding" >> >> Without bothering about backports. > >I understand the idea. I'm just not sure why this package is so special >that they shouldn't "bother with backports". the change iceweasel/firefox is in proposed-updates, so I proposed to have the package in the same suite >The relevant bits of that bug appear to be confused between the security >archive, proposed-updates and stable-updates, which is unfortunate. >(e.g. there is no firefox or iceweasel package in jessie-updates, nor >has there ever been one.) I'm not sure I follow here, but I tried to call rmadison on my machine (I might have given the wrong command, sorry in advance) son -u debian firefox-esr firefox-esr | 45.2.0esr-1~deb8u1 | proposed-updates | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x firefox-esr | 45.2.0esr-1| testing | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x firefox-esr | 45.2.0esr-1| unstable | source, amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x so, my proposal was to upload firefox-branding-iceweasel to proposed-updates (security is OT here, and I don't want to discuss that suite here) >I suspect we disagree as to whether this is a "bug" to begin with. > >It was an intentional choice on the part of the maintainers and the >security team, and was announced in the corresponding DSA. Are there >really users who aren't reading DSAs but are happy to install software >as root just because you told them to? there might be users that wants their name back, not sure who they are, I don't want to have to answer here, but I still think giving users the choice is something sane that might avoid troubles or complains. Just my .02$ G.
Bug#831810: transition: libmicrohttpd
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, Please allow the transition from libmicrohttpd10 to libmicrohttpd12. libmicrohttpd12 (0.9.50-1) is currently in experimental. The auto tracker seems correct [1]. With this new version libmicrospdy goes away (dead upstream, no r-deps), so does the libssl-dev build-dependency. This could avoid some conflicts with the openssl transition. Among the reverse build-dependencies I was able to build: - gnunet - libjson-rpc-cpp - opensips - psensor - yubikey-server-c - bfgminer Since I use a quite old laptop, I had difficulties to build (both with libmicrohttpd10 and libmicrohttp12): - systemd - kodi - ola (sid only) - pcp - varnish-agent (sid only) Do you know if I could have access to a testing build infrastructure ? pcp has a RC bug, but it is marked for autoremoval from testing on 2016-08-03. kodi has also a RC bug, but it is marked for autoremoval from testing on 2016-08-13. Last things: please note that I do not have uploads rights yet, but it should only be a matter of time [2], and that I will not have internet access between July, 23 and August, 7. Best regards, Bertrand Marc [1] https://release.debian.org/transitions/html/auto-libmicrohttpd.html [2] https://nm.debian.org/public/process/bmarc Ben file: title = "libmicrohttpd"; is_affected = .depends ~ /(libmicrohttpd\-dbg|libmicrohttpd10|libmicrospdy\-dbg|libmicrospdy\-dev|libmicrospdy0)/ | .depends ~ /libmicrohttpd12/; is_good = .depends ~ /libmicrohttpd12/; is_bad = .depends ~ /(libmicrohttpd\-dbg|libmicrohttpd10|libmicrospdy\-dbg|libmicrospdy\-dev|libmicrospdy0)/; -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
[forgot to CC release] On 2016-07-19 16:47, nord-stream wrote: With this in stable, we can say to anyone who wants to keep Iceweasel: "Run this command: sudo apt-get install xul-ext-iceweasel-branding" Why is the compatibility symlink shipped in the iceweasel package insufficient? If this is just about the title of the window that appears, I'm not sure that's a thing worth going to these lengths to deal with. I do have some sympathy with the branding suddenly changing in stable and causing some immediate confusion, but it's really not the end of the world and quite straightforward to understand. It's long been known that browsers are a moving target for stable. Without bothering about backports. It is just a rare exception. I don't understand where backports comes into this. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits
Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
On 2016-07-19 16:47, nord-stream wrote: With this in stable, we can say to anyone who wants to keep Iceweasel: "Run this command: sudo apt-get install xul-ext-iceweasel-branding" Why is the compatibility symlink shipped in the iceweasel package insufficient? If this is just about the title of the window that appears, I'm not sure that's a thing worth going to these lengths to deal with. I do have some sympathy with the branding suddenly changing in stable and causing some immediate confusion, but it's really not the end of the world and quite straightforward to understand. It's long been known that browsers are a moving target for stable. Without bothering about backports. It is just a rare exception. I don't understand where backports comes into this. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits
Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
On 2016-07-19 16:47, nord-stream wrote: On 18/07/16 17:57, Adam D. Barratt wrote: [Why is this CCed to quite so many places / people?] Sponsor, reviewer, related package maintainers... If they're interested, they can follow the bug. They don't all need to be CCed on every message. [...] It's because the package is part of the follow-up UX work of firefox-esr's migration into jessie, targeted at a significant portion of general stable Debian users. (I'm sorry for the delay) People who don't use backports have got firefox-esr. Quite a few users seem confused. This is important for consistency and usability. Who are these "quite a few users"? Where are they being confused? With this in stable, we can say to anyone who wants to keep Iceweasel: "Run this command: sudo apt-get install xul-ext-iceweasel-branding" Without bothering about backports. I understand the idea. I'm just not sure why this package is so special that they shouldn't "bother with backports". It is just a rare exception. Quote (from 815...@bugs.debian.org and pkg-mozilla-maintain...@lists.alioth.debian.org lists): The relevant bits of that bug appear to be confused between the security archive, proposed-updates and stable-updates, which is unfortunate. (e.g. there is no firefox or iceweasel package in jessie-updates, nor has there ever been one.) (Also there's no such thing as "pockets" in Debian, that's a Launchpadism. They're called suites, or distributions if you must.) On 15/06/16 14:06, Gianfranco Costamagna wrote: the "bug" is introduce with a stable-release-update, and should be fixed with another s-p-u I suspect we disagree as to whether this is a "bug" to begin with. It was an intentional choice on the part of the maintainers and the security team, and was announced in the corresponding DSA. Are there really users who aren't reading DSAs but are happy to install software as root just because you told them to? Regards, Adam
Bug#831447: firefox-branding-iceweasel 0.4.0 MIGRATED to testing
On 18/07/16 17:57, Adam D. Barratt wrote: > [Why is this CCed to quite so many places / people?] Sponsor, reviewer, related package maintainers... > A debdiff between two versions of the package is not that helpful to > convince anyone that the new version should be added to stable, given > that no version is currently in stable. I'm aware of that. ;) > As a more general note, adding packages to stable is something that's > done very sparingly and at least this SRM would need more convincing > that it should be done - rather than, say, using jessie-backports - than > "it's important". I understand that and I don't intend to make such a request regularly. It's because the package is part of the follow-up UX work of firefox-esr's migration into jessie, targeted at a significant portion of general stable Debian users. (I'm sorry for the delay) People who don't use backports have got firefox-esr. Quite a few users seem confused. This is important for consistency and usability. With this in stable, we can say to anyone who wants to keep Iceweasel: "Run this command: sudo apt-get install xul-ext-iceweasel-branding" Without bothering about backports. It is just a rare exception. Quote (from 815...@bugs.debian.org and pkg-mozilla-maintain...@lists.alioth.debian.org lists): On 15/06/16 14:06, Gianfranco Costamagna wrote: > the "bug" is introduce with a stable-release-update, and should be fixed > with another s-p-u Thank you for the reply. nord-stream signature.asc Description: OpenPGP digital signature
Processed: closing 831699
Processing commands for cont...@bugs.debian.org: > close 831699 Bug #831699 [release.debian.org] release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 831699: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831699 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
On Mon, Jul 18, 2016 at 07:41:54PM +0200, Andreas Metzler wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: britney > > Hello, > > I have been wondering why hugin 2016.2.0~rc1+dfsg-2 (urgency=low) will > be considered for testing migration after only 5 days and I think I found > the reason. > > Testing has 2016.0.0+dfsg-1, which was followed by > [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) > [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) > [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) > > britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium > urgency and chose to consider this urgency for sid->testing migration. > > I think that is a bug, especially as dch uses medium by default for > uploads to experimental. > > cu Andreas Does it remember or does it parse the changelog and use the highest priority since the version in testing? The hugin changelog contains the urgency=medium entry so this seems a valid urgency to use. MfG Goswin
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored after previous experimental medium-urgency upload
On Mon, Jul 18, 2016 at 18:51:33 +0100, Adam D. Barratt wrote: > On Mon, 2016-07-18 at 19:41 +0200, Andreas Metzler wrote: > > I have been wondering why hugin 2016.2.0~rc1+dfsg-2 (urgency=low) will > > be considered for testing migration after only 5 days and I think I found > > the reason. > > > > Testing has 2016.0.0+dfsg-1, which was followed by > > [2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low) > > [2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low) > > [2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium) > > > > britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium > > urgency and chose to consider this urgency for sid->testing migration. > > > > I think that is a bug, especially as dch uses medium by default for > > uploads to experimental. > > (dch uses medium by default for uploads to /all/ suites.) > > It's a feature, specifically because the information that britney has > about urgencies (via dak) is of the form: > > dm-writeboost 2.2.1-1 medium > libapache-mod-auth-kerb 5.4-2.3 medium > > i.e. there's no mention of suite. I don't know whether anything other > than britney uses the data; if not then I guess it would be a simple dak > patch to add the suite data if desired. > Closing as not a bug. Cheers, Julien
Geniet van gratis installatie en 5 jaren gratis bellen
Sync Solutions: tot 50% goedkoper dan een Proximus abonnement GRATIS installatie + GRATIS bellen gedurende 5 jaren Ontdek onze nieuwe Unify telefooncentrale, gebruiksvriendelijk en remote management voor de gebruiker. Ontvang gratis uw offerte: http://www.kapamedia.eu/sync-solutions-49/form.htm?lng=nl&tg=sync&utm_campaign=sync&utm_source=admr&utm_medium=email&you=debian-release@lists.debian.org We kopen uw oude telecom-apparatuur over - Keuzemenu in studio opgenomen - Fax to Mail Solution - Interventie binnen 4 uur, 7 op 7 SyncSolutions groep realiseert een omzet van € 9.500.000, en bestaat uit 60 medewerkers op 4 locaties, Brussel, Luik, Gent en Bergen. Sync Solutions biedt een totale oplossing voor bedrijven en beheert uw telefoonapparatuur, uw telefoonlijnen, uw internet, uw gsm-vloot, en de beveiliging van uw computerdata. Een consultant kan langskomen en een gratis en vrijblijvend analyse maken! --- Online versie: http://kapateco.fb.kp.kpmail.be/c53/e4753761/h1b250/l2247/index.html Deze e-mail werd verstuurd naar debian-release@lists.debian.org. Profiel aanpassen: http://kapateco.fb.kp.kpmail.be/c53/e4753761/h1b250/l2249/index.html Uitschrijven: http://kapateco.fb.kp.kpmail.be/c53/e4753761/h1b250/l2248/index.html Privacy policy: http://kapateco.fb.kp.kpmail.be/c53/e4753761/h1b250/l2250/index.html Powered by Addemar: http://poweredby.addemar.com/
