Did you re-export the backup after applying the patch?
IIRC it fixes the backup/export phase not the restore/import phase so
unless you re-created the dumps it wouldn't have actually done anything.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Did you re-export the backup after applying the patch?
IIRC it fixes the backup/export phase not the restore/import phase so
unless you re-created the dumps it wouldn't have actually done anything.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
*** This bug is a duplicate of bug 956051 ***
https://bugs.launchpad.net/bugs/956051
** This bug has been marked a duplicate of bug 956051
libc6 crash while running 'xm'
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Attached is a debdiff for the patch proposed in comment #7 by jwestfall:
disabling FMA4 if AVX support is unavailable.
A package containing this patch has been pushed to my lpbugs PPA at:
https://launchpad.net/~kmdm/+archive/lpbugs/
IMPORTANT NOTE: This is *UNTESTED* since due to commercial
Public bug reported:
Hi,
I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4 LTS
to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
supported yet).
The incompatible database upgrading process in the preinst/postinst
files failed in the following scenario.
We
(If requested I can provide a suitable debdiff for the proposed fix)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1003854
Title:
Database upgrade/migration fails with nested db
Public bug reported:
Hi,
I've just performed an upgrade of our LDAP server on Ubuntu 10.04.4 LTS
to Ubuntu 12.04 (I acknowledge this upgrade path is not officially
supported yet).
The incompatible database upgrading process in the preinst/postinst
files failed in the following scenario.
We
(If requested I can provide a suitable debdiff for the proposed fix)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1003854
Title:
Database upgrade/migration fails with nested db directories (lucid
Would appear the procedure for disabling the ssh component of gnome-
keyring has changed, from the Gnome site:-
Use the Startup Applications capplet (ie: gnome-session-properties) and
disable the SSH Key Agent startup program.
-- http://live.gnome.org/GnomeKeyring/Ssh
Performing the above
As attached:-
http://launchpadlibrarian.net/26008536/LP367577.patch
...is a debdiff.
I've long since moved to karmic (where the issue is fixed) so my
interest in this bug as waned since then.
But, if that debdiff isn't valid for sponsoring I'd very much appreciate
an explanation so I don't
I'd like to double check this again before confirming hardy PAM is ok
with usernames of this length but unfortunately I seem to have
lost/deleted the test VM where I had this issue setup.
I'll re-create the VM and re-test this issue just to be sure (give me a
couple of days or so depending on
I'd like to double check this again before confirming hardy PAM is ok
with usernames of this length but unfortunately I seem to have
lost/deleted the test VM where I had this issue setup.
I'll re-create the VM and re-test this issue just to be sure (give me a
couple of days or so depending on
@Steve:
Thanks for taking a look at this bug.
In my opinion the other upstream cherry picks are not needed to pass -s
to cryptsetup (I've been running with the first/original fix for several
months now without issue).
I believe the other cherry picks are a separate but very closely related
bug
** Description changed:
vsftpd has a max username length of 32, this is too small for a virtual
hosting environment where the username is a user's e-mail address (if
they have a long domain name etc...)
This issue was patched in FC10 via their patch system and has been
pulled into
Just spotted a slight error in my debdiff. I made my debdiff against
2.0.6-1ubuntu1, failing to notice the -ubuntu1.1 in hardy-updates.
I'll submit an updated patch/debdiff later today against -ubuntu1.1 if
someone else doesn't do so before hand.
TESTING NOTE: Please note that although the
** Description changed:
vsftpd has a max username length of 32, this is too small for a virtual
hosting environment where the username is a user's e-mail address (if
they have a long domain name etc...)
This issue was patched in FC10 via their patch system and has been
pulled into
Just spotted a slight error in my debdiff. I made my debdiff against
2.0.6-1ubuntu1, failing to notice the -ubuntu1.1 in hardy-updates.
I'll submit an updated patch/debdiff later today against -ubuntu1.1 if
someone else doesn't do so before hand.
TESTING NOTE: Please note that although the
Apologies for the mix up...
Updated patch attached to bug, old one removed (and new testing package
pushed to my PPA). :-)
** Attachment removed: LP343738-hardy.patch
http://launchpadlibrarian.net/30764250/LP343738-hardy.patch
** Attachment added: LP343738-hardy.patch
I'd just like to add that (as the original bug reporter) I agree with
Trent entirely. I can setup accounts (longer than 32 characters) that
work just fine with PAM (and etc...) yet vsftpd fails to authenticate
with them.
Although I can accept it's a somewhat grey area in this case between bug
and
@Mathias
In my opinion I would think:-
Bugs which do not fit under above categories, but (1) have an obviously safe
patch and (2) affect an application rather than critical infrastructure
packages (like X.org or the kernel).
--
vsftpd max username length too small
@Mathias:
You make an excellent point. Oversight on my part not realising I'd only
prepared a jaunty diff and not a hardy one for SRU.
I've re-based the jaunty diff against hardy and attached it to the bug
(as well as pushing it to my PPA for testing purposes).
** Attachment added:
Could very well be, upstream used the constant HXSIZEOF_Z32, I merely
used the value of that constant in the created debdiff which was
-4294967296.
If indeed it is flawed here then it's arguably also flawed upstream so
please do consider reporting it there as well.
--
mount.crypt needs to pass
Worth noting is two other commitdiffs from upstream that re-add support
for overriding the keysize (and then fixing the first patch) - the use-
case for this is given with an example keysize of 448:-
(Re-)Add support for overriding keysize:-
Discussion for the latter changes:
http://sourceforge.net/tracker/?func=detailaid=2727353group_id=41452atid=430594
** Bug watch added: SourceForge.net Tracker #2727353
http://sourceforge.net/support/tracker.php?aid=2727353
--
mount.crypt needs to pass -s to cryptsetup
@jcfp:
Strange, so if you run mount.crypt manually from the command line with
the attached patch it (mysteriously) passes through 104 instead of 448?
Can you paste the output of running the mount.crypt command with the -v
parameter? Just curious to see what's going on there since it works
I just failed to reproduce this on karmic, although karmic does have a
newer memcached version (1.2.8)
@fidian:
Can you provide the output of:-
$ find /etc -maxdepth 2 -name \*memcached\* -path \*rc?.d\*
and
$ cat /etc/default/memcached
Thanks!
--
Memcached not active after reboot on
Just reproduced this on karmic. Both as described and after installing
the binary package.
** Changed in: pitivi (Ubuntu)
Status: New = Confirmed
--
pitivi crash after compilation from source under jaunty
https://bugs.launchpad.net/bugs/374948
You received this bug notification because
Solved...
We already carry a patch in debian/patches to fix this issue. The
submitter hasn't patched the files with this patch and so it fails.
The binary package *DOES* work, it only failed since I happened to be in
the CWD of the package so it pulled in the unpatched files from pitivi/
rather
Package pushed for testing to my lpbugs PPA.
--
reportbug should depend on python-urwid
https://bugs.launchpad.net/bugs/324268
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Debdiff attached for karmic which moves python-urwid to Recommends: from
Suggests:
** Attachment added: LP324268.diff
http://launchpadlibrarian.net/26585971/LP324268.diff
--
reportbug should depend on python-urwid
https://bugs.launchpad.net/bugs/324268
You received this bug notification
Debdiff attached. I've also pushed the package for review/testing to my
lpbugs PPA.
** Attachment added: LP375098.diff
http://launchpadlibrarian.net/26600402/LP375098.diff
--
[hardy] libdkim-dev missing
https://bugs.launchpad.net/bugs/375098
You received this bug notification because you are
Public bug reported:
libdkim-dev is not available in hardy since it was superseded by dkim-
milter which was subsequently deleted.
In intrepid and onwards this issue has been resolved by increasing the
epoch number in the package version and once I have this bug number I'll
add a debdiff which
** Tags added: packaging patch
** Description changed:
libdkim-dev is not available in hardy since it was superseded by dkim-
milter which was subsequently deleted.
In intrepid and onwards this issue has been resolved by increasing the
epoch number in the package version and once I
@Steve:
Thanks for looking at this bug. Yes, merging that revision from Debian
would solve the issue for karmic (and indeed resolve this bug).
Would it be possible to nominate this debdiff for SRU to Hardy? Since I
believe it fulfils the requirements of:-
a) non-critical package
b) very minimal
@Sami:
My Jaunty install is able to receive files fine from my N80 (and my N80
was a victim of this bug). I do not have the gnome-bluetooth package
installed.
Did you have gnome-user-share and obex-data-server installed?
--
Cannot receive files using bluetooth
Jaunty test package with the debdiff applied has now been submitted to
my PPA.
--
mount.crypt needs to pass -s to cryptsetup
https://bugs.launchpad.net/bugs/367577
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
** Tags added: patch
--
mount.crypt needs to pass -s to cryptsetup
https://bugs.launchpad.net/bugs/367577
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Attachment added: LP367577.patch
http://launchpadlibrarian.net/26008536/LP367577.patch
--
mount.crypt needs to pass -s to cryptsetup
https://bugs.launchpad.net/bugs/367577
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Public bug reported:
mount.crypt needs to pass the -s option to cryptsetup or in some cases
mount.crypt fails to mount the encrypted volume. In my case this is
where I've used a keysize of 128 bits, but 256 is the default so unless
something tells cryptsetup the keysize is 128, it proceeds to
@Matt:
Which patch are you using? (The 0.4 codeka patch works for me, I've yet
to try Jonathan's updated patch.)
Also, in LCDd.conf what does the Driver= line say? I'm assuming it says
imonlcd?
I'll try to get someone at home to power on my htpc machine so I can ssh
into it and pull the config
@Matt...
Yep, I have the same problem. We're going to have to defer to Jonathan
on this one.
I've tried using usbmon+debugfs to sniff the Windows driver sending
commands to the LCD during a shutdown under vmware... Unfortunately I
haven't had much time to spend on this so I don't have much to
@Jonathan:
A week or so ago I downloaded what I believe is the latest patch, but
I'm having trouble compiling it.
Trying to build under intrepid/amd64 or intrepid/i386:-
if x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../..
@LIBUSB_CFLAGS@ @LIBFTDI_CFLAGS@ -fPIC -Wall -Wall -O3
@Jonathan...
Thanks for that, I can confirm it compiles ok.
I'm not at home so I can't test this at the moment so if anyone is
feeling really brave I've pushed intrepid packages to my (personal) repo
@ packages.kennynet.co.uk (intrepid-testing).
I'll try to give it a test tonight / over the
@Matt:
Well, I'd advise the adage of if it ain't broke don't fix it but if
you're feeling adventurous the jaunty packages should be pushed too
(jaunty-testing).
Let me/Jonathan know how you get on (I haven't even had time to test it
yet, I don't even have a jaunty machine here to check the repo
@Jonathan:
Patch works for me, thanks.
This patch is worth it just for the Protocol= option IMO. :-)
If Matt Price confirms it works in Jaunty I'll create a debdiff and see
if we can get it sponsored into the ubuntu package, although I'm
guessing by now that'll be Karmic!
--
lcdproc needs
Can this package now be backported to intrepid since intrepid-backports
currently has version: 0.8.4a0ubuntu2~intrepid1, in which lirc-
modules-source although on the user's own machine does FTBS.
I'm afraid I'm not sure how SRU requests involving updating backported
packages work.
--
Hmm, ok... I only subscribed sponsors for universe since this page
listed the component as universe:-
https://launchpad.net/ubuntu/jaunty/i386/lirc-modules-source
Am I missing something?
--
lirc-modules-source gives an error while building with dkms
https://bugs.launchpad.net/bugs/306346
You
Public bug reported:
vsftpd has a max username length of 32, this is too small for a virtual
hosting environment where the username is a user's e-mail address (if
they have a long domain name etc...)
This issue was patched in FC10 via their patch system and has been
pulled into the new upstream
Debdiff for jaunty which reflects the FC10 patch which has been
incorporated upstream in version 2.1
** Attachment added: LP343738.patch
http://launchpadlibrarian.net/23927354/LP343738.patch
** Changed in: vsftpd (Ubuntu)
Status: New = Confirmed
--
vsftpd max username length too
** Tags added: patch
--
vsftpd max username length too small
https://bugs.launchpad.net/bugs/343738
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
@Alexander:
With obex-data-server 0.4.3 being accepted into jaunty I believe this
bug can be satisfied by backporting that version to intrepid, ideally as
a SRU but even having it in intrepid-backports would help).
(A backport to hardy is alot more invasive due to bluez library version
Debdiff for intrepid that adds the driver to the lcdproc package,
package submitted to my PPA for testing purposes (but as of time of
commenting, not yet built).
Most of the patch just adds files to build the imonlcd.so driver and so
should be contained and not effect any of the other drivers.
Simple patch refresh against jaunty.
** Attachment added: LP153185-jaunty.patch
http://launchpadlibrarian.net/23590014/LP153185-jaunty.patch
--
lcdproc needs patch for the imon lcd
https://bugs.launchpad.net/bugs/153185
You received this bug notification because you are a member of Ubuntu
*** This bug is a duplicate of bug 306346 ***
https://bugs.launchpad.net/bugs/306346
** This bug has been marked a duplicate of bug 306346
lirc-modules-source gives an error while building with dkms
--
lirc dkms build fails to missing semaphore.h
https://bugs.launchpad.net/bugs/327359
I'm attaching an updated debdiff for jaunty with a more complete patch
that I've just found in LP: #305288.
Unfortunately I don't have a PVR150 to test out the module itself, both
patches allow the module to build successfully and thus fix the broken
package issue which makes lirc 0.8.4a
** Attachment added: LP306346-jaunty-updated.debdiff
http://launchpadlibrarian.net/23364030/LP306346-jaunty-updated.debdiff
--
lirc-modules-source gives an error while building with dkms
https://bugs.launchpad.net/bugs/306346
You received this bug notification because you are a member of
@Mircea: That was my plan. Basically I'm trying to tackle this in two
stages:-
1) Does it build without replacing the lirc_imon driver ?
2) Does it build with replacing the lirc_imon driver ?
Did the DKMS build succeed after you did the remove and then install?
If not, can you give me the
@Mircea:
Thanks for the clarification - the scope of this bug is limited to step
1 only, since with the debdiff fixes I've posted above the package will
once again work for everyone whereas currently it fails as it stands.
(E.g. the package is broken in the repositories.)
Can I get a sponsor for
@Mircea:
If by the package installs successfully you mean DKMS is able to build
all the modules then this bug is completely solved. There's no way
Ubuntu can support the arbitrary replacement of files once a package is
installed. (I'm not affiliated in any way with Ubuntu, mind.)
If however you
Just quickly tested the patch on my jaunty VM and it appears to work,
I've attached the debdiff refreshed against jaunty.
** Attachment added: LP306346-jaunty.debdiff
http://launchpadlibrarian.net/23266852/LP306346-jaunty.debdiff
--
lirc-modules-source gives an error while building with dkms
@Mircea:
Ah, can you try removing lirc-modules-source and then reinstalling it
again, e.g. apt-get remove then apt-get install... Maybe DKMS just needs
to remove what's there and then reinstall - I might have done that in my
testing.
--
lirc-modules-source gives an error while building with
I believe I've fixed this issue for intrepid with the attached debdiff,
I've also pushed the package to my PPA so it should be available from
there in the next hour or two.
** Attachment added: LP306346.debdiff
http://launchpadlibrarian.net/23235825/LP306346.debdiff
--
lirc-modules-source
@Max...
Tested before upgrading to obex-data-server 0.4.3 - failed.
Tested after upgrading to obex-data-server 0.4.3 - SUCCESS.
I've built a package for obex-data-server 0.4.3 in my PPA:
https://launchpad.net/~ubuntu-kennynet/+archive/ppa
The installation process is as follows...
1. Add my
Jeff,
Launch gconf-editor, apps/gnome-keyring/daemon-components, uncheck ssh.
Restart X. ssh-agent should start.
- http://bugzilla.gnome.org/show_bug.cgi?id=525574
--
Unable to disable the ssh module of gnome-keyring
https://bugs.launchpad.net/bugs/275010
You received this bug notification
This bug is more than likely a duplicate of: #209447
Can the OP or Chris provide echo $SSH_AUTH_SOCK so we can confirm gnome-
keyring-daemon is infact being used?
--
ssh-agent does not expire key
https://bugs.launchpad.net/bugs/252200
You received this bug notification because you are a member
*** This bug is a duplicate of bug 209447 ***
https://bugs.launchpad.net/bugs/209447
That's certainly gnome-keyring's socket.
I'm going to go ahead mark this bug a duplicate, for a work around
please see bug: #209447.
The work around involves resetting your ssh-agent back to the standard
This bug is more than likely a duplicate of: #209447
Can the OP or Chris provide echo $SSH_AUTH_SOCK so we can confirm gnome-
keyring-daemon is infact being used?
--
ssh-agent does not expire key
https://bugs.launchpad.net/bugs/252200
You received this bug notification because you are a member
*** This bug is a duplicate of bug 209447 ***
https://bugs.launchpad.net/bugs/209447
That's certainly gnome-keyring's socket.
I'm going to go ahead mark this bug a duplicate, for a work around
please see bug: #209447.
The work around involves resetting your ssh-agent back to the standard
As a workaround for myself I've built a version of the gnome-keyring
package that is compiled without ssh support and so it doesn't act as a
SSH agent...
I've attached a debdiff which will do the above, you just need to build
the package, alternatively, i've submitted the package to my PPA and
I've modified the description to hopefully include the required
information for the SRU update nomination to Hardy for bluez-utils. I'm
unable to modify for the obex-data-server bug since I cannot reproduce
it.
** Description changed:
Binary package hint: obex-data-server
Description:
Ok so here's my first attempt at tracking down the upstream fix and
creating a debdiff (for Hardy).
Unfortunately I don't experience this issue with either my Nokia N80 (or
my girlfriends N73) so the best I can report is that I don't suffer a
regression from using the fixed package.
I've sent
Please also make sure that obex-data-server actually gets restarted,
I've seen instances where unticking the option in bluetooth preferences
doesn't actually kill the process (this could be a separate bug but hey-
ho or it could mean I should untick it then upgrade then retick it). :-)
--
Cannot
Thanks for that Whoopie, I've updated my test package (and debdiff) to
reflect your patch.
The test package is queued in the PPA build system so once it'll be
ready for testing as described above.
** Attachment added: obex-data-server_0.3.1-0ubuntu2~test2.debdiff
I can't reproduce this bug on a Nokia 6630i so someone else will need to
test it. (The ~test2 package is built and ready in my PPA now.)
--
Cannot recieve files using bluetooth
https://bugs.launchpad.net/bugs/211252
You received this bug notification because you are a member of Ubuntu
Bugs,
Having just built my intrepid partition I can now confirm Emmet's
attached debdiff fixes the problem for me on Intrepid. Before the the
patch sending files to my laptop over bluetooth failed. After applying
the debdiff, building and installing the resultant deb I was able to
send files to my
75 matches
Mail list logo
