Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Sat, Jan 6, 2024 at 12:52 PM Mathias Gibbens wrote: > > Late last night I successfully built Incus as a Debian package for > the first time! ️ Nice! > There are two blockers before we can perform the initial upload to > NEW: > > 1 -- Remaining build deps: > > * We're still waiting on bin:golang-github-canonical-lxd-dev to > make it through NEW. > > * golang-github-grafana-dskit-dev still needs to be packaged, but > Incus seems to only have a single use of that library in > internal/server/loki/loki.go. Last night I just patched out any > reference in loki.go to dskit/backoff so everything else could build. > Obviously not an ideal approach. However, do we want to consider > disabling loki support in Incus for the time being to facilitate > getting Incus into Debian? I'll keep working on packaging dskit and > eventually we can re-enable loki support once it's packaged. I'm not terribly familiar with the LOKI integration but that particular dependency has been bothering me for a while given how much stuff it pulls in. I'd love to see it gone, but I'd have to figure out exactly what's needed and how easy it may be to re-implement. I wouldn't expect the LOKI log ingest protocol to be so complicated that it needs such a large dependency chain. > 2 -- Testing/QA: > > * General testing: Later today I'm planning to start testing Incus > on a sid machine. I'm sure this will turn up various things to > fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure > containers and VMs work out-of-the-box. > > * LXD migration: Simple migrations from LXD to Incus should work. > > * QA: Go through the debian/ directory in the Incus packaging to > make sure it's all in good shape and is synced up with current LXD > packaging work. > > Excited to be close to the finish line on this! Yep, exciting times! > Mathias -- Stéphane
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Yeah, it's my current plan to keep providing image server access to Debian users until the trixie release or until Incus makes it to bookworm-backports whichever happens first. We don't really want to block access to users who don't have a good way out. So while the published plan is fast paced and sounds pretty strict, we fully expect to be making exceptions where they make sense and where a clear timeline is known (as is the case with the trixie release). Stéphane On Wed, Dec 27, 2023, 1:03 p.m. Free Ekanayaka wrote: > Free Ekanayaka writes: > > > Raphael Hertzog writes: > > > >> Hello, > >> > >> On Tue, 26 Dec 2023, Mathias Gibbens wrote: > >>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: > >>> > I would really like to see incus in unstable/testing and even in > >>> > bookworm-backports at some point. > >>> > >>> Given the large number of new/updated dependencies for Incus, it > >>> would be a lot of work to properly prepare a release for bookworm- > >>> backports once Incus gets into unstable. Not saying that it couldn't be > >>> done, but I don't know if it would be worth the effort. If you would > >>> like to use Incus on bookworm right now, probably the best approach > >>> would be to install the package from Stéphane's repo: > >>> https://github.com/zabbly/incus. > >> > >> If we want to run debusine on a DSA-managed servers, we need to have > >> packages available on official Debian repositories, hence > >> bookworm-backports as installing packages from testing/unstable is out > of > >> question. :-| > > > > I agree with Mathias that having Incus in bookworm-backports requires > > quite a bit of work. It's probably doable (although we'll have to assess > > if that'd introduce tricky dependency conflicts), but perhaps having > > some more folks helping with it would make it more feasible. > > BTW, assuming that you don't need any "new" feature from later lxd/incus > releases, one option would be to have debusine conditionally use the lxd > package from bookworm when running on bookworm and incus when running on > trixie (or alternatively just use lxd on both and migrate later on down the > road). I think that would be much less work than backporting. > > The only problem would be that the image server run by LinuxContainers > is going to phase out support for LXD [0], so at some point bookworm's > lxd package will stop being able to pull images from there. > > One workaround would be to have Stéphane make an exception to the phase > out plan, and let bookworm's lxd keep working normally (at least until > trixie is released). I'm not sure how much he's willing to do that, but > I believe he's open to that possibility if other options (like > backporting incus) are not quite viable. > > [0] > https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479 >
Bug#1058592: LXD licensing changes and future for Debian packaging
Currently lxd-to-incus looks for the existing running LXD daemon to validate the user configuration ahead of migrating the data to Incus, that's why we need the LXD Go package for it, we actively interact with the LXD API before shutting it down for the migration. So if you want to get rid of LXD in Trixie, you're going to want to run the migration tool from preinst which doesn't seem ideal. Or at least put in a debconf prompt to force the user to go and run the migration logic before being allowed to continue with their system upgrade. An alternative is to turn the lxd and lxd-client packages into orphans, so they can still be on the system and running when the user installs Incus and runs the migration tool. Downside of this approach is that the user may not be aware of this situation and as those binaries wouldn't be in the archive anymore, there's no way for them to pull incus onto the system. Stéphane On Wed, Dec 13, 2023, 6:07 p.m. Free Ekanayaka wrote: > Hello Mathias, > > thanks for the thoughtful write-up. > > I'm pretty much on board with everything you said. > > The only detail I'm not totally sure about is whether it would actually > be beneficial to have trixie ship LXD 5.0 (at commit ^1364ae4). It's > true that it'd be an out-of-date LXD, but it might be handy for folks > upgrading from bookworm and not wanting to contextually migrate to > Incus, but rather leave that as a separate step later down the road. > > It's kind of a minor point, and something that I believe won't be such a > big deal in practice. So I'd be also perfectly fine not shipping the LXD > binary at all in trixie. > > Free > > Mathias Gibbens writes: > > > Control: retitle -1 LXD licensing changes and future for Debian packaging > > Control: severity -1 important > > > > Hi Jonathan, > > > > (Adding Free and Stéphane for their awareness) > > > > Free and I have been working on getting Incus packaged for Debian > > (see ITP#1042989 and https://wiki.debian.org/Incus). Free's getting a > > couple new dependencies into the archive, and we have to update some > > golang libraries, but once that's done we'll be able to get Incus > > officially into Debian. > > > > Up to this point, I had been planning to help maintain both LXD and > > Incus packaging for Debian so users could easily install either > > version. However, given Canonical's recent actions, I am pretty > > unmotivated to continue working on the LXD packaging. Their relicensing > > mess will make updating d/copyright for the next feature/LTS release a > > ton of work, and while LXD is still open source, it's very much a > > Canoncial-only project now with their CLA. (For the record, if anyone > > else is interested in helping maintain the LXD package, please feel > > free to do so!) > > > > So, what does the future of LXD in Debian look like? After some > > thought, this is what I'm envisioning: > > > > 1. Import the LXD stable-5.0 branch as a snapshot at the last commit > > before the relicensing announcement (upstream commit 1364ae4: "Merge > > pull request #12652") to get the last 5.0 LTS fixes/changes released > > under Apache-2.0. Importantly, this will pull in the import path > > changes when LXD was moved into Canonical's group on Github, which > > `lxd-to-incus` is expecting. > > > > 2. Upload this snapshot version of LXD to unstable, with lots of > > documentation about LXD likely not receiving further updates in Debian, > > and to consider switching to Incus. > > > > 2b. As part of that upload, introduce a bin:golang-github- > > canonical-lxd-dev package to facilitate building Incus. > > > > 3. Finish getting Incus packaged and into an equivalent shape as the > > current LXD packaging. Also make sure migrations from LXD to Incus work > > smoothly on Debian. > > > > 4. When Incus is sufficiently "mature" (either version 1.0 or we feel > > it would be proper to include in a stable Debian release), if no one > > else has expressed interest/willingness to maintain LXD's packaging in > > future Debian releases, we can modify src:lxd to no longer ship any > > binaries. Rather, it would then serve as a transitional package to > > src:incus for the bookworm -> trixie upgrade cycle. The only "real" > > binary package left would be bin:golang-github-canonical-lxd-dev, for > > use by Incus. > > > > 5. After the trixie release, file a RM bug for LXD. > > > > As for a timeline, we're roughly a year out from the trixie freezes > > starting, so that's how long we have to complete the LXD -> Incus > > transition for Debian. The alternative would be trixie shipping with a > > pretty old version of LXD, which I would like to avoid if possible. > > > > Other thoughts or opinions? > > > > Mathias >
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka wrote: > > Hey, > > I would think that Stéphane will want to backport these changes to the > 3.0.x series, as they improve performance considereably. It wouldn't be > a big change for the LXD code itself, since this is mostly "backend" > code. Yes, we will be backporting the switch to the new dqlite implementation in the 3.0.x branch, should be in 3.0.2. > I'll Stéphane say the last workd tho. > > Thanks for the initiative, looking forward to see LXD in Debian! > > Free > > Clément Hermann writes: > > > Hi, > > > > On 31/07/2018 17:28, Free Ekanayaka wrote: > >> Hello Clement, > >> > >> dqlite upstream and LXD team member here. > >> > >> Please note that dqlite is going through a bit of change, which I > >> started to merge yesterday. So a few of the ITPs you have filed will no > >> longer make sense. > > > > Thanks a lot for the heads up! > > > >> In a nutshell: > >> > >> 1) https://github.com/CanonicalLtd/dqlite is now a C project > >> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings > >> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore > >> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore > >> > >> This will all be effective starting with LXD 3.4, to be released in 3 > >> weeks. > >> > >> In LXD master, this will be effective once we land: > >> > >> https://github.com/lxc/lxd/pull/4854 > >> > >> which should happen today or tomorrow at latest. > > > > Good to know! I guess this won't change anything for 3.0.x series ? > > That's what we're aiming for, since we want to package the LTS version: > > the users needing cutting-edge version should use the snap IMO. > > > > Cheers,
Bug#853531: Upstream GCC bug
This issue is a compiler bug, tracked upstream. LXC upstreams has received reports of this affecting ArchLinux and OpenSUSE after they switched to gcc 7.1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: PGP signature
Bug#851473: snapd fails to run when apparmor is enabled
Package: snapd Severity: important Version: 2.20-2 Hello, On a clean stretch install, booted with apparmor enabled (security=apparmor apparmor=1), snapd fails to run due to apparmor failures. It appears to be caused by the fact that /lib is a symlink to /usr/lib, with the symlinks getting resolved and so failing because the apparmor profile only contains /lib paths. There is that and a failure to execute snap-exec if I remember correctly. It'd be great to have this fixed as snapd will very actively try to use apparmor if it's enabled in the kernel. To the point where disabling the apparmor profiles for snapd leads to another failure as snapd fails to manually change profile then. Stéphane signature.asc Description: PGP signature
Bug#746712: Please update the loginuid patch to match upstream's current version
Package: pam
Hello,
The loginuid patch currently applied to PAM in Debian is out of date and
doesn't contain the latest fixes I have submitted upstream.
I'm attaching the current version of the loginuid patch as we have it in
Ubuntu which should be a straight copy of what was merged upstream.
This change is required to get sshd properly working inside unprivileged
LXC containers.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
Author: Stéphane Graber stgra...@ubuntu.com
Description: pam_loginuid: Ignore failure in user namespaces
When running pam_loginuid in a container using the user namespaces, even
uid 0 isn't allowed to set the loginuid property.
.
This change catches the EACCES from opening loginuid, checks if the user
is in the host namespace (by comparing the uid_map with the host's one)
and only if that's the case, sets rc to 1.
.
Should uid_map not exist or be unreadable for some reason, it'll be
assumed that the process is running on the host's namespace.
.
The initial reason behind this change was failure to ssh into an
unprivileged container (using a 3.13 kernel and current LXC) when using
a standard pam profile for sshd (which requires success from
pam_loginuid).
.
I believe this solution doesn't have any drawback and will allow people
to use unprivileged containers normally. An alternative would be to have
all distros set pam_loginuid as optional but that'd be bad for any of
the other potential failure case which people may care about.
.
There has also been some discussions to get some of the audit features
tied with the user namespaces but currently none of that has been merged
upstream and the currently proposed implementation doesn't cover
loginuid (nor is it clear how this should even work when loginuid is set
as immutable after initial write).
.
Signed-off-by: Steve Langasek vor...@debian.org
Signed-off-by: Dmitry V. Levin l...@altlinux.org
Index: ubuntu/modules/pam_loginuid/pam_loginuid.c
===
--- ubuntu.orig/modules/pam_loginuid/pam_loginuid.c 2014-01-31
21:07:08.665185675 +
+++ ubuntu/modules/pam_loginuid/pam_loginuid.c 2014-01-31 21:05:05.0
+
@@ -47,25 +47,56 @@
/*
* This function writes the loginuid to the /proc system. It returns
- * 0 on success and 1 on failure.
+ * PAM_SUCCESS on success,
+ * PAM_IGNORE when /proc/self/loginuid does not exist,
+ * PAM_SESSION_ERR in case of any other error.
*/
static int set_loginuid(pam_handle_t *pamh, uid_t uid)
{
- int fd, count, rc = 0;
- char loginuid[24];
+ int fd, count, rc = PAM_SESSION_ERR;
+ char loginuid[24], buf[24];
+ static const char host_uid_map[] = 0 0 4294967295\n;
+ char uid_map[sizeof(host_uid_map)];
+
+ /* loginuid in user namespaces currently isn't writable and in some
+ case, not even readable, so consider any failure as ignorable (but
try
+ anyway, in case we hit a kernel which supports it). */
+ fd = open(/proc/self/uid_map, O_RDONLY);
+ if (fd = 0) {
+ count = pam_modutil_read(fd, uid_map, sizeof(uid_map));
+ if (strncmp(uid_map, host_uid_map, count) != 0)
+ rc = PAM_IGNORE;
+ close(fd);
+ }
- count = snprintf(loginuid, sizeof(loginuid), %lu, (unsigned long)uid);
- fd = open(/proc/self/loginuid, O_NOFOLLOW|O_WRONLY|O_TRUNC);
+ fd = open(/proc/self/loginuid, O_NOFOLLOW|O_RDWR);
if (fd 0) {
- if (errno != ENOENT) {
- rc = 1;
- pam_syslog(pamh, LOG_ERR,
- Cannot open /proc/self/loginuid: %m);
+ if (errno == ENOENT) {
+ rc = PAM_IGNORE;
+ }
+ if (rc != PAM_IGNORE) {
+ pam_syslog(pamh, LOG_ERR, Cannot open %s: %m,
+ /proc/self/loginuid);
}
return rc;
}
- if (pam_modutil_write(fd, loginuid, count) != count)
- rc = 1;
+
+ count = snprintf(loginuid, sizeof(loginuid), %lu, (unsigned long)uid);
+ if (pam_modutil_read(fd, buf, sizeof(buf)) == count
+ memcmp(buf, loginuid, count) == 0) {
+ rc = PAM_SUCCESS;
+ goto done; /* already correct */
+ }
+ if (lseek(fd, 0, SEEK_SET) == 0 ftruncate(fd, 0) == 0
+ pam_modutil_write(fd, loginuid, count) == count) {
+ rc = PAM_SUCCESS;
+ } else {
+ if (rc != PAM_IGNORE) {
+ pam_syslog(pamh, LOG_ERR, Error writing %s: %m,
+ /proc/self/loginuid);
+ }
+ }
+ done:
close(fd);
return rc;
}
@@ -165,6 +196,7 @@
{
const char *user = NULL
Bug#703906: Add upstart user session job
Package: src:openssh
Hello,
Starting with Upstart 1.7, users can choose to use it in user session
mode. When doing so, the regular Xsession script that usually spawns
ssh-agent doesn't work and so an equivalent upstart job needs to be
installed.
Attached is a debdiff adding such a job to the openssh-client package.
This job is a no-op on non-upstart systems or on upstart systems that
don't use user sessions. For those using user sessions, this job will do
the same work as 90x11-common_ssh-agent including checking
Xsession.options if present.
I'm currently using that job on a standard Ubuntu 13.04 system and I
have done a testbuild with the attached debdiff.
Thanks
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
diff -Nru openssh-6.1p1/debian/changelog openssh-6.1p1/debian/changelog
--- openssh-6.1p1/debian/changelog 2013-02-08 16:07:32.0 -0500
+++ openssh-6.1p1/debian/changelog 2013-03-25 11:30:18.0 -0400
@@ -1,3 +1,11 @@
+openssh (1:6.1p1-4) UNRELEASED; urgency=low
+
+ * Add ssh-agent upstart user job. This implements something similar to the
+90x11-common_ssh-agent Xsession script. That's, start ssh-agent and set
+the appropriate environment variables.
+
+ -- Stéphane Graber stgra...@ubuntu.com Mon, 25 Mar 2013 11:29:10 -0400
+
openssh (1:6.1p1-3) experimental; urgency=low
* Give ssh and ssh-krb5 versioned dependencies on openssh-client and
diff -Nru openssh-6.1p1/debian/rules openssh-6.1p1/debian/rules
--- openssh-6.1p1/debian/rules 2012-11-26 11:38:45.0 -0500
+++ openssh-6.1p1/debian/rules 2013-03-25 11:29:02.0 -0400
@@ -187,6 +187,9 @@
install -p -m 644 debian/openssh-client.apport debian/openssh-client/usr/share/apport/package-hooks/openssh-client.py
install -p -m 644 debian/openssh-server.apport debian/openssh-server/usr/share/apport/package-hooks/openssh-server.py
+ # Upstart user job (only used under user sessions)
+ install -m 644 -D debian/ssh-agent.user-session.upstart debian/openssh-client/usr/share/upstart/sessions/ssh-agent.conf
+
override_dh_installdocs:
dh_installdocs -Nopenssh-server -Nssh
dh_installdocs -popenssh-server -pssh --link-doc=openssh-client
diff -Nru openssh-6.1p1/debian/ssh-agent.user-session.upstart openssh-6.1p1/debian/ssh-agent.user-session.upstart
--- openssh-6.1p1/debian/ssh-agent.user-session.upstart 1969-12-31 19:00:00.0 -0500
+++ openssh-6.1p1/debian/ssh-agent.user-session.upstart 2013-03-25 11:10:22.0 -0400
@@ -0,0 +1,20 @@
+description SSH Agent
+author Stéphane Graber stgra...@ubuntu.com
+
+start on starting xsession-init
+
+pre-start script
+if [ -f /etc/X11/Xsession.options ]; then
+grep -q ^use-ssh-agent$ /etc/X11/Xsession.options || { stop; exit 0; }
+fi
+
+eval $(ssh-agent) /dev/null
+initctl set-env --global SSH_AUTH_SOCK=$SSH_AUTH_SOCK
+initctl set-env --global SSH_AGENT_PID=$SSH_AGENT_PID
+end script
+
+post-stop script
+kill $SSH_AGENT_PID 2/dev/null || true
+initctl unset-env --global SSH_AUTH_SOCK
+initctl unset-env --global SSH_AGENT_PID
+end script
signature.asc
Description: OpenPGP digital signature
Bug#698803: Running the testsuite at build time
Package: src:libseccomp
Hey there,
I'm currently working on getting libseccomp promoted to main in Ubuntu.
One thing that was identified as part of the MainInclusion process is
that libseccomp ships with a test suite but it's not run at build time.
Attached is a patch which turns on said testsuite and makes the build
fail if any failure (not error) is reported by the regression test.
The debian/rules change isn't as clean as some would expect because the
regression testing script upstream always returns 0, so the actual
output has to be diverted and parsed to detect failures.
I'm now uploading this change directly to Ubuntu. Once it lands in
Debian, a simple sync will bring Debian and Ubuntu back on the same source.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
=== modified file 'debian/changelog'
--- debian/changelog 2012-12-07 11:38:03 +
+++ debian/changelog 2013-01-23 20:27:08 +
@@ -1,3 +1,9 @@
+libseccomp (1.0.1-1ubuntu1) UNRELEASED; urgency=low
+
+ * Run the testsuite at build time.
+
+ -- Stéphane Graber stgra...@ubuntu.com Wed, 23 Jan 2013 20:26:39 +
+
libseccomp (1.0.1-1) unstable; urgency=low
* New upstream release.
=== modified file 'debian/rules'
--- debian/rules 2012-12-07 11:38:03 +
+++ debian/rules 2013-01-23 20:23:19 +
@@ -20,3 +20,8 @@
#sed -i -e 's/^prefix=.*/prefix=\/usr/' $(CURDIR)/libseccomp.pc \
# -e 's/^libdir=.*/libdir=$${prefix}\/lib\/$(DEB_HOST_MULTIARCH)/' \
# $(CURDIR)/libseccomp.pc
+
+override_dh_auto_test:
+ cd tests ./regression | tee regression.out \
+ grep -q tests failed: 0 regression.out rm regression.out || \
+ (rm -f regression.out exit 1)
signature.asc
Description: OpenPGP digital signature
Bug#658702: Fix for bug 658702
Hello,
We've just hit that same bug in Ubuntu when preparing for Ubuntu 10.04
to 12.04 upgrades without internet connectivity.
I'm attaching the patch we've applied to workaround/fix that problem.
It's based on a similar change that was done to doc-base a while ago,
basically implementing a local version of dirname.
I have uploaded updated patches to precise-proposed and quantal a few
minutes ago but don't expect any other issue with that package.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
Description: Copy DirName function from doc-base and use that instead of
dirname()
Author: Stéphane Graber stgra...@ubuntu.com
Forwarded: no
Last-Update: 2012-08-10
--- libxml-sax-perl-0.99+dfsg.orig/SAX.pm
+++ libxml-sax-perl-0.99+dfsg/SAX.pm
@@ -12,7 +12,6 @@ use Exporter ();
@EXPORT_OK = qw(Namespaces Validation);
-use File::Basename qw(dirname);
use File::Spec ();
use Symbol qw(gensym);
use XML::SAX::ParserFactory (); # loaded for simplicity
@@ -44,6 +43,13 @@ http://xml.org/sax/features/validation =
=cut
+sub _DirName { # {{{
+my @p = split '/', $_[0];
+return (join '/', @p[0..($#p-1)]) if $#p 1;
+return '/' if substr ($_[0], 0, 1) eq '/';
+return '.';
+} # }}}
+
sub load_parsers {
my $class = shift;
my $dir = shift;
@@ -54,7 +60,7 @@ sub load_parsers {
# get directory from wherever XML::SAX is installed
if (!$dir) {
$dir = $INC{'XML/SAX.pm'};
-$dir = dirname($dir);
+$dir = _DirName($dir);
}
my $fh = gensym();
@@ -190,7 +196,7 @@ sub save_parsers {
# get directory from wherever XML::SAX is installed
my $dir = $INC{'XML/SAX.pm'};
-$dir = dirname($dir);
+$dir = _DirName($dir);
my $file = File::Spec-catfile($dir, SAX, PARSER_DETAILS);
chmod 0644, $file;
signature.asc
Description: OpenPGP digital signature
Bug#673490: Event based network initialization in Ubuntu
Hello, I must admit not being perfectly up to date as to how Debian's networking stack is working at boot time, so to hopefully try to explain why Ubuntu did these changes, here's a quick explanation of how things work on our side. Ubuntu essentially supports two different tools to initialize the network. For desktop systems, that's Network Manager (only loopback is setup by ifupdown) and for servers, that's ifupdown. As you also know, Ubuntu uses upstart as its init system. Upstart has a udev bridge that's used to trigger init jobs on hotplug events. Take my usual test setup as an example: auto lo iface lo inet loopback auto eth0 iface eth0 inet manual bond-master bond0 auto eth1 iface eth1 inet manual bond-master bond0 auto bond0 iface bond0 inet static bond-slaves none bond-mode 802.3ad bond-miimon 100 address 172.17.0.55 netmask 255.255.255.0 gateway 172.17.0.1 dns-nameservers 2607:f2c0:f00f:2720:e084:d1ff:fe38:c4f5 2001:470:714b:1020:218:51ff:fe5a:9949 auto br1005 iface br1005 inet dhcp bridge-ports bond0.1005 bridge_stp off auto br1005:0 iface br1005:0 inet static address 192.168.99.1 netmask 255.255.255.0 In this example you can see a nice mix of: - 802.3ad bonding (eth0 is an onboard e1000e, eth1 is a USB 3com adapter that's usually NOT plugged in) - br1005 depends on bond0.1005 but bond0.1005 itself isn't defined The boot time sequence on this machine looks like this: 1) Kernel initialize 2) Upstart, udev and udev-bridge start 3) net-device-added is emitted for eth0 - upstart starts an instance of the network-interface job for eth0 1) this job runs ifup --allow auto eth0 2) ifenslave pre-up is called by ifupdown, creating the parent bond0 device 3) net-device-added is emitted for bond0 - upstart starts an instance of the network-interface job for bond0 1) this job runs ifup --allow auto bond0 2) ifenslave pre-up configures the bond device, not joining any slave 3) The ifup instance configuring bond0 detects that a slave was added and adds the IP/run dhcp (not possible until a slave is joined) - the vlan udev hook detects that bond0 now exists and creates bond0.10015 - upstart starts an instance of the network-interface job for bond0.1015 1) Nothing to do, it's not defined in /e/n/i - the bridge udev hook detects that bond0.1005 now exists, creates br1005 and joins bond0.1005 - net-device-added is emitted for br1005 - upstart starts an instance of the network-interface job for br1005 1) this job runs ifup --allow auto br1005 2) ifupdown configures br1005 (starts dhclient) 4) Now that bond0 is configured (ifenslave pre-up waits for that state on Ubuntu), join the first slave 4) upstart hits the fallback/legacy networking job and calls ifup -a - ifupdown brings the remaining virtual interfaces, in this case, br1005:0 5) some time later (days/weeks), net-device-added is emitted for eth1 - upstart starts an instance of the network-interface job for eth1 1) this job runs ifup --allow auto eth1 2) ifenslave pre-up is called by ifupdown, joining eth1 to bond0 Numbered items are run sequentially, non-numbered items are typically run in parallel. Also note, that I wrote these down based on what I remember from the work I did the past 6 months, it might be slightly inaccurate. In this example, not having the udev hooks might (race condition) cause br1005 to come up with bond0.1005 bridged into it. A similar thing can happen with the vlan code if an explicit definition of a vlan exists in /e/n/i and ifup -a is hit before the parent interface exists. I already had multiple users reporting some systems with a lot of storage and network hardware that'd take up to 5 minutes until all the udev network events would be emitted, so most of their ethX devices would appear on the system a long time after ifup -a was run. The only way of properly supporting these systems as well as the hotplug use cases is to have as much of the network stack as possible brought up by events and until such time that ifupdown supports bringing up reverse dependencies when an interface is brought up, these udev hooks will still be required. Sorry for it to be so complicated, but that's really the setup that explains the best what we're supporting in Ubuntu and the kind of setups we need to deal with. I hope this all helps explain why we've done these changes in Ubuntu, I hope that some of that work can be merged in Debian, for anything that's problematic, I'm certainly happy to continue maintaining that delta in Ubuntu as regression in that area simply isn't acceptable for us. An higher level view of the things can be found here: http://www.stgraber.org/2012/01/04/networking-in-ubuntu-12-04-lts/ -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP
Bug#657640: lb_chroot_resolv fails when /etc/resolv.conf is a symlink (resolvconf)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Package: src:live-build
Hello,
Ubuntu recently switched to using resolvconf by default, this change
showed a small issue in live-build in the way it deals with existing
/etc/resolv.conf, more specifically when it's a symlink.
The current live-build script will do a test -e on /etc/resolv.conf
which won't succeed when it's a dangling symlink. It then assumes it
can simply copy the /etc/resolv.conf from the outside into the chroot
but this makes cp fail (can't copy file to dangling symlink).
The attached patch detected that /etc/resolv.conf in the chroot is a
symlink and in such case, moves it aside to .orig but doesn't attempt
to Truncate it (which would obviously fail).
In the remove target, we now check for both -e and -L and restore the
.orig copy of resolv.conf.
- --
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPItQeAAoJEMY4l01keS1nv5EP/A+xp5oJc21JyHnKi12upwMc
WzIqVfK/3Eop/4nshOwCpMbt/Y605jaci/81rol0OCSCPgskAJ5a+rWMPxHdGfDp
ZUpHL1a4GCVIbhlv1gW+qVJKGyiu86lt4R6b4vPQf8ILSKB+/+dugJ3FfLOF+BI7
qBQQE6RBFkeJwuQXaFJFNAJQgkNczOHhsv8xnRPwy/xsBzDPDXDzPYMYhI7wNiRn
qcsZbuWxK0IRz6FvucZye7Gm3FBzgwHoIweXhYNWC+9Uk1PoujeAJq/kkweO/k0z
WFdE/65lJ0BiJ73H7nAShOPsYuo14CpbT2Vv1bJMxKvaeUp/qonryQbfAh/LaRZc
MeqiKxY2k/j7RocVJKI221dDfIm6B22cGYMFKkDrN30db7l8uV3fwn7i+iQEZH54
NLcCwp6myDRwiQIDhMfz4+JNYiu0MW7TkQROeBAG97fiD1nXIJA/1Uy5sc2HDezj
n6jqzjuSwfyNAbOW4hMWu8Co/pn8QiDUjbYmwsgzQTHUZFUxUGiTUkxcEwTPAyi2
C1/kPlYeR2kXOGAqY2puYbGEVqdNoxGdigAvnYSyHx6ncK6oQD/BJhBzbGYQ7vtM
wsxKZO09cMnGlKQenfWgCibU451FhHlFZA30D3nfExSglPBGyRs13I08cSiMvjgc
zmtoIbho1jjyYd4WFuKv
=SUm7
-END PGP SIGNATURE-
diff -Nrup live-build-3.0~a42/scripts/build/lb_chroot_resolv new/scripts/build/lb_chroot_resolv
--- live-build-3.0~a42/scripts/build/lb_chroot_resolv 2012-01-12 05:37:06.0 -0500
+++ new/scripts/build/lb_chroot_resolv 2012-01-27 11:22:54.220719008 -0500
@@ -51,6 +51,10 @@ case ${1} in
# If you want to have a custom resolv.conf, please
# overwrite it with normal local_includes mechanism.
Truncate chroot/etc/resolv.conf.orig
+ elif [ -L chroot/etc/resolv.conf ]
+ then
+ # Move resolv.conf aside if it's a symlink (likely resolvconf)
+ mv chroot/etc/resolv.conf chroot/etc/resolv.conf.orig
fi
if [ -f /etc/resolv.conf ]
@@ -77,7 +81,7 @@ case ${1} in
# Copying local resolv.conf
cp -a config/includes.chroot/etc/resolv.conf chroot/etc/resolv.conf
rm -f chroot/etc/resolv.conf.orig
- elif [ -e chroot/etc/resolv.conf.orig ]
+ elif [ -e chroot/etc/resolv.conf.orig ] || [ -L chroot/etc/resolv.conf.orig ]
then
# Restoring resolv file or symlink
mv chroot/etc/resolv.conf.orig chroot/etc/resolv.conf
resolvconf.diff.sig
Description: Binary data
Bug#656270: Calling ifdown on a label also brings down the parent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: src:ifupdown Hello, I just noticed another regression in ifupdown with regard to label handling (worked fine at least in 0.6.8, possibly later versions too). I have done these tests using 0.7~beta2. Here's my /etc/network/interfaces: auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 auto eth0:0 iface eth0:0 inet static address 192.168.2.100 netmask 255.255.255.0 Now calling: - ifup eth0 = Causes eth0 to appear and configure - ifup eth0:0 = Causes the label to appear and configure So far that's the expected behaviour, calling them in the reverse order: - ifup eth0:0 = Causes the parent to appear and the label to appear and configure - ifup eth0 = Causes eth0 to configure Still what we'd expect. Now the interesting part: - ifdown eth0:0 = Causes eth0:0 to disappear and eth0 to disappear! - ifdown eth0 = Fails because eth0 is already down Similar result if done the other way around: - ifdown eth0 = Causes both eth0 and eth0:0 to disappear - ifdown eth0:0 = Fails because the label is already gone So the few changes I'd expect are: - Bringing a label down shouldn't bring the parent down - Bringing the parent down should indeed bring the labels down but should bring them down properly (similar to calling ifdown eth0:0) to avoid having ifupdown in an inconsistent state. As far as I can tell, the first of these two changes would fix the current regression, the second would be an improvement as I can't find an ifupdown version doing that properly. Besides that small issue, 0.7~beta2 rocks, thanks for the good work! - -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPFfh7AAoJEMY4l01keS1nXl0QAMFi5IQQBf78uyhuv/U1JNF6 nwTniYBGfuvopCA4DTxSapwoZV5Eq5VaMwQ5WqwRKHDkrn5w/vlPMyYIgTFzSNOL 0JUDDbEffBNrGf2KtnLccOzMBB+skhIgDGnP87Dd9g3L+so0P33Pmma9I/bVLeW/ SPzR8sBcYv3YmiUu6qjk3NAQGwQ0OVMfZN/6b2WkIVln1kXwaXzyhy39USnuWgbv ZrAkoXDDYmod2jhNKQbwM+XJMdE8fsWSzo7ejw3abeMozNUvXW3A7IuqK+CD1vTT OI1W2XC4EYRRV7FfWerTh8daCGbY0+IVz5LJAzVJMZisFLlQOFYR9L46tEUx2KyL r6XudlvHmr6+pIFnLhun7WIazZaCzJLSvvHIW7pmSI6qwotPVd2x4xdI4unU38OK kmHhRxa1XutaspTxQ8lcN7ad1VX+MPehvpNBttgHdt1Fyc1/nYgwtUmE9Ndbm+KD RuXNzx0PVBLpinlU07yLedwHBYDFiUaeuAyQdHwByNZ79x4FsrnB1AQdWqtHV9Re rh8ynlTi+I2h70dLdyFw2E0A1D4cW36qUQMTSwAzb9WxQ0OjiwuvGYMqEz1cLJME TR2ZUzVItkxt5zmtMz33sAApYkJyyiyDnl63gIg24+uGYrx5jiEpTq3+XiyKrz4v 7vHWDuhzhEKFHNLiRLqa =/M3l -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616882: Patch to convert lybniz from python-central to dh_python2
Hello,
Attached is the patch I just uploaded to Ubuntu converting lybniz from
pycentral to dh_python2.
I tried to limit my changes to what's strictly needed to get it working.
I compared the resulting binary packages and made sure it installs and
starts fine.
Cheers
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
=== modified file 'debian/changelog'
--- debian/changelog 2008-03-21 20:36:36 +
+++ debian/changelog 2012-01-02 09:13:22 +
@@ -1,3 +1,19 @@
+lybniz (1.3.2-2ubuntu1) precise; urgency=low
+
+ * Convert from pycentral to dh_python2
+- debian/pycompat: Removed (no longer needed)
+- debian/rules
+ + Drop DEB_PYTHON_SYSTEM (no longer needed)
+ + Set DEB_PYTHON2_MODULE_PACKAGES to lybniz
+- debian/control
+ + Drop XS-Python-Version and set X-Python-Version instead
+ + Change build-dep on python-all-dev to python instead (arch: all)
+ + Bbump dependency on python and cdbs for dh_python2
+ + Drop XB-Python-Version from binary package
+ + Drop ${shlibs:Depends} from binary package's depends
+
+ -- Stéphane Graber stgra...@ubuntu.com Mon, 02 Jan 2012 10:08:56 +0100
+
lybniz (1.3.2-2) unstable; urgency=low
* Change Build-Depends: python-central (= 0.6.0). (Closes: #472015)
=== modified file 'debian/control'
--- debian/control 2008-03-21 20:36:36 +
+++ debian/control 2012-01-02 09:04:45 +
@@ -3,9 +3,8 @@
Priority: optional
Maintainer: Varun Hiremath va...@debian.org
Uploaders: Torsten Werner twer...@debian.org
-XS-Python-Version: = 2.3
-Build-Depends: debhelper (= 5), cdbs (= 0.4.43), python-all-dev (= 2.3.5-11),
- python-central (= 0.6.0), quilt
+X-Python-Version: = 2.3
+Build-Depends: debhelper (= 5), cdbs (= 0.4.90~), python (= 2.6.6-3~), quilt
Standards-Version: 3.7.3
Homepage: http://lybniz2.sourceforge.net/
Vcs-Svn: https://bollin.googlecode.com/svn/lybniz/
@@ -13,8 +12,7 @@
Package: lybniz
Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, python-gtk2, python-gnome2
-XB-Python-Version: ${python:Versions}
+Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-gnome2
Description: mathematical function graph plotter
Lybniz is a simple desktop graph plotter. It can currently plot three
functions and allows you to navigate the plot. Functions are entered
=== removed file 'debian/pycompat'
--- debian/pycompat 2006-12-10 20:59:34 +
+++ debian/pycompat 1970-01-01 00:00:00 +
@@ -1,1 +0,0 @@
-2
=== modified file 'debian/rules'
--- debian/rules 2008-03-21 20:36:36 +
+++ debian/rules 2012-01-02 09:03:53 +
@@ -1,5 +1,5 @@
#!/usr/bin/make -f
-DEB_PYTHON_SYSTEM=pycentral
+DEB_PYTHON2_MODULE_PACKAGES=lybniz
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/python-distutils.mk
Bug#616926: Patch to convert opendict from python-central to dh_python2
Hello,
Attached is a patch I just uploaded to Ubuntu converting opendict from
pycentral to dh_python2.
I tried to limit my changes to what was strictly needed to get it working.
I compared the resulting binary package and made sure it installs and
starts fine.
Cheers
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
=== modified file 'debian/changelog'
--- debian/changelog 2011-11-24 06:21:33 +
+++ debian/changelog 2012-01-02 10:09:55 +
@@ -1,3 +1,16 @@
+opendict (0.6.3-3.1ubuntu1) precise; urgency=low
+
+ * Convert from pycentral to dh_python2
+- debian/pycompat: Removed (no longer needed)
+- debian/rules: Replace dh_pycenral by dh_python2
+- debian/control
+ + Drop XS-Python-Version
+ + Drop python-central from build-depends
+ + Replace build-depends on python-all-dev to python = 2.6.6-3~
+ + Drop XB-Python-Version from binary package
+
+ -- Stéphane Graber stgra...@ubuntu.com Mon, 02 Jan 2012 11:07:38 +0100
+
opendict (0.6.3-3.1) unstable; urgency=low
* Non-maintainer upload.
=== modified file 'debian/control'
--- debian/control 2011-11-24 06:21:33 +
+++ debian/control 2012-01-02 10:02:37 +
@@ -2,16 +2,14 @@
Section: text
Priority: optional
Maintainer: KÄstutis BiliÅ«nas ke...@kaunas.init.lt
-XS-Python-Version: all
Build-Depends: debhelper ( 6.0.0), quilt (= 0.40)
-Build-Depends-Indep: python-all-dev (= 2.3.5-11), python-central (= 0.5)
+Build-Depends-Indep: python (= 2.6.6-3~)
Standards-Version: 3.8.0
Homepage: http://opendict.sourceforge.net/
Package: opendict
Architecture: all
Depends: ${python:Depends}, python-wxgtk2.8
-XB-Python-Version: ${python:Versions}
Suggests: dictd, festival
Description: computer dictionary for several dictionary formats
OpenDict is free cross-platform dictionary program. It works with
=== removed file 'debian/pycompat'
--- debian/pycompat 2006-10-01 21:53:17 +
+++ debian/pycompat 1970-01-01 00:00:00 +
@@ -1,1 +0,0 @@
-2
=== modified file 'debian/rules'
--- debian/rules 2007-09-23 19:33:02 +
+++ debian/rules 2012-01-02 10:03:14 +
@@ -52,7 +52,7 @@
dh_strip
dh_compress
dh_fixperms
- dh_pycentral
+ dh_python2
# dh_python
dh_installdeb
dh_shlibdeps
Bug#645813: interface aliases ignored in recent ifupdown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Confirmed that the issue is indeed only about missing labels on the added addresses. - -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJOpKI0AAoJEMY4l01keS1nZ2UP/1XKWzIUPRiXZmDSL0XrrE8k Z9IiYZ1cF/KiYHhyW8CVSnQlmG6+gbcEQ5qOW2+ygJZhtXzhGpD4kMhYRZWAbJ1A y/Xd9K6Tzn4ghszkSwlZ8C64CyYuge0HXZVYgTVHbTg/WTG4BYfao9D4kkZGVl9h CVipUJqnrgvTHOBYQAU9br70eUX/lkqwJt098zZou55NY7REUyaNqS1z+0HTUXhO cpOMXvEsWrY4QDXsXYTZM3Jowi7Kp0l0bzeQNKBIc2Em3nI25Ssx3+Xo1Gw+Rltd zctCLSNLA5qfeSocHUKbPCPCOu6DCwn6Tp8pbo6lIw+zb0inJvSp2Q6FaCVNM4RW uGYTk4QPXxDJk786Xh8gFDXCe0j4NoY3yWxYTmp/v2KqkIfARo1llx/OuYTkDSGW 1Dzq4rB9FPuia323rhmwgQRRUji5QlkAj4zkYFOEqhRacf0oyfa09aCixTuEHMev 9dsM6Eyq0EbgjUs+LngE3HdJ/mCUwDCcuplZEuB+u0TMKRZ3+uOh2cD0F3fBElDp dELvh35imUfmSCrw7YVZ3jSUMpwtPC1tIGa+5KzSHK2k3ejZNBScJMA0afLlCI4/ wE3Vsc+lkcpgS/7p/rPcKPLUY+pa8UQ2tYhC/924TC7iJlld1DQ9/M54V1WAyyQa NjIjq4UpAIJyNQxcOm53 =zr+A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645813: interface aliases ignored in recent ifupdown
Package: ifupdown Version: 0.7~alpha5.1ubuntu5 Severity: normal The following bug report was filed against Ubuntu Oneiric: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/678425 After a bit of testing I managed to reproduce it on Debian too. Using the following /etc/network/interfaces: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.122.17 netmask 255.255.255.0 gateway 192.168.122.1 auto eth0:0 iface eth0:0 inet static address 192.168.122.18 netmask 255.255.255.0 ifupdown 0.7~alpha5+really0.6.15 properly brings up both eth0 and eth0:0 when doing ifup -a, after upgrading to ifupdown 0.7~beta1, only eth0 is up. root@debian01:~# ifdown -a root@debian01:~# ifconfig root@debian01:~# ifup -a root@debian01:~# ifconfig eth0 Link encap:Ethernet HWaddr 8a:90:f8:95:7a:80 inet addr:192.168.122.17 Bcast:0.0.0.0 Mask:255.255.255.0 inet6 addr: fe80::8890:f8ff:fe95:7a80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:60745 errors:0 dropped:0 overruns:0 frame:0 TX packets:46113 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:89047505 (84.9 MiB) TX bytes:3240597 (3.0 MiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@debian01:~# ifup eth0:0 ifup: interface eth0:0 already configured Explicitly bringing up eth0:0 when eth0 is also considered down gives some intersting result: root@debian01:~# ifdown -a root@debian01:~# ifup eth0:0 root@debian01:~# ifconfig eth0 Link encap:Ethernet HWaddr 8a:90:f8:95:7a:80 inet addr:192.168.122.18 Bcast:0.0.0.0 Mask:255.255.255.0 inet6 addr: fe80::8890:f8ff:fe95:7a80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:60774 errors:0 dropped:0 overruns:0 frame:0 TX packets:46120 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:89048999 (84.9 MiB) TX bytes:3241631 (3.0 MiB) root@debian01:~# ifup --version ifup version 0.7beta Copyright (c) 1999-2007 Anthony Towns This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. -- System Information: Debian Release: wheezy/sid APT prefers oneiric-updates APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 'oneiric') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-12-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ifupdown depends on: ii initscripts 2.88dsf-13.10ubuntu4 scripts for initializing and shutt ii iproute 20110315-1build1 networking and traffic control too ii libc6 2.13-20ubuntu5 Embedded GNU C Library: Shared lib ii lsb-base4.0-0ubuntu16Linux Standard Base 4.0 init scrip ii upstart [upstart-jo 1.3-0ubuntu10event-based init daemon ifupdown recommends no packages. Versions of packages ifupdown suggests: ii isc-dhcp-client [dhc 4.1.1-P1-17ubuntu10 ISC DHCP client ii net-tools1.60-23ubuntu3 The NET-3 networking toolkit ii ppp 2.4.5-5ubuntu1 Point-to-Point Protocol (PPP) - da pn rdnssd none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645813: Acknowledgement (interface aliases ignored in recent ifupdown)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Just noticed that I didn't link to the right bug on Launchpad, the main bug report is: https://bugs.launchpad.net/debian/+source/ifupdown/+bug/876829 I think the other bug I linked in the initial report may be a duplicate though so I'll keep the link between Launchpad and the Debian bugtracker on that one too. - -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJOneBQAAoJEMY4l01keS1nHYcP/03F9nNtO3qd4Gds77kro09C X/v6MEskG84p4DBI65LjT8VAzBiLb8cilPBT4+KkpNDUTECk0Z3G5MwirDQc4hez zmWmZMgM0+i4PefLDH7KX7NRzXOhWA/imwdcP5zdCEAhbNwmFhuPW3WazAFoiB/9 AM4RZubpGX1d7M+HyvU3RVaG52DNBvQdyT1G5xAybw8ZOj1maFaJ9/1fOAofvKNE n/DJIY+pOck789AykDQt52NcSo1RLhER/vpzKxeF5tIirYBsEh6f6STxyrzRpmgU fLfg/JVc7AmziwKj9DKU/ysMPEO8wd+rGzTIBnwUtgb3HbMtxY/8rY/IVlYjpyR5 pdhXX0Fj6uqs7WmFZ76KEZwGStd/a5m5kfGtJ6gM+1805fKvswqwKksWo/6JzANe Al5g9HD5qPpy9h/lKIVkfj8PyjYTKRP3ne5CMIwELwipC/Jp3q22u2f3GaExvy6P LU99HA2Ek6aqXJf65zqiaoQ5WEs88fgbEg7nIWyYwk+v/8liyWlRM+MYd85R3JwL LMNGNGDg475Zylj5pj/XkAADkBHeyp8gdi/NC0M59/62oYG3OA6qJ1EDaIfg8qY0 9SWkTLNRzGROKZjOznWTBd3b5RIarpcvq/RwEBZatoBwkEmJ6tkqsyAMmlQmKS9E RTD9ZJWHMlHsoMqPk2UY =wg2z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616066: Fix for bug 616066
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/30/2011 08:02 AM, Raphael Hertzog wrote:
On Thu, 30 Jun 2011, Anders Kaseorg wrote:
$ time for p in $(dpkg-query -W -f='${PackageSpec} '); do \
dpkg-query --control-path $p md5sums; done /dev/null
real 2m34.050s user 2m8.480s sys0m19.140s
Hum, ok.
That accounts for basically all of the time the debsums hook is now
using. Besides, it’s the only thing that Stéphane’s patch changed.
Then I can only suggest to keep a cache to avoid doing it for all
installed package every time.
Or to work with us to integrate it in dpkg proper. :)
Cheers,
Ok, so in the mean time, I worked on a dirty workaround that should
work in most cases for debsums and be almost as fast as the old code.
I essentially replaced all the old direct lookup at .md5sums by a glob
call that'll return all the existing md5sums files for the package and
fail only if the checksum can't be found in any of them.
It's definitely not right and not what debsums should be doing but in
my opinion it's better than the old behavior (no multiarch support
whatsoever) and better than my former implementation as it's actually
usable.
As I think I already mentioned, I'm really not a perl coder. The
attached patch doesn't crash for me when I run debsums -sa and the
output seems to indeed match the state of my system.
I'd think debsums will need some major work to play nicely with dpkg and
not hardcode most of the paths but it's not something I have time to do
(or knowledge).
I'll have a few people to look at the patch and if it seems sane enough,
will upload it at least in Ubuntu so our current users who have debsums
installed don't have to wait 5 minutes every-time they call apt.
- --
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJODEk6AAoJEMY4l01keS1nW9sQANK1lSNWGypH7HcjyFhJE7kB
b3/VDjcaW3imPpFgRxzTLLdtdb4iZB8mTv39dUhQ0cawMNhMy/qeJF6E7+o7uLLE
Bo/pVZ0m31+PYTgyBmrmdJNnK5Cq/XqBfY3M52XgGFb51y8/LLSanYtvb1Ptp1Cv
r13sy9exgrMrbpJgMxCZZ0DmGMSPDP2B0a57MuJLoOuutdDf+MHFXDJq1QvLIlZX
KeU57a6PTgJ1eTxRa+jdL913iHfYnCACVSXwWGY3+VGhCcIrslLHTcZNmSLkS7gV
SzNspkWRBuEe00FKwM3380OaNNZe0M8mUAHlI7F/0r7V4+Zuxtu5HsYg018ijjwr
PsiJZnykbYQPBcDt0hfaVKlA7Ey59ELqcNuKlGomgU/mSDlffN5ak9S7o6oribbK
G12/Hf4jxZ01nsBs0O305VrLu+GWwTuaI1pjTPt9osaURYyQ8GZuimqKzJcHznD+
acDm06t0m53PtJ6Pev4sI8JtiAPG2Mk1JSUYq8UuKOa9rFpLCDcIW7J3P63F3mDC
cTfa9VmCRFSCIxf61691MQlvvajnLN/Zf09CYkg2E+imYjYl+dQArRCFBw5A4oQB
VobSKaX7WOWFs12FG164M7H//jydRAjIjNC/GCfk9VlkIPJtV1t+QBQLgaRt1izn
ehrZB1ClTSmuDNiTH8Qe
=17BJ
-END PGP SIGNATURE-
=== modified file 'debsums'
--- debsums 2010-11-17 17:16:07 +
+++ debsums 2011-06-30 09:53:19 +
@@ -257,6 +257,7 @@
sub is_replaced
{
my ($pack, $path, $sum) = @_;
+my @sumfiles;
unless ($installed{$pack}{ReplacedBy})
{
@@ -273,14 +274,17 @@
for my $p (@{$installed{$pack}{ReplacedBy} || []})
{
- open S, $DPKG/info/$p.md5sums or next;
- while (S)
- {
- if ($_ eq $sum $path\n)
- {
- close S;
- return 1;
- }
+ @sumfiles = glob($DPKG/info/$p.md5sums $DPKG/info/$p:*.md5sums);
+ foreach(@sumfiles) {
+ open S, $_ or next;
+ while (S)
+ {
+ if ($_ eq $sum $path\n)
+ {
+ close S;
+ return 1;
+ }
+ }
}
close S;
@@ -412,6 +416,7 @@
my $sums;
my $pack;
my $conffiles;
+my @sumfiles;
# looks like a package name
unless (/[^a-z\d+.-]/ or /\.deb$/)
@@ -460,31 +465,34 @@
}
else
{
- $sums = $DPKG/info/$pack.md5sums;
- unless (-f $sums or $config)
- {
- if ($missing)
- {
- print $pack\n;
- next;
- }
-
- unless ($generate{missing})
- {
- warn $self: no md5sums for $pack\n;
- next;
- }
-
- unless ($deb)
- {
- warn $self: no md5sums for $pack and no deb available\n
- unless $generate{nocheck} and $silent;
-
- next;
- }
-
- undef $sums;
- $_ = $deb;
+ @sumfiles = glob($DPKG/info/$pack.md5sums $DPKG/info/$pack:*.md5sums);
+ foreach(@sumfiles) {
+ $sums = $_;
+ unless (-f $sums or $config)
+ {
+ if ($missing)
+ {
+ print $pack\n;
+ next;
+ }
+
+ unless ($generate{missing})
+ {
+ warn $self: no md5sums for $pack\n;
+ next;
+ }
+
+ unless ($deb)
+ {
+ warn $self: no md5sums for $pack and no deb available\n
+unless $generate{nocheck} and $silent;
+
+ next;
+ }
+
+ undef $sums;
+ $_ = $deb;
+ }
}
}
@@ -626,9 +634,11 @@
if ($generate{keep})
{
- my $target = $DPKG/info/$pack.md5sums;
- copy $sums, $target
- or die $self: can't copy sums to $target ($!)\n;
+ @sumfiles = glob($DPKG/info/$pack.md5sums $DPKG/info/$pack:*.md5sums);
+ foreach(@sumfiles) {
+ copy $sums, $_
+ or die $self: can't copy sums to $_ ($!)\n;
+ }
}
}
debsums-glob.diff.sig
Description: Binary data
Bug#616066: Fix for bug 616066
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/30/2011 11:17 AM, Raphael Hertzog wrote:
On Thu, 30 Jun 2011, Stéphane Graber wrote:
if ($generate{keep}) { - my $target =
$DPKG/info/$pack.md5sums; -copy $sums, $target -
or die
$self: can't copy sums to $target ($!)\n; +@sumfiles =
glob($DPKG/info/$pack.md5sums $DPKG/info/$pack:*.md5sums); +
foreach(@sumfiles) { + copy $sums, $_ +
or die $self: can't
copy sums to $_ ($!)\n; + }
This looks entirely wrong. debsums generate a md5sums when the
package doesn't provide a md5sums files... so the glob can't return
anything.
And it's this part that I suggested to get rid of entirely, because
you're not qualified to know whether it should be $p.md5sums or
$p:$arch.md5sums. Ideally you should store those in a debsums
specific directory and use $p:$arch unconditionnaly.
Cheers,
Oops. I must admit having just done some simple replace in the code and
not having looked that closely to what it actually does.
I agree that generating .md5sums file is really bad and will completely
break the whole concept of having them in the first place.
I'll update the patch to never do the copy if any .md5sums file exist
for the package (so it behaves similarly as the old code) but I also
agree that debsums shouldn't do it in /var/lib/dpkg/info and should do
it somewhere else. Though I'm not the upstream for it (nor want to be)
so I won't be doing that change myself.
Thanks for pointing that mistake out.
- --
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJODFG2AAoJEMY4l01keS1nFf8QALJ7GPhKBhJVoe0l54EJ+/Im
50Yg4Njm61cs9ERGLVBN29HEFnPSiKnjifhxwwGExl+g4mB1XCAKvCqzLP6OizO2
KdkBDcHFaEhKdGyTfnnUjBwixLXQ/oBtkvqg0vitAL8gGmcmFpCvQWrTPs+JWV1X
kh1hMXwYXT5fcPbcmYlTrq4TdfxwBeb0XySxHWXdNycmzi4tyEbVPx6fvTCeGkru
TUHvL4zy+Z8bo6cPmgkTKrOmT/I1T/MkGzuvRPJaFO9/d2Jk9QsoPOLB3+NkBSox
lSDCtVt2lBRCTg0XdQe64ONcrafHIh0Y1gCosE0Ow3kwFHlBj1/6pH5m7nB9W43l
BjIwVwUIvKUGelwf7BtDbl730K5sOmB+S40JmJ1l3EOiA2TwBaIuRhlBDmD1TkXX
USXkpt9Qm/XVq/05mooYTZq8Mh2j7UhJ8hipEA6mDw6jxpwlJBLDpbIbOOgpI5Ga
RUPqidVboGeaOwPmZNx4ubpC0ObUTzVurlinbzqSzpYTI3M5IfZ670STugUg0Rep
1n0whCaTgB0IH9Nko74O79MA0mtSa4dtJeJfdQWGGZNqkIqhGxpFR5COlMPq5TJz
GKnhAveQoSVhR8vZa/OF+v6+CrS5YJ793YK6I3YJvsgBBGdrGOInJRdEBDXWz2Cp
n63QwNqTo2B6Snp6wiaj
=lzZ4
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616066: Fix for bug 616066
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/30/2011 11:17 AM, Raphael Hertzog wrote:
On Thu, 30 Jun 2011, Stéphane Graber wrote:
if ($generate{keep}) { - my $target =
$DPKG/info/$pack.md5sums; -copy $sums, $target -
or die
$self: can't copy sums to $target ($!)\n; +@sumfiles =
glob($DPKG/info/$pack.md5sums $DPKG/info/$pack:*.md5sums); +
foreach(@sumfiles) { + copy $sums, $_ +
or die $self: can't
copy sums to $_ ($!)\n; + }
This looks entirely wrong. debsums generate a md5sums when the
package doesn't provide a md5sums files... so the glob can't return
anything.
And it's this part that I suggested to get rid of entirely, because
you're not qualified to know whether it should be $p.md5sums or
$p:$arch.md5sums. Ideally you should store those in a debsums
specific directory and use $p:$arch unconditionnaly.
Cheers,
Attached is yet another patch that this time tries to bypass the md5sums
generation if an arch-specific md5sums file already exists.
- --
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJODFeaAAoJEMY4l01keS1nsJAQAI9ybaAtcAj+OnpjIz4sOlD7
MmnpADHxzlV8YGoRskR2kaLVXuwt52/oq0yXk2ZhA+xkx4m2zO5jEHcSKRvr0CtQ
ned+HLYkS1Q77cBZmVYE0BAF19Tv39dNL6dGHpwHpheZU53CtdKWYp445opuQNcx
JM8ql8WapXjkbbYnWDyQrN60DCAxF7kgAJFCOmsxFDPrgCDTRXyQEpwN1XkHU4od
IIqqFGZkrhsrcHC6vbEKAKIvQkPcKdzbB50VDod8e4+q/A2rlg7kKNxxi95QMlDy
kJHjVERy19AMB1ZufZd3EBdeBTf51Jeq0pv6W+4DoWcxBUx/dqZ2qmcM/Oj8T5cW
d2tNQ0EYgAsKVngBbl1DiNh7y7eZx7WNoNcs1hsEisl69WoYMqmLsniuMN6nyb3R
VtK8D13CwL5vq0wLXuqnELUfc99gilSLITqoNpu3p59xL9WrIgfQ3nH2wpDLcZnD
ZsKikPS0gCX4WKQfjcWPZhSk909DPfrySO8BiUQ4ubdf8bXGN+1Ft8k6crMHihzE
wNoA6hIz+AfCg9idhEmT4i2GVRc2xzvGWCg7NsPCRYUVOXHYERSZmuymGAOzaBIu
XTbXLY3EQoguzPIAk7qA9ySLqdnREOLBub9Sotnb6BBq0C7ukxqxpfO2LEsHoOuA
OsfJHV6NFnoWVyGunDD1
=V+2T
-END PGP SIGNATURE-
=== modified file 'debsums'
--- debsums 2010-11-17 17:16:07 +
+++ debsums 2011-06-30 10:48:13 +
@@ -257,6 +257,7 @@
sub is_replaced
{
my ($pack, $path, $sum) = @_;
+my @sumfiles;
unless ($installed{$pack}{ReplacedBy})
{
@@ -273,14 +274,17 @@
for my $p (@{$installed{$pack}{ReplacedBy} || []})
{
- open S, $DPKG/info/$p.md5sums or next;
- while (S)
- {
- if ($_ eq $sum $path\n)
- {
- close S;
- return 1;
- }
+ @sumfiles = glob($DPKG/info/$p.md5sums $DPKG/info/$p:*.md5sums);
+ foreach(@sumfiles) {
+ open S, $_ or next;
+ while (S)
+ {
+ if ($_ eq $sum $path\n)
+ {
+ close S;
+ return 1;
+ }
+ }
}
close S;
@@ -412,6 +416,7 @@
my $sums;
my $pack;
my $conffiles;
+my @sumfiles;
# looks like a package name
unless (/[^a-z\d+.-]/ or /\.deb$/)
@@ -460,31 +465,34 @@
}
else
{
- $sums = $DPKG/info/$pack.md5sums;
- unless (-f $sums or $config)
- {
- if ($missing)
- {
- print $pack\n;
- next;
- }
-
- unless ($generate{missing})
- {
- warn $self: no md5sums for $pack\n;
- next;
- }
-
- unless ($deb)
- {
- warn $self: no md5sums for $pack and no deb available\n
- unless $generate{nocheck} and $silent;
-
- next;
- }
-
- undef $sums;
- $_ = $deb;
+ @sumfiles = glob($DPKG/info/$pack.md5sums $DPKG/info/$pack:*.md5sums);
+ foreach(@sumfiles) {
+ $sums = $_;
+ unless (-f $sums or $config)
+ {
+ if ($missing)
+ {
+ print $pack\n;
+ next;
+ }
+
+ unless ($generate{missing})
+ {
+ warn $self: no md5sums for $pack\n;
+ next;
+ }
+
+ unless ($deb)
+ {
+ warn $self: no md5sums for $pack and no deb available\n
+unless $generate{nocheck} and $silent;
+
+ next;
+ }
+
+ undef $sums;
+ $_ = $deb;
+ }
}
}
@@ -585,7 +593,8 @@
close F;
}
- if (!-s $sums)
+ my @sumfiles = glob($DPKG/info/$pack:*.md5sums);
+ if (!-s $sums scalar(@sumfiles) == 0)
{
my $unpacked = $tmp/$pack;
print Generating missing md5sums for $deb... unless $silent;
debsums-glob.diff.sig
Description: Binary data
Bug#616066: Fix for bug 616066
Attached is a quick fix for this bug, using dpkg-query to get the path
to md5sums.
I did this to fix Launchpad bug 776030
(https://bugs.launchpad.net/debian/+source/debsums/+bug/776030) where
debsums would fail to find the md5sums on any multiarch package.
My perl is a bit rusty but it works for me. I also might have missed
some other hardcoded paths that might need a similar change.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
=== modified file 'debsums'
--- debsums 2010-11-17 17:16:07 +
+++ debsums 2011-06-27 09:24:06 +
@@ -271,9 +271,12 @@
}
}
+my $sumsfile;
for my $p (@{$installed{$pack}{ReplacedBy} || []})
{
- open S, $DPKG/info/$p.md5sums or next;
+ $sumsfile = `dpkg-query -c $p md5sums`;
+ chomp($sumsfile);
+ open S, $sumsfile or next;
while (S)
{
if ($_ eq $sum $path\n)
@@ -460,7 +463,8 @@
}
else
{
- $sums = $DPKG/info/$pack.md5sums;
+ $sums = `dpkg-query -c $pack md5sums`;
+ chomp($sums);
unless (-f $sums or $config)
{
if ($missing)
@@ -626,7 +630,8 @@
if ($generate{keep})
{
- my $target = $DPKG/info/$pack.md5sums;
+ my $target = `dpkg-query -c $pack md5sums`;
+ chomp($target);
copy $sums, $target
or die $self: can't copy sums to $target ($!)\n;
}
signature.asc
Description: This is a digitally signed message part
Bug#631841: python-httplib2 doesn't include upstream cacerts.txt
Package: python-httplib2 Version: 0.7.0-1 Severity: normal Upstream 0.7.0 version is missing cacerts.txt in setup.py This causes python-httplib2 to always fail when checking SSL certificates. Upstream release 0.7.1 as a bugfix release fixing that. I now uploaded 0.7.1 to Ubuntu and also cherry-picked a post-0.7.1 commit from upstream adding GoDaddy to cacerts.txt (needed for Launchpad) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631841: Acknowledgement (python-httplib2 doesn't include upstream cacerts.txt)
Sending the relevant patch to the packaging (adding debian/patches/godaddy_certificate). -- Stéphane Graber Ubuntu developer http://www.ubuntu.com === added directory 'debian/patches' === added file 'debian/patches/godaddy-certificate' --- debian/patches/godaddy-certificate 1970-01-01 00:00:00 + +++ debian/patches/godaddy-certificate 2011-06-27 16:59:47 + @@ -0,0 +1,91 @@ +Description: Cherry-pick GoDaddy root certificate from upstream hg + Add GoDaddy root certificate to cacerts.txt +Author: Joe Gregorio jcgrego...@google.com + +--- python-httplib2-0.7.1.orig/python2/httplib2/cacerts.txt python-httplib2-0.7.1/python2/httplib2/cacerts.txt +@@ -631,3 +631,84 @@ hvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7 + 95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9n9cd + 2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI= + -END CERTIFICATE- ++ ++Go Daddy Certification Authority Root Certificate Bundle ++ ++ ++-BEGIN CERTIFICATE- ++MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMx ++ITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28g ++RGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExMTYw ++MTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH ++QXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWRkeS5j ++b20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j ++b20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlcnRpZmlj ++YXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJKoZIhvcN ++AQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTtwY6vj3D3H ++KrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqVTr9vcyOdQm ++VZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aLGbqGmu75RpR ++SgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo7RJlbmr2EkRT ++cDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgWJCJjPOq8lh8BJ ++6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAwEAAaOCATIwggEu ++MB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVHSMEGDAWgBTSxLDS ++kdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEB ++BCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wRgYDVR0f ++BD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBv ++c2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVHSAAMDgwNgYIKwYBBQUH ++AgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTAO ++BgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBANKGwOy9+aG2Z+5mC6IG ++OgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPIUyIXvJxwqoJKSQ3kbTJSMU ++A2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL5CkKSkB2XIsKd83ASe8T+5o ++0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9p0iRFEUOOjZv2kWzRaJBydTX ++RE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsxuxN89txJx9OjxUUAiKEngHUuH ++qDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZEjYx8WnM25sgVjOuH0aBsXBTWV ++U+4= ++-END CERTIFICATE- ++-BEGIN CERTIFICATE- ++MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Zh ++bGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIElu ++Yy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24g ++QXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAe ++BgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDYyMFoX ++DTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZSBHbyBE ++YWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgMiBDZXJ0 ++aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC ++ggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCAPVYYYwhv ++2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6wwdhFJ2+q ++N1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXiEqITLdiO ++r18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMYavx4A6lN ++f4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+YihfukEH ++U1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ4EFgQU0sSw0pHU ++TBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBuzEkMCIGA1UEBxMb ++VmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwg ++SW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2xpY3kgVmFsaWRhdGlv ++biBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudmFsaWNlcnQuY29tLzEg ++MB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CAQEwDwYDVR0TAQH/BAUw ++AwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmdv ++ZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jZXJ0aWZpY2F0ZXMu ++Z29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybDBLBgNVHSAERDBCMEAGBFUd ++IAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNv ++bS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQC1 ++QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+Sn1eocSxI0YGyeR+sBjUZsE4O ++WBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgMQLARzLrUc+cb53S8wGd9D0Vmsf ++SxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j09VZw== ++-END CERTIFICATE- ++-BEGIN CERTIFICATE- ++MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0 ++IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAz ++BgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9y ++aXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG
Bug#614072: pastebinit: does not work with paste.debian.net
On Sun, 2011-02-20 at 12:46 +0800, Rolf Leggewie wrote: On 20.02.2011 03:29, Alexander Wirt wrote: Rolf Leggewie schrieb am Sunday, den 20. February 2011: Sending CC to Alexander to ask him about his opinion and whether he can remove the multi-line restriction. Please have a look at Debian bug 614072. As the multi-line restriction eliminates nearly all spam - no. Stéphane, I have to say, I'm with Alexander on this one. Single-line pastebins don't make a whole lot of sense and it evidently makes his life a whole lot easier. Can't we put another restriction in the pastebin configuration similar to the pastebin A supports up to XYZ bytes? Or simply disallow single-line pastebins in general? Regards Rolf I don't think disabling it for all pastebins is a good idea as people seem to actually use that (or we wouldn't have had bug reports ;)). Implementing a minimum lines option in the pastebin definition would be the preferred way of doing it. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com smime.p7s Description: S/MIME cryptographic signature
Bug#614072: pastebinit: does not work with paste.debian.net
On Sun, 2011-02-20 at 02:36 +0800, Rolf Leggewie wrote: On 19.02.2011 22:17, Lars Wirzenius wrote: Package: pastebinit Version: 1.1-2 Severity: normal When I try to use pastebinit with paste.debian.net, I don't get a URL to the new page, just to the front page: liw@havelock$ echo foo | pastebinit -i - -b http://paste.debian.net http://paste.debian.net/ liw@havelock$ Lars, thank you for reporting this. I can confirm the issue with the latest release, paste.debian.net is my default pastebin. pastebin.com is currently not working for me, either. I suspect there is something going on with the website, possibly the interface changed and we need an update to the pastebin definition. Regards Rolf As I mentioned on Launchpad, paste.debian.net requires the input to be multiple lines long: stgraber@castiana:~$ echo -e 1 2 | pastebinit -b http://paste.debian.net http://paste.debian.net/ stgraber@castiana:~$ echo -e 1\n2 | pastebinit -b http://paste.debian.net http://paste.debian.net/108205/ As far as I know, it's the only pastebin with such a limitation. It might be worth asking whoever maintains it to rem -- Stéphane Graber Ubuntu developer http://www.ubuntu.com smime.p7s Description: S/MIME cryptographic signature
Bug#499410: cannot properly read from stdin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A fix for that same bug has been applied a while ago on the bzr branch, can you try the pastebinit from the upstream branch to make sure it works as expected ? I still need to update the manpage and fix another couple of bug before releasing a new pastebinit. http://bazaar.launchpad.net/~pastebinit-developers/pastebinit/trunk/files -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkIVrcACgkQjxyfqkjBhuyz0wCfTMSz8WJO1cy9ztd5/KvpQKdJ GdsAnA5IPbtYN9Pqf6o+A0ExOCtry1Mg =4mqq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
