Bug#1051563: Backporting mutt patches to Debian Buster
On Wed, Sep 20, 2023 at 02:35:30PM -0300, Santiago Ruano Rincón wrote: > I kept the original From, tagged the Origin as backport, and kept your > name as Author. > Hope that makes sense for you. > > Thanks a lot for your work! I saw it percolate through the updates today. Thanks very much! - Chris
Bug#1051563: Backporting mutt patches to Debian Buster
On Sun, Sep 17, 2023 at 08:34:57PM +0300, Santiago Ruano Rincón wrote: > Chris, thanks for preparing the patches. Much appreciated. I have a > question though: Why are you placing those two patches in > debian-specific, and not in upstream/? They come from the upstream repo. I only put them there because I had to modify them for a clean patch. I changed the headers to make it clear that I edited them, but kept the original wording as well. I didn't think it was right to modify the patch contents without changing the name of who did it. - Chris
Bug#1051563: Backporting mutt patches to Debian Buster
Attached is a patch that applies to the unpackaged sources of Debian Buster's
version of mutt 1.10.
It includes 3 patches:
upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
debian-specific/Check-for-NULL-userhdrs.patch
debian-specific/Fix-write_one_header-illegal-header-check.patch
First one applied from Bullseye. The other two I modified slightly
to match the older sources.
The CVE's make mention of "specially crafted input" but I don't have
any samples to test with. I only tested that this built on Buster and
opens mail as before.
I have not adjusted any other files but the 3 above and debian/patches/series.
Hopefully this gives a head start on making these fixes available on buster.
- Chris
diff --git a/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
new file mode 100644
index 000..33f5cb5
--- /dev/null
+++ b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
@@ -0,0 +1,56 @@
+From: Chris Frey
+Date: Fri, 15 Sep 2023 08:41:00 -0400
+Subject: Check for NULL userhdrs.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4875
+
+The original patch from Kevin McCarthy backported to Debian buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original summary below:
+
+ From: Kevin McCarthy
+ Date: Mon, 4 Sep 2023 12:50:07 +0800
+ Subject: Check for NULL userhdrs.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6
+
+ When composing an email, miscellaneous extra headers are stored in a
+ userhdrs list. Mutt first checks to ensure each header contains at
+ least a colon character, passes the entire userhdr field (name, colon,
+ and body) to the rfc2047 decoder, and safe_strdup()'s the result on
+ the userhdrs list. An empty result would from the decode would result
+ in a NULL headers being added to list.
+
+ The previous commit removed the possibility of the decoded header
+ field being empty, but it's prudent to add a check to the strchr
+ calls, in case there is another unexpected bug resulting in one.
+
+ Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
+ crashes, giving a working example draft message, and providing the
+ stack traces for the two NULL derefences.
+ ---
+ sendlib.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d75e66a 100644
+--- a/sendlib.c
b/sendlib.c
+@@ -2070,7 +2070,7 @@ int mutt_write_rfc822_header (FILE *fp, ENVELOPE *env, BODY *attach,
+ /* Add any user defined headers */
+ for (; tmp; tmp = tmp->next)
+ {
+-if ((p = strchr (tmp->data, ':')))
++if ((p = strchr (NONULL (tmp->data), ':')))
+ {
+ q = p;
+
+@@ -2116,7 +2116,7 @@ static void encode_headers (LIST *h)
+
+ for (; h; h = h->next)
+ {
+-if (!(p = strchr (h->data, ':')))
++if (!(p = strchr (NONULL (h->data), ':')))
+ continue;
+
+ i = p - h->data;
diff --git a/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
new file mode 100644
index 000..8806525
--- /dev/null
+++ b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
@@ -0,0 +1,46 @@
+From: Chris Frey
+Date: Fri, 15 Sep 2023 10:09:00 -0400
+Subject: Fix write_one_header() illegal header check.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4874
+
+Backporting original patch from Kevin McCarthy to Debian Buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original commentary included below:
+
+ From: Kevin McCarthy
+ Date: Sun, 3 Sep 2023 14:11:48 +0800
+ Subject: Fix write_one_header() illegal header check.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0
+
+ This is another crash caused by the rfc2047 decoding bug fixed in the
+ second prior commit.
+
+ In this case, an empty header line followed by a header line starting
+ with ":", would result in t==end.
+
+ The mutt_substrdup() further below would go very badly at that point,
+ with t >= end+1. This could result in either a memcpy onto NULL or a
+ huge malloc call.
+
+ Thanks to Chenyuan Mi (@morningbread) for giving a working example
+ draft message of the rfc2047 decoding flaw. This allowed me, with
+ further testing, to discover this additional crash bug.
+ ---
+ sendlib.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d821061 100644
+--- a/sendlib.c
b/sendlib.c
+@@ -1832,7 +1832,7 @@ static int write_one_header (FILE *fp, int pfxw, int max, int wraplen,
+ else
+ {
+ t = strchr (start, ':');
+-if (!t || t > end)
++if (!t || t >= end)
+ {
+
Bug#1038987: ddd: version 3.4.0 available
Package: ddd Version: 3.3.12 Severity: wishlist FYI, looks like version 3.4.0 has been released: https://www.gnu.org/software/ddd/ - Chris
Bug#1037522: iptux crashes when receiving a file
On Wed, Jun 14, 2023 at 02:58:40PM +0800, xiao sheng wen(肖盛文) wrote: > Please also check your ~/.config/iptux > There are some log files under ~/.config/iptux/log > Do you find any error infos? All the log files there are 0 bytes long. > Has the dmesg output any error infos? On the Bullseye (segfaulted) machine: [2616127.693137] iptux[1381651]: segfault at 30 ip 7f3053d02252 sp 7fff96ea6f00 error 4 in libgtk-x11-2.0.so.0.2400.33[7f3053b4c000+275000] [2616127.693163] Code: 00 00 49 89 e6 48 89 ee 44 89 fa 48 89 df 4c 89 f1 e8 92 ee ff ff 48 8b 3c 24 e8 a9 f0 e4 ff 66 0f ef c0 31 f6 4c 8d 4c 24 20 <48> 8b 48 30 49 89 c0 0f 11 44 24 20 0f 11 44 24 30 0f 11 44 24 40 [2616237.697481] iptux[1381933]: segfault at 30 ip 7fb8f8162252 sp 7ffef88f25e0 error 4 in libgtk-x11-2.0.so.0.2400.33[7fb8f7fac000+275000] [2616237.697505] Code: 00 00 49 89 e6 48 89 ee 44 89 fa 48 89 df 4c 89 f1 e8 92 ee ff ff 48 8b 3c 24 e8 a9 f0 e4 ff 66 0f ef c0 31 f6 4c 8d 4c 24 20 <48> 8b 48 30 49 89 c0 0f 11 44 24 20 0f 11 44 24 30 0f 11 44 24 40 [2616302.696942] iptux[1382148]: segfault at 30 ip 7fb2406d2252 sp 7fff934c3d70 error 4 in libgtk-x11-2.0.so.0.2400.33[7fb24051c000+275000] [2616302.696966] Code: 00 00 49 89 e6 48 89 ee 44 89 fa 48 89 df 4c 89 f1 e8 92 ee ff ff 48 8b 3c 24 e8 a9 f0 e4 ff 66 0f ef c0 31 f6 4c 8d 4c 24 20 <48> 8b 48 30 49 89 c0 0f 11 44 24 20 0f 11 44 24 30 0f 11 44 24 40 [2616610.950542] iptux[1382450]: segfault at 30 ip 7f305b345252 sp 7ffce55c4fe0 error 4 in libgtk-x11-2.0.so.0.2400.33[7f305b18f000+275000] [2616610.950567] Code: 00 00 49 89 e6 48 89 ee 44 89 fa 48 89 df 4c 89 f1 e8 92 ee ff ff 48 8b 3c 24 e8 a9 f0 e4 ff 66 0f ef c0 31 f6 4c 8d 4c 24 20 <48> 8b 48 30 49 89 c0 0f 11 44 24 20 0f 11 44 24 30 0f 11 44 24 40 - Chris
Bug#1037522: iptux crashes when receiving a file
On Wed, Jun 14, 2023 at 10:39:12AM +0800, xiao sheng wen(肖盛文) wrote:
> Could you resize your iptux windows, then close and start iptux again?
That's true, I forgot to mention that I resized the *chat* windows the first
time I loaded iptux. Here's my config.json:
Buster:
cat /home/cdfrey/.iptux/config.json
{
"main_window_height" : 510,
"main_window_width" : 250,
"trans_window_height" : 350,
"trans_window_width" : 500,
"version" : 1
}
Bullseye:
cat .iptux/config.json
{
"main_window_height" : 510,
"main_window_width" : 250,
"trans_window_height" : 350,
"trans_window_width" : 500,
"version" : 1
}
> If you don't use xpra, Is this bug reproduce?
I'm trying to reproduce it even with xpra, and having trouble doing so.
Is there any thing else I should delete from my system, besides ~/.iptux/,
to have it start from scratch? I encounted the bug basically the
first time I used it.
Anyway, in the meantime, I encountered a new segfault, admittedly through
odd behaviour. I can reliably reproduce this:
Buster is sender, Bullseye is receiver.
Buster: select a file to send, then click Send
Buster: select that same file in send list, right click on it,
then click Remove Selected, then click Send again on the
empty list
Bullseye: select file in receive list, click Accept and Save
(nothing happens, as expected)
Bullseye: right click the file you didn't get, and click
Remove Selected... this causes a segfault on the Bullseye
system... Buster continues running fine
Thanks,
- Chris
Bug#1037522: iptux crashes when receiving a file
Package: iptux Version: 0.7.6-4 I installed iptux for the first time on two systems, one running Debian Buster (0.7.6-1), the other running Debian Bullseye. (0.7.6-4) I ran the Buster version in xfce4 from the applications menu. On Bullseye, I accessed it through an xpra session, and ran iptux from the command line. I sent a few simple messages back and forth, and then attempted to send a file from Buster to Bullseye. The Bullseye version crashed with this message: cdfrey:~$ iptux & [3] 1361101 cdfrey:~$ ** (iptux:1361101): WARNING **: 13:56:45.513: config file /home/cdfrey/.iptux/config.json not found (iptux:1361101): GLib-GObject-CRITICAL **: 13:57:28.425: g_object_get_data: assertion 'G_IS_OBJECT (object)' failed Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs corrupted double-linked list It's not that important to me, but I figured I'd be a good Debian citizen and at least report it. :-) - Chris
Bug#1035537: split -n k/N gives incorrect data on blocks after the first
Severity: grave Updating severity as suggested on the debian-lts mailing list. Do you think this bug warrants a security-related fix in stable, due to the potential for data corruption? Thanks, - Chris [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035537
Bug#1035537: split -n k/N gives incorrect data on blocks after the first
Package: coreutils
Version: 8.32-4+b1
This bug exists in both Debian Buster and Debian Bullseye.
It has been fixed in upstream.
It can be reproduced by splitting a file such that size of each
chunk produced by split is larger than the block size used to read
the files (io_blksize(), bufsize, in split.c).
Example:
# create source file
dd if=/dev/urandom of=/tmp/datafile bs=317634560 count=1
# create known good chunks
split -n 635 /tmp/datafile /tmp/datafile.
# attempt to extract one of the chunks using -n
split -n 4/635 /tmp/datafile > /tmp/chunk4
# compare - this will fail
cmp /tmp/datafile.ad /tmp/chunk4
The reason is that when bytes_chunk_extract() is called, the previous
call to input_file_size() has already read bufsize bytes and left
the file pointer there. Then bytes_chunk_extract() performs an
lseek(fd, start, SEEK_CUR) using its calculated offset "start",
and seeks past the real start point.
Here's the fix against Debian Buster, but the same can be done on Bullseye.
Upstream has an extra if statement, but is unnecessary since it is already
handled by the surrounding if(start < initial_read) check. We are
in the else statement, so we know start >= initial_read.
diff -ru coreutils-8.30/src/split.c coreutils-8.30-chunk-fix/src/split.c
--- coreutils-8.30/src/split.c 2018-05-14 00:20:24.0 -0400
+++ coreutils-8.30-chunk-fix/src/split.c2023-05-04 22:31:29.521398067
-0400
@@ -1000,7 +1000,7 @@
}
else
{
- if (lseek (STDIN_FILENO, start, SEEK_CUR) < 0)
+ if (lseek (STDIN_FILENO, start - initial_read, SEEK_CUR) < 0)
die (EXIT_FAILURE, errno, "%s", quotef (infile));
initial_read = SIZE_MAX;
}
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On Wed, Sep 14, 2022 at 01:54:40PM +0200, Emilio Pozuelo Monfort wrote: > Your top-commit looks very similar to the one from Santiago on [1]. I'd > rather use that to give him credit as he proposed the fix first (plus using > CPPFLAGS seems more correct for this flag). In addition to that, the commit > misses his follow-up fix in [2]. I'm going to consider that last debdiff > from him for an upload to buster. Thanks in any case for looking at it (and > coming up with a similar fix) and for testing the update. No problem, thank you! - Chris
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On the other hand, the fix has been known since 2019 and looks like a prime problem for an LTS newbie volunteer like me. I have created the fix based on the Debian/bzip2 repo, the fix is in the debian/buster branch. git clone http://digon.foursquare.net/debian-buster-bzip2/.git I have tested it on a 32bit buster, and it works on +2g files. I do not have privileges to push this to any server yet, so feel free to tweak the changelog and claim it as your own, whoever wishes to upload it. - Chris On Tue, Sep 13, 2022 at 04:46:14PM +0200, Sylvain Beucler wrote: > Hi, > > IIUC this is about fixing 2 non-security bugs, that were introduced prior to > buster's initial release. > > I personally don't think this fits the LTS project scope. > Maybe other LTS members will have a different opinion. > > Cheers! > Sylvain Beucler > Debian LTS Team > > On 13/09/2022 15:27, Santiago R.R. wrote: > > El 10/09/22 a las 19:11, Adam D. Barratt escribió: > > > On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: > > > > Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 > > > > CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. > > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 > > > > > > > > I've uploaded a fixed version to unstable yesterday. It would be > > > > great > > > > to fix it also in buster. Please, consider the attached debdiff. > > > > Would it be OK for you to upload it? > > > > > > > > > > Apologies for apparently letting this sit unanswered. (FTR there was a > > > reply from a non-SRM member 18 months ago.) > > > > And I am sorry I missed that answer. > > > > > > > > The final point release for buster has now happened, so any further > > > updates to packages in buster will need to be handled via LTS. I'm > > > therefore going to close this request now. > > [snip] > > > > I am forwarding this to the LTS folks, so they can decide about this > > change.
Bug#1016710: zlib bugs hiding in other packages
Please note that this same bug still exists in copies of the zlib library in other packages, such as FireFox. It is unclear to me that FireFox can never call its own inflateGetHeader() or a variation of inflate() with the right EXTRA mode flag, simply by examination of the source. But there are enough calls to zlib that it looks worthwhile fixing there too. - Chris
Bug#1005155: xpdf leaks a lot of memory
On Tue, Feb 08, 2022 at 03:06:04AM -0500, Chris Frey wrote: > On Tue, Feb 08, 2022 at 08:59:43AM +0100, Florian Schlichting wrote: > > I've uploaded xpdf from bullseye to buster-backports. > > Thank you very much! Just a heads-up. The xpdf package does not appear to have arrived in the buster-backports area yet. - Chris
Bug#1005155: xpdf leaks a lot of memory
On Tue, Feb 08, 2022 at 08:59:43AM +0100, Florian Schlichting wrote: > I've uploaded xpdf from bullseye to buster-backports. Thank you very much! - Chris
Bug#1005155: xpdf leaks a lot of memory
On Tue, Feb 08, 2022 at 04:53:53AM +0100, Florian Schlichting wrote:
> When you say "the Debian source package", you probably refer to the
> buster version (3.04-13)?
Confirmed, I used buster.
I think I found at least one issue, introduced by these items
in the poppler-0.71.patch:
it = decltype(it){ pages->erase(std::next(it).base()) };
and
- delete (PDFCoreTile *)page->tiles->del(j);
+itt = page->tiles->erase(itt);
The patch code assumes the GList contains smart pointers, but it doesn't.
When I patched it myself, it didn't fix all the memory leaks, sadly.
> buster is oldstable by now. If you look at
> https://tracker.debian.org/media/packages/x/xpdf/changelog-3.04git20211021-1,
> you'll see that there are several references to fixed bugs about memory
> leaks in newer versions of xpdf in Debian (#945188, #942086, #945188).
> Does any of those sound similar to your problem?
Looking at xpopple code, I see the items inside the vector are
unique_ptrs, so all this stuff is most likely fixed.
> Would you care to try that again with the
> bullseye version (3.04+git20210103-3) that should have all the above
> mentioned memory fixes?
I tried building bullseye's, but it needs a new debhelper and libpoppler.
I'm not sure I should mess with debhelper.
> If that helps, and you cannot upgrade to bullseye just now, I could
> probably upload a buster-backport version of the bullseye xpdf, if
> you're interested?
That would be fantastic!
Thanks,
- Chris
Bug#1005155: xpdf leaks a lot of memory
Package: xpdf Version: 3.04-13 Running buster, just about any PDF I view with xpdf causes memory leaks. It is aggravated by paging up and down through the document. If you page up and down from top to bottom and back often enough, you will run out of memory. At first I thought this was a long standing upstream bug, and most of the time it doesn't bite me. But it bit me enough to check. I compiled xpdf 4.03 from www.xpdfreader.com and no leak. I compiled xpdf 3.04 from the same source, and no leak. So sadly it appears to be a Debian-specific breakage. So I compiled the Debian source package leaving debug symbols in, and ran it inside valgrind, getting the report pasted below. It seems like tiles are not being properly freed, but I haven't found why yet. Thanks, - Chris ==31681== Memcheck, a memory error detector ==31681== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==31681== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==31681== Command: xpdf.real /tmp/redacted.pdf ==31681== ==31681== ==31681== HEAP SUMMARY: ==31681== in use at exit: 230,683,823 bytes in 11,908 blocks ==31681== total heap usage: 71,505 allocs, 59,597 frees, 341,659,666 bytes allocated ==31681== ==31681== 3 bytes in 1 blocks are definitely lost in loss record 32 of 2,868 ==31681==at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x4D3D873: systempapername (in /usr/lib/x86_64-linux-gnu/libpaper.so.1.1.2) ==31681==by 0x125A79: XPDFParams::XPDFParams(char const*) (XPDFParams.cc:708) ==31681==by 0x115BCA: main (xpdf.cc:156) ==31681== ==31681== 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 2,109 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x124F8E: XPDFParams::createDefaultKeyBindings() (XPDFParams.cc:921) ==31681==by 0x125B23: XPDFParams::XPDFParams(char const*) (XPDFParams.cc:795) ==31681==by 0x115BCA: main (xpdf.cc:156) ==31681== ==31681== 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 2,110 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x124FC6: XPDFParams::createDefaultKeyBindings() (XPDFParams.cc:923) ==31681==by 0x125B23: XPDFParams::XPDFParams(char const*) (XPDFParams.cc:795) ==31681==by 0x115BCA: main (xpdf.cc:156) ==31681== ==31681== 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 2,111 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x124FFE: XPDFParams::createDefaultKeyBindings() (XPDFParams.cc:925) ==31681==by 0x125B23: XPDFParams::XPDFParams(char const*) (XPDFParams.cc:795) ==31681==by 0x115BCA: main (xpdf.cc:156) ==31681== ==31681== 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 2,112 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x125036: XPDFParams::createDefaultKeyBindings() (XPDFParams.cc:927) ==31681==by 0x125B23: XPDFParams::XPDFParams(char const*) (XPDFParams.cc:795) ==31681==by 0x115BCA: main (xpdf.cc:156) ==31681== ==31681== 904 (56 direct, 848 indirect) bytes in 1 blocks are definitely lost in loss record 2,703 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x11AA1C: PDFCore::addPage(int, int) (PDFCore.cc:832) ==31681==by 0x11B5FB: PDFCore::update(int, int, int, double, int, bool, bool, bool) (PDFCore.cc:523) ==31681==by 0x122490: XPDFCore::update(int, int, int, double, int, bool, bool, bool) (XPDFCore.cc:297) ==31681==by 0x11696E: PDFCore::displayPage(int, double, int, bool, bool) (PDFCore.cc:300) ==31681==by 0x12ECC1: displayPage (XPDFViewer.cc:483) ==31681==by 0x12ECC1: XPDFViewer::XPDFViewer(XPDFApp*, GooString const*, int, GooString*, bool, GooString*, GooString*) (XPDFViewer.cc:320) ==31681==by 0x11D3DF: XPDFApp::open(GooString const*, int, GooString*, GooString*) (XPDFApp.cc:228) ==31681==by 0x116282: main (xpdf.cc:305) ==31681== ==31681== 904 (56 direct, 848 indirect) bytes in 1 blocks are definitely lost in loss record 2,704 of 2,868 ==31681==at 0x4835DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==31681==by 0x11AA1C: PDFCore::addPage(int, int) (PDFCore.cc:832) ==31681==by 0x11B5FB: PDFCore::update(int, int, int, double, int, bool, bool, bool) (PDFCore.cc:523) ==31681==by 0x122490: XPDFCore::update(int, int, int, double, int, bool, bool, bool)
Bug#1004689: Bug #1004689: xterm: CVE-2022-24130
Just curious why this bug is marked high priority for stretch but low priority for buster and bullseye? https://tracker.debian.org/pkg/xterm Is there something different in their builds? Thanks, - Chris
Bug#974208: xserver-xorg-core: Fix crash on XkbSetMap
Package: xserver-xorg-core Version: 2:1.20.4-1+deb10u1 Just reporting an upstream patch for an xserver crash related to xkb: See the patch here: https://gitlab.freedesktop.org/xorg/xserver/-/commit/fabc4219622f3c0b41 It does not appear to be in the debian buster sources yet, nor do I see any reference to it in existing bugs. I noticed it being discussed in the wild, so reporting it here. See: https://unix.stackexchange.com/a/574285 - Chris
Bug#964161: chromium amazingly slow after latest security update
Package: chromium Version: 83.0.4103.116-1~deb10u1 On my Debian buster system, the last security upgrade replaced chromium version 80.0.3987.162-1~deb10u1 with the new 83.x. This has resulted in a browsing experience 2 or 3 times slower than normal. I don't know if it is because of the new security changes in 83, or some flaw in the build process. Reporting in case anyone else notices the same thing. # dpkg -l |grep chromium ii chromium 83.0.4103.116-1~deb10u1 amd64web browser ii chromium-common83.0.4103.116-1~deb10u1 amd64web browser - common resources used by the chromium packages ii chromium-sandbox 83.0.4103.116-1~deb10u1 amd64web browser - setuid security sandbox for chromium # dpkg --status chromium Package: chromium Status: install ok installed Priority: optional Section: web Installed-Size: 261086 Maintainer: Debian Chromium Team Architecture: amd64 Version: 83.0.4103.116-1~deb10u1 Provides: gnome-www-browser, www-browser Depends: libasound2 (>= 1.0.16), libatk-bridge2.0-0 (>= 2.5.3), libatk1.0-0 (>= 2.2.0), libatspi2.0-0 (>= 2.9.90), libavcodec58 (>= 7:4.0), libavformat58 (>= 7:4.1), libavutil56 (>= 7:4.0), libc6 (>= 2.28), libcairo2 (>= 1.6.0), libcups2 (>= 1.7.0), libdbus-1-3 (>= 1.9.14), libdrm2 (>= 2.4.38), libevent-2.1-6 (>= 2.1.8-stable), libexpat1 (>= 2.0.1), libflac8 (>= 1.3.0), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.3.9), libgbm1 (>= 17.1.0~rc2), libgcc1 (>= 1:4.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.39.4), libgtk-3-0 (>= 3.19.12), libharfbuzz0b (>= 2.2.0), libicu63 (>= 63.1-1~), libjpeg62-turbo (>= 1.5.0), libjsoncpp1 (>= 1.7.4), liblcms2-2 (>= 2.2+git20110628), libminizip1 (>= 1.1), libnspr4 (>= 2:4.9-2~), libnss3 (>= 2:3.22), libopenjp2-7 (>= 2.2.0), libopus0 (>= 1.1), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpng16-16 (>= 1.6.2-1), libpulse0 (>= 0.99.1), libre2-5 (>= 20160901), libsnappy1v5, libstdc++6 (>= 7), libvpx5 (>= 1.6.0), libwebp6 (>= 0.5.1), libwebpdemux2 (>= 0.5.1), libwebpmux3 (>= 0.6.1-2), libx11-6 (>= 2:1.4.99.1), libx11-xcb1, libxcb-dri3-0, libxcb1 (>= 1.6), libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:5.0), libxi6 (>= 2:1.2.99.4), libxml2 (>= 2.7.4), libxrandr2 (>= 2:1.2.99.3), libxrender1, libxslt1.1 (>= 1.1.25), libxss1, libxtst6, zlib1g (>= 1:1.2.2), chromium-common (= 83.0.4103.116-1~deb10u1) Recommends: chromium-sandbox Suggests: chromium-l10n, chromium-shell, chromium-driver Breaks: chromium-lwn4chrome (<= 1.0-2), chromium-tt-rss-notifier (<= 0.5.2-2) Conflicts: libgl1-mesa-swx11, libnettle4, libsecret-1-0 (<< 0.18) Conffiles: /etc/chromium.d/README d534c23de20ba9a520d38a4147e752bf /etc/chromium.d/apikeys 4f20b0c45a8822b697dc9e36e6744037 /etc/chromium.d/default-flags 9a603fa145e701dd0205d8a282d492d2 /etc/chromium.d/extensions bda19dc8abc19e8f8e85d44520f146ed /etc/chromium/master_preferences d25395cf307b563bc9ed04d95947fbc7 Description: web browser Web browser that aims to build a safer, faster, and more stable internet browsing experience. . This package contains the web browser component. Homepage: http://www.chromium.org/Home
Bug#652999: xfce4-terminal: please add a way to disable (redefine?) middle click running mailto:
I'd add my vote to this. It's one of those consistent daily annoyances. Very grateful for the workaround in .config/Terminal/terminalrc though! Thanks, - Chris
Bug#816774: RM: barry -- ROM; Lack of maintainer time and does not support recent BlackBerry devices.
Package: ftp.debian.org Severity: normal
Bug#803049: barry: FTBFS: error: call of overloaded 'mem_fn(void (XmlNodeMapping::*)(std::ostream&) const)' is ambiguous
Thanks Chris!
This bug can be fixed with the following patch:
commit c3860b75b588f860d83f10b08749ffdc0a9271bd
Author: Chris Frey <cdf...@foursquare.net>
Date: Tue Oct 27 22:23:56 2015 -0400
desktop: avoid ambiguous function calls with newer compilers
diff --git a/desktop/src/xmlmap.cc b/desktop/src/xmlmap.cc
index 6b06531..ff26267 100644
--- a/desktop/src/xmlmap.cc
+++ b/desktop/src/xmlmap.cc
@@ -520,8 +520,6 @@ XmlNodeMap& XmlNodeMap::operator=(const XmlNodeMap )
#include
#include
#include
-using namespace std::tr1;
-using namespace std::tr1::placeholders;
int main(int argc, char *argv[])
{
@@ -540,14 +538,18 @@ int main(int argc, char *argv[])
np.SortBySummary();
cout << "\n\nCute summary:\n";
for_each(np.begin(), np.priority_end(),
- bind( mem_fn(::DumpSummaries),
- _1, ref(cout)));
+ std::tr1::bind(
+
std::tr1::mem_fn(::DumpSummaries),
+ std::tr1::placeholders::_1,
+ std::tr1::ref(cout)));
np.SortByPath();
cout << "\n\nCute summary:\n";
for_each(np.begin(), np.priority_end(),
- bind( mem_fn(::DumpSummaries),
- _1, ref(cout)));
+ std::tr1::bind(
+
std::tr1::mem_fn(::DumpSummaries),
+ std::tr1::placeholders::_1,
+ std::tr1::ref(cout)));
}
catch( Glib::ConvertError ) {
cerr << e.what() << endl;
I'm hoping to fix a bunch of other small things at the same time.
But if this is super urgent, feel free to proceed with this patch.
Thanks,
- Chris
Bug#774123: python-cqpid: Segfault on import cqpid
Package: python-cqpid Version: 0.16-6+deb7u1 Severity: important This is reproducable every time I import the cqpid python module. I'm assuming I should be able to do this. :-) I haven't been able to get a full backtrace yet, but this is what I have so far: cdfrey:~$ gdb python core GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/python...(no debugging symbols found)...done. [New LWP 18698] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Core was generated by `python'. Program terminated with signal 11, Segmentation fault. #0 0x7f641135f814 in init_cqpid () from /usr/lib/python2.7/dist-packages/_cqpid.so (gdb) bt #0 0x7f641135f814 in init_cqpid () from /usr/lib/python2.7/dist-packages/_cqpid.so #1 0x004440a8 in _PyImport_LoadDynamicModule () #2 0x0043c610 in ?? () #3 0x004aa4de in PyEval_EvalFrameEx () #4 0x004aad10 in PyEval_EvalFrameEx () #5 0x004b1ef8 in PyEval_EvalCodeEx () #6 0x0052eca4 in PyImport_ExecCodeModuleEx () #7 0x004d1b71 in ?? () #8 0x0046924f in ?? () #9 0x00480b29 in ?? () #10 0x00469610 in ?? () #11 0x004c02ad in ?? () #12 0x00471ace in PyEval_CallObjectWithKeywords () #13 0x004ac491 in PyEval_EvalFrameEx () #14 0x004b1ef8 in PyEval_EvalCodeEx () #15 0x0053b343 in ?? () #16 0x0044cac2 in PyRun_InteractiveOneFlags () #17 0x0044cbac in PyRun_InteractiveLoopFlags () #18 0x0044d1e8 in PyRun_AnyFileExFlags () #19 0x0044dd42 in Py_Main () #20 0x7f6411f9cead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x004c78b9 in _start () (gdb) quit -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 python-cqpid depends on: ii libc6 2.13-38+deb7u6 ii libgcc11:4.7.2-5 ii libpython2.7 2.7.3-6+deb7u2 ii libqpidmessaging2 0.16-6+deb7u1 ii libqpidtypes1 0.16-6+deb7u1 ii libstdc++6 4.7.2-5 ii python 2.7.3-4+deb7u1 ii python2.7 2.7.3-6+deb7u2 python-cqpid recommends no packages. python-cqpid suggests no packages. -- 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#770105: sed option bug in php5 update
I ran into this too. It appears to be from this commit: http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-wheezyid=849b648e88a067a80cd9a32122d5c0d8aaa93454 - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756061: Lack of time by maintainer
On Sat, Aug 30, 2014 at 06:08:48PM -0300, Olly Betts wrote: It would be a bit of a shame to lose this package, as it seems to be the only package for talking to BlackBerry mobiles that we have in Debian. You could consider seeking a co-maintainer to help out. Another option would be for us to upload with my patch, and if it proves problematic, get the release team to drop the package from jessie before it is actually released. There are no reverse dependencies to be broken by the removal. Thanks Olly. Was on vacation last week. I don't mind if you upload with your patch. I'd kinda like to have a patch that still allows things to work with wxWidgets 2.8, but if I really want that, I'll probably have to code it. :-) - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751262: barry: Working patch for wxwidgets3.0 support
Hi Olly, Thanks very much for this patch. As you've probably noticed from bug #756061, my time is limited for Barry work these days. But I hope to find time to test your patch soon. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756061: Lack of time by maintainer
Package: barry Version: 0.18.5-1 Severity: serious Tags: moreinfo upstream confirmed sid jessie As the maintainer of the package, I don't have enough time to handle important bugs like the recent wxWidgets 3.0 transition. This time situation may change in the near future, but until then, Barry is not suitable for a stable release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749281: gnome-terminal: Setting Title on tabs doesn't work
Package: gnome-terminal Version: 3.12.2-1 Severity: normal Dear Maintainer, In 3.10, I was able to right-click on the tabs, and use the Set Title option to give meaningful names to my terminal tabs. In this version, the dialog box comes up, but when I enter a new name, it doesn't change. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-terminal depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gconf-service3.2.6-2 ii gnome-terminal-data 3.12.2-1 ii gsettings-desktop-schemas3.8.2-2 ii libatk1.0-0 2.12.0-1 ii libc62.18-7 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libdconf10.20.0-2 ii libgconf-2-4 3.2.6-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.2-1 ii libnautilus-extension1a 3.8.2-3 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libuuid1 2.20.1-5.7 ii libvte-2.90-91:0.36.2-1 ii libx11-6 2:1.6.2-2 Versions of packages gnome-terminal recommends: ii dbus-x11 1.8.2-1 ii gvfs 1.20.1-1+b1 ii yelp 3.12.0-1 gnome-terminal suggests no packages. -- 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#698663: Download does not work
Hi, I'm trying out Anki for the first time, and I suspect my issue is likely caused by this bug. When first opening Anki, I'm greeted with the message: Welcome to Anki! Click 'Download' to get started... When I click Download, I get: Unable to connect to the server. Please check your network connection or try again in a few minutes. Error was: Traceback (most recent call last): File /usr/share/anki/ankiqt/ui/getshared.py, line 67, in fetchData URL + search?t=%dc=1 % self.type) File /usr/lib/python2.7/urllib2.py, line 127, in urlopen return _opener.open(url, data, timeout) File /usr/lib/python2.7/urllib2.py, line 407, in open response = meth(req, response) File /usr/lib/python2.7/urllib2.py, line 520, in http_response 'http', request, response, code, msg, hdrs) File /usr/lib/python2.7/urllib2.py, line 439, in error result = self._call_chain(*args) File /usr/lib/python2.7/urllib2.py, line 379, in _call_chain result = func(*args) File /usr/lib/python2.7/urllib2.py, line 626, in http_error_302 return self.parent.open(new, timeout=req.timeout) File /usr/lib/python2.7/urllib2.py, line 407, in open response = meth(req, response) File /usr/lib/python2.7/urllib2.py, line 520, in http_response 'http', request, response, code, msg, hdrs) File /usr/lib/python2.7/urllib2.py, line 445, in error return self._call_chain(*args) File /usr/lib/python2.7/urllib2.py, line 379, in _call_chain result = func(*args) File /usr/lib/python2.7/urllib2.py, line 528, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: Not Found Is there a workaround for this, or do I need to wait for v2? Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704732: gnome: Setting certain touchpad options makes it impossible to login
Package: gnome Version: 1:3.4+7 Severity: important If I open the settings window, from the top right user menu, and navigate to Mouse Touchpad, then click the Touchpad tab: Then I set: - enable clicks with touchpad - two-finger scrolling if I also set Disable touchpad while typing this causes a number of serious problems the next time I logoff and login: - even though the checkbox is checked, I cannot click with touchpad - the background style of the settings box has changed, with borders in different gray colour around the groups of icons - if I open a Terminal, the colours have been changed to black text on black background If I then reboot and try to login again, Gnome will not let me in, giving me a small dialog saying something like Something bad happened, you can't login. and then returns me to the gdm3 login. If I rm -rf .gconf and start again, but avoid changing the setting of Disable touchpad while typing, then things work fine. Thanks, - Chris -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) 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 gnome depends on: ii aisleriot1:3.4.1-1 ii alacarte 3.5.3-1 ii avahi-daemon 0.6.31-2 ii cheese 3.4.2-2 ii cups-pk-helper 0.2.3-3 ii desktop-base 7.0.3 ii evolution3.4.4-2 ii evolution-plugins3.4.4-2 ii file-roller 3.4.2-1 ii gedit3.4.2-1 ii gedit-plugins3.4.0-1 ii gimp 2.8.2-2 ii gnome-applets3.4.1-3 ii gnome-color-manager 3.4.2-1 ii gnome-core 1:3.4+7 ii gnome-documents 0.4.2-2 ii gnome-games 1:3.4.2-3 ii gnome-media 3.4.0-1 ii gnome-nettool3.2.0-1 ii gnome-orca 3.4.2-2 ii gnome-shell-extensions 3.4.0-2 ii gnome-tweak-tool 3.4.0.1-2 ii gstreamer0.10-ffmpeg 0.10.13-5 ii gstreamer0.10-plugins-ugly 0.10.19-2+b2 ii hamster-applet 2.91.3+git20120514.b9fec3e1-1 ii inkscape 0.48.3.1-1.3 ii libgtk2-perl 2:1.244-1 ii libreoffice-calc 1:3.5.4+dfsg-4 ii libreoffice-gnome1:3.5.4+dfsg-4 ii libreoffice-impress 1:3.5.4+dfsg-4 ii libreoffice-writer 1:3.5.4+dfsg-4 ii nautilus-sendto 3.0.3-2+b1 ii network-manager-gnome0.9.4.1-5 ii rhythmbox2.97-2.1 ii rhythmbox-plugin-cdrecorder 2.97-2.1 ii rhythmbox-plugins2.97-2.1 ii rygel-playbin0.14.3-2 ii rygel-preferences0.14.3-2 ii rygel-tracker0.14.3-2 ii seahorse 3.4.1-2 ii shotwell 0.12.3-2 ii simple-scan 3.4.2-1 ii sound-juicer 3.4.0-3 ii telepathy-gabble 0.16.5-1 ii telepathy-rakia 0.7.4-1 ii telepathy-salut 0.8.1-1 ii tomboy 1.10.0-2 ii totem3.0.1-8 ii totem-plugins3.0.1-8 ii tracker-gui 0.14.1-3 ii transmission-gtk 2.52-3+nmu1 ii vinagre 3.4.2-2 ii xdg-user-dirs-gtk0.9-1 ii xul-ext-adblock-plus 2.1-1 Versions of packages gnome recommends: ii browser-plugin-gnash 0.8.11~git20120629-1 ii gdebi0.8.7 ii gnome-games-extra-data 3.2.0-4 ii nautilus-sendto-empathy 3.4.2.3-2 ii telepathy-idle 0.1.11-2 Versions of packages gnome suggests: pn dia-gnome none pn gnome-boxesnone pn gnucashnone pn iceweasel-l10n-all none ii libreoffice-evolution 1:3.5.4+dfsg-4 pn plannernone pn xul-ext-gnome-keyring none Versions of packages gnome-core depends on: ii at-spi2-core2.5.3-2 ii baobab 3.4.1-1 ii brasero 3.4.1-4 ii caribou 0.4.4-1 ii caribou-antler 0.4.4-1 ii dconf-gsettings-backend 0.12.1-3 ii dconf-tools 0.12.1-3 ii empathy 3.4.2.3-2 ii eog 3.4.2-1+build1 ii evince 3.4.0-3.1 ii evolution-data-server 3.4.4-3 ii fonts-cantarell 0.0.9-1 ii gcalctool 6.4.2.1-3 ii gconf2 3.2.5-1+build1 ii gdm33.4.1-6 ii gkbd-capplet3.4.0.2-1 ii glib-networking 2.32.3-1 ii gnome-backgrounds 3.4.2-1 ii gnome-bluetooth 3.4.2-1 ii
Bug#653073: df still using uuid in wheezy
Hi, Just a reminder that as of 2013/04/05, this behaviour still exists in Wheezy. Are there plans to fix it before release? Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696205: g++-4.4: for condition fails with -O2
Package: g++-4.4
Version: 4.4.5-8
Severity: normal
When compiling the following simple program:
#include iostream
using namespace std;
int main()
{
for( int a = 0, b = 1; a = 0 b = 0 ; ) {
cout a , ;
int sum = a + b;
a = b;
b = sum;
}
}
If I use:
g++-4.4 -Wall -O2 -o fib fib.cc
Then the output doesn't stop when the value of a wraps into negative
territory.
If I use:
g++-4.4 -Wall -O0 -o fib fib.cc
Then it does stop, as expected.
- Chris
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.4.23 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages g++-4.4 depends on:
ii gcc-4.4 4.4.5-8The GNU C compiler
ii gcc-4.4-base 4.4.5-8The GNU Compiler Collection (base
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libmpfr4 3.0.0-2multiple precision floating-point
ii libstdc++6-4.4-dev4.4.5-8The GNU Standard C++ Library v3 (d
g++-4.4 recommends no packages.
Versions of packages g++-4.4 suggests:
pn g++-4.4-multilib none (no description available)
ii gcc-4.4-doc 4.4.4.nf1-1 documentation for the GNU compiler
pn libstdc++6-4.4-dbg 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#692854: barrydesktop: sync no working: No OpenSync libraries were found.
On Sat, Nov 10, 2012 at 05:12:14PM +0200, Nadav Vinik wrote: I try this repository, but it isn't working: W: Failed to fetch http://download.barry.netdirect.ca/barry-latest/dists/squeeze/Release Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. That repository does not contain Debian source packages. The source is indeed available though, on sourceforge, where all the binary packages are ultimately downloaded from. The download.barry.netdirect.ca site redirects downloads to the appropriate sourceforge link, and of course also provides the package signing. You will need to remove the deb-src lines from your sources.list. You can fetch signed source packages on sourceforge here: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/ I'll be closing this bug shortly, since this doesn't really have anything to do with Debian's repositories, and there are no plans to include opensync in Debian at this time. (Hopefully that will change someday, but that's the status right now.) You're welcome to continue contacting me directly though. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692854: barrydesktop: sync no working: No OpenSync libraries were found.
On Fri, Nov 09, 2012 at 10:15:03PM +0200, Nadav Vinik wrote: Package: barrydesktop Version: 0.18.3-5 Severity: important Opensync libraries are not available in Debian testing. They have been removed. If you want matching opensync library packages, you'll have to get them separately. See http://www.netdirect.ca/software/packages/barry/installdebian.php for more details on where to get these packages. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: Barry and ppp support on kfreebsd
Hi intrigeri, A new version of Barry is available which fixes the ppp dependency on kfreebsd. Upstream: http://repo.or.cz/w/barry.git Upstream tag: barry-0.18.3-4 Upstream diff: barry-0.18.3-3..barry-0.18.3-4 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-4.dsc - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: Barry and ppp support on kfreebsd
On Fri, Jun 22, 2012 at 11:06:46PM +0200, intrigeri wrote: First, it does not fix the dependency on ppp on kfreebsd: it *removes* that dependency on !linux. So, I think the changelog text is misleading: one could easily think that ppp is supposed to work on kfreebsd, thanks to this update. Second, for Linux, the barrydesktop Depends:ppp is silently turned into a Recommends, with no explanation. Please document this change. Technically, the dependency was the only thing I fixed, but I see your point. I'll spin another version. Someday I hope to add freebsd-ppp [kfreebsd-any] (if that works) to the same dependency lists as ppp, once real support is solved and added. Just to prevent wasted time with my build testing (since my machines are slow) here's the text I plan to use in changelog: --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,11 @@ -barry (0.18.3-4) unstable; urgency=low +barry (0.18.3-5) unstable; urgency=low - * Fixed dependency on ppp for kfreebsd (Closes: #678233) + * Removed dependency on ppp for kfreebsd, since kernel side pppd is not +available, and freebsd-ppp is not fully supported yet. Also changed +barrydeskop's ppp Depend into a Recommend, since Barry can technically +run without it. (Closes: #678233) - -- Chris Frey cdf...@foursquare.net Thu, 21 Jun 2012 16:35:40 -0400 + -- Chris Frey cdf...@foursquare.net Fri, 22 Jun 2012 17:56:40 -0400 If this is satisfactory, I'll proceed with my testing runs. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: Barry and ppp support on kfreebsd
On Sat, Jun 23, 2012 at 12:26:57AM +0200, intrigeri wrote: Suits me perfectly :) New version: Upstream: http://repo.or.cz/w/barry.git Upstream tag: barry-0.18.3-5 Upstream diff: barry-0.18.3-4..barry-0.18.3-5 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-5.dsc I won't wait for my kfreebsd VM, which is still stuck trying to create the configure script, since the only change I made here is to the changelog. But I did test build and run lintian on my i386 UML. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: barrydesktop/kfreebsd-* unsatisfiable Depends: ppp
On Thu, Jun 21, 2012 at 11:41:44AM +0200, Mehdi Dogguy wrote: FWIW, this specific issue is blocking the evolution migration. I'd recommend you, if possible, to fix your package as soon as you can I agree. Work continues on testing and fix. The current situation is not ideal since barry has a new upstream version sitting in sid since beginning of June? and we are about to freeze. The relevant part of the diff between testing's and sid's looks like: 995 files changed, 80636 insertions(+), 24248 deletions(-) ? which is pretty huge. If I were you, I would try to fix this issue asap. It is huge, but it also fixes a lot of bugs in the old 0.15 that was in testing before. If you need help with kfreebsd specifics, you may try to ask on debian-...@lists.debian.org. Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: Barry and ppp support on kfreebsd
Hi, I'm searching for a solution to the above CC'd bug (#678233). It is holding up the evolution transition, and so I'm very interested in fast (and correct) solutions. :-) On Linux, Barry supplies a number of pre-configured pppd options files to easily support the various wireless providers around the world. So far there are about 16 options files, which get installed under /etc/ppp/peers. This lets users connect via BlackBerry with something like: pppd call barry-rogers Each options file has a 'pty' option that causes Barry's pppob to run and provide the low level modem support, similar to rp-pppoe. I can't seem to find rp-pppoe on kfreebsd, so I can't use it as an example to find a solution. On kfreebsd, the ppp package is not available, and on a fresh install of the freebsd-ppp package, there is no /etc/ppp directory, let alone /etc/ppp/peers. I'm not even sure yet if 'ppp call ...' is supported. It seems that freebsd-ppp is waiting for me to configure things from scratch myself. :-) Can someone point me to pppd - freebsd-ppp porting documentation? Or even better, suggest a solution? What are my options so far? It would be nice if Barry was supported on kfreebsd, and it would be a shame if Barry got booted from Linux because of this lack of support. Thanks in advance for any help, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: Barry and ppp support on kfreebsd
On Thu, Jun 21, 2012 at 09:45:23PM +0200, Robert Millan wrote: Is ppp functionality essential for Barry to be useful at all? It is only expected to be there by one part of barrydesktop... its Modem button. But it will give a simple error if it can't find it. If so, I suggest you make Barry linux-only by adjusting Architecture field. Otherwise, Barry is not supposed to Depend on ppp and should use Recommends instead (preferably with [linux-any] filter). This sounds like the quickest solution. I can work on actually getting modem support to work on kfreebsd separately. I'd welcome tips on that task, if anyone has them handy. Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678233: barrydesktop/kfreebsd-* unsatisfiable Depends: ppp
On Wed, Jun 20, 2012 at 07:26:18AM +0200, Mehdi Dogguy wrote: Package: barry Version: 0.18.3-2 Severity: serious Tags: wheezy sid Hi, barry/0.18.3-2 added a dependency on ppp for barrydesktop. Unfortunately, ppp is not available on kfreebsd and this change renders the package uninstallable on that architecture. barrydesktop/kfreebsd-amd64 unsatisfiable Depends: ppp barrydesktop/kfreebsd-i386 unsatisfiable Depends: ppp Thanks Mehdi. I see that the freebsd ports use a freebsd-ppp package instead of ppp. I'm not familiar enough with the freebsd ports to know if just changing the dependency line is sufficient, so I'll have to test. I'm working on tracking down a machine for that testing. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676605: Missing dependency for libgoogle-glog-dev
Package: libgoogle-glog-dev Version: 0.3.2-1 The file /usr/include/glog/logging.h contains: #if 1 #include gflags/gflags.h #endif But the package does not depend on libgflags-dev. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582190: Barry documentation package discussion
On Fri, Jun 08, 2012 at 03:22:40AM +0200, intrigeri wrote: hi, Chris Frey wrote (08 Jun 2012 00:39:27 GMT) : I've closed all but one, which is the wishlist item for better documentation. Great! For everything that follows, I strongly prefer to have such a discussion on the bug report rather than privately. Good idea, thanks. I've kept you in the To: list, but not sure if that is necessary. Should they have individual -doc packages, or can user and doxygen go into one? I think we should first ask this question: Why would we want to ship doxygen docs in Debian? It would be useful for developers who want to write applications based on libbarry. But it is not hard to generate, and it is available online. I'm not familiar with Debian's policy on doxygen docs, but from a quick apt-cache search, it doesn't appear to be a new thing. The ffmpeg-doc package is about 13M compressed, for example. I don't think a -doc package is really high priority though, since the latest docs will be online anyway. In general, we want software in Debian to be happily usable even for disconnected users, so this is no very convincing argument :) It was more an expression of my personal time priorities. :-) It is on my own wishlist as well, not just a Debian bug. From my (remote, ignorant) standpoint, I think shipping the small, end-user documentation with the software it's about is the right thing to do. I like this idea, but the question is: which package does it belong in? The user documentation is organized a bit more like a book than a manpage, and can't easily be split up, nor do I think it is useful that way. It covers installation, building from source, how to use the backup program, syncing, troubleshooting, etc. I plan on adding sections for the Desktop as well. Not all of it is applicable for Debian, since opensync is not yet packaged. Everyone who uses Barry will probably have barry-util installed, since that's the one with the udev rules. Do the docs belong in there? Here are the size stats (all HTML docs): User docs, uncompressed:350K Doxygen, without dot graphs, uncompressed: 12M compressed: 875K Doxygen, with dot graphs, uncompressed: 79M compressed: 56M The dot graphs are optional... basically look nicer and are sometimes easier to read. Doxygen uses HTML instead when dot is disabled. I think a barry-doc package for the user docs would work. That would leave the libbarry-doc name for doxygen docs later, if needed. Let me know what you think. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676321: wrong order of build-deps
On Wed, Jun 06, 2012 at 10:10:20AM +0300, Riku Voipio wrote: The build-deps of barry were set to: gettext ( 0.18) | autopoint This fails on buildd's that always pick up the first dependency when a alternative build-dep is given. Since autopoint is available since last stable release, make autopoint the first alternative. Thanks. I've created 0.18.3-3 which changes the order. Intrigeri: Sourceforge.net seems to be having trouble, so you can grab the latest source package here, to prepare for upload. Upstream tags: barry-0.18.3-2..barry-0.18.3-3 URL: http://download.barry.netdirect.ca/debian/barry_0.18.3-3.dsc - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Jun 03, 2012 at 10:34:04AM +0200, intrigeri wrote: Sure. However, the URLs you provided me until now did not. Did I miss a way to get the real download URL from the click-one, without firing up a web browser? I didn't understand how the .dsc file could be used until I started playing around with git-buildpackage. I'll send the .dsc URL now instead, since it is much easier. I'm also signing the .dsc file. My key is in the public servers. I had to add my personal keyring to my ~/.devscripts file, but other than that, it worked great. New release version 0.18.3-2: Upstream tag: barry-0.18.3-2 Upstream diff: git log -p barry-0.18.3..barry-0.18.3-2 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-2.dsc After importing via git-buildpackage, the resulting trees of gbp master and my upstream tag were identical. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Thanks for your considerate replies, and continued patience. So far, when I think I can see the end, it is not the end, and it gets a little frustrating. :-) So your patience is appreciated. I've done some testing and experiments, and below are my results. On Tue, May 29, 2012 at 02:46:32PM +0200, intrigeri wrote: Chris Frey wrote (29 May 2012 09:45:15 GMT) : On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote: Commit 85a9d87f makes debian/rules stop passing DEB_BUILD_MAINT_OPTIONS = hardening=+all to dpkg-buildflags. AFAIK, no large general-purpose distro builds all software with PIE by default; this is due to some performance problems on register-starved architectures, and the fact it breaks quite some software. So, the only practical way for Debian to get more hardening thanks to PIE is to have maintainers enable it pro-actively, on a package by package basis. Which is what I am kindly asking you to do :) Don't worry, I've added it back. Just seems wrong on a certain level. :-) I assumed that these default flags could be set on a per-architecture basis. And if they default to on, then the packages that legitimately need things turned off, could disable them. This would leverage the power of debhelper, buildflags, cdbs, etc. Making every maintainer update their package in order to support hardening seems like the long way around. But so be it. :-) They are part of what can be uploaded. I also have to build and upload the corresponding binary packages. Interesting... that's a newbie surprise for me. I thought that in the end, all packages were built with buildd. As for pristine-tar, my initial reaction is that I'm disappointed that I can't get rid of it yet. I had hoped that by taking on the role of maintainer, I could avoid that waste. What waste, exactly? The (small) binary xdelta blobs in the source repo. Except for some graphics, such as background images, buttons, etc., I believe all the files in the (huge) Barry source tree are text-based source files that can be read and understood by a human. In my mind, git is for committing source code, written and reviewed by a human at each commit, and final binary results are all based on, and extracted from, that source. Pristine-tar breaks that, by inserting automated commits in binary format. There is no guarantee either that the diffs you look at with git-log are the same changes that end up in the binary file you get out of a pristine-tar commit. It is unlikely that they will differ, but thinking that pristine-tar is somehow closer to the real git sources than a signed binary tarball from sourceforge is mistaken. There is a trust gap in both. The xdelta can contain anything. Maybe there's an easy way to diff between a git branch and a pristine-tar tarball, but that's starting to look like hack upon hack to me. I can certainly understand the convenience of using git for everything, though. And that might be worth it in itself. If I find a way to make git-buildpackage run for you as expected, without pristine-tar, would that be satisfactory? Maybe that's impossible, but I'd really like to get rid of that dependency. This would be satisfactory, but indeed it looks impossible to me: I don't know how you can ship a source package purely over Git without using pristine-tar. If you go on not using pristine-tar, I still have to fetch both from Git and (at least) the orig.tar.gz from a painful web site. pristine-tar was created *exactly* to allow shipping, over Git, the tiny delta that goes between a Git tree and a .orig.tar.gz. The debian/rules script contains the code needed to run autoreconf, so it is possible to simply checkout a tag and build Debian packages straight from there. It is also possible to extract consistent tarballs using git-archive, and do the same thing. Pristine-tar uses git-archive for the bulk of its work as well. If I stop autogenerating configure in the .orig.tar.gz, and stop pre-generating html docs in it, which aren't used anyway, it should be possible for you to import the .dsc file using git-buildpackage and have a completely empty git-diff between my release tag and your git-buildpackage master tree. This would allow you to peruse my upstream git log with certainty that you're actually viewing the real changes. I don't think you'll need to use debdiff anymore. To test this, I did: git init git remote add barrypublic git://repo.or.cz/barry.git git fetch barrypublic git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.2/sources/barry_0.18.2-1.dsc git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/barry_0.18.3-1.dsc git diff --stat master barry-0.18.3 I hacked dget to accept unsigned .dsc files for my test. I'll have to start signing those to make this easier. But the diff between
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote: Commit 85a9d87f makes debian/rules stop passing DEB_BUILD_MAINT_OPTIONS = hardening=+all to dpkg-buildflags. I was doing testing with and without the revert, and the lintian tests did not improve. I plan to do a few more tests though. I'm curious why we would force all hardening options on when it is not the default for Debian. I assume hardening defaults were chosen for good reason. Doesn't this make it harder to adjust the whole distro at once, if needed? This is not like -Wall where it only affects compilation. It affects runtime as well, as I understand it. However, process-wise, it would make things much easier for me on the long run if you maintained this package using the classic git-buildpackage + pristine-tar workflow: - a branch dedicated to Debian packaging (usually called master, but since your repo is the upstream one, I suggest calling it debian-master instead) - a branch dedicated at importing upstream tarballs using git-import-orig (called upstream, by default) - git-import-orig takes care of maintaining the pristine-tar branch, merging the orig tarball into upstream, merging upstream into debian-master, and creating tags as needed, so this should not change your current workflow much: the main thing that changes is how you send me your work. This way, every time you ask me to upload a package, I can easily check the changes using Git, run git-buildpackage, inspect and push the result. Also, it will make maintaining official Debian backports much easier. What do you think? Well, you asked. :-) I mean no offense by the following. It reflects my perspective as an upstream focused programmer, at least so far. First, some questions: are my source packages not the files that will be uploaded? Do you need to recreate them for some reason? I had assumed that uploading was easy if you had accurate, signed source packages from me. What changes do you check when you use git? Is it not suitable to do: git log -p barry-0.18.2..barry-0.18.3 -- debian to see what changed? Also, the debian/ directory lives in master, and if I understand correctly, you're asking for it to be moved. This makes no sense to me. I can see creating new tags for Debian-only -1, -2, releases, but not splitting debian/ into its own little world. As for pristine-tar, my initial reaction is that I'm disappointed that I can't get rid of it yet. I had hoped that by taking on the role of maintainer, I could avoid that waste. I know downstream loves pristine-tar, but upstream, it looks like a hack. :-) I admire Joey Hess, but unfortunately pristine-tar rubs me the wrong way. If I find a way to make git-buildpackage run for you as expected, without pristine-tar, would that be satisfactory? Maybe that's impossible, but I'd really like to get rid of that dependency. If worse comes to worst, would it be possible to get a git repo somewhere on debian.org that I could push pristine-tar stuff to? I'm sure I could script something to do it automatically, but I don't want that waste in upstream, and it seems rude to put it on repo.or.cz too. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Wed, May 16, 2012 at 12:32:01PM +0200, intrigeri wrote: So, here's what Lintian tells me this time: * The no-symbols-control-file Lintian overrides were not updated. * The new hardening checks detect possible problems: I'll let you check, override false positives, and fix real problems. New version available, when you have time: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/ I left the hardening checks as-is for now, not overriding them, since from the conversation on some of the mailing lists: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1024761.html it is a work in progress, and I want to see the warnings. But, that said, I did test with hardening flags, and they were indeed used during the build, even though some of the lintian checks failed at the end. I'm hoping the lintian tests will improve over time. Let me know if you run into problems with this version. Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, May 14, 2012 at 07:48:04PM -0400, Chris Frey wrote: Hold the presses. I found one more issue. The pkg-config files need to be renamed to match the major version number (libbarry-18.pc instead of libbarry-0.pc). I'll be releasing 0.18.2 to fix this. Ok, version 0.18.2 is here: http://sourceforge.net/projects/barry/files/barry/barry-0.18.2/sources/ Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sat, May 12, 2012 at 10:38:23AM +0200, intrigeri wrote: The trailing : is wrong in: Files: src/vformat.h src/vformat.c: Oops, thanks. I also get: W: barry source: debhelper-but-no-misc-depends barrybackup-gui-dbg W: barry source: debhelper-but-no-misc-depends libbarry18 W: barry source: debhelper-but-no-misc-depends barrydesktop W: barry source: debhelper-but-no-misc-depends libbarry18-dbg W: barry source: debhelper-but-no-misc-depends libbarry-dev W: barry source: debhelper-but-no-misc-depends barry-util-dbg W: barry source: debhelper-but-no-misc-depends barrydesktop-dbg W: barry source: debhelper-but-no-misc-depends barrybackup-gui W: barry source: debhelper-but-no-misc-depends barry-util My lintian command didn't catch the *.dsc files. Fixed that, and fixed all the above. Hopefully this is the one. :-) You can grab it in the usual place: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Thanks again for all your help! Assuming this release is acceptable, here on out, I'm hoping to match point releases (0.18.1, 0.18.2, etc) with debian uploads. Development continues on Barry, and I assume it is ok to upload to Debian as soon as any new version is available. I'm also looking forward to getting feedback through the Debian bug system, and fixing in the same manner, although I realize that sometimes those will need backported patches, depending on which version is in stable. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, May 14, 2012 at 05:35:45PM -0400, Chris Frey wrote: My lintian command didn't catch the *.dsc files. Fixed that, and fixed all the above. Hopefully this is the one. :-) You can grab it in the usual place: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Hold the presses. I found one more issue. The pkg-config files need to be renamed to match the major version number (libbarry-18.pc instead of libbarry-0.pc). I'll be releasing 0.18.2 to fix this. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667109: barry: diff for NMU version 0.15-1.3
I'm assuming you're aware of #657076, but mentioning it
just in case. I don't mind at all if 0.15 is fixed,
but work is under way for 0.18.1 to replace it.
Thanks for your work on this.
- Chris
On Sun, May 13, 2012 at 02:20:31PM +0100, Jonathan Wiltshire wrote:
tags 667109 + pending
thanks
Dear maintainer,
I've prepared an NMU for barry (versioned as 0.15-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -u barry-0.15/debian/changelog barry-0.15/debian/changelog
--- barry-0.15/debian/changelog
+++ barry-0.15/debian/changelog
@@ -1,3 +1,12 @@
+barry (0.15-1.3) unstable; urgency=low
+
+ [ Cyril Brulebois ]
+ * Non-maintainer upload.
+ * Fix FTBFS with gcc 4.7 by fixing missing unistd.h include
+(Closes: #667109).
+
+ -- Jonathan Wiltshire j...@debian.org Sun, 13 May 2012 14:02:11 +0100
+
barry (0.15-1.2) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- barry-0.15.orig/src/packet.h
+++ barry-0.15/src/packet.h
@@ -26,6 +26,7 @@
#include string
#include stdint.h
+#include unistd.h
#include protocol.h
namespace Barry { class Data; }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, May 11, 2012, intrigeri wrote:
Next review round results in:
Thanks :-)
1. debian/copyright may be syntaxically correct, but it looks weird
compared to how people usually put things in there.
Attached patch fixes this. Please consider applying it.
I applied the patch, with a slight change.
I didn't realize that the License section could be all by itself,
so thanks for that!
2. I don't think src/vformat.{h,c} is supported syntax in a Files:
field in debian/copyright.
Probably not, according to the spec. I changed it to list both files
separately.
3. The homepage set in debian/control is not the same as the one set
in debian/copyright. This looks wrong.
The one in copyright, under the Source: field, is where you get the source
code, while the one in control, under Homepage, is where you find the
welcome and documentation. I've updated copyright to make this clearer.
4. barrydesktop Suggests: gksu. How usable is it without gksu?
I picked Suggests so that it would be easy to install without gksu.
It is for the modem mode, and if the user is a member of the dip group,
then it is not needed. But if not, the desktop warns the user to add
themselves to the same group used by /usr/sbin/pppd, and then offers a
way to continue anyway, by calling gksu.
5. It seems to me BARRY_FIFO_NAME is handled in a way that opens
avenues to symlink attacks. Am I wrong? Files in world-writable
directories must be treated with care.
I believe it is safe. Here is the comment I added to the code in git to
explain my reasoning:
// Security Note:
// --
// This should be safe from symlink attacks, since
// mkfifo(), in the constructor, will fail if any other
// file or symlink already exists, and therefore we will
// never get to this open() call if that fails. And if
// mkfifo() succeeds, then we are guaranteed (assuming /tmp
// permissions are correct) that only root or our own
// user can replace the fifo with something else, such
// as a symlink.
//
// The server side is not intended to run as root, yet
// if it is, then we are still safe, due to the above logic.
// The client side can run as root (depending on what pppd
// does with pppob), and has no control over creation of
// the fifo, but only opens it for reading, never for
// creation or writing. (See FifoClient() below.)
//
// Therefore, we can only be attacked, via symlink,
// by root or ourselves.
//
int fd = open(BARRY_FIFO_NAME, O_WRONLY | O_NONBLOCK);
if( fd == -1 ) {
...
Also, Lintian in --info --display-info --pedantic mode still outputs
a bunch of relevant comments.
In my testing there were only info statements, which for the most part
I thought could be ignored. I beefed up the descriptions a bit to
avoid the extended-description-is-probably-too-short message.
For desktop-entry-contains-encoding-key, I added overrides with the
following explanation:
# The encoding key is set to UTF-8, and this is the default, and according
# to lintian help text, this is harmless. For the sake of simplicity
# and backward compatibility, it has been left in.
For no-symbols-control-file, I did some research, and found that it is
pretty tricky business to accomplish this for C++ libraries. I added
overrides with the following message:
# Barry is a C++ library, and as such it encounters similar struggles
# as documented here: http://www.eyrie.org/~eagle/journal/2012-01/008.html
# and here: http://www.eyrie.org/~eagle/journal/2012-02/001.html
# As well, Barry already uses the ABI Compliance Checker from
# linuxtesting.org to discover ABI/API breaks, and intends to bump the
# major number each time, and has had this policy since 0.17.x.
# See the following page for details:
# http://linuxtesting.org/upstream-tracker/versions/barry.html
Those were all the lintian messages that I found on my sid testing.
Since these issues only affected the debian/ directory, I spun a version
0.18.1-2 and have released it here:
http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/
I assume we can label the changelog version anything we want, until we
actually perform our first upload, and then it is written in stone.
Otherwise I have to bump the upstream version, and I'd prefer to avoid
that if possible, as it wastes space on sourceforge.net.
Let me know what you think.
Thanks,
- Chris
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577119: carmetal does not launch
Hi, I ran into this bug too, and I think it has something to do with the size of my screen... probably being too small. It is 1024x768. If I commented out the following line, it started, but the GUI was not very friendly, so I'm assuming some more GUI and resizing work is needed beyond this patch. Maybe pass this information on to upstream? Thanks, - Chris diff -ru carmetal-2.9.8.2/src/eric/JPalette.java carmetal-2.9.8.2-cdf/src/eric/JPalette.java --- carmetal-2.9.8.2/src/eric/JPalette.java 2009-02-12 05:46:27.0 -0500 +++ carmetal-2.9.8.2-cdf/src/eric/JPalette.java 2012-05-11 00:11:47.0 -0400 @@ -46,7 +46,7 @@ //x=location.x; // y=Zirkel.SCREEN.y+Zirkel.SCREEN.height-JPM.MainPalette.getPreferredSize().height; //pressed=me; -MW.JPM.CollapseToFitScreenHeight(null); +//MW.JPM.CollapseToFitScreenHeight(null); } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, Apr 30, 2012 at 01:46:13PM +0200, intrigeri wrote: $ sudo apt-get install libconfig-model-perl $ cme check dpkg-copyright $ cme dump dpkg-copyright Thanks intrigeri. The cme check did find a syntax oddity, although the error message it produced was a bit cryptic. :-) I believe this release can be uploaded. Let me know if you agree, and what the next steps are. I'm assuming that you will do the actual upload? Or is this something I need to process? The sources and signed SHA1SUMS file can be found here: http://sourceforge.net/projects/barry/files/barry/barry-0.18.1/sources/ Thanks again for all your help! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Tue, May 08, 2012 at 11:22:48AM +0200, intrigeri wrote: I'm assuming that you will do the actual upload? I will, once I'm happy with the state of the package. Excellent. Thanks very much. Let me know if you find any show stoppers. :-) - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, Apr 27, 2012 at 01:38:29AM +0200, intrigeri wrote: Looks like great work. Congrats! Thanks for the feedback! * can you please convert debian/copyright to DEP5 format? (you're almost there, see http://dep.debian.net/deps/dep5/) Is there a tool I can use to make sure I've got the new format right? I ran it against lintian on sid, but I'm not sure if that's enough. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Apr 26, 2012 at 03:36:45PM +0200, intrigeri wrote: The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Where can I find the corresponding orig.tar.gz? I'm hoping to release a real 0.18.0 this weekend, but for your testing purposes, I've spun a source package and put it here: http://foursquare.net/cdfrey/barry/ Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi intrigeri, I'm hoping you're still interested in reviewing Barry for upload to Debian sid. As for Barry itself, there's only general documentation updates, and one feature in the Desktop GUI that needs to be implemented before version 0.18 is released. As for the Debian packaging, it is ready for sid, to the best of my knowledge. By default, the Barry sources will include the command line utilities, the backup GUI, and the Desktop GUI without sync mode compiled in. The opensync plugins will also not be compiled. This is because the state of opensync in unstable still needs work. But that shouldn't hold Barry back. The latest git sources from http://repo.or.cz/w/barry.git should compile on sid, with no lintian warnings. Please let me know what you think. Thanks again, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666001: evolution-data-server test
Hi, I'm the original reporter, and I grabbed Jordi's sources, built for i386 here, and tested, and things worked great. Thanks! Looking forward to seeing this in Squeeze. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658445: [Evolution] Bug#658445: libebook1.2-9: e_book_get_changes always reports no changes in libebook evolution data server
On Wed, Mar 28, 2012 at 09:02:48PM +0200, Jordi Mallach wrote: Thanks for your old report, analysis, search for a patch and testing it. I was working on unrelated e-d-s bugs when I noticed yours and thought your effort should be compensated with some action: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666001 If you could do me a favour and test my proposed packages, and send your feedback to bug #666001 above (stating you're the reporter), that would be very useful. You can find them in http://people.debian.org/~jordi/eds/ Thanks Jordi! I really appreciate you tackling this bug. I grabed your code, rebuilt on my machine (i386 here) and tested, and it works fine. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Mon, Mar 19, 2012 at 06:53:19PM +0100, intrigeri wrote: Hi, Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? There is, actually, a way to make your debian/control dynamic: http://lists.debian.org/msgid-search/87y5rcla88.fsf@algernon.balabit Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Mar 04, 2012 at 01:33:14PM +0100, intrigeri wrote: I named it opensync0 since that plugin depends on libopensync0, which is available in Squeeze. libopensync0 was a binary library package built from the opensync source package. Using ABI numbers in such a binary package name is recommended. But I don't see any reason to use ABI numbers in the name of this *source* package, unless you really expect to maintain multiple opensyncN-plugin-barry *source* packages concurrently in Debian, which can be done, but generally needs to be backed with solid arguments. I already do maintain two separate opensync plugin source trees. They are both included in Barry, under the opensync-plugin and opensync-plugin-0.4x directories. The opensync API changed significantly between 0.2x and 0.3x, hence the need for two plugin sources. The opensync-plugin-4x plugin depends on libopensync1 which is not yet officially released, but does work. That plugin is named opensync1-plugin I can't find any such package in Debian. The 0.3x version of opensync was called libopensync1exp7 in Debian, but may have been removed by now. In my own binary packaging for 0.3x I moved to calling the binary package libopensync1, since that matched the pkgconfig name to some degree. In order to use both 0.22 opensync and 0.4x on the same system, the specific naming was needed. Can these two versions of opensync be installed concurrently on a Debian testing/sid system? Yes. I'd have to double check the -dev packages, but I worked specifically to make it possible to install both at the same time. The opensync subdirectories do not get built automatically. Do you confirm you mean that the opensync-plugin/ and opensync-plugin/debian are part of the orig.tar.gz, shipped in the source package, but not used to build any binary package? Yes. There are opensync-plugin/debian and opensync-plugin-0.4x/debian that are both built separately, or as make targets from the root debian/rules file. The main subprojects (the plugins, the gui/, and the desktop/ directories) have their own configure scripts and can be used standalone if desired, although they all depend on the Barry library. I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers I'm not sure how this is misleading, since if it doesn't exist in Debian, then Debian shouldn't care. I, as the one who's spending time to review your packaging, and offered to sponsor your packages, do care. I find it useful to be able to infer, from a given package version number (be it a source or binary package built from your Git repository, or installed on my system), if it was a package that was uploaded to Debian or a random development snapshot. With the versionning scheme you're currently using, how can we distinguish between a package built from your current Git repository, and the package (with version 0.18.0-1 as well) that will hopefully get uploaded into Debian once all this stuff is sorted out? I misunderstood who you were referring to. I can see how you would care, and it's not my intention to make it confusing. But once 0.18.0-1 is uploaded to Debian, my git repo should not say 0.18.0-1 anymore. My git repo contains the version number of the next release, so I can use it in the same state that it will be released in, and fix issues that arise. As soon as the release is made, the version gets bumped again. I would assume that if I'm doing the maintainer work, I'd have some say over when an upload happens, and could therefore update the version numbers appropriately. The Desktop GUI currently requires either libopensync0 or libopensync1, or both, and is fairly useless without the plugins to go along with it. It is tricky to compile the Desktop for both. Just to confirm I've understood what you mean, do you mean the desktop GUI binary package should depend on libopensync1exp7, and the source package should build-depend on whatever opensync -dev package? Well, libopensync1exp7 should not be used at all. It is too old. The latest opensync 0.3x devel tree in git should be used instead, if we're going the devel tree route. To clarify, the Desktop GUI which is found in Barry is designed to use either opensync 0.2x or 0.3x, or both. It uses dlopen to load the library manually, so technically opensync can be uninstalled completely and the Desktop will still run, just not sync. But in order to build, you need the headers,
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Mar 01, 2012 at 09:26:34AM +0100, intrigeri wrote: The answer is basically none. Once can maintain a package in Debian (as is: doing maintenance work, being responsible, and being in the Maintainer: control field) without any kind of special status. Excellent! In the latest Barry git tree, I've updated the debian packaging to Standards-Version 3.9.1 (the latest for Squeeze) and the compat level to 7 (the latest for Ubuntu 10.04 LTS). I can keep pressing forward with the Standards-Version, but not the compat, since that halts builds on older systems. But compat 7 isn't too bad. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. W: barrydesktop: binary-without-manpage usr/bin/bsyncjail W: barry-util: binary-without-manpage usr/bin/hal-blackberry bsyncjail is used by the Desktop GUI to isolate the sync process, in case opensync crashes. It is not meant to be run by the user. Is there any harm in putting this in /usr/lib/barry or /usr/lib/barrydesktop? Similarly for hal-blackberry... that is just a script run by HAL to fill in device identification info. This could go in /usr/lib as well. Is it bad form to share a /usr/lib/barry directory between multiple packages? W: barrydesktop: package-name-doesnt-match-sonames libosyncwrap18 This is a library only used by the Desktop GUI, and therefore packaged right along with it. Someday it may be useful as a standalone library, and could be packaged that way, but it is not ready for that yet. I'm thinking this warning can be ignored for now too. Barry 0.18 is not yet released yet, but the Debian packaging is just about ready for when it is released. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sat, Mar 03, 2012 at 02:54:34PM +0100, intrigeri wrote: We don't wait until all previous Debian releases are EOL'd before we start following the latest Debian Policy. Please follow the latest available Standards-Version: Debian Policy 3.9.3 was released. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz :) Stable is what I had handy. I realize this is a work in progress. I used the upgrade checklist to move from 3.8.0 to 3.9.1, without much change needed. I agree compat level 7 is not too bad, and this is obviously not a blocker at all, but I must state I strongly dislike the idea of refraining from using compat level 9 in Debian before 2015, merely because nobody has uploaded a recent debhelper into lucid-backports. We manage to be slow enough, by ourselves, to adopt recent changes at Debian, without needing any such external help to get things stalled. There's a large body of work on the opensync side that is not yet visible to anyone in Debian. Maybe I can get that into Debian as well, but I doubt it will make the Wheezy deadline. I've also fixed some lintian errors. The following warnings remain: W: opensync0-plugin-barry: new-package-should-close-itp-bug This can be ignored, I think. Putting two source packages into the same Git repository will be a pain. Let's talk about this other, new source package (opensync0-plugin-barry) later, and keep focused on the barry one to start with. By the way, I think the source package would be better called opensync-plugin-barry; and if it really needs to be a separate source package, Lintian is right, you need to fill an ITP for opensync-plugin-barry, and close it in its debian/changelog. I named it opensync0 since that plugin depends on libopensync0, which is available in Squeeze. The opensync-plugin-4x plugin depends on libopensync1 which is not yet officially released, but does work. That plugin is named opensync1-plugin In order to use both 0.22 opensync and 0.4x on the same system, the specific naming was needed. There used to be an opensync-plugin-barry in Lenny, as I recall. According to the Barry PTS log (if I read it right), the entire set of barry binaries was removed because of a python 2.6 issue, which was triggered by opensync. Barry should not have been yanked due to that. Only the opensync plugin. But the entire opensync side of things can be postponed for now, at least where Debian is concerned. The opensync subdirectories do not get built automatically. IIRC /usr/lib/$BINARY_PACKAGE/$PROGRAM is appropriate, but please check the Debian Policy and FHS. I couldn't find any mention of /usr/lib in the policy. Glad to see my assumption was correct. I find it misleading to write barry (0.18.0-1) unstable in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers I'm not sure how this is misleading, since if it doesn't exist in Debian, then Debian shouldn't care. If git-dch can completely eliminate editing the changelog file, though, that might be worth looking into. Building in a sid chroot fails for me: checking for OPENSYNC22... no checking for OPENSYNC40... no configure: error: Unable to find development libraries for either opensync 0.22 or 0.4x. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables: OPENSYNC22_CFLAGS and OPENSYNC22_LIBS or OPENSYNC40_CFLAGS and OPENSYNC40_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for desktop make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 = missing build-deps? The Desktop GUI currently requires either libopensync0 or libopensync1, or both, and is fairly useless without the plugins to go along with it. It is tricky to compile the Desktop for both. Without opensync plugins, though, we should leave the Desktop out of Debian for now. Is there an easy way to make packages optional? The way I've done it so far is adding debian/ directories in the subprojects, as completely separate source trees, like the opensync plugins are. As for the rest of your list, thank you for the feedback. This will take some time to process. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Mar 01, 2012 at 01:37:42AM +0100, intrigeri wrote: Hi Chris! One month has passed, and nobody adopted the barry package in Debian; the Wheezy freeze will happen in a few months. I suggest you decide whether you want to take care of barry in Debian, so that we avoid uploading packages in a hurry at the last minute. My help proposal (reviews and sponsoring) still holds :) Hi intrigeri, Thanks for the heads-up, and the renewed offer of help. After some consideration, I'd like to release version 0.18 of Barry in the next month or so, and I'd like to do so before adding more complexity to my plate. I'm hoping this is possible. How much lag time is there between applying for maintainer status, and being able to have sponsored uploads? It would be really nice to upload 0.18 in the next month, but I still have much work to do to achieve that. If someone else steps up in the meantime, I would greatly appreciate the help! But if nobody does, I still want to have Barry in Debian, and so far it looks like it's up to me. :-) Thanks again, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658445: libebook1.2-9: e_book_get_changes always reports no changes in libebook evolution data server
Subject: libebook1.2-9: e_book_get_changes always reports no changes in libebook evolution data server Package: libebook1.2-9 Version: 2.30.3-2 Severity: normal Tags: patch Bug #641898 was somehow overlooked in the lastest Debian 6.0.4 stable update. The above bug contains a small patch to fix the problem, and was available four months ago. I look forward to seeing this fix in the next Debian stable update. If there is some other step I need to perform to get this fix included, please do let me know. Thanks, - Chris -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32.55 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Fri, Jan 27, 2012 at 10:20:10AM +0100, intrigeri wrote: I don't understand very well what you are expecting from the Debian maintainer. Be them anyone else or (soon?) yoursef, what they must put in debian/changelog is: Oh, I know the changelog must be updated, but some maintainers have the opinion that upstream should not have a debian/ directory. So when they do, there's conflicts. If the Debian maintainer wants to keep it up to date, I'm happy to let him, since my main changelog is in the git commit fields anyway. I don't usually get patches to my repo for the debian/ directory, so I ended up trying to keep changes to debian/ minimal, so that the diffs for downstream would be smaller. Of course, if I'm the maintainer, I'll have to keep it more up to date than I have been. * use git-dch to get intermediary snapshots versions (this will give you something like 0.18.0-1~1.gbp9cb656, 0.18.0-1~2.gbp646619 and so on) that won't conflict between themselves or with the official Debian ones, and that will provide sane upgrade paths. Cool... I may need to look into this. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Thu, Jan 26, 2012 at 02:04:42AM +0100, intrigeri wrote: Changelog: The changelog needs to be kept up to date in Debian. I've tried to limit myself to just using my own entry at the top, but I'm willing to find a better way to share that file if downstream wants to work with me. Are you thinking of the upstream ChangeLog or of debian/changelog? I'm referring to the upstream debian/changelog. If the Debian maintainer zaps what I have, and just uses his own debian/ directory, there's no conflict, but there have been conflicts in the past, when we both update it, and so I've tried to keep my changes there minimal. This versionned dependency was brought in Debian by Riku Voipio's 0.15-1.1 NMU. It seems (being offline, I've not checked the actual packages) this change was actually imported from... Ubuntu's 0.15-1ubuntu1, uploaded to Ubuntu for Lucid by Bhavani Shankar right2bh...@gmail.com on 06 Nov 2009. I guess one particularly interested in supporting Ubuntu 8.04 would need to see with this person, and possibly others at Ubuntu, why they did this undocumented change in the first place. Thanks! Sure. What about subscribing to the package PTS? - http://packages.qa.debian.org/b/barry.html I didn't realize this was possible. Thanks. There is an upper limit on what an upstream maintainer can subscribe to, though, given the sheer number of distros and versions of distros available, plus the number of BlackBerry forums where Barry is discussed. I can't track them all. But I'm a Debian user on my main system, so maybe it gets special treatment. :-) Feel free to ask questions. Thanks! * missing manpages for bktrans, brimtrans and btranslate ... Either they're not installed, and I will just shut up :) They've been removed. :-) I'm not sure I'll do any more active work on this topic myself, but don't hesitate asking questions; also, I'll be happy to sponsor uploads if the need arises, that is if a team without Debian developers with upload rights adopts the barry package in debian. I understand, but I appreciate the work you've done so far. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582195: user friendly error messages in GUI
I was pointed to this bug just recently. While the permissions issues have been long fixed in version 0.17.x and the upcoming 0.18.x, the user friendly error message was still a valid request. So I coded it up. The latest Barry git repo has this fixed. When version 0.18.x gets releasd, and makes it to the Debian repos, this bug can be closed. The fix also inspired some enhancements to the library, for ease of use and programming, so this fix is not a simple backport to version 0.17 and earlier. Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582189: Updating and maintaining barry in Debian / Ubuntu
Hi Inrigeri, Thanks very much for your feedback. I have a few comments: 1) Version 0.18 is nearing readiness I'm hoping to release 0.18, maybe mid-Feb. There's a GUI in development to make syncing with opensync easier as well. It would be nice to have this coordinated with Debian packaging. 2) I've applied some of your changes to upstream's packaging too, thanks! There are a couple of incompatabilities between upstream and Debian's packaging. Changelog: The changelog needs to be kept up to date in Debian. I've tried to limit myself to just using my own entry at the top, but I'm willing to find a better way to share that file if downstream wants to work with me. udev: Also, I try to support old versions of Debian and Ubuntu... the oldest that I support is Ubuntu 8.04 (LTS) and the latest Debian stable. Ubuntu 8.04 uses udev 117, which is the oldest one I work with (even when taking Fedora 11 into account). I notice that your packaging depends on = 136. I'm not sure if there is a technical reason for this. 3) I rely a lot on the maintainers to funnel bug reports upstream to the barry-devel mailing list. Some bugs may be distro specific, and might only need a change in the build scripts, but others like udev changes, I'd like to hear about, and maybe fix upstream if it makes sense. So in that respect, a distro maintainer can save himself a lot of time if he regularly pings me on the mailing list regarding bug reports. Please do! 4) Barry library version numbers I've been pig-headed in the past about this, and that may be why some of the Debian packaging has been so old. I've since updated my doc/VersionNotes file which explains my versioning plans. Basically, if the library API / ABI changes, I bump the major number, which wasn't always guaranteed in the past. Version 0.18 is due to API changes, as well as lots of features. The 0 is just a logical version. The 18 is used as the library's major version, and any other versions, such as 0.18.1 is the minor. The binary packaging hasn't yet made the jump. It still uses the logical version 0 as part of the binary packaging name. i.e. libbarry0. But it could just as well be libbarry18, and would allow multiple versions of the library to be installed at once. 5) I'm also working on a project called binary-meta. I'm slowly working on opensync integration with Barry, as well as general opensync functionality. I want to see opensync 0.4x released, and I need testers to help with that. To that end, I've created binary-meta, which I'm using to help create binary packages for both opensync and Barry, as one harmonious system. The binary-meta tree is just a git repo, that uses git submodules to pull in git repositories of the opensync library, the supported opensync plugins, and Barry, with a top level makefile that supports building the whole thing without installing anything along the way. This makes it easy for end users to create binary packages to test with, as well as for me to create an apt-get repo for users. This is my plan for the upcoming version 0.18. But there's no reason that Debian can't take advantage of this work as well. Latest opensync development sources, which I'm maintaining, are in git repositories. I'd be happy to work with a maintainer who is interested in trying any of this out. 6) Me as a Debian maintainer I suppose this would make some sense, but if there are others who are willing to volunteer, I would be very happy to work with them. I try to be as responsive as possible to any Barry emails, whether direct or via the barry-devel mailing list. 7) Specific responses: Additionally, I think the new upstream release may also fix the following issues, although I've not checked in details: * Debian bug #600469: No mount possible due to 10-blackberry.rules Yes, there were USB claim changes made. I would highly encourage trying 0.17 or the upcoming 0.18. Either should fix this. I haven't heard of a USB claim error in a long time. * Debian bug #582195: Cannot backup content as a regular user (permissions issue) If udev is working, this bug won't show up. Again 0.17 / 0.18 should have this fixed. But he makes a good point about a user-friendly error message. I've added it to my todo list to double check this. However, on the short run, a few other problems would need fixing to get things up-to-date with current packaging standards: * deprecated debhelper compatibility level (4) At least the way -dbg
Bug#582190: web documentation is in the source tree
Hi, Just browsing old Debian bugs and found this one. Note that if you want faster Barry support, you can post to the barry-devel list on sourceforge. Anyway, all the website documentation is in the source tree under the doc/www directory. Of course, you'll need a recent source tree for this. I generally make the changes in the source tree before updating the website. These docs could be packaged into a barry-doc package, along with the doxygen documentation, which gets pretty big, with all the graphics and things. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641898: [Evolution] Bug#641898: libebook: e_book_get_changes always reports no changes in libebook evolution data server
On Thu, Sep 22, 2011 at 11:17:19PM -0400, Chris Frey wrote: The patch is below. Hi, I haven't heard back yet, on this bug. I'm *really* hoping that the fix can be included in the next Debian update. Is there anything I can do to help this process? Thanks! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642480: apt-key uses gpg --list-sigs instead of --check-sigs
Subject: apt-key uses gpg --list-sigs instead of --check-sigs Package: apt Version: 0.8.10.3+squeeze1 Justification: root security hole Severity: critical Tags: security *** Please type your report below this line *** Georgi Guninski reported on Full Disclosure a potential bug in apt-key's use of gpg --list-sigs, when comparing keys to the master keyring in add_keys_with_verify_against_master_keyring(), revealing a potential MITM attack for adding keys. You can find the original emails here: http://marc.info/?l=full-disclosurem=13166824712w=2 It is a legitimate bug, as far as I can tell, but could use confirmation. The original message is copied below. - Chris From: Georgi Guninski gunin...@guninski.com To: full-disclos...@lists.grok.org.uk Date: Thu, 22 Sep 2011 12:07:08 +0300 Subject: owning ubuntu apt-key net-update (maybe apt-get update related) owning ubuntu apt-key net-update (maybe apt-get update related) in ubuntu 10.04 in /usr/bin/apt-key in add_keys_with_verify_against_master_keyring() if $GPG_CMD --keyring $ADD_KEYRING --list-sigs --with-colons $add_key | grep ^sig | cut -d: -f5 | grep -q $master_key; then $GPG_CMD --quiet --batch --keyring $ADD_KEYRING --export $add_key | $GPG --import ADDED=1 to my knowledge --list-sigs doesn't do crypto verification, just looks for well formedness. it is trivial to generate a gpg key with key ID == $master_key: set gpg version to 3, set the lowest 64 bits of the RSA $n$ to the key ID, generate random high bits until one can trial factor $n$ (numerology is on your side), this is it. to reproduce: attached is ubuntu-archive-keyring.gpg. put it on http://A/ubuntu-archive-keyring.gpg make a copy of apt-key and set: ARCHIVE_KEYRING_URI=http://A/ubuntu-archive-keyring.gpg ^ this emulates MITM. do |./apt-key-new net-update| and check for new keys with |apt-key list| this might or might not be related with |apt-get update|. 10x. -- joro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642480: apt-key uses gpg --list-sigs instead of --check-sigs
On Fri, Sep 23, 2011 at 12:44:55AM +0200, Julian Andres Klode wrote: It is a bug for Ubuntu. Debian's apt-key does not support net-update and is thus not affected. I'm not sure that's true. On my system, with apt 0.8.10.3+squeeze1, there is definitely a net-update command available: case $command in add) $GPG --quiet --batch --import $1 echo OK ;; del|rm|remove) $GPG --quiet --batch --delete-key --yes $1 echo OK ;; update) update ;; net-update) net_update But regardless of net-update, I think the real bug is the reliance on --list-sigs instead of --check-sigs. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641898: [Evolution] Bug#641898: libebook: e_book_get_changes always reports no changes in libebook evolution data server
On Sat, Sep 17, 2011 at 11:04:42AM +0200, Yves-Alexis Perez wrote: It might be worth identifiying when the bug was closed upstream and see if it's possible to backport that fix to stable. Not something I'll be able to do soon though, but if you manage to identify a relevant patch, that would definitely help. I couldn't find anything upstream... the changes in upstream code were too large to find a simple fix, but after much debugging, it ended up being a one-liner in e_data_book_respond_get_changes(). I've confirmed that this fixes my issue. The patch is below. I noticed that there is an upcoming point release, according to http://www.debian.org/News/2011/20110919, and that there's a Sept 24 deadline for bugs and testing. If this fix could be included in the next Squeeze point release, I'd be happy and grateful!! Thanks, - Chris From 15ad5dc232f493afef212a8217e82eedd0fe6e64 Mon Sep 17 00:00:00 2001 From: Chris Frey cdf...@foursquare.net Date: Thu, 22 Sep 2011 23:07:29 -0400 Subject: [PATCH] Fixed libedata-book's e_data_book_respond_get_changes(): missing array add When building the get_changes DBUS response, the code forgot to add the values to the response array, resulting in get_changes calls that never returned any data. This fixes Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/658459 and Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641898 --- addressbook/libedata-book/e-data-book.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/addressbook/libedata-book/e-data-book.c b/addressbook/libedata-book/e-data-book.c index 7794e8b..d7a2a80 100644 --- a/addressbook/libedata-book/e-data-book.c +++ b/addressbook/libedata-book/e-data-book.c @@ -620,6 +620,10 @@ e_data_book_respond_get_changes (EDataBook *book, guint32 opid, EDataBookStatus /* Now change-vcard is owned by the GValue */ g_free (change); + + /* append vals to array */ + g_ptr_array_add(array, vals); + changes = g_list_remove (changes, change); } -- 1.7.2.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641898: libebook: e_book_get_changes always reports no changes in libebook evolution data server
Subject: libebook: e_book_get_changes always reports no changes in libebook evolution data server Package: libebook1.2-9 Version: 2.30.3-2 File: libebook Severity: important *** Please type your report below this line *** When using the e_book_get_changes() function on Debian Squeeze, I am unable to get it to return any changes, even if modifications are made to the data via evolution. This bug, along with some test code, was reported in Ubuntu at the following URL, but did not get a satisfactory answer: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/658459 This bug seems to also be in stable Debian Squeeze. I tested my own code on Debian Sid, with version 3.0.3, and it worked, so it seems Squeeze-specific. Note that this will affect other software that relies on this function for checkpoint-style changes, such as opensync-plugin-evolution. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32.44 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libebook1.2-9 depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcamel1.2-14 2.30.3-2 The Evolution MIME message handlin ii libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libedataserver1.2- 2.30.3-2 Utility library for evolution data ii libgconf2-42.28.1-6 GNOME configuration database syste ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libxml22.7.8.dfsg-2+squeeze1 GNOME XML library libebook1.2-9 recommends no packages. libebook1.2-9 suggests no packages. -- 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#641898: [Evolution] Bug#641898: libebook: e_book_get_changes always reports no changes in libebook evolution data server
On Sat, Sep 17, 2011 at 10:10:23AM +0200, Yves-Alexis Perez wrote: version: 3.0.3-1 tag 641898 squeeze thanks On sam., 2011-09-17 at 03:03 -0400, Chris Frey wrote: I tested my own code on Debian Sid, with version 3.0.3, and it worked, so it seems Squeeze-specific. Ok so closing with version and tagging accordingly. Does this mean it is closed in Squeeze as well? I was hoping for a fix in Squeeze (or at least keep it open). I'm not sure what the tag means, and I don't see it via the web anymore. Is there any flexibility with upgrading to 2.31.x or 2.32.x in squeeze? I'm guessing not, but is it worth testing them? Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628743: closed by Santiago Vila sanv...@unex.es (Re: Bug#628743: autopoint: Autopoint depends on git)
On Wed, Jun 01, 2011 at 09:18:04AM +, Debian Bug Tracking System wrote: From: Santiago Vila sanv...@unex.es That does not make much sense. autopoint is a tool to copy or update standard gettext infrastructure files into a source package. If your sources are recent enough that you don't have to update anything, then you just don't need autopoint at all to begin with. In either case, we can't relax the dependency, because several packages have autopoint in their build-depends, and autopoint uses git internally, so it HAS to work when invoked, no matter what. Hi Santiago, Thanks for your quick response. When I look inside the autopoint script, I find that there are 3 options for working with the autopoint archive. Historically, autopoint used to use cvs, but it looks like it has switched to git. But there is a 'dir' option as well, with the only drawback of using about 6 times more space, according to the comments in the script. When cvs was the dependency, this wasn't a problem. Not too many people would install their own copies of cvs on their system. But git is new enough, and still in development, and I think it is more likely that people will have their own copies of git installed. I find it unfortunate that something as basic as autopoint depends on git (or cvs for that matter), but I can understand the reason. And upon a second look, the fix is not as simple as I first thought. But switching to 'dir' would indeed fix the problem, and make autopoint standalone. Is this a reasonable option, or am I missing another factor? Thanks, - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628743: closed by Santiago Vila sanv...@unex.es (Re: Bug#628743: autopoint: Autopoint depends on git)
On Wed, Jun 01, 2011 at 08:39:48PM +0200, Santiago Vila wrote: Hmm, wait a moment. I thought you were against the dependency on git because you didn't want git installed in your system. If the problem is that you have your own version of git installed, then that's a completely different problem! I can suggest several solutions for that problem: * Use equivs. That would help you to satisfy the dependency without having to install the Debian package. Perfect! This fixes my concern. Thank you! - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628743: autopoint: Autopoint depends on git
Subject: autopoint: Autopoint depends on git Package: autopoint Version: 0.18.1.1-3 Severity: normal *** Please type your report below this line *** Debian Squeeze's version of autopoint has a hard dependency on git. I believe this should be changed to Recommends, so that people who work with bleeding edge git sources can still use autopoint. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32.40 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages autopoint depends on: pn git | git-corenone (no description available) autopoint recommends no packages. autopoint suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597153: libgcal0: Segfault due to early global cleanup of libxml
Subject: libgcal0: Segfault due to early global cleanup of libxml Package: libgcal0 Version: 0.9.4-1 Justification: breaks unrelated software Severity: critical Tags: upstream patch *** Please type your report below this line *** libxml2 has a global cleanup function that is meant to be called at the end of an application called xmlCleanupParser(). This ends up freeing a number of global tables inside libxml2. If an application uses both libgcal and libxml2, and get_the_url() is called in libgcal, libxml2 stops working for the app, and often causes a segfault when it tries to access the global tables that are now freed. This patch below fixes the issue, and has been included in upstream. The latest upstream sources can be found here: Tarballs: http://code.google.com/p/libgcal/ Git repo: http://gitorious.org/libgcal Note that some software is already checking for = 0.9.6 in configure scripts, to avoid this bug, and the latest 0.9.6 release fixes an API bug that the binary package has a special patch for. If at all possible, upgrading Squeeze to upstream 0.9.6 would be much preferred. But if not, this patch at least. Thanks, - Chris Patch: diff --git a/src/gcal_parser.c b/src/gcal_parser.c index 437d6ac..f1aa13c 100644 --- a/src/gcal_parser.c +++ b/src/gcal_parser.c @@ -103,7 +103,6 @@ int get_the_url(char *data, int length, char **url) result = 0; xmlFreeDoc(doc); - xmlCleanupParser(); exit: return result; @@ -160,7 +159,6 @@ int get_edit_url(char *data, int length, char **url) result = 0; xmlFreeDoc(doc); - xmlCleanupParser(); exit: return result; @@ -183,7 +181,6 @@ int get_edit_etag(char *data, int length, char **url) result = 0; xmlFreeDoc(doc); - xmlCleanupParser(); exit: return result; -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.35.4 (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libgcal0 depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libxml2 2.7.7.dfsg-4 GNOME XML library libgcal0 recommends no packages. libgcal0 suggests no packages. -- 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#528167: zapping: Cannot start capturing... ioctl VIDIOC_REQBUFS failed: 0, Success
Package: zapping Version: 0.10~cvs6-2 Severity: important Tags: patch *** Please type your report below this line *** I ran into the bug which is also reported here: https://bugs.launchpad.net/ubuntu/+source/zapping/+bug/304530 I looked at the kernel code, and it is possible that the ioctl VIDIOC_REQBUFS can return a value greater than 0 on success. This break's zapping's TV engine code, which assumes most ioctl's return 0 on success. Below is a hackish patch that got video working for me on a Conexant card. I'm still having trouble getting channels working, but that's a separate problem. - Chris diff -ru zapping-0.10~cvs6/src/tveng25.c zapping-0.10~cvs6-cdf/src/tveng25.c --- zapping-0.10~cvs6/src/tveng25.c 2006-06-07 02:56:51.0 -0400 +++ zapping-0.10~cvs6-cdf/src/tveng25.c 2009-05-10 18:05:30.0 -0400 @@ -2575,7 +2575,7 @@ rb.memory = V4L2_MEMORY_MMAP; rb.count = n_buffers; - if (-1 == xioctl (info, VIDIOC_REQBUFS, rb)) + if (xioctl_may_fail (info, VIDIOC_REQBUFS, rb) 0) return FALSE; if (rb.count = 0) -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.28.9snoopbuffuse (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511741: libtar fails to build on unstable
Hi, Recent changes in unstable have caused this package to fail to build on unstable itself. There is an updated libtar in Ubuntu Jaunty that may solve this issue. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484995: Pango-WARNING **: Error loading GPOS table 5503
Hi, I'm getting this error message on Lenny as well, using doxygen, and the FreeSans font. It would be really great if this could be fixed in the next Lenny update. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484995: Pango-WARNING **: Error loading GPOS table 5503
On Fri, Apr 10, 2009 at 07:27:04AM +0200, Josselin Mouette wrote: Do you have the means to check whether this patch fixes the issue? http://svn.gnome.org/viewvc/pango/trunk/pango/opentype/harfbuzz-gpos.c?r1=2725r2=2730view=patch If you can confirm that, there???s no problem with backporting the change to lenny for the next point release. Thanks! That fixes it for me. - Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496832: bakefile: Request to package Bakefile
Subject: bakefile: Request to package Bakefile Package: bakefile Severity: wishlist *** Please type your report below this line *** Would it be possible to include Bakefile in Debian? It is licensed with the MIT license and the official site provides debian packages, so some of this work is already done. The official site is: http://www.bakefile.org/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
