I don't think that checks for ABI stability should be at the discretion of the
package maintainer. Symbols files for C++ is the implementation which is not
ideal, but currently in use. The right thing to do is to replace these with
state of the art technology, like abi-check from Google, or liba
The feature freeze for the 24.04 LTS release is approaching (Feb 29),
however we have some packages which didn't see merges since the last
Ubuntu LTS release, including packages with new upstream versions.
Please have a look at
https://merges.ubuntu.com/universe.html
and merge packages in t
On 07.02.24 09:17, Utkarsh Gupta wrote:
On Wed, Feb 7, 2024 at 6:17 AM Pushkar Kulkarni
wrote:
=== freedombox/bootstrapform ===
The freedombox package depends on bootstrapform. Autopkgtests of the
former fail because the latter imports distutils. I did a Debian MR
[15] to replace distutils.St
On 09.02.24 18:51, Brian Murray wrote:
Additionally, we've increased the default instance size from 1 CPU and
1536MB to 2 CPUs and 4096MB. Subsequently, the Ubuntu QA team will also
be testing all the packages hinted to run on the big flavor to see if
the hint is still necessary.
is this just f
Hi,
according to
https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt
we still have a lot of hard-coded dependencies on shared library packages.
These fixes just take some minutes, not only replacing a shared library
name with another hard-coded name.
On 13.09.24 10:48, Timo Aaltonen wrote:
Hi,
We are now under the Kernel Feature Freeze for Oracular Oriole:
https://wiki.ubuntu.com/KernelFeatureFreeze
This means that all the new features for the kernel (6.11) have landed
in oracular-proposed, and from now on we will focus on fixing bugs.
On 04/08/2011 10:32 AM, Daniel Holbach wrote:
What exactly Did he do? What kind of violation?
Without going into too much detail, because I feel it's wrong discussing
somebody's merits and mistakes publicly, it should suffice to say that a
number of people repeatedly complained about his genera
The bugs filed on 2011-04-19, and tagged with `ftbfs' `oneiric' are only seen
with GCC-4.6 and binutils trunk only. Forgot to update the bug text, sorry.
You don't need to change/fix anything for natty.
The bugs can be shown with:
https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs+oneiric&fiel
On 04/19/2011 04:14 PM, Matthias Klose wrote:
The bugs filed on 2011-04-19, and tagged with `ftbfs' `oneiric' are only seen
with GCC-4.6 and binutils trunk only. Forgot to update the bug text, sorry.
You don't need to change/fix anything for natty.
The bugs can be sho
On 04/20/2011 08:41 PM, Barry Warsaw wrote:
When multiarch landed in Natty, it caused some problems with upstream Python.
With my Python core developer hat on, I wanted to relate my experiences in
dealing with that change. I do this purely in the spirit of improving things
for the next time. I'
On 04/14/2011 06:28 PM, Scott Kitterman wrote:
This should get done before UDS, during toolchain upload (i.e. before the first
autosync), but I think it's worth mentioning.
The current Boost that's default and in Main is 1.42. Debian's current
default is 1.46. My proposal for Oneiric is that we
On 04/26/2011 04:47 AM, Scott Kitterman wrote:
On Saturday, April 23, 2011 06:26:27 AM Matthias Klose wrote:
On 04/14/2011 06:28 PM, Scott Kitterman wrote:
This should get done before UDS, during toolchain upload (i.e. before the
first autosync), but I think it's worth mentioning.
The cu
On 04/26/2011 08:50 PM, Barry Warsaw wrote:
Apologies for the long delayed response.
On Apr 01, 2011, at 01:11 PM, Scott Kitterman wrote:
On Friday, April 01, 2011 12:58:37 PM Barry Warsaw wrote:
Agreed. Can you elaborate on what "experimental support for Python3 as the
Python that is shippe
Oneiric is now open for development, with syncs from unstable starting shortly.
The development version starts with an updated GCC and binutils, some soname
changes (gmp, libffi, boost) and re-enables the default linker settings, which
were disabled just before the natty release.
When merging
On 05/29/2011 05:25 PM, Martin Pitt wrote:
gnome-python (2.28.1-2svn1) oneiric; urgency=low
Upload current Debian svn to oneiric. We drop all our remaining changes:
- -dbg packages: huge delta for little benefit, and this package is rather
obsolete
why do you drop the bindings for
On 05/29/2011 06:49 PM, Martin Pitt wrote:
Hello Matthias,
Matthias Klose [2011-05-29 17:47 +0200]:
Upload current Debian svn to oneiric. We drop all our remaining changes:
- -dbg packages: huge delta for little benefit, and this package is rather
obsolete
why do you drop the
On 05/24/2011 04:09 PM, Daniel Holbach wrote:
Hello everybody,
if you come across bugs that are easy to solve or could where you could
imagine helping somebody solve them, please tag them as 'bitesize'.
see https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs
maybe I'm stretching the definition
On 06/16/2011 05:29 PM, Martin Pitt wrote:
> Hey Mike,
>
> Michael Terry [2011-06-16 11:17 -0400]:
>> Hello! I was just considering how a dh_python2 transition for the
>> various ubuntuone python modules would work. They all install into
>> the ubuntuone module, so would need to be updated at th
On 06/08/2011 11:52 PM, Francis J. Lacoste wrote:
> Hello,
>
> When user file bugs on the distribution and enter a package name in the
> widget, Launchpad automatically adds a line to the description with
> Binary package hint: binarypackagename
>
> That binarypackagename actually comes from the
the current gcc-4.6/eglibc is now built multilib'd for -mfloat-abi=softfp|hard,
including the GCC runtime libraries. I hope that the gcc cross builds will pick
this up soonish, not needing to build the cross compiler twice for softfp and
hard float-abi.
Matthias
--
ubuntu-devel mailing list
The current list of component mismatches needs some work. we didn't have such a
long list for a long time, so please help cleaning this up today. with feature
freeze we actually want to see the features in the archive in *binary* package
form.
Some people from the archive admins, ubuntu MIR, and
when uploading new upstream versions, please make sure that changes which are in
the current version are applied to the new package to. You did re-introduce the
build failure on powerpc. Please fix it.
Thanks, Matthias
On 08/19/2011 10:50 AM, Sebastien Bacher wrote:
> nux (1.2.2-0ubuntu1) oneiric
A test rebuild for oneiric is currently running, an overview of the build
failures can be found at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
The test rebuild archive itself is found at
https://launchpad.net/ubuntu/+archive/test-rebuild-20110816
The
There's currently a lot of activity fixing build failures in oneiric, and bug
reports are reported back to Debian. Thanks for the progress! However ...
- please check first, if there is already a bug report filed
in Debian
- In any case, if you know that some kind of issue is tracked in Debi
On 08/19/2011 06:09 PM, Matthias Klose wrote:
> A test rebuild for oneiric is currently running, an overview of the build
> failures can be found at
> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
>
> The test rebuild archive itself is f
packaging of twisted plugins with python-support is broken by design. Even
python policy mentions explicitly that you should use the same packaging helper
for packages sharing the same python namespace.
You should use dh_python2 for that, or (deprecated) build with dh_pycentral
using `include-
On 09/13/2011 12:08 AM, Colin Watson wrote:
> On Mon, Sep 12, 2011 at 10:16:09PM +0100, hugo shepherd wrote:
>> The trouble with rebuilds is that more (new) bugs, appear to jump in
>> the place of the ones you've fixed - and like the Forth Bridge in
>> Scotland - its a never-ending job to paint it
On 09/13/2011 02:15 PM, Jani Monoses wrote:
> Fourthly, for armel at least, fixing toolchain related build failures (quite a
> few and usually gcc regressions) in universe helps make the tools better and
> can
> translate to similar fixes in main. This is less of an issues on x86/amd64
> where
>
On 09/13/2011 12:44 PM, Colin Watson wrote:
> On Tue, Sep 13, 2011 at 11:32:58AM +0200, Martin Pitt wrote:
>> Right, for those in particular the fixes should be sent to upstream
>> right away, not to Debian, as it's not a problem that actually affects
>> Debian (yet).
>
> I think Matthias said tha
On 09/15/2011 05:00 PM, Gediminas Paulauskas wrote:
> zope.interface (3.6.1-1ubuntu1) oneiric; urgency=low
>
> * debian/rules: no longer install zope/__init__.py, dh_python2 will create
> it for us.
>
pretty please, can we revert this immediately? There is absolutely *no* reason
to do that.
On 09/15/2011 06:08 PM, Gediminas Paulauskas wrote:
> 2011/9/15 Matthias Klose :
>> On 09/15/2011 05:00 PM, Gediminas Paulauskas wrote:
>>> zope.interface (3.6.1-1ubuntu1) oneiric; urgency=low
>>>
>>> * debian/rules: no longer install zope/__init__.py, dh_p
On 09/15/2011 08:02 PM, Gediminas Paulauskas wrote:
> 2011/9/15 Gediminas Paulauskas :
>> 2011/9/15 Matthias Klose :
>>> On 09/15/2011 06:08 PM, Gediminas Paulauskas wrote:
>>>> Bad timing, I understand.
>>>
>>> It's not just the timing, it
On 09/20/2011 01:59 PM, Jonathan Lange wrote:
> On Mon, Sep 19, 2011 at 8:55 PM, Colin Watson wrote:
>> On Mon, Sep 19, 2011 at 12:09:54PM -0700, Evan Broder wrote:
>>> If we're going to focus on making this easier, can we focus on the
>>> first two options? Historically speaking, packages that li
During the oneiric development cycle we had syncs of library packages from
experimental, introducing new sonames, and changing APIs in a way that other
packages need to be ported to the new API, or if the port isn't trivial, need to
be removed at the end of the cycle. This doesn't add much benefit
On 10/05/2011 10:47 PM, Scott Kitterman wrote:
> On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote:
>> To take an example I think porting universe GNOME2 applets to GNOME3
>> wouldn't be a good use of our time, we better spend the resources we
>> have making sure our current desktop
While Oneiric is not yet released, it's time to prepare packages for the opening
of the P-series. Please add to the lists at
https://wiki.ubuntu.com/P-SeriesOpening
what packages to prepare at the beginning of the release cycle, and what to
avoid. When adding to this list, please see it as a c
Precise is now open for development, with syncs from testing starting shortly.
The development version starts with an
- an updated GCC (4.6.x, Linaro 2011-10) and binutils (2.22 branch),
- gnat-4.6 as the default gnat,
- python2.6 dropped from the list of supported python 2.x versions,
- merge
On 10/26/2011 10:54 PM, Tom Gall wrote:
> In prep for Linaro Connect & the Ubuntu Developers Summit next week
> I've put together some performance measurements comparing libjpeg8c
> and libjpeg-turbo compiled with it's libjpeg8 compatibility setting.
> Quality settings of 95 and 75 are used. Image
On 11/02/2011 08:30 AM, Ilya Barygin wrote:
> velvet (1.1.06~nozlibcopy-1ubuntu1) precise; urgency=low
>
> * Fix FTBFS with --as-needed linker option.
>
> Date: Wed, 02 Nov 2011 16:20:35 +0400
> Changed-By: Ilya Barygin
> Maintainer: Ubuntu Developers
> https://launchpad.net/ubuntu/precise/+s
On 11/13/2011 11:19 PM, Colin Watson wrote:
> On Sun, Nov 13, 2011 at 05:59:35PM +, Colin Watson wrote:
>> I'm happy to shepherd this transition. While the transition to Perl
>> 5.12 involved some base system disruption, I do not think that we will
>> see the same problems with Perl 5.14, than
This week, a kind of rebuild for precise pangolin in the disguise of the armhf
bootstrap did end. The build did expose some ARM unspecific build failures;
please use the information from the armhf build logs to address these build
failures. Please use the ftbfs pages to gather more information:
Another test rebuild for precise pangolin is currently running on amd64, armhf
and i386. The results will show up at [1]. Half of main is rebuilt, and the
universe packages will start to build around this weekend.
The rebuild is running on the distro buildds, so please be a bit conservative
In preparation for the upload of eglibc-2.15 to precise I would like to ask for
people running the eglibc-2.15 packages from the ubuntu-toolchain-r/glibc PPA
for some daily work. The packages are currently used by some developers on
amd64, armhf and i386 and should not break your precise instal
On 25.02.2012 19:10, Ted Gould wrote:
As we're hitting beta freeze for this LTS I think it's a good time to
talk about something that gets discussed from time to time, but we
should commit to for this round of the meta-cycle. That is quite simply
having a process for things that aren't in the 6
Another (and probably the last) test rebuild for precise pangolin is currently
running on amd64, armhf and i386 (finished for main, universe is still
building). The results will show up at [1].
The rebuild is running on the distro buildds, so please be a bit conservative
with uploading packag
A rebuild of the archive using GCC-4.7 shows about ~330 additional build
failures. The rebuild was only done for Debian unstable [1], but I don't expect
many differences compared to precise. GCC-4.7 will become the default compiler
for the q-series, so be prepared to address these issues.
Hi
forgot the link to the bug reports:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
On 28.04.2012 00:13, Micah Gersten wrote:
> Now that we have the faster i386/amd64 buildds, I'd like to suggest at
> least one extra rebuild earlier in the cycle at least for i386/amd64 so
> there's time to get these changes upstream.
>
> Around alpha 1 ~ June 7 (archive raw, lots of failures, sho
Quantal is now open for development, with syncs from unstable starting shortly.
The development version starts with updated versions of GCC and OpenJDK, some
soname changes (boost, hdf5), and some changes with setting the build flags for
package builds. We are finally targeting Python3 as the
only
On 22.05.2012 23:42, Scott Kitterman wrote:
> On Tuesday, May 22, 2012 11:33:18 AM Barry Warsaw wrote:
>> For example, I took a look at authres which uses dh_python2. debian/rules
>> creates a symlink in pyshared to its test suite, and then
>> d/python-authres.install references pyshared. Even af
On 23.05.2012 02:50, Barry Warsaw wrote:
> On May 22, 2012, at 11:50 AM, Scott Kitterman wrote:
>
>> It seems to me that making changes that are known to break other packages to
>> gather data is not consistent with the stated goal of keeping the development
>> release in a functional state at ~al
On 08.06.2012 17:10, Chris Coulson wrote:
> I've just finished debugging a Unity crash which occurs when we try a
> test rebuild of Unity and Nux with GCC4.7 in quantal. Although the
> original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't
> been rebuilt yet in quantal), it was no
On 12.06.2012 18:50, Chase Douglas wrote:
> My understanding is that this is only a problem if one library compiled
> with one standard passes objects to another library compiled with
> another standard. The following examples illustrate the difference:
>
> * Nux (c++11) and libsigc++ (c++98) are
On 12.06.2012 19:18, Matthias Klose wrote:
> On 12.06.2012 18:50, Chase Douglas wrote:
>> My understanding is that this is only a problem if one library compiled
>> with one standard passes objects to another library compiled with
>> another standard. The following ex
On 03.07.2012 12:02, Bjoern Michaelsen wrote:
> so we "only" need:
>
> - the gcc with the revert
which is there since Jun 23.
> - a full rebuild of quantal
>
> right?
why? not every package like LibreOffice turns off verbose build logs so you can
see from the log how the package was built.
On 08.06.2012 17:10, Chris Coulson wrote:
> What is happening is, in GCC4.7, std::_List_base::_List_impl has a data
> member which only exists for compilation units that are built with
> -std=c++0x (_M_size). This means that the STL ABI is dependent on the
> language standard. This obviously causes
The oracle-java-installer packages mess around with distribution packages, nam
ely the postinst runs
#create default-java symbolic link
rm -rf /usr/lib/jvm/default-java
ln -s /usr/lib/jvm/java-7-oracle /usr/lib/jvm/default-java
the prerm runs
rm -rf /usr/lib/jvm/default-java
This is no
On 19.09.2012 20:15, Felix Geyer wrote:
> qt4-x11 (4:4.8.3+dfsg-0ubuntu1) quantal; urgency=low
>
> * New upstream bugfix release. * Drop patches that have been merged
> upstream: - QElfParser-fix-type-of-sh_size.patch -
> Fix-cursor-truncate-to-include-line-position.patch -
> qt_atomic_sparc64.pat
This weekend a test rebuild of quantal quetzal did start for the amd64, i386 and
armhf architectures. The test rebuild is now finished for the main and
restricted components, and continues with the universe and multiverse
components.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/reb
On 18.10.2012 23:55, Barry Warsaw wrote:
> On Oct 18, 2012, at 05:35 PM, Scott Kitterman wrote:
>
>> One further issue to consider is limited support for multiple python3
>> versions in dh_python3. It has a hard coded default value to rewrite
>> extensions for (python-qt4 needs this) to get the P
On 19.10.2012 21:41, Steve Langasek wrote:
> Hi Barry,
>
> On Thu, Oct 18, 2012 at 05:04:35PM -0400, Barry Warsaw wrote:
>> Continuing on discussions we've had at previous UDSes, and looking ahead
>> to the probably schedule for Python 3.4, it is almost certain that we'll
>> carry Python 3.3 as th
On 20.10.2012 16:58, Scott Kitterman wrote:
> On Saturday, October 20, 2012 01:45:22 PM Matthias Klose wrote:
> ...
>> If people do not want to address the pyqt "tooling" issues, these
>> should be at least documented in the bug tracker.
> ...
>
> I spent a f
On 20.10.2012 23:34, Dmitrijs Ledkovs wrote:
> I took a stab at the transition tracker:
> http://people.canonical.com/~ubuntu-archive/transitions/python3.3.html
>
> It does not look that bad. Locally (newer transition tracker ;-) ) it
> tells me 120 arch:all packages & 90 arch:any source packages.
On 22.10.2012 12:48, Matthias Klose wrote:
> here's the list of architecture dependent python3 modules, which need looking
> at
> for raring. I did look at ones with interesting build systems.
[...]
> The list may contain packages which only build for the the default python
&
A test rebuild of raring ringtail started in 2012 for the amd64, i386 and
armhf architectures is now finished for all components on armhf. The amd64 and
i386 rebuilds will hopefully finish in a few days.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20
Am 03.01.2013 03:56, schrieb Julian Taylor:
> On 01/03/2013 03:46 AM, Scott Kitterman wrote:
>> Jeremy Bicha wrote:
>>
>
>>>
>>> Yes, is this something that can be fixed once in the python-defaults
>>> source, or are we really going to have to patch every Python package
>>> in the archive?
>>
>>
Am 25.01.2013 23:43, schrieb Scott Kitterman:
> There's another case as well. If there is pure python code that is python3
> version specific. This is rare, but exists. To make sip4/python-qt4 support
> multiple python versions I had to do some really unfortunate and painful
> things to make
A second test rebuild of raring ringtail was started yesterday for the amd64,
i386 and armhf architectures. Currently running, and with mostly idle buildds
over easter and the current freeze it will hopefully finish within ten days.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/rebui
Am 08.04.2013 14:13, schrieb James Hunt:
> As a precis of my earlier blog post [1], I'd like to encourage those involved
> with a C, C++ or Java project in Ubuntu to take a look at the Coverity Scan
> static-analysis service offered free to OSS projects [2].
>
> We're already using it for critical
Saucy is now open for development, with syncs from unstable currently running.
The development version starts with updated versions of GCC and boost.
- GCC 4.8 is now the default compiler, introducing among other things
improved C++11 support, AddressSanitizer , a fast memory error detector,
Am 16.05.2013 01:29, schrieb Brian Murray:
> On Wed, May 15, 2013 at 03:15:05PM -0700, Brian Murray wrote:
>> On Wed, May 15, 2013 at 04:36:56PM -0400, Barry Warsaw wrote:
>>> Hello Developers,
>>>
>>> I am trying to debug and fix a particularly vexing problem in Python
>>> that manifests on Ubunt
The first test rebuild of saucy salamander was started yesterday for the amd64,
i386 and armhf architectures. Currently running, finished for main, universe
will finish within the next ten days (armhf a bit earlier).
Results can be seen at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/te
I had to look at many "core" packages, which are needed for a normal and a
buildd chroot, and and which are needed to build these packages for the chroots.
And I was not that pleased to see how the packaging wasted CPU time. I think
even for our migration from proposed to release it would make se
Today the debian-cr...@lists.debian.org ML was created. The rationale for
having such a ML can be found in http://bugs.debian.org/717332. The description
for the ML currently is:
Discuss cross building of packages and infrastructure for cross-builds
The list discusses
* How to cross-build pac
The second test rebuild of saucy salamander was started on Tuesday for the
amd64, i386 and armhf architectures. Currently running, finished for main
(armhf only), universe will finish within the next ten days (armhf a bit
earlier).
Results can be seen at
http://people.ubuntuwire.org/~wgrant/reb
Am 22.09.2013 13:49, schrieb Sergey Shambir:
> There are reasons to place headers in /usr/src instead of usual location.
I have never seen header files shipped in /usr/src. I still think that
/usr/include/ is the correct location, or at least something like
/usr/lib/qtcreator/include.
Matthias
Trusty is now open for development, with syncs from unstable currently running.
The development version starts with a new port and with minor updates to the
toolchain and some transitions.
- GCC 4.8 was updated to the GCC 4.8.2 release and the GCC Linaro
4.8-2013-10 release. Binutils is built
The first test rebuild of Trusty Tahr was started last week for all
architectures (main component only). It is still running for arm64, all other
architectures did finish the test rebuild.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty
Trusty currently has qt 5.0 packages. Trusty-proposed has some unbuilt 5.1
packages. There are daily builds of 5.2 packages. Feature freeze is not that
far away. What are the qt plans for trusty? I would like to include updated qt
packages for the next test rebuild.
Matthias
--
ubuntu-dev
Am 24.01.2014 16:48, schrieb Martin Pitt:
> Hello all,
>
> Matthias asked me to run all our available autopkgtests with python3.4 as
> default Python 3 (using the PPA [1]), to see the fallout. These should be
> fixed before we consider making 3.4 the default Python3 version. The full
> raw logs ar
Am 26.01.2014 11:30, schrieb Martin Pitt:
> Matthias Klose [2014-01-26 9:53 +0100]:
>> Unfortunately this includes some tests which did fail before too
>> (python-misaka). Marking these as python3.4 is "interesting".
>
> As I wrote, I didn't file bugs abo
The second test rebuild of Trusty Tahr was started this week for the i386
architecture (all components). The rebuild of the main component is finished
and it is now rebuilding the universe.
Results can be seen at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trust
The third test rebuild of Trusty Tahr was started this week for all
architectures except powerpc (all components).
Results will appear at (currently this link doesn't yet exist)
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
The archive for the test reb
[[ sent the appended email to debian-devel. I'm planning to do the default
change around the same time for utopic. Build failures are not filed
in Ubuntu, please use [3] for now. When fixing an issue ahead of Debian
please make sure to attach the patch to the Debian issue. And please
Am 28.05.2014 12:28, schrieb Robie Basak:
> apache2 (2.4.9-1ubuntu2) utopic; urgency=medium
>
> * Revert 2.4.4-6ubuntu3 and build against lua 5.1 again, since Apache
> doesn't yet support building against lua 5.2 (LP: #1323930).
This is not the way to "fix" issues. You are only hiding the issue
Hi,
tomorrow I'll set the gcc and g++ defaults to 4.9 in utopic on all
architectures. the gfortran, gccgo, gdc, gij, gcj and gnat defaults are already
set to 4.9.
Matthias
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/
Am 28.07.2014 um 14:37 schrieb Rodney Dawes:
> I've noticed that packages which have been changed already to explicitly
> require gcc-4.9/g++-4.9 to build, are no longer cross-compilable under
> sbuild as the gcc-cross versions don't seem to be getting set up
> correctly in the chroot. Will having
A test rebuild of Utopic Unicorn was started this week for all
architectures, and is finished for amd64, i386, armhf and ppc64el. The rebuild
for arm64 and powerpc will finish this week.
Results can be found at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.h
A test rebuild of Vivid Vervet was started this week for all
architectures, and is finished for the main component.
Results can be found at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-vivid.html
The archive for the test rebuild is
https://launchpad.net/ubuntu/+a
python-nemo is missing in the archive.
folder-color-nemo (- to 0.0.45-0ubuntu1)
Maintainer: Marcos Costales
Section: universe/utils
19 days old
folder-color-nemo/amd64 unsatisfiable Depends: python-nemo
On 02/12/2015 07:09 PM, Marcos Costales wrote:
> folder-color-nemo (0.0.45-0ubuntu1) v
Hi,
two test rebuilds for vivid are almost finished on all architectures (pending
powerpc and arm64). It's time to address the build failures seen with these
test rebuilds. The most important ones are listed in [1] for the vivid
archives. These really have to be addressed.
In preparation for t
As part of packaging GCC 5, there is now also a gccgo-5 package in vivid. GCC 5
now builds the go and gofmt commands from it's own source, so the gccgo-go
package was removed from the distro. gccgo is now based on Go 1.4.2, while
golang still stays at 1.3. There is a hack in the golang package i
Before leaving for PyCon and with 15.04 beta2 released, I had a look at removing
Python2 from the desktop images. We are not there yet, but it looks promising
and realistic to achieve for 15.10. Bugs can be seen at
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3
software-center
823
On 04/07/2015 01:28 AM, Matthias Klose wrote:
> Before leaving for PyCon and with 15.04 beta2 released, I had a look at
> removing
> Python2 from the desktop images. We are not there yet, but it looks promising
> and realistic to achieve for 15.10. Bugs can be seen at
A second test rebuild of Vivid Vervet was started last week for all
architectures, and is finished for the main component.
Results can be found at
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150402-vivid.html
The archive for the test rebuild is
https://launchpad.net/ub
On 04/16/2015 03:17 PM, Michael Hudson-Doyle wrote:
> Hi Matthias (belated response sorry)
>
> On 31 March 2015 at 17:33, Matthias Klose wrote:
>> As part of packaging GCC 5, there is now also a gccgo-5 package in vivid.
>> GCC 5
>> now builds the go and gofmt comman
On 04/07/2015 01:28 AM, Matthias Klose wrote:
> Before leaving for PyCon and with 15.04 beta2 released, I had a look at
> removing
> Python2 from the desktop images. We are not there yet, but it looks promising
> and realistic to achieve for 15.10. Bugs can be seen at
Hi,
GCC 5 will be the default compiler for the wily release, and it's time to
prepare the change of the default in wily, so that we don't have to do it during
the next relase cycle before the next LTS release. This time things are a bit
more complicated, we basically need to rebuild all C++ packa
Hi,
We are currently preparing the switch to GCC 5 as the default compiler for 14.10
(wily). Unlike earlier updates to newer compiler versions, which only required
updating packages to newer language standards, this time we have a partial ABI
transition in the standard C++ library (libstdc++6).
On 07/23/2015 07:11 PM, Iain Lane wrote:
> I can certainly help out with that, though. I guess we need a tracker
> like this? I've set one up now.
>
>
> http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/old/python3.3-4.ben
no, that's t
1 - 100 of 259 matches
Mail list logo
