On 16.03.24 18:41, Steven Robbins wrote:
This recent transition has really illuminated how little I know of the dark
corners of Debian infrastructure...
Some packages (e.g. libcdk5/experimental) aren't buildable on the armel/armhf
because the build-deps don't install, and in particular:
The fol
On 16.03.24 15:29, Simon McVittie wrote:
On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote:
For example curl isn't building on armel/armhf now and numerous packages that
depend of curl are not building on armel/armhf.
I believe a maintainer upload or NMU of #1066981 and #1066982 wou
On 22.02.24 20:43, Niels Thykier wrote:
Simon McVittie:
We could also make unused substvars a hard failure (FTBFS).
I'd prefer not this, because this would be really painful if you're
using substvars for something other than a simple list of dependencies,
like gobject-introspection does:
[...
On 08.02.24 20:07, Ansgar wrote:
Hi,
On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
Once all of these packages have built in experimental and we have identified
and addressed all adverse interactions with the usrmerge transition, the
plan is:
- dpkg uploaded to unstable with abi=ti
as a supported version. If you see
builds failing because of a missing 3.12 extension, please just wait a
few days until all the binNMUs are done.
For the progress, see (ignoring the 'unknown' status)
https://release.debian.org/transitions/html/python3.12-add.html
Matthias
On 07.11.23
Link time optimizations are an optimization that helps with a single digit
percent number optimizing both for smaller size, and better speed. These
optimizations are available for some time now in GCC. Link time optimizations
are also at least turned on in other distros like Fedora, OpenSuse (
On 4/17/21 7:09 PM, Shengjing Zhu wrote:
> Hi,
>
> As the release of Go 1.16, upstream no longer supports x87-only
> floating-point.
>
> https://golang.org/doc/go1.16#386
>
>> require at least SSE2 support on 386, raising Go's minimum GOARCH=386
>> requirement to the Intel Pentium 4 (released i
On 2/11/21 10:40 AM, Paul Gevers wrote:
> Hi,
>
> On 11-02-2021 10:16, Matthias Klose wrote:
>> These dependencies should look like:
>>
>> default-jdk [!hppa !hurd-i386 !kfreebsd-any]
>>
>> or
>>
>> default-jdk [alpha amd64 arm64 armel ar
Please see https://bugs.debian.org/982085
I think it's wrong to encode build dependencies for language stacks that are not
available on some platforms, just using a profile.
Seen in gettext:
default-jdk , maven-repo-helper
and also in db5.3.
A more cooperative usage of such build dependenci
On 2/7/21 3:20 PM, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
>> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
>> or
>> crashes when it gets shipped with a release. Packages that are being shipped
>> with
>> a release should also be properly mainta
On 12/6/20 12:27 PM, Philipp Kern wrote:
> On 06.12.20 01:08, Paul Wise wrote:
>> On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote:
>>
>>> Maybe there is more. But there's no progress, or intent to fix every tool
>>> to be
>>> aware of binNMUs.
On 12/1/20 5:02 AM, YunQiang Su wrote:
> I am sorry for the later response.
>Hi,
>
> I am an active porter for the following architectures and I intend
> to continue this for the lifetime of the Bullseye release (est. end
> of 2024):
>
> For mipsel and mips64el, I
> - test most pac
On 12/1/20 11:56 AM, Simon McVittie wrote:
> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
>> Can someone remind me: Why is it that we cannot do arch-independent
>> auto-building?
>
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-relea
On 11/11/20 8:37 PM, Russ Allbery wrote:
> Simon McVittie writes:
>> My understanding is that Rust and Go code literally doesn't have
>> analogous built-in system-wide search paths for third-party libraries,
>> and when building Debian packages that contain Rust and Go code, we have
>> to invent t
On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> On 15948 March 1977, Paul Wise wrote:
>
>> Does this include the -dev packages for C/etc libraries?
>
> No.
>
>> I guess it also applies to Haskell and other statically-linked languages.
>> https://wiki.debian.org/StaticLinking
>
> StaticLinking itse
On 9/17/20 11:12 AM, Ole Streicher wrote:
> "Adam D. Barratt" writes:
>> On Thu, 2020-09-17 at 09:55 +0200, Ole Streicher wrote:
>>> Graham Inggs writes:
On Thu, 17 Sep 2020 at 09:18, Raphael Hertzog
wrote:
> Please reduce the severity of all the bugs that you opened to
> "norm
On 7/28/20 12:02 PM, Norbert Preining wrote:
> Dear GCC Team,
>
> (please Cc)
>
> I would like to ask about how we should deal with gcc10 creating
> completely different symbols than what we currently have.
>
> Are we supposed to bump the ABI version for every library due to the
> symbols change
On 7/6/20 8:04 AM, Lucas Nussbaum wrote:
> Hi,
>
> On 04/07/20 at 13:24 +0200, Steffen Möller wrote:
>> Hello,
>>
>> I just skimmed through https://trends.debian.net/ and am impressed. Many
>> thanks for these figures.
>
> Thanks
>
>> Do you accept wishes for additional graphs?
>
> Sure
>
>>
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.
I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July). binutils will be updated before mak
On 5/19/20 3:29 AM, Norbert Preining wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Norbert Preining
>
> * Package name: rocr-runtime
> Version : 3.3.0
> Upstream Author : AMD
> * URL : https://github.com/RadeonOpenCompute/ROCR-Runtime/
> * License : Univ
Package: wnpp
Severity: wishlist
Owner: Matthias Klose
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: python-pebble (already an unrelated pebble source
in the archive)
Version : 4.5.1
Upstream Author : Matteo Cafasso
* URL : https
Package: wnpp
Severity: wishlist
Owner: Matthias Klose
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: cvise
Version : 1.0.0
Upstream Author : Martin Liška and Moritz Pflanzer, The University of Utah
* URL : https://github.com/marxin/cvise
* License
On 3/30/20 1:24 PM, Emilio Pozuelo Monfort wrote:
> Hi,
>
> We've just finished the transition to python3.8 as the default python3
> interpreter, which was a bit difficult due to some autopkgtest regressions in
> a
> few rdeps, and to the fact that many modules only build their extensions for
>
On 3/7/20 9:41 PM, Julian Andres Klode wrote:
> # APT 2.0
>
> After brewing in experimental for a while, and getting a first outing in
> the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable.
> 1.10 would be a boring, weird number, eh?
>
> Compared to the 1.8 series, the APT 2
On 12.11.19 00:00, Sam Hartman wrote:
"Moritz" == Moritz Mühlenhoff writes:
Moritz> Scott Kitterman schrieb:
>> One maintainer doesn't get to block the removal of an entire
>> stack like Qt4. I think there's a reasonable point of discussion
>> about when RoQA is appropria
On 11.11.19 16:10, Norbert Preining wrote:
Hi Ondřej,
(please Cc, I am not subscribed to debian-devel)
thanks for your work on the Python2 removal.
On Mon, 11 Nov 2019, Ondřej Nový wrote:
We are going to raise the severity of the py2removal bugs to "serious"
in several steps. In the
...
Co
On 11.11.19 10:33, Ondřej Nový wrote:
Hi,
We are aiming to remove Python 2 for the bullseye release, or at least
remove as many Python 2 related packages as possible. Python 2 is
discontinued upstream, but crucially, more and more providers of Python
modules don't support Python 2 in either the
On 03.11.19 16:24, Holger Levsen wrote:
On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:
As part of general QA we did some test rebuilds during the last release
cycle, and filing the ftbfs reports as RC issues. Afaics there were no such
test rebuilds and RC filing for bullseye
As part of general QA we did some test rebuilds during the last release cycle,
and filing the ftbfs reports as RC issues. Afaics there were no such test
rebuilds and RC filing for bullseye after the release of buster. People only
have a limited amount of time, however it would be nice if these
On 12.09.19 17:01, Ian Jackson wrote:
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to
On 09.07.19 21:54, Boyuan Yang wrote:
> Dear -devel list,
>
> Looks like dh_dwz was recently added into debhelper and it is causing some
> FTBFS on one of my packages. It could be a bug of dwz itself but I'm looking
> for some help inside Debian first.
>
> Please try to build package marisa from
> No binary maintainer uploads for bullseye
> =
>
> The release of buster also means the bullseye release cycle is about to begin.
> From now on, we will no longer allow binaries uploaded by maintainers to
> migrate to testing. This means that you will need
On 13.04.19 17:01, Joerg Jaspert wrote:
> On 15371 March 1977, Aurelien Jarno wrote:
>
>>> How is the move to debian-ports supposed to happen? I won't have the
>>> time to do anything about it within the 2 weeks.
>
>> The process to inject all packages to debian-ports is to get all the
>> deb, ud
On 22.02.19 12:44, Dmitry Bogatov wrote:
>
> [2019-02-21 00:00] Guillem Jover
>> On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Dmitry Bogatov
>>>
>>> * Package name : build-alternative
>>> Version : 0.0.1
>>> Upst
On 24.11.18 11:26, Andy Simpkins wrote:
>> So, again: which of the two flavors is the one that benefits more of our user
>> base?
>
> BOTH are possible so why dictate only one?
>
> I would like to see OpenGLES available on all architectures
>
> I would like to see OpenGL available on all archite
On 21.11.18 16:56, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
>> Why is any of this a reason for an ftpmaster REJECT ? I still think
>> all of this should be handled as bugs (possibly RC bugs) in the BTS
>> in the conventional way, after ACCEPT.
>
> becaus
On 31.10.18 02:01, Joseph Herlant wrote:
> Hi guys,
>
> I was reviewing Tobias' updates on the use of dbg packages vs dbgsym
> in dev ref and was wondering if there was any other know use cases
> where we cannot use dbgsym over dbg packages for building debugging
> symbols.
>
> As far as I rememb
GCC 8 is available in testing/unstable, and upstream is approaching the first
point release. I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't ex
I'll add these as breaks in the next python3.7 upload. Please mention these in
#902788.
On 08.07.2018 12:36, Emilio Pozuelo Monfort wrote:
On 08/07/18 00:17, Paul R. Tagliamonte wrote:
Hey DPMT (BCC'ing -devel, let's keep conversaion on DPMT),
I see that Python 3.7 now raises a syntax error w
On 09.07.2018 12:13, Alexander Zaitsev wrote:
Hello.
As far as I know binaries in Debian repositories most binaries are compiled
without
PGO (profile-guided optimization). Also I don't know any LInux-based OS
where all (or significant part) binaries are precompiled with PGO. With PGO we
can imp
On 09.06.2018 18:31, Matthias Klose wrote:
On 09.06.2018 11:55, Philipp Kern wrote:
On 6/9/18 7:20 AM, Steve Langasek wrote:
- the package is being upgraded; it is in the common case (when no python
module names have been dropped from within the package) less important to
run py3clean
On 09.06.2018 11:55, Philipp Kern wrote:
On 6/9/18 7:20 AM, Steve Langasek wrote:
- the package is being upgraded; it is in the common case (when no python
module names have been dropped from within the package) less important to
run py3clean because the same files will be recreated shortl
On 05.06.2018 22:54, Paul Gevers wrote:
Hi all,
On 06-06-18 08:52, Simon McVittie wrote:
On Wed, 06 Jun 2018 at 10:28:53 +0530, Pirate Praveen wrote:
ruby-state-machines and ruby-state-machines-activemodel should go
together and even when autopkgtest for the version is unstable passed,
instead
On 03.05.2018 09:03, Alastair McKinstry wrote:
> On 03/05/2018 08:43, Matthias Klose wrote:
>
>> On 03.05.2018 07:29, Alastair McKinstry wrote:
>>> Hi,
>>>
>>> FTBFS bugs haveveen filed for packages that fail under gcc8.
>> I didn't file any, a
On 03.05.2018 07:29, Alastair McKinstry wrote:
> Hi,
>
> FTBFS bugs haveveen filed for packages that fail under gcc8.
I didn't file any, and I didn't see any being filed. Which ones do you mean?
Hi,
I'm intending to update binutils to 2.31 and GCC to 2.8.x for the buster
release. binutils 2.31 has an upstream release date around Agust 2018, and GCC
8 will be released next week (already available in unstable). It's usually this
time when I start filing bug reports for packages which don'
On 24.04.2018 07:37, Niels Thykier wrote:
> Thomas Goirand:
>> [...]
>>> I'm generally in favor of getting rid of old stuff, but python2 isn't
>>> there yet.
>>
>> Right. But I do believe we need to be very careful to not send a wrong
>> message to our users. Debian deprecating Python 2 is good. A
Package: wnpp
I'd like to drop maintenance of doxygen. I think I hijacked that package in 2004
to be able to build the libstdc++ docs from the GCC sources. Now that the
package needs a concise understanding about the javascript issues (sources,
different upstream versions), I'd like to stay off th
On 11.12.2017 13:42, Michael Meskes wrote:
> Anyone interested in citadel/webcit? If not I'm going to have it removed I
> guess.
>
> There used to be a team maintaining these packages, but I'm the only one who
> worked on it in recent years. Not having used the software myself I don't
> really in
On 10.10.2017 12:38, Mathieu Malaterre wrote:
> Mathias,
>
> On Tue, Oct 10, 2017 at 12:25 PM, Matthias Klose wrote:
>> On 10.10.2017 11:42, Mathieu Malaterre wrote:
>>> On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose wrote:
>>>> On 10.10.2017 08:45, Mat
On 10.10.2017 11:42, Mathieu Malaterre wrote:
> On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose wrote:
>> On 10.10.2017 08:45, Mathieu Malaterre wrote:
>>> Dear all,
>>>
>>> Since the GCC 6 release [1], the default mode for C++ is now
>>> -std=gnu++1
On 10.10.2017 08:45, Mathieu Malaterre wrote:
> Dear all,
>
> Since the GCC 6 release [1], the default mode for C++ is now
> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
> (re)compilation a library written for c++98 will be recompiled using a
> different c++ standard (c++14 i
On 03.08.2017 21:08, ba...@debian.org wrote:
> On Aug 3, 2017, at 17:57, Matthias Klose wrote:
>>
>> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be
>> done
>> to deprecate Python2 usage within the distribution. It might not be
>> po
While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be done
to deprecate Python2 usage within the distribution. It might not be possible to
drop Python2 for the next release, but there are still too many issues with
packages. For now we identified some categories which need f
On 18.01.2017 09:34, Guillem Jover wrote:
> On Wed, 2017-01-18 at 08:10:53 +0100, Bálint Réczey wrote:
>> 2017-01-18 4:34 GMT+01:00 Guillem Jover :
>>> So, I'd like to know how people feel about the requested interface
>>> (i.e. not enabling PIE globally from dpkg-buildflags). If there's
>>> consen
On 08.01.2017 17:27, Lars Wirzenius wrote:
> On Sun, Jan 08, 2017 at 04:58:01PM +0100, Galbo Branbert wrote:
>> I couldn't find any official statement if Python 3.6 will be the default
>> interpreter in stretch (as it was the current stable when the soft freeze
>> happened it should be, right?)
>
On 04.01.2017 00:23, Christoph Biedl wrote:
> Hi there,
>
> as the stretch freeze approaches, I'm getting concerned about the
> status of logrotate, most notably #734688. The maintainer (CC'ed)
> hasn't shown any sign of activity for a while, also no response to a
> private message (I admit, it's
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
>
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
No, you are not maintaini
On 15.09.2016 22:43, Helge Deller wrote:
> Hi Matthias,
>
> On 10.09.2016 00:48, Matthias Klose wrote:
>> While the Debian Release team has some citation about the quality of the
>> toolchain on their status page, it is not one of the release criteria
>> documented
&
On 14.09.2016 00:11, Santiago Vila wrote:
> On Tue, Sep 13, 2016 at 11:31:44PM +0200, Matthias Klose wrote:
>> On 13.09.2016 18:25, Adam D. Barratt wrote:
>>>
>>> Regardless of whether there's consensus that you agree with, it's an RC bug
>>> to
>&
On 13.09.2016 18:25, Adam D. Barratt wrote:
> On 2016-09-13 12:55, Sebastiaan Couwenberg wrote:
>> On 09/13/2016 01:49 PM, Santiago Vila wrote:
>>> You can't reproduce it, or you don't want to reproduce it?
>>
>> I added the tag because I couldn't reproduce the issue in unstable where
>> we build o
On 10.09.2016 09:59, Paul Gevers wrote:
> Hi,
>
> On 10-09-16 00:48, Matthias Klose wrote:
>> - fpc not available on powerpc anymore (may have changed recently)
>
> For whatever it is worth, this was finally fixed this week. It is
> missing on mips*, ppc64el and s390
On 10.09.2016 10:21, Simon McVittie wrote:
> On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
>> The arm-linux-gnueabi is not that well defined, so it may include the hard
>> float
>> variant as well. However Debian default to armv4t, while the default
>>
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that t
Hi,
thanks for the work on this. I'd like to defer the final decision to the
release team, however I'm not keen on having these defaults turned on
architectures which already have enough issues on their own. In the recent
porters call people claim that turning on these "should not be a problem"
On 15.05.2016 23:10, Iustin Pop wrote:
On 2016-05-15 21:45:55, Bálint Réczey wrote:
Hi Niels,
2016-05-15 20:49 GMT+02:00 Niels Thykier :
Bálint Réczey:
Hi,
[...]
Hi,
I think making PIE and bindnow default in dpkg (at least for amd64) would be
perfect release goals for Stretch.
I supp
On 11.05.2016 00:17, Lisandro Damián Nicanor Pérez Meyer wrote:
On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote:
Last year it was decided to increase the minimum CPU features for the
i386 architecture to 686-class in the stretch release cycle. This
means dropping support for 586-class and
On 09.05.2016 16:37, Jakub Wilk wrote:
* Helmut Grohne , 2016-05-09, 06:47:
The first misconception I see in this thread is that somehow pkg-config is
good and foo-config is bad. It's not as simple as that. Have a look at
libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config.
This is a
On 03.05.2016 22:50, Josh Triplett wrote:
Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit. We can't do anything automated about the fo
On 03.05.2016 11:33, Holger Levsen wrote:
On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
So I looked to see whether the Debian Policy was saying multi-arch is a
should, a must or something else.
It turns out it does not say anything of value: multi-arch is mentioned
as being a
On 03.05.2016 13:25, Simon McVittie wrote:
On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
A large number of packages, particularly development packages, are not
multi-arch aware.
...
3.10 Multi-arch support
Packages must be multi-arch aware and architecture-specific
On 22.04.2016 00:31, Steve McIntyre wrote:
On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
So why does the netinst image need a compiler?
It's been a feature for years that we include a compiler and kernel
headers to allow people to build third party modules on amd64
Control: severity -1 important
On 21.04.2016 19:28, Steve McIntyre wrote:
Control: severity -1 serious
Justification: wasting many megabytes of space and download
sorry, I don't see this as a justification.
We're shipping broken toolchain packages
please stop trolling. Nothing is broken.
On 05.04.2016 00:23, Steve Langasek wrote:
On Mon, Apr 04, 2016 at 10:28:18PM +0200, Matthias Klose wrote:
On 03.04.2016 12:12, Niels Thykier wrote:
With the latest debhelper upload today, I believe compat 10 is now ready
for widespread testing.
please could you consider generating new
On 03.04.2016 12:12, Niels Thykier wrote:
Hi,
With the latest debhelper upload today, I believe compat 10 is now ready
for widespread testing.
please could you consider generating new style dbg files (using build-id) for
every debhelper compat level, if a binary file has a build-id? The trigg
On 22.03.2016 17:36, Simon McVittie wrote:
Package: g++
Control: submitter -1 Jeffrey Walton
On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:
We just took a report due to
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
It appears Debian built the library with GC
On 25.02.2016 22:45, Adam Borowski wrote:
On Thu, Feb 25, 2016 at 09:54:30PM +0100, John Paul Adrian Glaubitz wrote:
On 02/25/2016 06:41 PM, Steven Chamberlain wrote:
Packages are auto-removed from testing when they are RC-buggy.
Could we do something similar in unstable, for Debian's ports?
Hi,
this is seen with the recent upload of the librevenge package. The maintainer
scripts modify the librevenge-0.0-0-dbgsym package to include the gdb pretty
printer files (around 10kB of python scripts). I got aware of this, because the
package fails to build on Launchpad, not yet having t
On 03.02.2016 06:34, Helmut Grohne wrote:
Hi Tollef,
On Wed, Feb 03, 2016 at 06:10:50AM +0100, Tollef Fog Heen wrote:
Those scripts can wrap pkg-config, and pkg-config already knows how to
provide user-defined variables, so this sounds like a problem that's
solveable.
What sounds obvious isn'
On 30.01.2016 20:08, Helmut Grohne wrote:
Cross building the Debian archive
-
Debian unstable has about 22000 source packages. Out of those, about 5000
source packages can satisfy their Build-Depends in a cross build
setting. For failing packages, detailed diagnos
GCC 6 is still intended to be the default GCC for the upcoming stretch release.
It doesn't yet build on mips and mipsel (gfortran and gnat), however GCC 5 has
non-addressed RC issues on these architectures, so maybe better regress on
release architectures than toolchain progress.
Debian QA di
86
- Ben Hutchings
- Aurelien Jarno
- Matthias Klose
On 09/14/2015 08:38 AM, Niels Thykier wrote:
> On 2015-09-13 21:02, Matthias Klose wrote:
>> [...]
>>
>> still using the globbing feature for command line arguments in DH_COMPAT=2
>> mode.
>> Was this re-added in higher levels again?
>>
>> Matthias
On 09/13/2015 08:29 PM, Niels Thykier wrote:
> On 2015-09-13 11:04, Niels Thykier wrote:
>> Hi,
>>
>> EXECUTIVE SUMMARY
>> =
>>
>> I am planning to remove the following features/commands in debhelper in
>> the near future:
>>
>> * compat level 1,2 and 3.
>> * dh_scrollkeeper
>>
>>
On 09/06/2015 06:59 PM, Simon McVittie wrote:
> On 06/09/15 17:30, Simon Richter wrote:
>> I have a package (librevisa) with a C API that uses C++ internally. Can
>> I ignore the transition completely because nothing breaks?
>
> If it is purely internal, then yes this is fine, and you do not need
On 08/24/2015 11:12 PM, Niels Thykier wrote:
> * debhelper will be including debug-ids in the control file to make it
>easier to find the necessary debug symbols for a given file.
>- Thanks to paultag for this idea.
>- This is merged into git and will be included in the next upload.
a
On 08/23/2015 12:48 PM, Chris Lamb wrote:
> Hi -devel,
>
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
>
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate repository whilst
> o
On 08/21/2015 01:12 PM, Simon McVittie wrote:
> On 18/08/15 00:37, Steve Langasek wrote:
>> On Mon, Aug 17, 2015 at 01:46:16PM +0100, Simon McVittie wrote:
>>> Having done more rebuilds in Ubuntu, it would be great if you could
>>> publish a complete list of the transitions you believe to be necess
Unstable now has GCC 5 as the default for more than two weeks. The follow-up
transitions are in progress, however the list of transitions at [1] is not
exhaustive, because this only covered libraries without dependencies on
libraries which need a transition. There is now another test rebuild [2] d
On 07/03/2015 03:24 PM, Matthias Klose wrote:
> On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote:
>> On 01/07/15 14:39, Matthias Klose wrote:
>>> On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote:
>>>> On 25/06/15 17:44, Matthias Klose wrote:
>>>&g
On 07/05/2015 08:52 PM, Steve M. Robbins wrote:
> Hi,
>
> I've heard rumours that GCC 5 is coming :-)
there are even rumours about GCC 6 (defaulting to C++14) ;)
> I help maintain several C++ libraries and expect some work is required to get
> through this GCC transition. I'd like to understan
On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote:
> On 01/07/15 14:39, Matthias Klose wrote:
>> On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote:
>>> On 25/06/15 17:44, Matthias Klose wrote:
>>>> On 06/25/2015 01:20 PM, Matthias Klose wrote:
>>>&g
On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote:
> On 25/06/15 17:44, Matthias Klose wrote:
>> On 06/25/2015 01:20 PM, Matthias Klose wrote:
>>> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
>>>> - You suggest that some libraries may need to be renam
On 06/25/2015 01:20 PM, Matthias Klose wrote:
> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
>> - You suggest that some libraries may need to be renamed due to the ABI
>> breaks.
>> Do you have a list of affected libraries?
>
> No. Getting this list is a bi
On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
> Thanks for the report. I have looked at the wiki page, but it's not entirely
> clear to me how the libstdc++ transition will go, so I have a few questions to
> better understand it.
>
> - You suggest that some libraries may need to be renamed
On 06/17/2015 09:42 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote:
>> Hi,
>>
>> it's time to prepare for GCC 5 as the default compiler in unstable.
>> Compared to earlier version bumps, the switch to GC
On 06/17/2015 11:17 PM, Joerg Jaspert wrote:
> Hi,
>
> we got one more lintian auto-reject active on ftp-master, in dak.git
> commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc
>
> Everything hitting "empty-binary-package" is a *nonfatal* reject now.
How does this make packages better?
Is there a
Hi,
it's time to prepare for GCC 5 as the default compiler in unstable. Compared to
earlier version bumps, the switch to GCC 5 is a bit more complicated because
libstdc++6 sees a few ABI incompatibilities, partially depending on the C++
standard version used for the builds. libstdc++6 will suppo
On 05/10/2015 03:32 AM, Guillem Jover wrote:
> CC_FOR_BUILD = gcc
the above mentioned wiki pages still talk about HOSTCC and BUILDCC. Please
clarify when to use these. Are the names now final? Also I don't see OBJC and
OBJCXX in use, and GOC and GDC are missing.
Matthias
--
To UNSUBSCRIBE, em
On 04/22/2015 02:30 AM, James McCoy wrote:
> On Wed, Apr 22, 2015 at 12:58:38AM +0200, Matthias Klose wrote:
>> - note that in Debian python extensions aren't usually linked with
>>-lpythonX.Y. This is done to not depend on multiple python versions
>>when
1 - 100 of 354 matches
Mail list logo
