On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote:
> Also, does tinc work in a purely Jammy context? :-)
Sorry, I just realized that I had not mentioned here on this bug the
results of my tests between various Ubuntu versions. I didn't test
Jammy-to-Jammy, but (briefly):
* Jammy
On Wed, May 18, 2022 at 13:37:46 -, Simon Chopin wrote:
> Could you give more details about what happens when using the legacy
> providers?
The short version is that by enabling the legacy provider and setting
SECLEVEL to 1, I'm able to get past the "digital envelope
routines::unsupported"
On Wed, May 18, 2022 at 13:41:06 -, Simon Chopin wrote:
> Also, does tinc work in a purely Jammy context? :-)
As far as I can determine the issue relates to compatibility between
libssl3 and the algorithms used by the Xenial-era tinc, and thus I can't
imagine Jammy-to-Jammy would be a
On Wed, May 18, 2022 at 07:42:04 -, Simon Chopin wrote:
> I'm guessing there are some SSL certificates involved? If so, this issue
Tinc uses openssl's implementations of specific alogorithms, but does not
use either TLS or SSL certificates. (So I don't think the Tinc situation
is covered by
** Also affects: openssl (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1972939
Title:
Jammy tinc incompatibile with older (e.g. Xenial) tinc
Since the tinc version number in Focal/Impish and Jammy are the same, it
might be worth adding a warning to the release notes to people don't
unexpectedly loose VPN access by upgrading to Jammy. (Or explaining a
workaround, if one can be determined.)
** Package changed: tinc (Ubuntu) =>
Public bug reported:
The tinc included in Jammy (1.0.36-2build1 linked with libssl3) cannot
connect to tinc nodes running e.g. tinc from Xenial (1.0.26-1).
(Tinc from Impish, which is also v1.0.36-2 but is linked to libssl1.1,
can connect to these nodes without problems.)
The symptom is a log
(The change described in comment #6 was applied as a fix for LP:
#1465567)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1291434
Title:
GRUB_CMDLINE_LINUX_DEFAULT contains duplicate options
To
(In addition to the one mentioned by WirelessMoves, I found several
other Ubuntu Forum threads as well as blog posts, etc. which recommend
working around this problem by editing the /etc/cloud/cloud.cfg file to
set the "preserve_hostname:" line's value to "true". However, that
approach means
Presumably the ideal solution would be for Subiquity to hand off to
cloud-init in a manner that really only ran on that very first boot of
the new system.
However, assuming that a true fix to that situation is too invasive to
be included into Bionic at this point, it seems like it might be a good
When installing Ubuntu Server using Subiquity (i.e. using the
ubuntu-18.04-live-server-amd64.iso installer image), the user is
prompted to enter a hostname for the new installation (along with
username/password info, etc.)
At the very end of the Subquity run, it writes this info into
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1764172
Title:
Unable to change hostname from the one specified
** Summary changed:
- Unable to change hostname
+ Unable to change hostname specified during Bionic server installation
** Also affects: subiquity (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- Unable to change hostname specified during Bionic server installation
+
I ran into a problem with grub-legacy-ec2 v1:1 in Bionic (on an EC2
instance built from a Canonical Bionic AMI)... but the problem I found
relates to the switch from /var/run to /run, so it seems like it could
be related the earlier reports as well.
Specifically, what I noticed was the "The first
** Also affects: grub-legacy-ec2 (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- Running update-grub-legacy-ec2 doesn't cause /boot/grub/menu.lst
+ Running update-grub-legacy-ec2 doesn't update kernel list in
/boot/grub/menu.lst
--
You received this bug notification
On Thu, Aug 08, 2019 at 23:50:14 -, James Kingdon wrote:
> Hmm, you've got me curious now. It's been a while since I really looked
> at the ARM boards. sources.list.d contains armbian.list which has a
> single entry:
>
> deb http://apt.armbian.com xenial main xenial-utils xenial-desktop
>
>
On Thu, Aug 08, 2019 at 21:59:50 -, James Kingdon wrote:
> source.list is using http://ports.ubuntu.com/
Okay, interesting. So I guess most of your install is the armhf
architecture packages from ports.ubuntu.com. However, the the kernel
you mentioned (4.14.111-odroidxu4) isn't from there;
On Thu, Aug 08, 2019 at 18:57:24 -, James Kingdon wrote:
> Yes, hdparm -S.
Okay, thanks.
> Not sure if it's relevant, but the distro is 16.04.6 LTS
> (Xenial Xerus) in this case.
Okay, yeah, that makes a little more sense. Again, I don't know the
timeline on these specific kernels, but in
On Thu, Aug 08, 2019 at 18:05:55 -, James Kingdon wrote:
> I'm not sure what kernel was there before. I was expecting to see traces
> in /boot but the only references are to 4.14.133.
(Weird. I'm not familiar with the kernels for odroid, but off hand I'd
be suprised if the
** Summary changed:
- for Seagate USB drive enclosures, SAT (e.g. smartmontools) works on kernel
4.13 but not on 4.15
+ for Seagate USB drive enclosures, SAT (e.g. smartmontools, hdparm) works on
kernel 4.13 but not on 4.15
--
You received this bug notification because you are a member of
On Thu, Aug 08, 2019 at 15:27:20 -, James Kingdon wrote:
> I got hit by this after a power outage cycled my file servers and
> presumably activated a previous automatic kernel update (the servers
> normally stay up for months at a time).
>
> The kernel that is currently running is:
>
> Linux
@Mike/Robie:
Actually the "uas: Always apply US_FL_NO_ATA_1X quirk to Seagate
devices" patch to the kernel is (part of) the cause of the current
smartmontool failure rather than a fix for it.
The underlying problem is that most Seagate drive enclosures do not
properly handle SAT (= "ATA
Upstream bug related to the first half (issue 1 in original report) is
https://www.smartmontools.org/ticket/60
, "DEVICESCAN and hotplug"
** Bug watch added: www.smartmontools.org/ #60
https://www.smartmontools.org/ticket/60
--
You received this bug notification because you are a member of
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote:
> $ timedatectl status
> Network time on: yes
> NTP synchronized: yes
>
> So it seems it is synchronized, it just re-tries too frequently.
(I am not sure what exactly timedatectl looks at when checking the
status of ntpd, but
On Fri, Oct 19, 2018 at 14:36:35 -, Manuel López-Ibáñez wrote:
> Both of them work. I don't understand how the last command can work and
> I may still be behind a firewall.
"ntpdate -d" sends packets using an unprivileged source port, so
a firewall could allow those packets but block outgoing
** Bug watch added: Debian Bug tracker #775612
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775612
** Also affects: amanda (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775612
Importance: Unknown
Status: Unknown
** Bug watch added: Red Hat Bugzilla #1257686
I ran into this (using hdparm 9.48+ds-1 running under Ubuntu
16.04.1 LTS) with some HP Enterprise MB4000GCWLV drives that don't
have APM support (i.e.
hdparm -I /dev/sdb | grep "Advanced Power"
returns no output, or [as mentioned in comment #5] "hdparm -B"
reports "not supported").
For these
I'm not at all familiar with the net-tools source, but here's a quick
proof-of-concept patch to pull the list of interface names out of
/proc/net/dev (silently skipping any that don't support the SIOCGMIIPHY
ioctl [lo, lxcbr0, etc.]).
= first example =
./mii-tool_lp962616
enp4s0:
> Upstream fix http://net-tools.git.sourceforge.net/git/gitweb.cgi?p
=net-tools/net-
tools;a=commitdiff;h=9dc3a20511a409e1de1a41d715a10028d3bc1b56
This commit can be found at this updated URL:
https://sourceforge.net/p/net-tools/code/ci/9dc3a20511a409e1de1a41d715a10028d3bc1b56/
Not that the
Since Xenial now uses "predictable" interface naming schemes, mii-tool's
limit will affect most systems.
= first example =
# mii-tool
no MII interfaces found
# mii-tool $(cd /sys/class/net/; ls -d en*)
enp4s0: negotiated 100baseTx-FD, link ok
enp6s0: negotiated 1000baseT-FD flow-control,
Here are my current versions of the affected packages:
# dpkg -l ntp systemd | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Public bug reported:
I recently installed the ntp package on a fairly vanilla installed-from-
DVD Xenial system, and noticed that after the package installation both
systemd-timesyncd and ntp were running:
# systemctl status ntp systemd-timesyncd.service --no-pager
ntp.service - LSB: Start NTP
Looks like this bug is covered by debbugs #825317, "bash-completion: Un-
escaped "~*" leads to spurious NSS lookups"
** Bug watch added: Debian Bug tracker #825317
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825317
** Also affects: bash-completion (Debian) via
** Summary changed:
- chkrootkit gives false positive ebury
+ chkrootkit gives false positive Linux/Ebury - Operation Windigo
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508248
Title:
** Bug watch added: Debian Bug tracker #796599
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796599
** Also affects: chkrootkit (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796599
Importance: Unknown
Status: Unknown
--
You received this bug notification
The fix implemented in Fedora is to change the invocation of "$ssh -G" to
instead use "$ssh -H". See e.g.
http://pkgs.fedoraproject.org/cgit/rpms/chkrootkit.git/commit/?h=f23=82dd537b2fd88850eb4327a80b2c9acb7dbcf2ab
--
You received this bug notification because you are a member of Ubuntu
** Bug watch added: Red Hat Bugzilla #1234436
https://bugzilla.redhat.com/show_bug.cgi?id=1234436
** Also affects: chkrootkit (Fedora) via
https://bugzilla.redhat.com/show_bug.cgi?id=1234436
Importance: Unknown
Status: Unknown
--
You received this bug notification because you
The manpage for apt.conf doesn't mention any parameters (such as the
package names) that can passed to the DPkg::Post-Invoke hook.
Yeah, I agree that the DPkg::Post-Invoke hook doesn't seem to be passed
any useful info
I see that there is a Pre-Install-Pkgs hook, which is passed the list of
(One thing not handled by the cat /var/lib/dpkg/info/$P.list approach
described above is symlinks, e.g. /usr/bin/mail. These don't appear in
the dpkg .list file [as the actual executable files do], but when the
target of the symlink is changed then rkhunter will detect that as a
property mismatch
Getting the automatic update to be restricted to only the files actually
part of the upgraded package certainly makes sense.
However, when I experimented with this I found the package name option
only works if the rkhunter.dat file was originally built using the DPKG
value for the --pkgmgr, which
On Fri, Jan 16, 2015 at 18:05:04 -, Ryan Tandy wrote:
will no longer be used. But switching to nss-pam-ldapd is a good
recommendation anyway, since the older modules are dead upstream.
(In fact there is discussion underway regarding downgrading libnss-ldap
and libpam-ldap out of main; see
On Fri, Jan 16, 2015 at 18:05:04 -, Ryan Tandy wrote:
will no longer be used. But switching to nss-pam-ldapd is a good
recommendation anyway, since the older modules are dead upstream.
(In fact there is discussion underway regarding downgrading libnss-ldap
and libpam-ldap out of main; see
I was in the middle of testing this, too, when Randy posted his
message.
I got the same results he did for the 0.8.4 - 0.8.4ubuntu0.3 and 0.8.4
- 0.8.4ubuntu0.4 upgrades, using the uri value to test the upgrade
behavior.
Also, to follow up on the original report in Bug #1350778, I did an
If you are working on cleaning up the slapd.postinst script, you may
find some of these related discussions to be interesting and/or
helpful...:
LP: #450645 error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
LP: #632051 Improve slapd postinst error message in
If you are working on cleaning up the slapd.postinst script, you may
find some of these related discussions to be interesting and/or
helpful...:
LP: #450645 error during slapd configuration: chown: cannot access
`olcDbDirectory\nolcDbDirectory'
LP: #632051 Improve slapd postinst error message in
** Description changed:
[Impact]
- * When nslcd is upgraded, the config script runs and wrongly updates
-/etc/nslcd.conf with the name of the first AD server it finds. this
-should not happen.
+ * When nslcd is upgraded, the config and postinst scripts run and
+wrongly update
I tried upgrading to nlslcd 0.8.4ubuntu0.3 on a system where the ldap-
uris debconf entry was out of sync from the uri line in nslcd.conf,
and confirmed that the .conf file line was overwritten with the debconf
value, thus resulting in a non-working configuration. (The debconf-
show nslcd did not
On Tue, Sep 24, 2013 at 13:13:32 -, Simon Fraser wrote:
The guess_ldap_uri() function should only be called if /etc/nslcd.conf
is not usable, to prevent it overwriting valid configuration with
incorrectly guessed ones.
Looking more closely at the nslcd.config script, I'm pretty sure
that
The proposed nlscd package provided in LP: #1229713 successfully
installed without generating a broken nslcd.conf file, at least for the
case of my test server where the uri line was getting overwritten by a
stale debconf value in previous upgrades.
--
You received this bug notification because
Over in LP #1229713 nslcd auto-configuration disregards existing
nslcd.conf there's a proposed update package (currently available from
a PPA for testing) which includes the patch Arthur mentioned (in comment
#6) as a fix to Debian bug 717063.
--
You received this bug notification because you
I'm not sure can be considered a duplicate, but there's a similar
package-upgrade bug (or set of bugs) discussed in LP#1350778 .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229713
Title:
nslcd
** Tags added: precise regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1350778
Title:
Upgrading nslcd on precise rewrites /etc/nslcd.conf, leaving users
with unusable systems
To
Just to clarify the situation, the problem is that the current
nslcd.postinst script (i.e. the one in 0.8.4ubuntu0.3) unconditionally
rewrites various lines in the /etc/nslcd.conf file using the parameter
values pulled from the debconf database... which can lead to a non-
working configuration if
Public bug reported:
I noticed that when my Trusty systems upgrade from resolvconf
1.69ubuntu1 to 1.69ubuntu1.1 (from trusty-updates),
/etc/init.d/resolvconf is changed from a symlink pointing to
/lib/init/upstart into a normal file containing the Debian sysinit
startup script.
Is that change
Also note that another set up duplicates is added to the line each time the
grub-pc.postinst script is run -- on one of my Trusty systems I now see:
GRUB_CMDLINE_LINUX_DEFAULT=nomdmonddf nomdmonisw nomdmonddf nomdmonisw
nomdmonddf nomdmonisw
(I see that this value is also saved in the debconf
Hmm, one additional thing to note is that when /boot/grub/grub.cfg is
generated, each linux line created there gets an additional copy of the
keywords. That is, if I run dpkg-reconfigured grub-pc and strip the Linux
default command line prompt down to just nomdmonddf nomdmonisw and then let
In case there isn't a some better solution, here's a quick attempt at a
patch to the dmraid2mdadm.cfg script so that it only adds the keywords
to the value of GRUB_CMDLINE_LINUX_DEFAULT if it doesn't already contain
them. That would at least prevent the command line from accumulating
any
On Mon, Apr 28, 2014 at 19:11:59 -, Phill Whiteside wrote:
hmm...
root@build:/boot/grub# grep -r GRUB_HIDDEN *
root@build:/boot/grub#
No sign of GRUB_HIDDEN ?
The GRUB_HIDDEN... variables are found in /etc/default/grub .
Nathan
** Also affects: ntp via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** Also affects: ntp (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** No longer affects: ntp
** Also affects: ntp via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** Also affects: ntp (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672
Importance: Unknown
Status: Unknown
** No longer affects: ntp
Public bug reported:
the cron.daily/chkrootkit script's current logic for simplifying the
PACKET SNIFFER lines for dhclient and dhcpcd processes needs to be
updated to include the names of current versions of those binaries.
** Affects: chkrootkit (Ubuntu)
Importance: Undecided
We have found that chkrootkit now complains after each reboot, with a message
similar to:
-eth0: PACKET SNIFFER(/sbin/dhclient[895])
+eth0: PACKET SNIFFER(/sbin/dhclient[888])
---[ END: diff -u
Public bug reported:
the cron.daily/chkrootkit script's current logic for simplifying the
PACKET SNIFFER lines for dhclient and dhcpcd processes needs to be
updated to include the names of current versions of those binaries.
** Affects: chkrootkit (Ubuntu)
Importance: Undecided
We have found that chkrootkit now complains after each reboot, with a message
similar to:
-eth0: PACKET SNIFFER(/sbin/dhclient[895])
+eth0: PACKET SNIFFER(/sbin/dhclient[888])
---[ END: diff -u
** Patch added: debian/rules patch to generate default/grub file without
GRUB_HIDDEN_TIMEOUT= line
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1258597/+attachment/4070785/+files/grub2_debian_rules.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I don't have a build environment were I can actually test it, but here's
an attempt to update the debian/rules file so that (under Ubuntu) it
generates a /usr/share/grub/default/grub file that uses
GRUB_TIMEOUT_STYLE=hidden instead of a GRUB_HIDDEN_TIMEOUT= line.
(Note that grub-pc.config and
** Patch removed: debian/rules patch to generate default/grub file without
GRUB_HIDDEN_TIMEOUT= line
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1258597/+attachment/4070785/+files/grub2_debian_rules.patch
** Patch added: debian/rules patch to generate default/grub file without
The grub-pc package generates the initial /etc/default/grub file based
on /usr/share/grub/default/grub , which currently includes a
GRUB_HIDDEN_TIMEOUT=0 line.
There is logic in the .postinst script to comment out that line if the
grub-pc/hidden_timeout debconf value is set to False, but as far
(Some background info about this warning message and GRUB_HIDDEN_TIMEOUT's
deprecation can be found in the following threads:
http://lists.gnu.org/archive/html/grub-devel/2013-11/msg00388.html
http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00122.html
)
--
You received this bug
It looks like the GRUB_HIDDEN_TIMEOUT line in the /usr/share/grub/default/grub
file comes from the setting at about line 60 of the debian/rules file for the
grub2 source package (
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/grub2/trusty/view/head:/debian/rules
) :
ifeq
On Thu, Feb 27, 2014 at 21:47:26 -, Jamie Strandboge wrote:
This also affect openjdk-7.
** Also affects: openjdk-7 (Ubuntu)
Importance: Undecided
Status: New
For what it's worth, I tried running the GetInstance.java test
program on a Trusty sandbox machine, and it completed
I've tried running the GetInstance.java test case pulled out of
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c5d869453212
in a Precise development environment, and can confirm that it aborts with the
Cannot find any provider supporting RSA/ECB/OAEPPadding exception when run
using
On Tue, Feb 25, 2014 at 16:10:50 -, Stéphane Graber wrote:
By default, resolvconf will truncate the list of DNS servers after the
loopback address. This can be overriden by putting
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in
/etc/default/resolvconf
This behaviour is documented
Public bug reported:
After upgrading the various openjdk-6-* packages to version
6b27-1.12.6-1ubuntu0.10.04.4 on our server, all incoming client connections
started failing with the following error message at the top of the stack dump
(on the client side).
javax.xml.ws.soap.SOAPFaultException:
It looks like this is the JDK 6 version of the JDK 7 problem described in:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017173
That bug was apparently fixed in JDK 7 by this one-line commit:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/c5d869453212
In the JDK6 upstream, it
Ah, actually I see that for the 6b27-1.12.6-1ubuntu0.10.04.4 package the origin
of the change was not (directly) the JDK6 upstream but rather this backport of
that change in IcedTea 1.12.6::
We're also seeing this hang-on-reboot problem when running linux-
image-2.6.32-53-server and linux-image-2.6.32-50-server kernels in a Xen
guest... but in our case our Xen hypervisor is v4.0.
For what it's worth, I found this related discussion thread:
Additional note: Precise guests on the same Xen host don't have problems
rebooting, e.g. using the latest linux-image-3.5.0-43-generic kernel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1199987
Public bug reported:
When I attempt to use logger with the -n option, the syslog messages are sent
to the local
rsyslog process instead of the specified remote server:
$ logger -n log.example.com test message
$ echo another test message | logger -n log.example.com
** Affects: util-linux
In bsdutils 1:2.20.1-1ubuntu3 (Precise), the man page now says:
-f, --file file
Log the contents of the specified file. This option cannot be
combined with a command-line message.
Looks like this was changed upstream:
(I am running bsdutils 1:2.20.1-1ubuntu3, on a Precise box.)
Looks like upstream applied a simple patch similar to the one suggested in the
Debian bug:
http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=86248cd28a27bdd9a437e389966b0415e106802e
** Tags added: patch
--
You
** Bug watch added: Red Hat Bugzilla #822117
https://bugzilla.redhat.com/show_bug.cgi?id=822117
** Also affects: html2ps (Fedora) via
https://bugzilla.redhat.com/show_bug.cgi?id=822117
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a
Here's a patch that comments out the line in question (applied against
the Ubuntu html2ps 1.0b7-1 package).
** Patch added: comment out the deprecated line
https://bugs.launchpad.net/ubuntu/+source/html2ps/+bug/1130851/+attachment/3650902/+files/html2ps.lp1130851.patch
--
You received this
On Thu, Apr 04, 2013 at 23:14:02 -, Barry Warsaw wrote:
I have a horribly ugly workaround for PyCurl in the works. I'll link a branch
when ready, but I want to get Matthias's input to see if a toolchain fix is
more appropriate.
(Since you have an environment set up to build the
On Fri, Apr 05, 2013 at 14:02:13 -, Nathan Stratton Treadway wrote:
you to try building the package (without the workaround patch) against
libssl instead of libgnutls? That might be a fairly-easy way to test the
(More precisely: libcurlX-openssl instead of libcurlX-gnutls
On Fri, Apr 05, 2013 at 15:02:54 -, Barry Warsaw wrote:
To be honest, I don't really have much more time to spend investigating this.
The workaround fixes the problem and while a bit wasteful, seems harmless
enough. Since Doko agrees, I think I'll just apply this for now, and maybe we
can
On Thu, Apr 04, 2013 at 21:06:58 -, Barry Warsaw wrote:
Yes, 32bit Raring has this problem, 64bit does not apparently.
I'm curious if the machine you are using is also an MMX-but-not-SSE2
machine; what does
grep -E name|flags /proc/cpuinfo
show?
Or are you saying that you found the
On Thu, Apr 04, 2013 at 23:14:02 -, Barry Warsaw wrote:
when ready, but I want to get Matthias's input to see if a toolchain fix is
more appropriate.
Yeah, I was wondering about that too.
It seems like the problem probably originates somewhere in libgnutls26
or below, since it's only
On Thu, Mar 14, 2013 at 18:36:52 -, Douglas King wrote:
currently it affects ppa:n-muench/calibre2 and ppa:n-muench/calibre
If you are experiencing the same bug as I am, you will get the same
error no matter what PPA you are trying to add. In other words, the
problem is with your local
I found a Redhat bug that seems to be related:
https://bugzilla.redha t.com/show_bug.cgi?id=758446
(It's for a different Python program, but pycurl is used there, too, and in it
NaNs are similarly showing up in unexpected places.)
In comment #9, Zdeněk Pavlas suggests the problem might
On Wed, Mar 06, 2013 at 11:18:25 -, Paul BROWN wrote:
I can confirm this patch worked for me!
Cool.
I'm curious if you get the same result I do when running the direct
python test mentioned in comment #10.
Actually, here's basically the same test, but in a format easier
to cut-and-paste
The significant change between python-software-properties 0.82.7 and
0.82.7.3 is in the .3 release: softwareproperties/ppa.py: download gpg
key to temporary keyring, and validate using v4 fingerprint before
importing to apt keyring. (Specifically, that change is the reason
that
Actually, it looks like the problem is in pycurl, since calling .close()
seems to cause the very next floating point operation to return NaN.
(In the case of add-apt-repository, that floating point operation just
happens to be in the random() call invoked from inside the
tempfile.mkdtemp()
Given that performing any sort of floating-point operation seems to
clear the error condition, I tried simply added a dummy = 1.0/2 line
to the get_ppa_info_from_lp() function immediately after the
curl.close() line (see attached patch)... and after that add-apt-
repository successfully processed
** Summary changed:
- add-apt-repository and apt-add-repository fails
+ add-apt-repository/apt-add-repository fails with ValueError: cannot convert
float NaN to integer
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
On Wed, Dec 05, 2012 at 04:25:10 -, tdeering wrote:
Still no DNS resolution when connected to the VPN. I'm fairly certain
that 10.0.0.1 really is the intended/correct address of the VPN
nameserver, but I will double-check with the owner. I do know, however,
that the VPN network setup has
Red Hat bug no. 836803, RHEL6: Potential fix for leapsecond caused futex
related load spikes:
https://bugzilla.redhat.com/show_bug.cgi?id=836803
** Bug watch added: Red Hat Bugzilla #836803
https://bugzilla.redhat.com/show_bug.cgi?id=836803
--
You received this bug notification because you
Note that even though it's been a while since the leap second, a kernel
affected by this bug could persist with its desynced internal idea of
time, and the system would show no noticable symptoms until someone
eventually runs an effected application. (See
https://lkml.org/lkml/2012/7/1/203 and
(Revised the script to set its exit status based on the results of the
testing.)
** Attachment removed: Python script to check for post-leap-second sub-second
timeouts issue
Debbugs #679882 pulls together a list of various leap-second-related kernel
patches:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679882
** Bug watch added: Debian Bug tracker #679882
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679882
--
You received this bug notification because
1 - 100 of 404 matches
Mail list logo
