Your message dated Mon, 7 Jan 2019 10:14:33 +0100
with message-id <4f315c66-a9e1-a4e4-4e6a-fa042d22c...@debian.org>
and subject line Re: Bug#918379: please decide: severity of "fails to purge"
issues
has caused the Debian Bug report #918379,
regarding please decide: severity of "fails to purge" is
Hi Otto,
On 06/01/2019 16:08, Otto Kekäläinen wrote:
> Hello!
>
> I just realized that the upload of mariadb-10.3 into Debian includes
> the following transitions:
> - libmariadbd18 -> libmariadbd19
> - libmariadbclient18 becomes deprecated and fully replaced by the
> libmariadb3 library already
Your message dated Mon, 7 Jan 2019 10:21:50 +0100
with message-id <2fdb905d-3a89-a30b-0f78-ed1896269...@debian.org>
and subject line Re: Bug#918367: nmu: pam-mysql_0.8.0-1
has caused the Debian Bug report #918367,
regarding nmu: pam-mysql_0.8.0-1
to be marked as done.
This means that you claim tha
On 06/01/2019 13:11, Pirate Praveen wrote:
> [asking -release]
>
> On 1/6/19 5:31 PM, Pirate Praveen wrote:
>> Control: reopen -1
>>
>> On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?=
>> wrote:
>>>* Suggests npm - because nodejs must not be blocked by it.
>>> Closes: #918
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Dear Release Team,
I would like to update libnfs in unstable to the 3.0 version.
It is built for all release architectures in experimental except for
mips* but it is unlikely to have a
ma 7. tammik. 2019 klo 11.20 Emilio Pozuelo Monfort (po...@debian.org)
kirjoitti:
..
> https://packages.qa.debian.org/m/mariadb-10.3.html points to an autopkgtest
> failure on pam-mysql too, though that one doesn't seem to have a corresponding
> bug report yet.
That's right, there is no bug report
Hey Niels,
Thanks for the mail!
On Sun, Dec 30, 2018 at 07:13:00PM +, Niels Thykier wrote:
> Otherwise, check your britney configuration. If the path set for the
> "TESTING" configuration points to a standard APT mirror (with a Release
> file) you are unaffected by this mail. If it instead
On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote:
>
> [ Please note the cross-post and respect the Reply-To... ]
>
> Hi folks,
>
> This has taken a while in coming, for which I apologise. There's a lot
> of work involved in rebuilding the whole Debian archive, and many many
> hours spent analy
Your message dated Mon, 7 Jan 2019 13:57:24 +0100
with message-id <20190107125723.gm23...@mapreri.org>
and subject line Re: Bug#918372: unblock: med-fichier/4.0.0+repack-6
has caused the Debian Bug report #918372,
regarding unblock: med-fichier/4.0.0+repack-6
to be marked as done.
This means that
Your message dated Mon, 7 Jan 2019 14:16:31 +0100
with message-id <20190107131628.ga22...@mapreri.org>
and subject line Re: Bug#918136: RM: srtp/1.4.5~20130609~dfsg-2
has caused the Debian Bug report #918136,
regarding RM: srtp/1.4.5~20130609~dfsg-2
to be marked as done.
This means that you claim
Hi Niela!
Am So., 30. Dez. 2018 um 20:19 Uhr schrieb Niels Thykier :
>
> Hi,
>
> I am writing to you, because I know that you are (or have been) involved
> in setting up or maintaining a britney instance for a Debian derivative.
> If you are no longer involving please let me know who to contact
>
Your message dated Mon, 7 Jan 2019 18:35:30 +0200
with message-id <20190107163530.4hyqqtfv5lai2...@elgar.kardiogramm.net>
and subject line Re: Bug#891185: transition: re2
has caused the Debian Bug report #891185,
regarding transition: re2
to be marked as done.
This means that you claim that the pr
Control: tags -1 confirmed
On 06/01/2019 20:10, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> re2 is a C++ regex library, requiring about a transition a year, for
> various symbol changes.
>
> Only
Processing control commands:
> tags -1 confirmed
Bug #918501 [release.debian.org] transition: re2
Added tag(s) confirmed.
--
918501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918501
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 confirmed
On 06/01/2019 03:40, Simon Quigley wrote:
> On 1/4/19 3:50 AM, Emilio Pozuelo Monfort wrote:
>> On 27/12/2018 05:00, Simon Quigley wrote:
>>> On 12/26/18 3:39 AM, Emilio Pozuelo Monfort wrote:
On 24/12/2018 20:30, Simon Quigley wrote:
> Package: release.debian.o
Processing control commands:
> tags -1 confirmed
Bug #917255 [release.debian.org] transition: yaml-cpp
Added tag(s) confirmed.
--
917255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917255
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processing control commands:
> tags -1 confirmed
Bug #918308 [release.debian.org] transition: botan
Added tag(s) confirmed.
--
918308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 confirmed
On 07/01/2019 10:16, Bálint Réczey wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Dear Release Team,
>
> I would like to update libnfs in unstable to the 3.0 version.
>
> It is built fo
Control: tags -1 confirmed
On 04/01/2019 23:08, Laszlo Boszormenyi (GCS) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi RMs,
>
> It's a small transition with only three packages: biboumi,
> libqtshadowsocks and
Your message dated Mon, 7 Jan 2019 18:06:58 +0100
with message-id
and subject line Re: Bug#918029: transition: corosync
has caused the Debian Bug report #918029,
regarding transition: corosync
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the
Processing control commands:
> tags -1 confirmed
Bug #918539 [release.debian.org] mini-transition: libnfs
Added tag(s) confirmed.
--
918539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918539
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 confirmed
On 05/01/2019 11:29, Faidon Liambotis wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Release Team,
>
> This has been pending for a long time, and while the pieces have been
> mostly ther
Processing control commands:
> tags -1 confirmed
Bug #918341 [release.debian.org] transition: jemalloc
Added tag(s) confirmed.
--
918341: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918341
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Hi,
I am preparing an stretch-p-u upload of opensc/0.19.0-1~deb9u1 which is
essentially a trivial backport. What should the changelog look like --
should it be based on the 0.19.0-1 release or should it also contain the
0.16.0-3+deb9u1 which got us into this mess?
Cheers,
-Hilko
Hi Emilio (2019.01.07_19:05:02_+0200)
> Go ahead.
Thanks, uploaded.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
On Mon, 2019-01-07 at 18:49 +0100, Hilko Bengen wrote:
> I am preparing an stretch-p-u upload of opensc/0.19.0-1~deb9u1 which
> is essentially a trivial backport. What should the changelog look
> like -- should it be based on the 0.19.0-1 release or should it also
> contain the 0.16.0-3+deb9u1 whic
Iain Lane:
> Hey Niels,
>
> Thanks for the mail!
>
Hi Iain,
Thanks for your reply. :)
> On Sun, Dec 30, 2018 at 07:13:00PM +, Niels Thykier wrote:
>> Otherwise, check your britney configuration. If the path set for the
>> "TESTING" configuration points to a standard APT mirror (with a Rel
Hi Adam,
> That's rather large for a regression fix.
Agreed. I had previously tried fixing the patch that broke Yubikey NEO
support, but I was unsuccessful. This is documented in #910786.
I can understand concerns about updating the upstream version; the only
other option I see would involve rem
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
https://tracker.debian.org/pkg/console-setup
console-setup-freebsd/amd64 unsatisfiable Depends: vidcontrol
console-setup-freebsd/amd64 unsatisfiable Depends: kbdcontrol
uninstallable on arc
Hi,
On Mon, Jan 07, 2019 at 06:10:02PM +0100, Emilio Pozuelo Monfort wrote:
> > So, I'd like to ask for permission to upload jemalloc 5.1.0-2 to sid:
>
>
> Please go ahead.
Thank you Emilio & team, appreciate it! I've went ahead and uploaded
5.1.0-2, seems it was successfully built on most arch
On Mon, Jan 07, 2019 at 10:28:31AM +, Luke Kenneth Casson Leighton wrote:
> On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote:
> >
> > [ Please note the cross-post and respect the Reply-To... ]
> >
> > Hi folks,
> >
> > This has taken a while in coming, for which I apologise. There's a lot
On Tuesday, January 8, 2019, Mike Hommey wrote:
> .
>
> Note that Firefox is built with --no-keep-memory
> --reduce-memory-overheads, and that was still not enough for 32-bts
> builds. GNU gold instead of BFD ld was also given a shot. That didn't
> work either. Presently, to make things link at a
On Mon, Jan 07, 2019 at 11:46:41PM +, Luke Kenneth Casson Leighton wrote:
> On Tuesday, January 8, 2019, Mike Hommey wrote:
>
> > .
> >
> > Note that Firefox is built with --no-keep-memory
> > --reduce-memory-overheads, and that was still not enough for 32-bts
> > builds. GNU gold instead of
On Tuesday, January 8, 2019, Mike Hommey wrote:
> On Mon, Jan 07, 2019 at 11:46:41PM +, Luke Kenneth Casson Leighton
> wrote:
>
> > At some point apps are going to become so insanely large that not even
> > disabling debug info will help.
>
> That's less likely, I'd say. Debug info *is* getti
$ python evil_linker_torture.py 2000 50 100 200
ok so it's pretty basic, and arguments of "2000 50 10 100"
resulted in around a 10-15 second linker phase, which top showed to be
getting up to around the 2-3GB resident memory range. "2000 50 100
200" should start to make even a system
On Tue, Jan 8, 2019 at 6:27 AM Luke Kenneth Casson Leighton
wrote:
> i'm just running the above, will hit "send" now in case i can't hit
> ctrl-c in time on the linker phase... goodbye world... :)
$ python evil_linker_torture.py 2000 50 100 200
$ make -j8
oh, err... whoopsie... is this norm
$ python evil_linker_torture.py 3000 100 100 50
ok so that managed to get up to 1.8GB resident memory, paused for a
bit, then doubled it to 3.6GB, and a few seconds later successfully
outputted a binary.
i'm going to see if i can get above the 4GB mark by modifying the
Makefile to do 3,000 sh
On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton
wrote:
> i'm going to see if i can get above the 4GB mark by modifying the
> Makefile to do 3,000 shared libraries instead of 3,000 static object
> files.
fail. shared libraries link extremely quickly. reverted to static,
trying this
38 matches
Mail list logo
