@xnox - yes I also only saw it happening in do-release-upgrade.
I was even going for a VM instead of a container knowing that some of the time
services will auto-disable themselves when running in a container.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
This will be fixed on the next merge, in the debhelper discussion we
settled on --no-also which is a hidden dh_systemd option.
OTOH the undocumented option even exists in Bionic, so for quite a while.
Maybe we should just add it to focal which would stop printing that warning and
maybe solve
Public bug reported:
Due to changes in systemd for bug 1849156 this issue now happens.
On an upgrade for people that had chrony installed on a do-release upgrade it
now will:
Calculating the changes
MarkInstall systemd-timesyncd:amd64 < none -> 245.4-4ubuntu1 @un uN Ib > FU=1
Removing:
FYI - Hi Rbalint, this most likely has exposed/triggered bug 1872183
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1849156
Title:
systemd-timesyncd.service broken on upgrade
Sure @seb128 - I'll let you know if it happens again (as I did a
cleaning-reboot now).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to accountsservice in Ubuntu.
https://bugs.launchpad.net/bugs/1871538
Title:
dbus
> 1. Look in /var/crash for crash files and if found run:
>ubuntu-bug YOURFILE.crash
> Then tell us the ID of the newly-created bug.
Again, they all seem to be prior or follow on issues, but they already
have IDs in the error tracker.
/var/crash/_usr_bin_gnome-clocks.1000.uploaded
> Also do you have any gnome-shell/gdm crash collected in /var/crash?
No, just these:
$ ll /var/crash/*.crash
-rw-r- 1 paelzer whoopsie 3589735 Apr 6 08:34
/var/crash/_usr_bin_gnome-clocks.1000.crash
-rw-r- 1 paelzer whoopsie 53170176 Apr 8 10:36
> could you add the journalctl log from that session, that might include
some hints
Sure attached here, you see in the initial report and the later comments
the time indexes to look out for.
Also FYI for the rtkit issue that you will see in there => bug 1871543
** Attachment added:
A full system restart resolved the issue for me, but thereby also
removed my chances to debug further. I hope the bug gives others that
might hit it as well a head start.
For now I'm marking it incomplete
** Changed in: rtkit (Ubuntu)
Status: New => Incomplete
--
You received this bug
Hi Daniel,
none of the crashes that I had has the same signature as those that are
reported on the dup.
Furthermore as I outlined the crashes seem to be secondary issues after
soemthing breaks and recycles gnome-shell.
I'd ask for re-triage as that doesn't seem to be the same thing to me.
**
Another crash just happened:
Apr 08 10:28:06 Keschdeichel systemd[1]: Reloading.
Apr 08 10:28:06 Keschdeichel systemd[1]: /lib/systemd/system/dbus.socket:5:
ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run>
Apr 08 10:28:17
I compared e.g. systemd-coredump vs rtkit.
Similar user add calls:
rtkit has:
--disabled-password
I recreated it without, and it made no difference.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rtkit in Ubuntu.
I was playing with different similar users (system user with nologin)
$ for u in $(grep nologin /etc/passwd | cut -d':' -f 1); do echo Trying $u;
/tmp/rtkit-0.12/rtkit-daemon --stderr --user-name $u; done
Working:
daemon bin sys games man lp mail news uucp proxy www-data backup list irc gnats
Knowing that --no-drop-privileges is related I was breaking that into
sub-sections.
I set -O0 for better debugging.
Then I dropped code of the drop-priv section.
This section is it:
1755 if (setgroups(0, NULL) < 0 ||
1756
This would work as well as a workaround:
--user-name root
setgroups and setresgid are safe, it is the user set via
setresuid
that makes it fail eventually.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rtkit in Ubuntu.
$ sudo userdel --remove rtkit
$ id rtkit
id: ‘rtkit’: no such user
$ sudo apt install --reinstall rtkit
$ id rtkit
uid=109(rtkit) gid=114(rtkit) groups=114(rtkit)
The issue does not go away by removing and recreating the user.
--
You received this bug notification because you are a member of
It is the raw clone call that fails:
101 if (__glibc_unlikely (ARCH_CLONE (_thread, STACK_VARIABLES_ARGS,
102 »···»···»···»···clone_flags, pd, >tid, tp, >tid)
103 »···»···»···== -1))
104 return
Similar:
https://superuser.com/questions/1440725/rtkit-fails-to-start-on-reboot
=> but I have no docker (nor runc/containerd)
https://bbs.archlinux.org/viewtopic.php?id=230079
=> re-install doesn't help for me (also I have no user issue)
--
You received this bug notification because you are a
Breakpoint 2, start_canary () at rtkit-daemon.c:2300
2300if (start_canary() < 0)
(gdb) n
1670if ((canary_fd = eventfd(0, EFD_NONBLOCK|EFD_CLOEXEC)) < 0 ||
(gdb)
1677if ((r = -pthread_create(_thread_id, NULL,
canary_thread, NULL)) < 0 ||
(gdb)
Breakpoint 1,
Start through dbus fails the same way.
$ rtkitctl --start
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rtkit in Ubuntu.
https://bugs.launchpad.net/bugs/1871543
Title:
rtkit fails to start in focal "pthread_create
Reproducible:
$ sudo /usr/libexec/rtkit-daemon --stderr
rtkit-daemon[1764664]: Successfully called chroot.
rtkit-daemon[1764664]: Successfully dropped privileges.
rtkit-daemon[1764664]: Successfully limited resources.
rtkit-daemon[1764664]: pthread_create failed: Resource temporarily unavailable
The issue is on my workstation which might have all kind of config history.
On a fresh focal system it looks like "default off, start works"
root@f:~# systemctl status rtkit-daemon
● rtkit-daemon.service - RealtimeKit Scheduling Policy Service
Loaded: loaded
Public bug reported:
I was debugging something else and found rtkit broken on my system.
Apr 08 06:09:22 Keschdeichel rtkit-daemon[1726502]: Successfully called chroot.
Apr 08 06:09:22 Keschdeichel rtkit-daemon[1726502]: Successfully dropped
privileges.
Apr 08 06:09:22 Keschdeichel
Public bug reported:
This morning I found my computer on the login screen.
But not the one of the screen log, no a new one - so something must have
crashed.
Logging in again confirmed that all apps were gone and the gnome shell
was brought down what seems like triggered by a background update o
Great @rbalint - the chrony test fixes have landed ~1h ago.
Combined with your upload this should be ok then - thanks!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1849156
After install the daemon runs fine in 18.04:
root@b:~# systemctl status dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset:
enabled)
Active: active (running) since Mon 2020-04-06
Debian MP is merged at the end of last Week.
It is in 245.4-2 in debian/unstable since Saturday.
It is not yet in 245.2-1ubuntu3 which is the current focal-proposed.
I was working on bug 1870144 and considering to modify timesyncd there,
but seeing this change coming I'll (on the chrony side)
Hmm, the pager is called from dpkg to show the diff in your case.
This didn't change and dpkg doesn't do anything magic.
I can only assume that you might have the "pager" itself setup in an odd way.
Due to a bug or intentional - I don't know.
Could you report back the output of:
$
Lol - sorry for the noise after seeing another case like that I had to realize
that focal-unapproved just is multiple pages now :-)
It is on the second page still waiting for the release team to accept after
beta is out.
--
You received this bug notification because you are a member of Ubuntu
@Jamie/John - did you let this upload cancel from focal-unapproved?
It was, but is no more in -unapproved - but it also does not show up in
-proposed.
I'm confused and was wondering if this was lost in work of the release-team or
if you cancelled (and plan to re-upload) it intentionally?
--
If you follow the Debian discussion it seems this tends to go the "please fix
in systemd" way.
Therefore I'm adding a systemd task
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
It seems Rich has already requested the same change upstream after we
identified it is not chrony but a general issue. That is great that
allowed to backport an official commit.
Thanks jjohansen for making the debdiff of that.
I polished the dep3 headers and changelog a bit to fit in lines and
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869629
Title:
please add /etc/mdns.allow to /etc/apparmor.d/abstractions/mdns
Status in
Hi Rich,
thanks for your continued help - yes I agree that we need to fix this in the
apparmor abstraction and not each individual other affected package.
FYI: I pinged jjohansen yesterday and he said he will make an upload
ready and will ask jdstrand to sponsor it. I subscribed them both here
Hi,
/etc/apparmor.d/usr.sbin.chronyd has
#include
And thereby should have:
/etc/apparmor.d/abstractions/nameservice: #include
Which in turn defines:
/etc/apparmor.d/abstractions/mdns: # mdnsd
/etc/apparmor.d/abstractions/mdns: /etc/nss_mdns.conf r,
/etc/apparmor.d/abstractions/mdns:
** Tags added: champagne
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1867908
Title:
Fix RTM NEW/DELLINK IFLA_IFNAME copy for maximum ifname length
Status in wpa package
This waits on systemd for a general approach/solution.
Related discussions that happened already:
- https://lists.debian.org/debian-devel/2020/01/msg00032.html
- https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040911.html
** Tags removed: server-triage-discuss
--
You received this
Both migrated, issue resolved.
libcap2 | 1:2.32-1| focal | source, amd64, arm64, armhf, i386,
ppc64el, s390x
bubblewrap | 0.4.0-1ubuntu3 | focal | source, amd64, arm64, armhf,
i386, ppc64el, s390x
** Changed in: libcap2 (Ubuntu)
Status: New => Fix Released
**
Hmm,
that worked for me just nice.
root@b:~# apt install sasl2-bin
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
db-util db5.3-util
The following NEW packages will be installed:
db-util
FYI: here an info how current Bionic should look like:
Package: sasl2-bin
Architecture: amd64
Version: 2.1.27~101-g0780600+dfsg-3ubuntu2.1
Priority: optional
Section: utils
Source: cyrus-sasl2
Origin: Ubuntu
Maintainer: Ubuntu Developers
Original-Maintainer: Debian Cyrus SASL Team
Bugs:
Merge Proposal review is complete, but waiting on some feedback that
helps to classify the severity and urgency correctly.
Depending on that the options will be:
- actually unimportant: don't SRU it at all
- some reasonable cases exists, but are very rare: SRU it but hold the release
in
Autopkgtests are complete on the PPA at
https://bileto.ubuntu.com/#/ticket/3962
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3962/+packages
Tests all passed or are known force-badtest cases already.
Waiting for Kyle's response to properly handle the severity of this ...
--
You
I've redone the patches following the usual patch guidelines and opened an MP
with these at:
=>
https://code.launchpad.net/~paelzer/ubuntu/+source/openssh/+git/openssh/+merge/380138
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
protoversion
of "1.99" as equivalent to "2.0"; however, some backward-compatible
clients send a protoversion of "1.99" and expect the server to treat it
as "2.0".
This regression was introduced in openssh-portable 7.6p1 from commit
97f4d3083; fixes
Yep, thanks cjwatson
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1863930
Title:
SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
Status in
@Kyle - in prep for an SRU - do you have steps to reproduce this e.g.
with which Ubuntu based client/options one can easily send 1.99 on a
connection attempt?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
Assigned to cjwatson for now, but feel free to tell us you want us to
drive the SRU for this and we can change it.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1863930
Thanks Kyle for the great report and prepping a fix already.
offending: 97f4d3083 is in >=1%7.6p1-1
fix: 9e9c4a7e5 is in >=1%7.7p1-1
fix: c9c1bba06 is in >=1%7.7p1-1
Matching that with versions in Ubuntu means only Bionic should be
affected.
openssh | 1:5.9p1-5ubuntu1| precise |
The MP was approved and I uploaded but it seems Lukasz did the same upload
already.
=> https://launchpad.net/ubuntu/+source/bubblewrap/0.4.0-1ubuntu3
I now marked the MP as rejected.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Changing the behavior in Ubuntu only would only break plenty of scripts
automation and expectations.
I (personally) agree to Simon who also is "the upstream" on this that it
is a security feature and people can still (if preferred) just not set
it.
I have read the answer twice but don't really
Test build in
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3943/+packages
works against the older libcap2
=>
FYI - I'm taking a look if the proposed change on the issue would help
us to unblock the new libcap2.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libcap2 in Ubuntu.
https://bugs.launchpad.net/bugs/1863733
Title:
Tests are all good now, things should migrate once britney gets to them
...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1864423
Title:
Failed test 'default log is not
** Bug watch added: Debian Bug tracker #951577
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951577
** Also affects: bubblewrap (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951577
Importance: Unknown
Status: Unknown
--
You received this bug notification
** Bug watch added: Debian Bug tracker #951577
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951577
** Also affects: bubblewrap (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951577
Importance: Unknown
Status: Unknown
--
You received this bug notification
FYI:
- postgresql-common itself had a flaky test on armhf (re-started) and should
migrate soon (everything else is good)
- I triggered the procps tests with the new postgresql-common
@Steve - thanks for picking up the cleanup of the fs.protected_regular
setting on procps itself
--
You received
Submitted to Debian via:
https://salsa.debian.org/postgresql/postgresql-common/merge_requests/8
And if there are no other blockers Myon will do an upload soon, so we
can sync and retest procps against that then.
** Changed in: postgresql-common (Ubuntu)
Status: New => In Progress
--
You
I see no difference between the simple test above and the status when
the real test is running:
Bad:
-rw-r- 1 postgres adm 559 Feb 24 10:55
/var/log/postgresql/postgresql-12-main.log
12 main 5432 online postgres /var/lib/postgresql/12/main
/var/log/postgresql/postgresql-12-main.log
Good:
I found that it depends on file permissions/ownership.
The construct:
open L, ">$default_log"; close L; # empty default log file
only works if you are the file owner.
The test is running as root and the open/close will fail to open the
postgres:adm opened file.
A simple test might look like:
A trivial check like:
$ echo foo > testfile; perl -e 'my $test = "/home/ubuntu/testfile"; open L,
">$test"; close L;' cat testfile
Is not broken, it must be more special to the test env of postgresql-
common ?!
--
You received this bug notification because you are a member of Ubuntu
Touch
Replacing the perl construct
open L, ">$default_log"; close L; # empty default log file
with the also more readable:
truncate "$default_log", 0;
Fixes the issue in postgresql-common.
That might be a fix for this particular test, but (unfortunately) the
construct above is a common use-case in
The failing tests are part of 020_create_sql_remove.t:
The checks are like:
ok -z $default_log, "default log is not used";
And $default_log points to /var/log/postgresql/postgresql-12-main.log in
both cases.
Entering interactive mode on fail:
$ sudo ./testsuite -f 20 -V -s
Eventually the
Subscribing Steve who did the merge according to the Changelog
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1864424
Title:
new vim version in 20.04 sets mouse=a by default
Public bug reported:
Upgrading vim in Focal from 2:8.1.0875-5ubuntu4 to 2:8.1.2269-1ubuntu1
changed the default behavior.
Old:
:set mouse
mouse=
New:
:set mouse
mouse=a
That new behavior prevents most peoples common
In fact that is one thing that always annoys me when working with a Debian
Public bug reported:
Since the new procps upload
procps | 2:3.3.16-1ubuntu1 | focal-proposed | source, amd64, arm64, armhf,
i386, ppc64el, s390x
the tests of postgresql-common fail.
The issues are:
autopkgtest [15:43:10]: test run-testsuite: - - - - - - - - - - results - - -
- - - - - - -
FYI - libcap2 2.32 is blocking on bubblewrap (bug 1863733) that needs
the tests updated (https://github.com/containers/bubblewrap/issues/353)
to pass proposed migration.
FYI No current chrony tests in excuses that are blocking anyone (and if
so testing vs libcap2 from proposed makes it work) - we
FYI: 2.32 was uploaded to Debian, should resolve via autosync
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libcap2 in Ubuntu.
https://bugs.launchpad.net/bugs/1863590
Title:
Chrony test hangs with libpcap2 1:2.31-1
Since it is a sync I filed a Debian bug for it, but due to our FF it
depends how they respond.
=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951492
** Bug watch added: Debian Bug tracker #951492
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951492
** Also affects: libcap2 (Debian)
** Changed in: chrony (Ubuntu)
Status: New => Confirmed
** Changed in: libcap2 (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libcap2 in Ubuntu.
libcap2 breaks it, libcap2 has a fix.
I'd prefer that we get libcap2 2.32 to fix it.
References:
- https://sites.google.com/site/fullycapable/release-notes-for-libcap
- https://bugzilla.kernel.org/show_bug.cgi?id=206539
** Also affects: libcap2 (Ubuntu)
Importance: Undecided
Status:
This is a post 2.13 fix upstream.
As mentioned by Christian it is in the backport branches, the respective merge
for 2.13 is:
$ git tag --contains 28c4d3a339dea8120eb59fea314bc0026b50
v2.13.3
Thereby this is fixed in E
2.12:
$ git tag --contains 1ce8cd213c1f8948658818ac8a9a964755aac6d0
Hi Hadmut,
we had the same discussion over the weekend if 8.2 would be good to have in
20.04.
I subscribed cjwatson who usually does openssh updates to comment on his
intentions in this regard.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
** Merge proposal linked:
https://code.launchpad.net/~bryce/ubuntu/+source/openssh/+git/openssh/+merge/378685
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1861472
We can see in your logs (thanks for all your effort BTW) that the failing cases
are exactly those which have:
...
Server: 127.0.0.53
Address: 127.0.0.53#53
...
That represents the switch to systemd-resolved.
It might be worth to check (and if you want report) your output of:
$ systemd-resolve
FYI
The ones working seem to be those building as:
Architecture: all
While the ones you report as failing are:
Architecture: any
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-crypto in Ubuntu.
** Changed in: rsyslog (Ubuntu)
Status: New => In Progress
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/rsyslog/+git/rsyslog/+merge/378910
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Public bug reported:
Debian is at 8.2001.0-1 which among many fixes by the new upstream
changes also resolved python3 issues.
This is a year of extra fixes that would be nice going into a new LTS.
Important: I think I might be able to prepare the merge but I'm
unavailable next week so I'd need
We have a new MP that fixes things for real in Focal.
The former SRUs already have been set to verification-failed and can be
cancelled from -proposed if it helps to clear up things.
** Changed in: rsyslog (Ubuntu Disco)
Status: Fix Committed => Triaged
** Changed in: rsyslog (Ubuntu
** Changed in: rsyslog (Ubuntu)
Status: Fix Released => In Progress
** Also affects: rsyslog (Ubuntu Eoan)
Importance: Undecided
Status: New
** Changed in: rsyslog (Ubuntu Eoan)
Status: New => Triaged
** Changed in: rsyslog (Ubuntu Eoan)
Importance: Undecided => Low
Thank you for taking the time to report this bug and helping to make
Ubuntu better. I appreciate the quality of this bug report and I'm sure
it'll be helpful to others to find this discussion if they are
experiencing the same issue.
This sounds like an upstream bug to me. I have checked the
Hi Thomas,
as you already described yourself if you set in /etc/dnsmasq.conf
tftp-root=/
then all paths you provide in per subnet config would work if each of them were
added as absolute path.
This works as-is without any change to the package.
`tftp-root` is defined as:
--tftp-root=[,]
Look
** Changed in: strongswan (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1861975
Title:
libiptc.pc non-functional
Status in
Actually the merge of 1.8.4 and the FTBFS are so different - closing the
iptables tasks to live in a different place if needed.
** No longer affects: iptables (Debian)
** Changed in: iptables (Ubuntu)
Status: New => Invalid
** Also affects: strongswan (Ubuntu)
Importance: Undecided
Actually this isn't as bad as I first thought, but it can be. Let me
illustrate how/why.
iptables changed its -dev packaging.
Then strongswan adapted by changing iptables-dev to libip4tc-dev + libip6tc-dev.
If strongswan would have stayed as-is it woul still work. But due to
adapting to the
Public bug reported:
Hi,
I found this by trying to merge a newer strongswan which was an FTFBS.
I wondered what happened and found:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947176
This is exactly my issue and we might face FTBFS in strongswan, systemd
and probably others as well.
The
>From man ssh:
-i identity_file
Selects a file from which the identity (private key) for public key
authentication is read. The default is ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa. Identity files may also be specified on a
per-host basis in the
An SRU for just a FTBFS seems wrong.
Even keeping it forever in block-proposed seems wrong.
The fixes are known and ready for whoever does a real upload.
The most likely upload is a full backport of the new version which already
includes the fixes.
For whoever does an upload to Eoan what you
.
** Changed in: pango1.0 (Ubuntu)
Status: New => Won't Fix
** Changed in: navit (Ubuntu)
Status: New => Triaged
** Changed in: navit (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Ubu
** Also affects: cmake (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cmake (Ubuntu)
Assignee: (unassigned) => Rik Mills (rikmills)
** Changed in: cmake (Ubuntu)
Status: New => Triaged
** Description changed:
+ A change in Pango [1] broke builds using GTK2 as
navit last time built fine in Eoan on 2019-09-10
Comparing the environments between late Eoan and Focal...
The Eoan version of pango-coverage.h doesn't have the include that is
failing me.
** Bug watch added: gitlab.kitware.com/cmake/cmake/issues #19531
#ubuntu-desktop was helpful:
[11:29] cpaelzer, hey, it's
https://gitlab.kitware.com/cmake/cmake/issues/19531
[11:29] RikMills, ^
[11:29] cpaelzer, we talked about it on friday on #ubuntu-release, we
should backport that patch to cmake
--
You received this bug notification because you are a
This is in Focal, lets close the bug
pango1.0 | 1.44.7-1 | focal | source
** Changed in: pango1.0 (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pango1.0
navit actually just naively includes and the error pups up
much below that.
It has #define GDK_ENABLE_BROKEN might that be related?
Build dep is:
libgtk2.0-dev
Which brings in:
libpango1.0-dev | 1.44.7-1 | focal | amd64, arm64, armhf,
i386, ppc64el, s390x
And that has
Added a pango1.0 task for awareness
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pango1.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1855993
Title:
FTBFS in focal blocking gpsd transition for libgps25
Status in navit
I reworded the bug Description to be the general discussion that it is.
Waiting for:
- Debian GR [1] to complete as its decision has direct impact on how to handle
this in packages
- Ubuntu systemd maintainers to chime in as this might have been discussed in
other bugs before
[1]:
Adding a systemd task as I really think this is more a general than a
haproxy specific discussion/bug/feature.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1855140
Title:
Maybe related discussion https://lists.debian.org/debian-
devel/2019/12/msg00060.html
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in
Issue is in systemd, fix known (now).
I'll prep an MP to discuss, but given how much extra churn systemd updates
usually cause this most likely won't be uploaded "on its own"
** Changed in: libseccomp (Ubuntu)
Status: New => Invalid
** Changed in: systemd (Ubuntu)
Status: New =>
FYI: Discussions with both upstreams continue, I'm right now trying a
new spin with a different approach that does not use the _exact calls
and will get back to the upstreams once (if) that works.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
First of all I beg your pardon, I'm sure there was a similar discussion
recently but I only find this bug which is older. I think it was
something paride found, so maybe it was on IRC?
Well I tried to proactively let you know via this bug months before
anyway :-)
Well wherever that other recent
601 - 700 of 1232 matches
Mail list logo
