Re: libotr 4.0.0 hasn't entered testing after 55 days
On Sat, Jul 6, 2013 at 5:27 PM, Paul Wise wrote: > On Sat, Jul 6, 2013 at 11:14 PM, Thibaut VARENE wrote: > > > Still don't get it: why are bugs in packages that depend on libotr > blocking > > libotr? libotr is perfectly fine and I don't see why it should be blocked > > from moving to testing because some packages that depend on it aren't > > properly maintained? Wnat if these packages are never updated to libotr5? > > Are we going to punish those who have updated? This is for instance > > preventing the migration of pidgin-otr and irssi-plugin-otr, and I'm > > receiving (angry) mail about it (which is the reason why I looked into > this > > in the first place) ;-P > > There are still binary packages depending on libotr2, once those are > fixed to depend on libotr5 then the binary packages from the old > libotr can be removed and the new one can migrate. I think, I'm not a > release team member though. > > $ apt-cache rdepends libotr2 > libotr2 > Reverse Depends: > psi-plus-plugins > mcabber > libotr2-dev > libotr2-bin > bitlbee-plugin-otr > The two libotr2* are gone, as part of the migration. So all is left to wait for the 3 packages you already mentioned, and as I said, that means that if, for some reason, they're never updated, libotr will never migrate, i.e. slow pokes penalize good citizens. That seems backwards. Seriously so. T-Bone
libotr 4.0.0 hasn't entered testing after 55 days
Hi,
libotr 4.0.0 hasn't entered testing yet and I don't understand why. The
status page reports that it hasn't been built on any arch ("missing 3
binaries"), but those binaries are no longer built by libotr.
Help?
Thanks
--
Thibaut VARENE
http://hacks.slashdirt.org/
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 2:43 PM, Neil Williams wrote: > Having a freeze simply means that some package changes *must* be > delayed until after the freeze. Experimental works for some, if it > doesn't work for you then you cannot update the package in Debian until > the release, so maybe help get the release out. I believe I was mistaken as to what a "freeze" is. To me the freeze impacted testing, not unstable, being the whole purpose of a "freeze", i.e. ensuring that new packages in unstable don't make it to testing-soon-to-be-stable. I didn't realize this meant that /unstable/ was to be considered as frozen too. Maybe it should effectively be so, so that new packages that aren't RC fixes can't even be uploaded to sid. This would avoid something like this happening again in the future. Anyway, I stand corrected. That being said, I'd like to point out again that all this fuss was made for nothing, since none of the packages listed in the initial email are being blocked from entering wheezy because of this upload, since none of them are unfrozen, and wheezy is unaffected by this change. And I see nothing wrong with breaking packages in unstable, but maybe there too I'm mistaken. -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+dqjfjuluuu5b9txxuoplg-shsnc8xfavek_vgnfgqmo9d...@mail.gmail.com
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 1:04 PM, Neil Williams wrote: > On Tue, 6 Nov 2012 10:59:42 +0100 > Thibaut VARENE wrote: > >> On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern wrote: >> > On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: >> >> I thought that Wheezy having been frozen for quite some time, it was okay >> >> to upload new packages to unstable again. >> > >> > I'm sure we would've communicated that on d-d-a if this would've been >> > the case. >> >> Okay then. Wheezy has been frozen for 4 months already. Out of >> curiosity, how long will we have to wait before new software can be >> pushed again to Debian? > > If it's targeting experimental, that is already possible and has never > been a problem. > > If it's to target unstable then expect an announcement on d-d-a to the > effect that unstable is now open again a few days after the Wheezy > release. (Release, not freeze). i.e. around the time that Jessie > becomes available as the new testing. > > Note that from past experience, it's not advisable to upload very soon > after the d-d-a announcement anyway. So many other packages get > uploaded at that point that many dependencies become uninstallable. Talk > to maintainers of packages which your package needs and co-ordinate in > advance. > > If you want it in Debian now, push it into experimental. If you want it > Jessie (the next testing), then wait for the d-d-a announcement. If you > wanted it in Wheezy it's too late. If you just wanted it in unstable > then it's clear that this is not desirable and your only option is > experimental. Noted. The package was in experimental for several weeks and got zero attention. My general understanding is that nobody looks at experimental anyway. Another part of the issue was upstream's will to have it in Ubuntu as soon as possible. Ubuntu autosync doesn't fetch from experimental. -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+dqjfiuwtblme5mcotwygyuryj+-5m7ek-gk+sxb47eg_l...@mail.gmail.com
Bug#692327: libotr: Please provide libotr2
On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern wrote: > On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote: >> I thought that Wheezy having been frozen for quite some time, it was okay >> to upload new packages to unstable again. > > I'm sure we would've communicated that on d-d-a if this would've been > the case. Okay then. Wheezy has been frozen for 4 months already. Out of curiosity, how long will we have to wait before new software can be pushed again to Debian? > (Also please don't put a ">" before the lines you wrote yourself.) I blame Gmail's silly new interface :-P Best -- Thibaut VARENE http://hacks.slashdirt.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+DQjFhrL+AEekfOGHLD_cBYf78yRQP5=ndlin+rpclg5af...@mail.gmail.com
Bug#692327: libotr: Please provide libotr2
On Mon, Nov 5, 2012 at 2:32 PM, Dmitrijs Ledkovs wrote: > On 05/11/12 10:58, Thibaut VARENE wrote: > > severity 692327 important > > thanks > > > > I don't see how this is a serious bug. > > Currently libotr2* are not build from any source package in sid. > That means that any packages depending on it cannot transition into > testing (if it was not frozen). > Is there such a not frozen package? > That also means that libotr5 cannot transition into testing (if it was > not frozen). > That was never the plan, considering libotr5 got uploaded (purposefully) after the freeze. > Sure it's not a problem. But if the existing status quo is kept, neither > libotr5 nor the new pidgin will make it into wheezy nor jessie. > That it won't make it to wheezy, I can see why and that's intended. I don't see how jessie is affected. My package is fine, pidgin-otr is fine, and they both work. The other packages that depend on libotr need to update, and again, I don't see why they wouldn't considering that libotr5 is the NEW libotr. Or are you suggesting that for the sake of the argument, all dependencies are going to stick using libotr2 just to piss me off? > Your package is not fit for inclusion in a stable release. > Really? That's news to me. > Given your position, maybe you should file removal requests for package > that still depend on libotr2. > I don't see a need for that when all it takes to "resolve" this "issue" is an update from the dependent packages. If we were to request package removal everytime a new library breaks its API, things would get pretty ugly (and by that I mean, more than they usually are). > In Ubuntu, I have uploaded libotr2 source package to transition libotr5 > into testing and keep all applications that use libotr2 or libotr5 > installable and releasable. > Very nice. Enjoy dealing with the innevitable mess this will provoke. -- Thibaut VARENE http://hacks.slashdirt.org/
Bug#692327: libotr: Please provide libotr2
On Mon, Nov 5, 2012 at 2:36 PM, Julien Cristau wrote: > On Mon, Nov 5, 2012 at 11:58:12 +0100, Thibaut VARENE wrote: > > > severity 692327 important > > thanks > > > > On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs > wrote: > > > > > Package: libotr, release.debian.org > > > Severity: serious > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Recently libotr has been updated to version 4.x.x with binary package > > > name libotr5. > > > > > > By the looks of things, it was done because of pidgin-otr package which > > > now requires libotr5. > > > > > > > It was done because upstream has updated their source and the new libotr > is > > incompatible with the old one. > > > Which means it's not an appropriate change during a freeze. > > I thought that Wheezy having been frozen for quite some time, it was okay to upload new packages to unstable again. Please note in passing that libotr5, being NEW, went through the NEW queue and was reviewed at that time. > > > > > But this means an un-coordinated transition has started, as there are 6 > > > other packages that build-depend on libotr2-dev and all of them fail to > > > build from source against libotr5-dev: > > > > > > > I was not aware a "coordinated transition" was necessary for such a small > > library. I'm under the impression the release team has bigger fish to fry > > right now. > > > Which is why they very much don't appreciate this kind of disruption. > A SONAME bump in a library right now in sid is not welcome, and needs to > wait until the wheezy release. Please revert. > > That wasn't obvious to me. What do you mean "revert"? I cannot upload a package with an older revision. -- Thibaut VARENE http://hacks.slashdirt.org/
Bug#692327: libotr: Please provide libotr2
severity 692327 important thanks On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs wrote: > Package: libotr, release.debian.org > Severity: serious > User: release.debian@packages.debian.org > Usertags: transition > > Recently libotr has been updated to version 4.x.x with binary package > name libotr5. > > By the looks of things, it was done because of pidgin-otr package which > now requires libotr5. > It was done because upstream has updated their source and the new libotr is incompatible with the old one. > But this means an un-coordinated transition has started, as there are 6 > other packages that build-depend on libotr2-dev and all of them fail to > build from source against libotr5-dev: > I was not aware a "coordinated transition" was necessary for such a small library. I'm under the impression the release team has bigger fish to fry right now. > * bitlbee > * irssi-plugin-otr > * kdenetwork > * mcabber > * psi-plus > * python-otr > > Please do something to resolve this. Input from release team is highly > welcome. > > Possibilities I can think of are: > * revert libotr source package to 3.2.1-1 & upload libotr5 (4.0.0-2) > source package > No. Upstream will not provide maintenance for 3.x. > * keep libotr source package as it is, upload libotr2 (3.2.1-1) source > package > No. See above. > * provide patches/NMUs to fix FTBFS for above packages when built > against libotr5-dev. > How about letting their upstreams doing their jobs? libotr 3.x is gone, I'm sure they'll wake up eventually. > Usually disruptive uploads like this one, should be co-ordinated with > the release team with a transition bug, and staged in experimental to do > test rebuilds. > I don't see how this is a serious bug. 1) it only affects unstable (which is named so for a reason) 2) libotr5 has been sitting in experimental for quite a while, and upstream devs have been quite vocal about the transition 3) libotr5 can be installed alongside libotr2 kthxbye -- Thibaut VARENE http://hacks.slashdirt.org/
Bug#686463: followup
"Adam D. Barratt" > In that case, would it not make more sense to remove it from unstable? Sure, why not. Removing it from the upcoming stable distribution is really necessary anyway. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+dqjfiwrerxnvhmnos9vjpxtj7xdnnk83dnmh-cwr4m44t...@mail.gmail.com
Bug#686463: RM: lomoco/1.0beta1+1.0-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Dead upstream, orphaned. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120901205243.21448.69606.report...@gropaf.esiee.fr
Bug#684140: unblock: libotr/3.2.1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libotr
Fixes security hole (possible buffer overflow in base64 routines): #684121
The only change from 3.2.0-4 (currently in wheezy) and 3.2.1-1 is the security
fix, see the attached debdiff.
unblock libotr/3.2.1-1
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.29.2 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
diff -Nru libotr-3.2.0/ChangeLog libotr-3.2.1/ChangeLog
--- libotr-3.2.0/ChangeLog 2008-06-15 22:16:34.0 +0200
+++ libotr-3.2.1/ChangeLog 2012-08-07 12:21:35.0 +0200
@@ -1,3 +1,20 @@
+2012-07-27
+
+ * src/version.h: Update libotr version number to 3.2.1
+
+2012-07-19
+
+ * src/b64.[ch], src/proto.c, toolkit/parse.c: Clean up the
+ previous b64 patch and apply it to all places where
+ otrl_base64_decode() is called.
+
+2012-07-17
+
+ * src/b64.c: Use ceil instead of floor to compute the size
+ of the data buffer. This prevents a one-byte heap buffer
+ overflow. Thanks to Justin Ferguson
+ for the report.
+
2008-06-15:
* README: Release version 3.2.0.
diff -Nru libotr-3.2.0/debian/changelog libotr-3.2.1/debian/changelog
--- libotr-3.2.0/debian/changelog 2011-12-26 18:34:38.0 +0100
+++ libotr-3.2.1/debian/changelog 2012-08-07 12:25:12.0 +0200
@@ -1,3 +1,9 @@
+libotr (3.2.1-1) unstable; urgency=high
+
+ * Fix potential buffer overflow in base64 routines (Closes: #684121)
+
+ -- Thibaut VARENE Tue, 07 Aug 2012 12:24:15 +0200
+
libotr (3.2.0-4) unstable; urgency=low
* lintian cleanup:
diff -Nru libotr-3.2.0/src/b64.c libotr-3.2.1/src/b64.c
--- libotr-3.2.0/src/b64.c 2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/b64.c 2012-08-07 12:21:31.0 +0200
@@ -55,7 +55,7 @@
\*** */
/* system headers */
-#include
+#include
#include
/* libotr headers */
@@ -147,8 +147,9 @@
* base64 decode data. Skip non-base64 chars, and terminate at the
* first '=', or the end of the buffer.
*
- * The buffer data must contain at least (base64len / 4) * 3 bytes of
- * space. This function will return the number of bytes actually used.
+ * The buffer data must contain at least ((base64len+3) / 4) * 3 bytes
+ * of space. This function will return the number of bytes actually
+ * used.
*/
size_t otrl_base64_decode(unsigned char *data, const char *base64data,
size_t base64len)
@@ -234,13 +235,18 @@
return -2;
}
+/* Skip over the "?OTR:" */
+otrtag += 5;
+msglen -= 5;
+
/* Base64-decode the message */
-rawlen = ((msglen-5) / 4) * 3; /* maximum possible */
+rawlen = OTRL_B64_MAX_DECODED_SIZE(msglen); /* maximum possible */
rawmsg = malloc(rawlen);
if (!rawmsg && rawlen > 0) {
return -1;
}
-rawlen = otrl_base64_decode(rawmsg, otrtag+5, msglen-5); /* actual size */
+
+rawlen = otrl_base64_decode(rawmsg, otrtag, msglen); /* actual size */
*bufp = rawmsg;
*lenp = rawlen;
diff -Nru libotr-3.2.0/src/b64.h libotr-3.2.1/src/b64.h
--- libotr-3.2.0/src/b64.h 2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/b64.h 2012-08-07 12:21:31.0 +0200
@@ -20,6 +20,19 @@
#ifndef __B64_H__
#define __B64_H__
+#include
+
+/* Base64 encodes blocks of this many bytes: */
+#define OTRL_B64_DECODED_LEN 3
+/* into blocks of this many bytes: */
+#define OTRL_B64_ENCODED_LEN 4
+
+/* An encoded block of length encoded_len can turn into a maximum of
+ * this many decoded bytes: */
+#define OTRL_B64_MAX_DECODED_SIZE(encoded_len) \
+(((encoded_len + OTRL_B64_ENCODED_LEN - 1) / OTRL_B64_ENCODED_LEN) \
+ * OTRL_B64_DECODED_LEN)
+
/*
* base64 encode data. Insert no linebreaks or whitespace.
*
@@ -33,8 +46,9 @@
* base64 decode data. Skip non-base64 chars, and terminate at the
* first '=', or the end of the buffer.
*
- * The buffer data must contain at least (base64len / 4) * 3 bytes of
- * space. This function will return the number of bytes actually used.
+ * The buffer data must contain at least ((base64len+3) / 4) * 3 bytes
+ * of space. This function will return the number of bytes actually
+ * used.
*/
size_t otrl_base64_decode(unsigned char *data, const char *base64data,
size_t base64len);
diff -Nru libotr-3.2.0/src/proto.c libotr-3.2.1/src/proto.c
--- libotr-3.2.0/src/proto.c 2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/proto.c 2012-08-07 12:21:31.0 +0200
@@ -537,13 +537,17 @@
msglen = strlen(otrtag);
}
+/* Skip over the "?OTR:" */
+otrtag += 5;
+msglen -= 5;
+
/* Base64-decode the message */
-rawlen = ((msglen-5) / 4) * 3; /* maximum possible */
+rawlen = OTRL_B64_MAX_DECODED_SIZE(msglen);
Re: open issues with the hppa port
On Fri, Sep 11, 2009 at 10:01 PM, LaMont Jones wrote: > On Fri, Sep 11, 2009 at 02:06:36PM -0400, Carlos O'Donell wrote: >> On Fri, Sep 11, 2009 at 1:06 PM, dann frazier wrote: >> What happened to sarti? Loosing a box like that would certainly add >> load to the others. > > Sarti failed to power on one day. As in you can access GSP but it won't load anything? If so, I've seen that on a couple of my boxes. Usually a replacement of the GSP board (and possibly the power regulator) fixes it. At least it did for me... I've also seen PSU failures, I've been able to fix some of them. I see sarti seems to be a regular A500-5X. I happen to have a scrapped A400 with a bogus PSU (not entirely dead, seems like high voltage goes off, been unsuccessful at fixing it so far). If necessary, I might be able to collect the GSP board from that machine and send it some place, assuming it's compatible with an A500's (I'm expecting it would require a modelname change, which needs MFG mode access password, which can only be obtained by an HP employee). Just thinking out loud, but the possibility's there. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Fri, Sep 11, 2009 at 10:44 PM, LaMont Jones wrote: > On Fri, Sep 11, 2009 at 02:35:00PM -0600, dann frazier wrote: >> That would prevent it from getting uploaded, but won't that package >> get marked as built, preventing other buildds from trying? > > Yep. If you just want to build packages over and over, then don't start > the buildd up, and just run sbuild on a series of sources It's also relatively easy to setup a local w-b database fed with proper quinn-diff input (using Sources.gz / Packages.gz to extract the missing packages). I have scripts that do exactly that, if you want to explore that way. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sat, Jun 20, 2009 at 4:39 PM, Kurt Roeckx wrote: > On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: >> So it's my understanding that the porters have no idea about the >> problems. So I will start to mail you about problems as soon >> as I see them and they look like porting issues specific >> to hppa. > > Ruby1.9 hangs in test_thread.rb and gets killed after > 150 minutes of inactivity. I assume NPTL will fix this. yes, it's a ruby bug, it's been explained on this m-l already. Ruby's implementation cannot handle linuxthreads. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Thu, Jun 18, 2009 at 8:33 AM, Luk Claes wrote: > John David Anglin wrote: >>> Grant Grundler schrieb: >>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: >>>>> Grant Grundler wrote: > >> I can understand the desire to trim architectures. However, it's clear >> the current decision was based on some misinformation, and an unclear >> rational. > > There is no desire to trim working architectures. > > It's very easy to tell there is nothing wrong when you don't have to > deal with unreliable build daemons, endless discussions but no visible > progress (except for java support) and complaints from DSA, package > maintainers and others. I'm sorry, but this thread is now over 2 weeks old and we yet have to see a *rationale* motivating the current decision. Not some claims about bugs (which we still haven't been pointed at, except for the ruby one, which we addressed already) affecting the buildds (and that only you experience). Speaking of which, I'm not aware of any problem affecting lafayette... We have given you tangible elements and have answered each and every questions that have been raised in this thread. The release team, on the other hand, failed to answer the single question we've been asking: what's the rationale for dropping parisc? I joined Debian many years ago because it seemed to me that it had proper ethics, in particular because decisions were taken transparently, and were properly - and openly - discussed before anything final was settled. I too have invested time and money into the project. I'm extremely disappointed with the handling of the issue at stake here. Again, I would like to see a comprehensive rationale for this decision, so that we can at least try to address the problems at hands and hope for re-inclusion after squeeze. BTW, can you clarify whether that would be an option? Cheers, T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 12, 2009 at 5:35 PM, dann frazier wrote: > On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote: >> It seems to be related to what machine you actually have. > > And the load - buildds for unstable seem to trip over issues that we > don't see elsewhere. "Workload" more to the point. Almost all my parisc boxen have been running BOINC for years and never puked on it. I'm quite convinced the issues buildds are suffering are much less random than people believe. It's more likely that they are very uncommon corner cases. FWIW, afaik "lafayette" - the autobuilder I recently provided - seems to be running mostly fine. And as far as I (as the local admin) am concerned, I believe my "response" time to problems (such as when the first hardware that was committed to this autobuilder failed beyond salvation and had to be entirely replaced) is acceptable. Let me know if that weren't true ;-) HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Tue, Apr 28, 2009 at 11:34 PM, dann frazier wrote: > On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote: >> On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes wrote: >> > * The machines that host the buildds still seem to have a very >> > unreliable kernel. Is there any update on this? >> >> I can't comment on this. > > Thibaut had planned to setup a second buildd (and I think had it up > for a while?) but that box experienced a hardware failure. We're also > working on moving one of the buildds to a different platform > (rp2470). We have no specific reason to believe that will be any > better, but its worth a shot. Yes the supplementary buildd had a major hardware failure today (SBA/LBA failures during last POST and now the GSP can't load PDC anymore. The machine is basically dead). I'm switching the hard drives to another box I have that I used elsewhere (not yet back online as the Debian kernel seems to have major trouble coping with PCI addon NICs - tulip and tg3 HPMC the machine on driver load), and I'm still hoping to get feedback on some hardware donation requests I've made a month or so ago. I hereby take the opportunity to say that I would gladly welcome any rackable parisc system in my server room. :-) >> I run stock: linux-image-2.6.26-1-parisc64-smp (2.6.26-13) >> on my SMP 2x PA8700 system without any problems. > > There are several reports of stability on various mixtures of > kernel/platform - and the non-buildd debian.org hppa machine seems to > be quite stable as well. But, once we start running a buildd on > something, instability issues abound. The only issue I've been aware of so far was the ruby build problem. If there are others, they need more publicity I think. OTOH, ISTR Carlos said most of the problems could go away with the transition to NPTL. Might be worth a try... >> > * The debian-installer dailies that are now built again, but seem to >> > fail to build most of the time. Is there any particular reason for this? >> >> No idea. Do you have a log? I would blame recent failures on failure to build kernel, maybe? AFAICT there was the phonet issue (fixed since then) and it seems recent kernel builds fail to link the btrfs module... HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Missing gmo files in pidgin-otr package
Le 21 févr. 09 à 21:06, Luk Claes a écrit : Please open a bug for the issue and mention your package including the Done that bug number on the wiki [1]. Please also upload a fixed package to proposed-updates, TIA Seems I'll need some help there: tried to upload yesterday, got rejected with: Mapping stable-proposed-updates to proposed-updates. Rejected: pidgin-otr_3.2.0-2lenny0_amd64.deb: old version (3.2.0-2) in testing <= new version (3.2.0-2lenny0) targeted at proposed-updates. Rejected: pidgin-otr_3.2.0-2lenny0.dsc: old version (3.2.0-2) in testing <= new version (3.2.0-2lenny0) targeted at proposed-updates. Seems the upload queue assumes I'm uploading to testing-proposed- updates, which I'm not... Thanks T-Bone -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Fri, Dec 19, 2008 at 2:38 PM, Christoph Martin wrote: > The kernel build succeded after 71 hours. [snip] > What do I have to do to establish and configure it as a buildd host? How about being a little bit sensible? a C100 will *never* be suitable as a buildd host. Your offer is certainly generous and appreciated, but it's not realistic. There have been other offers in the past (including mine) involving much more powerful machines (which can build a kernel in a matter of minutes, not hours). They, so far, have been left unanswered, so it seems that Debian is satisfied with the current number of hppa buildds. Regarding the bugs themselves, there's a fair amount of work currently ongoing to fix them (check the linux-parisc archive), stay tunned for (hopefully) good news. Cheers -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Mon, Dec 15, 2008 at 9:49 AM, Matt Taggart wrote: > A c100 is _really_ slow and probably wouldn't be able to keep up as a > buildd. I've already offered countless times (it's in the m-l archive) to provide buildd power from the ESIEE cluster (see http://www.fr.parisc-linux.org/cluster.html), which is also used by a bunch of DD to fix hppa problems. Granted, this cluster currently has some hw issues which I'm trying to fix (hopefully with the help of some folks in the US ;-) > The real problem is that no one is fixing hppa kernel problems. I don't see > much point in keeping the archive up to date if nobody is working on fixing > the kernel (not currently and I suspect not in the future either). This has > been stated on the debian-hppa list several times over a long period and in > that time no one (AFAIK) has stepped up to work on it. Sad but true, though I wouldn't say that "no one" is working; the linux-parisc m-l shows "some" activity from a couple of developers (Kyle McMartin, Helge Deller, to name a few) Cheers, T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please allow libapache-mod-musicindex 1.2.2-3 into lenny
Hi, I just uploaded libapache-mod-musicindex 1.2.2-3 to unstable, which contains a single fix (interdiff follows) for #494857. Though not a severe bug, it has a direct impact on some functionalities regarding the module: it basically breaks any customisation the user might want to add to the module in a very unpleasant and hard to track way (see the full bug report for details). It would also imply reopening #385619 and #371164 which are not really fixed unless this bug is actually fixed as well... The fix is really trivial, as the following interdiff shows, and I would feel really better knowing that the version shipped in the upcoming stable release had it. TIA T-Bone interdiff -zz libapache-mod-musicindex_1.2.2-2.diff.gz libapache-mod-musicindex_1.2.2-3.diff.gz diff -u libapache-mod-musicindex-1.2.2/debian/changelog libapache-mod-musicindex-1.2.2/debian/changelog --- libapache-mod-musicindex-1.2.2/debian/changelog +++ libapache-mod-musicindex-1.2.2/debian/changelog @@ -1,3 +1,9 @@ +libapache-mod-musicindex (1.2.2-3) unstable; urgency=medium + + * Closes: #494857: Wrong Alias directive in configuration file + + -- Thibaut VARENE <[EMAIL PROTECTED]> Thu, 14 Aug 2008 21:04:00 +0200 + libapache-mod-musicindex (1.2.2-2) unstable; urgency=low * The "lazy bastard won't roll out a new release just for translation" repack diff -u libapache-mod-musicindex-1.2.2/debian/musicindex.conf libapache-mod-musicindex-1.2.2/debian/musicindex.conf --- libapache-mod-musicindex-1.2.2/debian/musicindex.conf +++ libapache-mod-musicindex-1.2.2/debian/musicindex.conf @@ -1,5 +1,5 @@ -Alias /musicindex/ "/usr/share/mod_musicindex/" - +Alias /musicindex "/usr/share/mod_musicindex" + Order allow,deny Allow from all -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Sun, Jun 8, 2008 at 9:46 PM, Andreas Barth <[EMAIL PROTECTED]> wrote: > Of course, this demands enough buildd power, and wanna-build access by > (some of) the porters (or whatever else you consider appropriate). > Moreover it needs quite a lot of time to track that closely, which the > Release Team probably won't have on its own, so we will need hppa > buildd-admin and hppa porters time, a lot. > > After the transition is done (and we can only hope it is in time for > lenny), hppa could be added back to the normal architectures. Downside > of this is of course that in case hppa is slower than lenny, lenny would > be released without hppa. Should the need arise, I can provide hppa buildd horsepower. I (pretty much) know how to run a buildd[0], thanks to lamont, and I can give root access to my cluster to whoever (provided minor trust checks) needs it (lamont already has it). Time is definitely something I have very little control over nowadays tho, but I'll try my best ;P HTH T-Bone [0] unless it has significantly changed in the last couple years: I ran the first autobuild effort for hppa ubuntu, and I'm currently running hppa/ia64/alpha autobuilders for debian-multimedia.org -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unblock and help request
On 3/8/07, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: "Thibaut VARENE" <[EMAIL PROTECTED]> writes: > First, I'd like to ask for unblocking on uptimed 1:0.3.10-3, which is > a debconf translation-only upload (I also swapped Maintainer/Uploaders > after discussing with the previous maintainer Daniel Gubser, in order > to reflect the fact that I'm the new de-facto maintainer of uptimed). Unblocked. Thanks > Second, I'd need help dealing with #411301. Upstream suggested a fix > (see the last mail on this bug report), but I'd like to know if said > fix is suitable for etch, or not. I don't feel that static linking of something like libgcrypt is something we should encourage. This really needs to be fixed in gaim, Well, if my understanding of the problem is right, I'd say it's rather libcrypt which needs to be fixed... but that fix will not be ready before we release. So I guess this important bug will not be fixed for the release :-/ Seems that way, unfortunately Thanks -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unblock and help request
Hi, First, I'd like to ask for unblocking on uptimed 1:0.3.10-3, which is a debconf translation-only upload (I also swapped Maintainer/Uploaders after discussing with the previous maintainer Daniel Gubser, in order to reflect the fact that I'm the new de-facto maintainer of uptimed). Second, I'd need help dealing with #411301. Upstream suggested a fix (see the last mail on this bug report), but I'd like to know if said fix is suitable for etch, or not. Thanks T-Bone PS: please CC-me in replies, I'm not subscribed. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugfix uploads
On 2/20/07, Thibaut VARENE <[EMAIL PROTECTED]> wrote: Hi, I just uploaded libapache-mod-musicindex 1.1.4-1 and uptimed 1:0.3.10-1 which are both bugfix-only (#388440, #385619, #381593, #192395) releases. Sorry for such a close by upload, by the portuguese translation team sent a portuguese translation which I uploaded in -2, as long as a fix in debian/control so that uptimed can be correctly binNMU'd in the future... HTH T-Bone PS: please CC-me in answers -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bugfix uploads
Vorlon wrote: >On Tue, Feb 20, 2007 at 03:32:18AM +0100, Thibaut VARENE wrote: >> I just uploaded libapache-mod-musicindex 1.1.4-1 > >Fairly large diff, fairly low-impact bugs AFAICS; not unblocked. Err, "fairly large"? The code almost hasn't changed. The only thing that changed are text strings in said code because I modified the html that is output (and checked it still valid, of course). You can assert that by checking that the biggest changes are in html.c and musicindex.css... I thought it'd be ok, even more since you ACK'd the same kind of "formatting changes" for uptimed... Being the upstream author of that piece of code, I can totally /assert/ that I'm in full maintenance mode on my side as well :) But it's your call anyway... HTH T-Bone (Please CC me in replies) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bugfix uploads
Hi,
I just uploaded libapache-mod-musicindex 1.1.4-1 and uptimed
1:0.3.10-1 which are both bugfix-only (#388440, #385619, #381593,
#192395) releases.
The version number bump on both is just meant to avoid a version skew
with upstream.
I think it'd be nice to have these fixes in etch, so feel free to unblock...
HTH
T-Bone
PS: FWIW, there's been an override disparity between the binary-indep
and binary-arch packages generated by libapache-mod-musicindex:
- mod-musicindex-common is in web - optional
- libapache{2}-mod-musicindex is in net - optional
So far I've settled for the latter, leaving a conflict between .deb
and override on the -common package...
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uptimed 1:0.3.8-2
Hi all In case anyone cares, I just uploaded uptimed-1:0.3.8-3 which includes the spanish translation (#404491) and a quick fix for #256968. Feel free to let it in etch (or not) :) HTH and HNY! T-Bone On 12/15/06, Andreas Barth <[EMAIL PROTECTED]> wrote: * Thibaut VARENE ([EMAIL PROTECTED]) [061215 12:01]: > uptimed 1:0.3.8-2 is stuck in unstable, but it would make sense to let > it through to testing as it fixes a couple bugs (#383516, #389834). > The only upstream change is a variable size issue that could cause a > variable overflow. There's no functionnality change aside that, so > even at the upstream level, this was a bugfix release. There was another change, but still approved. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uptimed 1:0.3.8-2
Hi, I had uploaded a new version of uptimed with the hope that it would make it before the freeze, unfortunately it didn't: uptimed 1:0.3.8-2 is stuck in unstable, but it would make sense to let it through to testing as it fixes a couple bugs (#383516, #389834). The only upstream change is a variable size issue that could cause a variable overflow. There's no functionnality change aside that, so even at the upstream level, this was a bugfix release. HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#350501: nscd: [hppa] error while loading shared libraries: unexpected reloc type 0x42
On 2/9/06, Denis Barbier <[EMAIL PROTECTED]> wrote: > On Thu, Feb 09, 2006 at 11:32:15AM +0100, Thibaut VARENE wrote: > > Good catch, I completely forgot about that one, I thought it was > > already merged in. > > Thibaut, there is something strange about this bugreport, it seems > to prevent glibc 2.3.5-13 from entering testing, even if it is > tagged "etch,sid". Thus maybe I will temporarily close it to let > 2.3.5-13 enter testing, and reopen it afterwards. This is ugly, > but I do not know of a better solution. That doesn't look good at all to me. Better ask release managers, hence CCing debian-release. T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/
Security fix in libotr1-2.0.2-1
Hi I've just uploaded libotr1-2.0.2-1 which contains a security fix (potential buffer overflow). Quoting the upstream author: "it's indeed a potential security issue for apps that use libotr in a certain way. But it turns out gaim-otr doesn't use it in that way, so it isn't affected. But other (hypothetical) apps that use the sarge libotr probably should be protected by getting 2.0.2, yes." I think it would be wise to update the sarge version (libotr1-2.0.1-1) whenever possible. Thx T-Bone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Dropping 2.4 hppa kernel-image packages
*** PLEASE CC ME IN REPLIES *** > If the hppa 2.6 kernels were included in the last d-i release candidate > and there are successful install reports with that version, I think it's > reasonable to consider dropping 2.4 kernels if they're really this > difficult to support. Not only are they. They are OBSOLETE, and UNMAINTAINED upstream. > If 2.6 was not actually used on this architecture in RC2, then someone > should have realized that 2.4 was unsupportable three months ago, > *before* RC2 was released. Going straight from no 2.6 support in the > installer to using it as the only kernel we're shipping in the space of > a single release candidate cycle is really not an option, there simply > aren't enough safeguards against a change like this derailing the > release planning process. You don't get the correct reasoning here: Last summer, 2.6 wasn't working properly on hppa (much borkage) and the only reasonably working kernel we had back then was 2.4. Though, 2.4 support was already a _HACK_ and much effort was put into 2.6, with the aim of getting rid of 2.4 ASAP. Back then, it was emphasised that Sarge might release anytime soon, so we decided to take the safe approach and go with 2.4. Now 6 months have elapsed, and things are the complete opposite: 2.4 is completely obsolete, and 2.6 works smoothly. So ranting about not having received proper advice a few months ago is a moot point. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ pgpNNZt81ahGC.pgp Description: PGP signature
Re: Re: Dropping 2.4 hppa kernel-image packages
*** PLEASE CC ME IN REPLIES *** > If the hppa 2.6 kernels were included in the last d-i release candidate > and there are successful install reports with that version, I think it's > reasonable to consider dropping 2.4 kernels if they're really this > difficult to support. Not only are they. They are OBSOLETE, and UNMAINTAINED upstream. > If 2.6 was not actually used on this architecture in RC2, then someone > should have realized that 2.4 was unsupportable three months ago, > *before* RC2 was released. Going straight from no 2.6 support in the > installer to using it as the only kernel we're shipping in the space of > a single release candidate cycle is really not an option, there simply > aren't enough safeguards against a change like this derailing the > release planning process. You don't get the correct reasoning here: Last summer, 2.6 wasn't working properly on hppa (much borkage) and the only reasonably working kernel we had back then was 2.4. Though, 2.4 support was already a _HACK_ and much effort was put into 2.6, with the aim of getting rid of 2.4 ASAP. Back then, it was emphasised that Sarge might release anytime soon, so we decided to take the safe approach and go with 2.4. Now 6 months have elapsed, and things are the complete opposite: 2.4 is completely obsolete, and 2.6 works smoothly. So ranting about not having received proper advice a few months ago is a moot point. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ pgp6IGL6weSm7.pgp Description: PGP signature
Dropping 2.4 hppa kernel-image packages
Hi, I've been discussing lately on #d-kernel about the fate of 2.4 hppa kernel packages. Here is a brief summary of the issue: I received a bugreport (#289590) because 2.4.27 package FTBFS, and that's the result of: 1) a (imho) very invasive and massive Debian patchset that conflicts with 2) a huge, dirty and no longer maintained parisc 2.4 diff to the pristine kernel. In other words, I'm up to the point where it begins to be unreasonably complicated to maintain a 2.4 Debian package because OTOH we (parisc-linux kernel hackers) no longer maintain our 2.4 repository and OTOH the 2.4 parisc port has always been nothing but a big hack to the 2.4 pristine source. Indeed, we never merged upstream because in order to get things somehow working we've touched many arch-indep files in a dirty and hacky way, making the changes unsuitable for upstream inclusion. Since the parisc-linux diff is taken against a snapshot of the pristine kernel tree. Tailoring it to make it apply fine on a Debian patched kernel is quite a PITA (the parisc patch is roughly 800k). Now comes the question of the meaning of having a debian package for a no longer supported _UPSTREAM_ kernel. We (parisc hackers) put all our efforts in 2.6 and strongly advise everyone to use 2.6. We are no longer maintaining 2.4 (last update to our tree is several months old, and 2.4.28 merge is not on the todo list). I've been told by Joey Hess that 2.6 support for d-i is mostly there, so I'd like to know what would eventually raise against dropping 2.4 package in the very near future (ie: before sarge releases). TIA, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ PS: please CC me in answers. pgpWu7pTZPUdp.pgp Description: PGP signature
Dropping 2.4 hppa kernel-image packages
Hi, I've been discussing lately on #d-kernel about the fate of 2.4 hppa kernel packages. Here is a brief summary of the issue: I received a bugreport (#289590) because 2.4.27 package FTBFS, and that's the result of: 1) a (imho) very invasive and massive Debian patchset that conflicts with 2) a huge, dirty and no longer maintained parisc 2.4 diff to the pristine kernel. In other words, I'm up to the point where it begins to be unreasonably complicated to maintain a 2.4 Debian package because OTOH we (parisc-linux kernel hackers) no longer maintain our 2.4 repository and OTOH the 2.4 parisc port has always been nothing but a big hack to the 2.4 pristine source. Indeed, we never merged upstream because in order to get things somehow working we've touched many arch-indep files in a dirty and hacky way, making the changes unsuitable for upstream inclusion. Since the parisc-linux diff is taken against a snapshot of the pristine kernel tree. Tailoring it to make it apply fine on a Debian patched kernel is quite a PITA (the parisc patch is roughly 800k). Now comes the question of the meaning of having a debian package for a no longer supported _UPSTREAM_ kernel. We (parisc hackers) put all our efforts in 2.6 and strongly advise everyone to use 2.6. We are no longer maintaining 2.4 (last update to our tree is several months old, and 2.4.28 merge is not on the todo list). I've been told by Joey Hess that 2.6 support for d-i is mostly there, so I'd like to know what would eventually raise against dropping 2.4 package in the very near future (ie: before sarge releases). TIA, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ PS: please CC me in answers. pgp28f8BgPciO.pgp Description: PGP signature
Re: kernel and upgrades from woody to sarge
On Fri, 29 Oct 2004 20:44:33 +0200 Andreas Barth <[EMAIL PROTECTED]> wrote: > > + hppa: 64bit kernel with 32bit user land - details unknown. > If i remember correctly from the few attempts i made, the kernel has to be upgraded (and the box rebooted) before upgrading glibc. Otherwise I can't remember of anything particular. HTH -- Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ pgpKbyHqfn7mE.pgp Description: PGP signature
