Re: Next d-i release

[Steve McIntyre]

On Thu, Oct 20, 2016 at 02:05:25AM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2016-10-20):
>> >Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
>> >a new d-i release soonish. I'll probably freeze udebs in the upcoming
>> >hours or days, and try to figure out what to do with packages sitting
>> >in unstable for the time being.
>> 
>> Cool.
>
>FWIW I'll probably try not to get in the way of linux's reaching testing
>due to the security fix.

OK.

>> >Feel free to mention packages you want to see in testing, in case I go
>> >for a conservative approach (and only hand-pick a few packages); feel
>> >free to cc me explicitly to make sure I read your replies.
>> 
>> We should definitely get a newer debootstrap in before the release.
>> Nothing else really comes to mind right now.
>
>ACK. For merged-/usr support as mentioned in Ansgar's mail I suppose? Or
>do you have other things in mind?

That's the one I'm thinking of. Dunno if there's anything else queued
up, I've been buried for the last week and haven't had a chance to
look.

>> Once this release is done, I'd like to get the jessie update images
>> done. I think I'm there with the changes I need, but it needs:
>> 
>>  * a little more testing
>>  * d-i in backports
>>  * a list of packages to pull from backports
>
>Sure, but as far as I'm concerned: one step at a time…

ACK, just giving an update.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Re: Next d-i release

[Cyril Brulebois]

Steve McIntyre  (2016-10-20):
> >Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> >a new d-i release soonish. I'll probably freeze udebs in the upcoming
> >hours or days, and try to figure out what to do with packages sitting
> >in unstable for the time being.
> 
> Cool.

FWIW I'll probably try not to get in the way of linux's reaching testing
due to the security fix.

> >Feel free to mention packages you want to see in testing, in case I go
> >for a conservative approach (and only hand-pick a few packages); feel
> >free to cc me explicitly to make sure I read your replies.
> 
> We should definitely get a newer debootstrap in before the release.
> Nothing else really comes to mind right now.

ACK. For merged-/usr support as mentioned in Ansgar's mail I suppose? Or
do you have other things in mind?

> Once this release is done, I'd like to get the jessie update images
> done. I think I'm there with the changes I need, but it needs:
> 
>  * a little more testing
>  * d-i in backports
>  * a list of packages to pull from backports

Sure, but as far as I'm concerned: one step at a time…


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Steve McIntyre]

On Wed, Oct 19, 2016 at 03:33:03PM +0200, Cyril Brulebois wrote:
>Hi,
>
>Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
>a new d-i release soonish. I'll probably freeze udebs in the upcoming
>hours or days, and try to figure out what to do with packages sitting
>in unstable for the time being.

Cool.

>Feel free to mention packages you want to see in testing, in case I go
>for a conservative approach (and only hand-pick a few packages); feel
>free to cc me explicitly to make sure I read your replies.

We should definitely get a newer debootstrap in before the
release. Nothing else really comes to mind right now.

Once this release is done, I'd like to get the jessie update images
done. I think I'm there with the changes I need, but it needs:

 * a little more testing
 * d-i in backports
 * a list of packages to pull from backports

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#827061: transition: openssl

[Kurt Roeckx]

On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote:
> 
> I'm sorry but I'm going to have to nack this for Stretch, as much as I like to
> approve transitions and get new stuff in. I have looked at the opened bugs and
> I'm afraid this still is too disruptive. I have noticed that you have 
> forwarded
> some of them and sent patches, and I appreciate that. We can do this early in
> the Buster cycle, so let's look at the status of this and prepare for the
> transition when Stretch gets released.

Is having 2 version of OpenSSL in Stretch an option?

I could upload an openssl102 source package that provides an
libssl1.0.2-dev package, so that packages that aren't ready to
move to the 1.1.0 version can build-depend on that instead.


Kurt

Re: Xen in stretch - 4.7 or 4.8 ?

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Xen in stretch - 4.7 or 4.8 ?"):
> On 19/10/16 17:37, Ian Jackson wrote:
> > There are no changes between 4.7 and 4.8 that would upset any of the
> > rdeps.  So, great, thanks.
> 
> What about between 4.6 and 4.[78]? As we currently have 4.6 in the archive.

The 4.6 that is currently in stretch is in very bad shape.  It could
perhaps be fixed but I don't think it's a good idea.  It will have a
very limited upstream support lifetime.

But in any case I don't think 4.7 will be a problem for the rdeps
either.  I explicitly checked libvirt (which is the biggest risk) and
it's fine - although it will need a rebuild.

> > 
> > I don't know how long it will take me.  But I work for Citrix as part
> > of the Xen Project upstream, and this is currently my top priority.
> > So I'm hoping to have something RSN, in a matter of (working) days.
> 
> Great! Let us know when you have more news, preferably in a transition bug :-)

Ack.

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: samba_4.2.14+dfsg-0+deb8u1_armel.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_armhf.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_mipsel.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: samba_4.2.14+dfsg-0+deb8u1_mips.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: samba_4.2.14+dfsg-0+deb8u1_arm64.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_i386.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: samba_4.2.14+dfsg-0+deb8u1_s390x.changes
  ACCEPT

Re: Next d-i release

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Hi,
> 
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.
> 
> Feel free to mention packages you want to see in testing, in case I go
> for a conservative approach (and only hand-pick a few packages); feel
> free to cc me explicitly to make sure I read your replies.

The only pending changes in git (incl. l10n) are netcfg:

netcfg (1.140) unstable; urgency=medium

  [ Julien Cristau ]
  * Stop writing netmask/network/broadcast lines in /etc/network/interfaces,
just set the prefix length as part of the address (closes: #646860).


I have a ready upload if you're OK with it. It would then be the last
"bubulle automanual builder" upload until the D-I release


-- 





signature.asc
Description: PGP signature

Bug#839907: Minimal diff

[Daniel Lange]

I don't mind either way.

Attached is a minimal diff that will - of course - not make a current
build tool chain happy ("dh_builddeb: This package will soon FTBFS; time
to fix it!").

But it fixes the immediate issue of making the program usable again.


diff -Nru metar-20061030.1/debian/changelog metar-20061030.1/debian/changelog
--- metar-20061030.1/debian/changelog   2016-10-19 19:08:25.0 +0200
+++ metar-20061030.1/debian/changelog   2016-10-19 19:08:25.0 +0200
@@ -1,3 +1,10 @@
+metar (20061030.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Import patch for new METAR URL from Kees Leune (Closes: #839907)
+
+ -- Daniel Lange   Wed, 19 Oct 2016 19:00:00 +0200
+
 metar (20061030.1-2) unstable; urgency=low
 
   * Build-Depends on libcurl3-gnutls-dev instead of libcurl3-dev
diff -Nru metar-20061030.1/src/metar.h metar-20061030.1/src/metar.h
--- metar-20061030.1/src/metar.h2006-04-05 22:30:28.0 +0200
+++ metar-20061030.1/src/metar.h2016-10-19 19:08:25.0 +0200
@@ -24,7 +24,7 @@
 #define  METAR_MAXSIZE 512
 
 /* where to fetch reports */
-#define  METARURL 
"http://weather.noaa.gov/pub/data/observations/metar/stations;
+#define  METARURL "http://tgftp.nws.noaa.gov/data/observations/metar/stations;
 
 /* clouds */
 typedef struct {

Re: Xen in stretch - 4.7 or 4.8 ?

[Emilio Pozuelo Monfort]

On 19/10/16 17:37, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: Xen in stretch - 4.7 or 4.8 ?"):
>> On 19/10/16 16:54, Ian Jackson wrote:
>>> Sorry to hassle you, but I would appreciate an opinion so that I can
>>> get started on the integration work etc.
>>
>> Assuming the rdeps are fine with Xen 4.8, then I'd be all for moving
>> to it.
> 
> There are no changes between 4.7 and 4.8 that would upset any of the
> rdeps.  So, great, thanks.

What about between 4.6 and 4.[78]? As we currently have 4.6 in the archive.

>> Xen is a security sensitive package and I think it'd be good
>> to get the extra security support from upstream. Note the transition
>> freeze will start soon. Do you have an idea of how long it may take
>> to prepare for this?
> 
> I don't know how long it will take me.  But I work for Citrix as part
> of the Xen Project upstream, and this is currently my top priority.
> So I'm hoping to have something RSN, in a matter of (working) days.

Great! Let us know when you have more news, preferably in a transition bug :-)

Cheers,
Emilio

Re: Xen in stretch - 4.7 or 4.8 ?

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Xen in stretch - 4.7 or 4.8 ?"):
> On 19/10/16 16:54, Ian Jackson wrote:
> > Sorry to hassle you, but I would appreciate an opinion so that I can
> > get started on the integration work etc.
> 
> Assuming the rdeps are fine with Xen 4.8, then I'd be all for moving
> to it.

There are no changes between 4.7 and 4.8 that would upset any of the
rdeps.  So, great, thanks.

> Xen is a security sensitive package and I think it'd be good
> to get the extra security support from upstream. Note the transition
> freeze will start soon. Do you have an idea of how long it may take
> to prepare for this?

I don't know how long it will take me.  But I work for Citrix as part
of the Xen Project upstream, and this is currently my top priority.
So I'm hoping to have something RSN, in a matter of (working) days.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Xen in stretch - 4.7 or 4.8 ?

[Emilio Pozuelo Monfort]

On 19/10/16 16:54, Ian Jackson wrote:
> Ian Jackson writes ("Xen in stretch - 4.7 or 4.8 ?"):
>> Hi.  I was wanting an initial opinion from the Release Team, about the
>> Xen packages.  Currently they are in bad shape in stretch and I intend
>> to fix them ASAP.
>>
>> The question is whether I should move to Xen 4.7, or Xen 4.8.
> 
> I just asked the Xen Project's Release Manager and their current best
> guess is that Xen 4.8.0 will be released in "early to mid November".
> 
> Sorry to hassle you, but I would appreciate an opinion so that I can
> get started on the integration work etc.

Assuming the rdeps are fine with Xen 4.8, then I'd be all for moving to it. Xen
is a security sensitive package and I think it'd be good to get the extra
security support from upstream. Note the transition freeze will start soon. Do
you have an idea of how long it may take to prepare for this?

Cheers,
Emilio

Processed: Re: Bug#836795: jessie-pu: package samba/2:4.1.17+dfsg-2+deb8u2

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #836795 [release.debian.org] jessie-pu: package samba/2:4.1.17+dfsg-2+deb8u2
Added tag(s) pending.

-- 
836795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836795
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#836795: jessie-pu: package samba/2:4.1.17+dfsg-2+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On 2016-09-24 20:14, Adam D. Barratt wrote:

Control: tags -1 -moreinfo +confirmed

On Mon, 2016-09-05 at 20:50 +, Jelmer Vernooij wrote:
I'd like to update Samba in jessie to 4.2.14+dfsg. Debdiff is 
attached.


The 4 Samba releases since 4.2.10 (currently in jessie) only fix
important bugs, in particular a CVE (CVE-2016-2119) and various
regressions introduced by the security fixes from 4.2.10.


Please go ahead, with the changelog distribution set to "jessie".


Uploaded and flagged for acceptance.

Regards,

Adam

Re: Xen in stretch - 4.7 or 4.8 ?

[Ian Jackson]

Ian Jackson writes ("Xen in stretch - 4.7 or 4.8 ?"):
> Hi.  I was wanting an initial opinion from the Release Team, about the
> Xen packages.  Currently they are in bad shape in stretch and I intend
> to fix them ASAP.
> 
> The question is whether I should move to Xen 4.7, or Xen 4.8.

I just asked the Xen Project's Release Manager and their current best
guess is that Xen 4.8.0 will be released in "early to mid November".

Sorry to hassle you, but I would appreciate an opinion so that I can
get started on the integration work etc.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: samba_4.2.14+dfsg-0+deb8u1_multi.changes
  ACCEPT

Next d-i release

[Cyril Brulebois]

Hi,

Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
a new d-i release soonish. I'll probably freeze udebs in the upcoming
hours or days, and try to figure out what to do with packages sitting
in unstable for the time being.

Feel free to mention packages you want to see in testing, in case I go
for a conservative approach (and only hand-pick a few packages); feel
free to cc me explicitly to make sure I read your replies.


KiBi.


signature.asc
Description: Digital signature

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: quagga_0.99.23.1-1+deb8u3_allonly.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_amd64.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_arm64.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_armel.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_armhf.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_i386.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_mips.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_mipsel.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_powerpc.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_ppc64el.changes
  ACCEPT
Processing changes file: quagga_0.99.23.1-1+deb8u3_s390x.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_debian.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_amd64.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_arm64.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_armel.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_armhf.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_i386.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_mips.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_mipsel.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_powerpc.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_ppc64el.changes
  ACCEPT
Processing changes file: tor_0.2.5.12-3_s390x.changes
  ACCEPT

Re: ppc64el porter situation

[Breno Leitao]

Hello Adrian,

Let me share my view as the only DD listed as ppc64el porter.

On Mon, Oct 17, 2016 at 10:50:01PM +0300, Adrian Bunk wrote:
> Is a DM enough, if the only DD gets killed by a car [2] the day after
> the release of stretch?

The other DM is in the process of becoming a DD[1]. This might reduce
the truck factor by half.

[1] https://nm.debian.org/person/frediz

> Second, all 4 committed porters seem to be employees of IBM.
>
> What happens if for whatever good or bad reason IBM decides in 2018
> or 2019 to go away from ppc64el, and all 4 committed porters get fired?

I understand your point here. ppc64el architecture is IBM's current and
future focus. ppc64el is also planned for POWER9 and beyond. While it's
hard to predict what future business decisions IBM may make, we believe
the future of ppc64el and OpenPower systems looks good.

There are many other distros that support ppc64el at this moment, as
Ubuntu, Fedora, SLES, RHEL and others coming. So, your point is not
Debian specific, but, generic to the Linux ecossystem.

> The wording of the porter commitment is already limited to "I intend
> to", and there is the single point of failure that one business
> decision by IBM might reduce the number of porters immediately from 4
> to 0.

Right, since ppc64el machines are not desktop/personal machines, it is
harder to get porters, compared to more pervasive architectures, as amd64.
I hope to have more DD porters in the future, as ppc64el become more
prevalent.

lso, there are many other hardware manufactors and partners that relies
on Linux for the Power platform[1]. In my opinion, the Power platform is
bigger than IBM at this moment.

[1] http://openpowerfoundation.org/membership/current-members/

> Third, the skills of the committed porters for post-release work.
>
> It is extremely valuable when people are doing manual and automated
> testing and fix the usual porting issues prior to the release.
>
> But the most important skills required post-release until end-2020 are
> quite different.
>
> How many of the committed ppc64el porters are personally able to fix
> difficult issues that require intimate knowledge of hardware, kernel
> and toolchain?

I understand that it is going to be hard to find a developer that is
able to fix difficult issues on kernel/toolchain, we are relying and
supported by differents team doing Kernel, virtualization, toolchain,
optimization, etc.  On situations we are not skilled enough to work on,
we have these other teams support.

This is shown by the amount of package that was ported to ppc64el[2].
We, the Debian porters, didn't do it by ourself, but we counted on
different teams doing their work on each area, as from package
optimizations to toolchain enablement.

On the other side, if there is a requirements for being a porter that
says that the porter might be able to fix difficult issues on kernel and
toolchain, then it is a different story. I do not believe that this
requirement exists.

[2] https://buildd.debian.org/stats/

Also I assure you I have personal interest in Debian success

Re: ppc64el porter situation

[Aurelien Jarno]

Hi,

On 2016-10-17 22:50, Adrian Bunk wrote:
> Disclaimer:
> I am not a member of the release team, and I am only speaking for myself.
> 
> 
> The architecture requalification status for stretch [1] lists the 
> ppc64el porter situation as green, but there are three reasons why
> the situation doesn't look that good to me.
> 
> 
> First, official status of the porters:
> - 1 DD
> - 1 DM
> - 2 no DD/DM
> 
> Is a DM enough, if the only DD gets killed by a car [2] the day after 
> the release of stretch?

I am actually not sure it makes a lot of difference being DD or DM or
even not a DD/DM. What is important is that issues are fixed, that 
patches are provided. For that you need access to the knowledge and
access to the hardware, not upload or vote rights.
 
> Second, all 4 committed porters seem to be employees of IBM.

That's true, but they are from two different teams in two different
countries.

> What happens if for whatever good or bad reason IBM decides in 2018
> or 2019 to go away from ppc64el, and all 4 committed porters get fired?
> 
> The wording of the porter commitment is already limited to "I intend to",
> and there is the single point of failure that one business decision
> by IBM might reduce the number of porters immediately from 4 to 0.

I think it's unlikely to happen, and even if that happens the porters
might continue to work on Debian on their personal time.

> Third, the skills of the committed porters for post-release work.
> 
> It is extremely valuable when people are doing manual and automated 
> testing and fix the usual porting issues prior to the release.
> 
> But the most important skills required post-release until end-2020 are 
> quite different.
> 
> How many of the committed ppc64el porters are personally able to fix
> difficult issues that require intimate knowledge of hardware, kernel
> and toolchain?

The 4 porters have been working on ppc64el for years, they have done the
initial bootstrapping outside of Debian, they have done the initial
bootstrap in Debian, they have participated in the release of Jessie and
they have sent hundred of patches in the BTS.

To me it looks like they are really skilled for that job. Do you have
actual facts showing the contrary?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#840927: nmu: llvm-toolchain-3.8_1:3.8.1-12

[Andreas Beckmann]

On Mon, 17 Oct 2016 00:38:00 +0200 Emilio Pozuelo Monfort
 wrote:
> I
> think the problem was that #839033's subject mentioned mips64el, but that
> information was outdated, and that confused the ftp team member. The fact that
> llvm-toolchain-snapshot builds versioned binaries that later get taken over by
> llvm-toolchain-X.Y didn't help here.

Hi,

I originally filed #839033 and included mips64el in the list. I just
noticed that I still had the dak output from that time in the history,
and according to that I didn't expect any problems:

anbe@coccia:~$ dak rm -Rn -a mips64el llvm-toolchain-snapshot
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

clang-modernize-3.8 | 1:3.8~svn254193-1 | mips64el
llvm-toolchain-snapshot | 1:3.7~svn230892-1 | source
llvm-toolchain-snapshot | 1:3.8~svn247576-1 | source
llvm-toolchain-snapshot | 1:3.8~svn254193-1 | source
llvm-toolchain-snapshot | 1:4.0~svn279916-1 | source
python-lldb-3.8 | 1:3.8~svn254193-1 | mips64el

Maintainer: LLVM Packaging Team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas

Bug#840927: marked as done (nmu: llvm-toolchain-3.8_1:3.8.1-12)

[Debian Bug Tracking System]

Your message dated Wed, 19 Oct 2016 07:07:46 + (UTC)
with message-id <1114567532.5943092.1476860866...@mail.yahoo.com>
and subject line Re: Bug#840927: nmu: llvm-toolchain-3.8_1:3.8.1-12
has caused the Debian Bug report #840927,
regarding nmu: llvm-toolchain-3.8_1:3.8.1-12
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
840927: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840927
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu llvm-toolchain-3.8_1:3.8.1-12 . mips64el . unstable . -m "rebuild to fix 
wrongly removed binaries (cfr: #839033)"

yes, such packages have been wrongly removed with the llvm-toolchain-snapshot 
decruft.

And now they are preventing 3.8 from migration.
Please binNMU them when you got why they have been removed, or whenever you 
prefer


thanks

Gianfranco
--- End Message ---
--- Begin Message ---
>Mostly I wanted ftpteam to know about this and maybe patch dak rm to

>not remove stuff from different versions, or something to that effect.


closing then :)

thanks for fixing llvm!

G.--- End Message ---

Bug#840927: nmu: llvm-toolchain-3.8_1:3.8.1-12

[Julien Cristau]

On Mon, Oct 17, 2016 at 00:38:00 +0200, Emilio Pozuelo Monfort wrote:

> Keeping this bug opened here as Julien wanted to look at how we got here. I

Mostly I wanted ftpteam to know about this and maybe patch dak rm to
not remove stuff from different versions, or something to that effect.

Cheers,
Julien

Re: final decision about MySQL r-deps needed / cleaning up the MySQL mess

[Rene Engelhard]

Hi,

On Wed, Oct 19, 2016 at 08:26:22AM +1100, Dmitry Smirnov wrote:
> On Monday, 17 October 2016 9:01:24 PM AEDT Rene Engelhard wrote:
> > This means I'll orphan mysql-connector-c++ (well, remove myself from
> > Uploaders:, which makes it having no Uploader at all). Dmitry, if you
> > want/need it for mysql-connector-c++ feel free to add yourself and upload
> > 1.1.7 to whatever you want and it actually works.
> 
> (Eventually) I'll see what I can do but at the moment I have no capacity to 
> take care of mysql-connector-c++... Is there a public repository for its 
> packaging anywhere?

No, there's something at pkg-mysql but it's outdated. What is in 
sid/experimental
is what is current.

Regards,

Rene