Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware

[Cyril Brulebois]

Lucas Nussbaum  (2023-11-03):
> UDD uses several independant "importers". The constraint you quoted is
> in the "blends" importer (maintained by Andreas Tille, cced).

ACK, I spotted a number of things that were blends-related, didn't
realize that particular schema was too.

> The reason why UDD thinks that #1055136 does not affect unstable, is
> because the BTS thinks it does not affect unstable. If you look at the
> version graph for the bug, you see that the BTS only knows about the
> version in oldstable, not about the versions in stable/testing/unstable.
> The same happens for other packages in non-free-firmware (see #1038610
> for example).

https://github.com/dondelelcaro/debbugs/issues/2 then.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware

[Cyril Brulebois]

Andreas Beckmann  (2023-11-03):
> The list of RC bugs in sid
> https://udd.debian.org/bugs.cgi?release=sid&merged=ign&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=desc&format=html#results
> does not contain e.g. #1055136 filed against src:nvidia-graphics-drivers
> which is in non-free-firmware, but it lists the clones of this bug that
> are assigned to various old driver series
> src:nvidia-graphics-drivers-{tesla,legacy}-* that are still in non-free
> (not in non-free-firmware).
> 
> Interestingly the RC bug list for bullseye
> https://udd.debian.org/bugs.cgi?release=bullseye&merged=ign&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=desc&format=html#results
> does list the bug. src:nvidia-graphics-drivers/bullseye is in non-free.

Indeed, udd doesn't seem to know about non-free-firmware at all, e.g.:

CONSTRAINT check_component CHECK ((component = ANY (ARRAY['main'::text, 
'contrib'::text, 'non-free'::text])))

Things like udd/ftpnew_gatherer.py could almost work by accident since
that's using .startswith() (but then assigning "non-free" as value, so
that probably doesn't work anyway).

I'm afraid I'm not learning udd's codebase and configuration today.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#843944: tracker.debian.org: please add “changes” anchor in news entries

[Cyril Brulebois]

Paul Wise  (2016-11-11):
> On Fri, Nov 11, 2016 at 11:20 AM, Cyril Brulebois wrote:
> 
> > I think the attached patch should do the job.
> >
> > But I suspect the following bits from the CSS might need updating (the
> > naked “a” part notably), since this anchor gets highlighted in blue,
> > which might not be too desirable?
> 
> Merged, changed from https://tracker.debian.org/news/814326

Or maybe I didn't patch the right code path?


KiBi.


signature.asc
Description: Digital signature

Bug#843944: tracker.debian.org: please add “changes” anchor in news entries

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2016-11-11):
> It would be nice if an anchor could be added on the “Changes:” line of
> the news entry. For example, when trying to point to recent grub2
> changes, this link would lead to a page full of descriptions (one for
> each binary):
>   https://tracker.debian.org/news/811622
> 
> while the following link could lead directly to the Changes: part which
> is filled according to debian/changelog:
>   https://tracker.debian.org/news/811622#changes
> 
> grub2 isn't too bad; linux is… I seem to be needing 11 page downs to get
> to the changes part on this entry, for example:
>   https://tracker.debian.org/news/811137
> 
> Thanks for considering.

I think the attached patch should do the job.

But I suspect the following bits from the CSS might need updating (the
naked “a” part notably), since this anchor gets highlighted in blue,
which might not be too desirable?
| a, a:hover, a:focus {
| color: #0530D7;
| }


KiBi.
From 669f0459a86e2902e4972ecae9224f888977f6ba Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Fri, 11 Nov 2016 04:13:38 +0100
Subject: [PATCH] auto_news: add a "changes" anchor.

This way, one can share links pointing directly to the interesting part
of a news page (Closes: #843944).

Signed-off-by: Cyril Brulebois 
---
 distro_tracker/auto_news/tracker_tasks.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/distro_tracker/auto_news/tracker_tasks.py b/distro_tracker/auto_news/tracker_tasks.py
index ecd8089..186950d 100644
--- a/distro_tracker/auto_news/tracker_tasks.py
+++ b/distro_tracker/auto_news/tracker_tasks.py
@@ -49,7 +49,7 @@ class GenerateNewsFromRepositoryUpdates(BaseTask):
 # Add changelog entries since last update...
 changelog_content = package_version.get_changelog_entry()
 if changelog_content:
-content = content + '\nChanges:\n' + changelog_content
+content = content + '\nChanges:\n' + changelog_content
 
 return content
 
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#843944: tracker.debian.org: please add “changes” anchor in news entries

[Cyril Brulebois]

Package: tracker.debian.org
Severity: wishlist

Hi,

It would be nice if an anchor could be added on the “Changes:” line of
the news entry. For example, when trying to point to recent grub2
changes, this link would lead to a page full of descriptions (one for
each binary):
  https://tracker.debian.org/news/811622

while the following link could lead directly to the Changes: part which
is filled according to debian/changelog:
  https://tracker.debian.org/news/811622#changes

grub2 isn't too bad; linux is… I seem to be needing 11 page downs to get
to the changes part on this entry, for example:
  https://tracker.debian.org/news/811137

Thanks for considering.


KiBi.

Bug#841984: tracker.debian.org: comment appears on tracker pages

[Cyril Brulebois]

Package: tracker.debian.org
Severity: important
Tags: patch

Hi,

Michael Biebl noticed this message appears on pages like [1]:
|{# A hidden modal which would display a list of email addresses, allowing 
the user to choose which one to subscribe to the package. #} 

 1. https://tracker.debian.org/pkg/dpkg

Looking at the git history, it seems a comment going multiline triggered
this. Proposal to fix that attached.


KiBi.
>From 6d37120adefe7eb22f585db6e12dc612c0c94f51 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 25 Oct 2016 01:59:53 +0200
Subject: [PATCH] Fix multiline comment.

This fixes a regression introduced in:
| commit 3f029d09d27ba2fb656c34fa63d5d13edcb1caf1
| Author: Ben Finney 
| Date:   Tue Oct 11 16:23:29 2016 +1100
|
| Rephrase all gendered references to the user, to be gender-neutral.

since the {# foo #} syntax is only for single line comments.
---
 distro_tracker/core/templates/core/package.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/distro_tracker/core/templates/core/package.html b/distro_tracker/core/templates/core/package.html
index d861f27..fadedab 100644
--- a/distro_tracker/core/templates/core/package.html
+++ b/distro_tracker/core/templates/core/package.html
@@ -67,10 +67,10 @@
 {% endblock %}
 
 {% block page-content %}
-{#
+{% comment %}
   A hidden modal which would display a list of email addresses,
   allowing the user to choose which one to subscribe to the package.
-#}
+{% endcomment %}
 {% spaceless %}
 
   
-- 
2.1.4

Re: Testing d-i for stable-p-u

[Cyril Brulebois]

Hi,

Steven Chamberlain  (2015-10-05):
> Does anyone test d-i for stable-proposed-updates?  If so, how?
> It seems rather difficult currently.

Around p-u time, when d-i's been built (uploaded or binNMUd) against p-u.

> You could build the d-i jessie branch from Git, or get release-candidate
> stable-p-u images from
> http://ftp.debian.org/debian/dists/jessie-proposed-updates/main/installer-amd64/current/images/
> 
> but choose-mirror will default to installing jessie.  To override it,
> you may need to use preseed/early_command or execute in a shell:
> 
> sed -i 's/$/-proposed-updates/' /etc/default-release
> 
> If you don't do that, the installer may fetch some of its udebs from
> stable, rather than newer ones in stable-p-u.  (Or otherwise you could
> build a custom d-i image having all the latest udebs from stable-p-u,
> but I've become tired of that).

Depending on particular changes I'd like to check (e.g. grub-installer),
I indeed end up building an image with debian-cd.

> Next, it would be nice to test that the base system in stable-p-u is
> still installable.  d-i's debootstrap can't seem to do this as it
> doesn't recognise "-proposed-updates" suites, so would need a patch to
> add those.  I tried that but ran into some other issue next.

You've mentioned this in your follow-up mail, which I'm quoting to reply
directly in a single mail:
> Oops, of course it doesn't make sense to do that.  stable-p-u contains
> the updated packages and not the whole archive.
> 
> I can't think of an obvious way to make anna (udeb fetcher) and
> d-i debootstrap use stable-p-u in addition to stable.

You're missing net-retriever in this picture. You might find the
following somewhat helpful:
  https://lists.debian.org/debian-cd/2014/01/msg00026.html

BTW, back to the original topic: I don't expect the base system to
become uninstallable over night in p-u. We have release managers and
debian-boot@ (well me) looking over changes affecting the installation
process in stable, and I don't recall many booboos in this area.

(That said, yes, testing more is better than testing less.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#757427: rmadison: fails to mimick dak ls output

[Cyril Brulebois]

Hi again,

Cyril Brulebois  (2014-08-08):
> out of curiosity I tried rmadison from devscripts for a change and got
> this output:
> | kibi@arya:~$ \rmadison partman-lvm
> |  partman-lvm | 74 | squeeze/main/debian-installer | all
> |  partman-lvm | 74 | squeeze   | source
> |  partman-lvm | 82 | wheezy/main/debian-installer  | all
> |  partman-lvm | 82 | wheezy| source
> |  partman-lvm | 90 | jessie/main/debian-installer  | all
> |  partman-lvm | 90 | sid/main/debian-installer | all
> |  partman-lvm | 90 | jessie| source
> |  partman-lvm | 90 | sid   | source
> 
> while a real dak ls returns a far more readable output:
> | kibi@arya:~$ alias rmadison
> | alias rmadison='ssh release.debian.org dak ls'
> | kibi@arya:~$ rmadison partman-lvm
> | partman-lvm |74 |  oldstable | source, all
> | partman-lvm |82 | stable | source, all
> | partman-lvm |90 |testing | source, all
> | partman-lvm |90 |   unstable | source, all
> 
> Please note that the format is different, and that one uses suite names
> while the other one uses codenames.

And having tried that again:
| kibi@chloe:~$ rmadison -u api.ftp-master.debian.org/madison systemd|grep 22
| systemd| 221-1  | testing | source, 
amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
| systemd| 221-1+deb9u1   | buildd-testing-proposed-updates | source
| systemd| 221-1+deb9u1   | testing-proposed-updates| source
| systemd| 222-1  | unstable| source
| systemd| 222-2  | buildd-unstable | source, 
amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc
| systemd| 222-2  | unstable| source, 
amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc

versus:
| kibi@chloe:~$ rmadison systemd|grep 22
|  systemd | 221-1  | stretch  | source, amd64, arm64, armel, 
armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
|  systemd | 221-1+deb9u1   | stretch-p-u  | source
|  systemd | 222-1  | sid  | source
|  systemd | 222-2  | sid  | source, amd64, arm64, armel, 
armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc


I don't think returning “stretch-p-u” is a good idea… Selecting it with
-s doesn't even work anyway:
| kibi@chloe:~$ rmadison systemd -s stretch-p-u
| debian:
| new:
| kibi@chloe:~$ rmadison systemd -s stretch-proposed-updates
| debian:
|  systemd | 221-1+deb9u1 | stretch-p-u | source
| new:


Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Sources required by Built-Using break multiple assumptions?

[Cyril Brulebois]

Hello Guillem,

Guillem Jover  (2014-08-22):
> Hi!
> 
> I was mightily confused when I saw that supposedly dpkg 1.17.12, which
> had an RC bug filed and had not spent enough time to transition had
> “migrated” [M], w/o any sign of MIGRATION mail, nor any release team
> hint directive.
> 
> This is what rmadison has to say about this:
> 
> ,---
>  dpkg | 1.17.10 | jessie | source, amd64, armel, armhf, i386,
>kfreebsd-amd64, kfreebsd-i386, mips, mipsel,
>powerpc, s390x
>  dpkg | 1.17.13 | sid| source, amd64, arm64, armel, armhf, hurd-i386,
>i386, kfreebsd-amd64, kfreebsd-i386, mips,
>mipsel, powerpc, ppc64el, s390x, sparc
> `---
> 
> The Sources for jessie do contain both versions, 1.17.10 and 1.17.12
> with an Extra-Source-Only:yes field, due to at least deets and the
> recently introduced Built-Using in debsig-verify.

whether it was correct to let these packages migrate without dpkg
1.17.12 migrating at the same time is a question I have no answer to.

> The following are probably issues with the QA codebase, it lists as
> migrated when that's not true:
> 
>   (thinks that testing is 1.17.12)
>    [M]
>   
>   
> 
>   (thinks that source is 1.17.12 and binaries 1.17.10, half-true I guess)
>    (1.17.10)
>    (1.17.12)
> 
> This is part of the release team, which looks wrong:
> 
>   (thinks it's migrating from 1.17.12 to 1.17.13)
>   

At least britney has things right:
| dpkg (1.17.10 to 1.17.13)
| 
| Maintainer: Dpkg Developers
| Too young, only 2 of 10 days old
| dpkg (source, i386, amd64, armel, armhf, kfreebsd-amd64, kfreebsd-i386, 
mips, mipsel, powerpc, s390x) has new bugs!
| Updating dpkg introduces new bugs: #758778
| Updating dpkg fixes old bugs: #758199
| Not considered 

(https://release.debian.org/britney/update_excuses.html)

> If this analysis seems right I can probably file some bug reports, and
> I guess the way to fix this would be to ignore any source that is marked
> Extra-Source-Only:yes?

That's probably the issue for testing.pl yeah. Looking briefly at it, it
seems to be using stripped-down versions of packages/sources files,
namely testing.pkgs and testing.srcs.

I think tools/migration/cronjob.sh would need to be smarter. And use
more https. And it might be helpful to figure out how incoming changes
might have led to the need for other fixes.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#757427: rmadison: fails to mimick dak ls output

[Cyril Brulebois]

Package: qa.debian.org
Severity: normal

Hi,

out of curiosity I tried rmadison from devscripts for a change and got
this output:
| kibi@arya:~$ \rmadison partman-lvm
|  partman-lvm | 74 | squeeze/main/debian-installer | all
|  partman-lvm | 74 | squeeze   | source
|  partman-lvm | 82 | wheezy/main/debian-installer  | all
|  partman-lvm | 82 | wheezy| source
|  partman-lvm | 90 | jessie/main/debian-installer  | all
|  partman-lvm | 90 | sid/main/debian-installer | all
|  partman-lvm | 90 | jessie| source
|  partman-lvm | 90 | sid   | source

while a real dak ls returns a far more readable output:
| kibi@arya:~$ alias rmadison
| alias rmadison='ssh release.debian.org dak ls'
| kibi@arya:~$ rmadison partman-lvm
| partman-lvm |74 |  oldstable | source, all
| partman-lvm |82 | stable | source, all
| partman-lvm |90 |testing | source, all
| partman-lvm |90 |   unstable | source, all

Please note that the format is different, and that one uses suite names
while the other one uses codenames.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140807235947.28400.34072.report...@arya.home.mraw.org

Bug#757351: tracker.debian.org: regression from old-pts: RFH source packages aren't listed

[Cyril Brulebois]

Raphael Hertzog  (2014-08-07):
> On Thu, 07 Aug 2014, Cyril Brulebois wrote:
> > Something like this would be nice:
> > | The package depends on source packages which need a new maintainer:
> > |   dosfstools (#756088), elilo (#707112), hfsutils (#60)
> > 
> > No need to retain the old, a bit too verbose wording IMHO.
> 
> Have you seen that you get (most) of this information if you click on the
> question mark next to the entry?

Having to click is a major usability regression from just having to read.

Also, a question mark looks like a help button. So counterintuitive anyway.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#757357: tracker.debian.org: regression from old-pts: links to F&P bugs

[Cyril Brulebois]

Package: tracker.debian.org
Severity: normal

Hi,

here's another regression from old-PTS. Both tools list "F&P: 2" for
debian-installer, but the link is only correct in old-PTS:
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-installer&archive=no&pend-inc=pending-fixed&pend-inc=fixed&repeatmerged=no

tracker.d.o uses this, which doesn't show any of the 2 bug reports:
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-installer&pend-inc=fixed&archive=no&repeatmerged=no

You seem to be missing "&pend-inc=pending-fixed".

(For reference in case their status changes in the meanwhile, those are
#696418 and #700026.)

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140807120312.14347.60051.report...@arya.home.mraw.org

Bug#757351: tracker.debian.org: regression from old-pts: RFH source packages aren't listed

[Cyril Brulebois]

Package: tracker.debian.org
Severity: normal

Hi,

here's what tracker.d.o says for debian-installer, under "action
needed":
| The package depends on source packages which need a new maintainer.
| 6 bugs tagged patch in the BTS
| lintian reports 2 warnings

while old-pts is a bit more helpful:
| This package has "Build-Depends: dosfstools" while dosfstools needs a new 
maintainer, see O #756088.
| This package has "Build-Depends: hfsutils" while hfsutils needs a new 
maintainer, see O #60.
| This package has "Build-Depends: elilo" while elilo needs a new maintainer, 
see O #707112. 

Something like this would be nice:
| The package depends on source packages which need a new maintainer:
|   dosfstools (#756088), elilo (#707112), hfsutils (#60)

No need to retain the old, a bit too verbose wording IMHO.

Thanks for considering.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140807112609.11538.16574.report...@arya.home.mraw.org

Bug#757350: tracker.debian.org: please don't limit box height

[Cyril Brulebois]

Package: tracker.debian.org
Severity: normal

Hi,

at the moment the "binaries" and "news" boxes are the last ones
"vertically" in their respective columns. I don't think limiting their
heights is a good idea because you get to scroll inside each box if you
need to look at this or that binary, or at older news.

The only item below is the page footer, so I don't think removing the
height limit is going to create any functional issue, quite the
contrary. (In the old-PTS case, the subscribe link was somehow hidden
below, but tracker.d.o got it reflowed elsewhere.)

Thanks for considering.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140807111919.11156.32827.report...@arya.home.mraw.org

Bug#757349: tracker.debian.org: please sort binary packages

[Cyril Brulebois]

Package: tracker.debian.org
Severity: normal

Hi,

the list of binary packages isn't sorted yet, which makes it uneasy to
browse for packages shipping a long list of binaries. Examples:
  https://tracker.debian.org/pkg/parted

and even worse:
  https://tracker.debian.org/pkg/linux

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140807111201.10614.3735.report...@arya.home.mraw.org

Bug#750905: qa.debian.org: broken links to patch-tracker

[Cyril Brulebois]

Vincent Lefevre  (2014-06-08):
> Package: qa.debian.org
> Severity: normal
> 
> http://packages.qa.debian.org/d/dragonegg.html has 2 patch-tracker
> links, but patch-tracker.debian.org can't be found.

Well, the problem surely isn't qa.d.o, right?

https://lists.debian.org/debian-devel/2014/05/msg00888.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Getting backports news into the PTS / ddc@ vs. dbc@

[Cyril Brulebois]

Hi,

the news section on the PTS[1] seems to be built upon data received from
ddc@. It looks like backports changes go to dbc@ instead[2]; asking Paul
about it on IRC, he was wondering whether that was set in stone, or
possible/a good idea to change at some point. Depending on the answer, I
suspect it might be feasible to feed the PTS data from another list, or
just reuse the existing mechanism, if the mails would be sent to ddc@
(instead of or in addition to the existing dbc@).

 1. http://packages.qa.debian.org/d/django-ldapdb.html
 2. https://lists.debian.org/debian-backports-changes/2014/01/msg00044.html

Thanks for your time and guidance.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Broken links/redirections due to URL encoding issues

[Cyril Brulebois]

Hi again,

Raphael Geissert  (2013-09-30):
> Apologies, it is fixed now. IPv6 is currently served by a different instance 
> running a new codebase - hence the differente results.

ah, that explains. Seems to be OK now for the following URLs at least:
  
http://http.debian.net/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60+1.dsc
  http://http.debian.net/debian/pool/main/libu/libusb/libusb_0.1.12-20+nmu1.dsc

(according to wget -d; iceweasel has likely cached the earlier
redirections and is still reaching a 404.)

Thanks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Broken links/redirections due to URL encoding issues

[Cyril Brulebois]

Hi,

xorg-server's PTS page[1] links to the oldstable-bpo .dsc[2] and that
one returns broken results
 1. http://packages.qa.debian.org/x/xorg-server.html
 2. 
http://http.debian.net/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60+1.dsc

wget is happy for IPv4, but 404's for IPv6:
| wget -d -6 
http://http.debian.net/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60+1.dsc
| Setting --inet6-only (inet6only) to 1
| DEBUG output created by Wget 1.14 on linux-gnu.
| 
| URI encoding = ‘UTF-8’
| --2013-09-29 19:59:48--  
http://http.debian.net/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60+1.dsc
| Resolving http.debian.net (http.debian.net)... 2a01:4f8:131:152c::42
| Caching http.debian.net => 2a01:4f8:131:152c::42
| Connecting to http.debian.net (http.debian.net)|2a01:4f8:131:152c::42|:80... 
connected.
| Created socket 3.
| Releasing 0x00e9c5f0 (new refcount 1).
| 
| ---request begin---
| GET 
/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60+1.dsc 
HTTP/1.1
| User-Agent: Wget/1.14 (linux-gnu)
| Accept: */*
| Host: http.debian.net
| Connection: Keep-Alive
| 
| ---request end---
| HTTP request sent, awaiting response... 
| ---response begin---
| HTTP/1.1 301 Moved Permanently
| Date: Sun, 29 Sep 2013 17:59:43 GMT
| Location: 
http://free.hands.com/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60%201.dsc
| Content-Type: text/plain
| Vary: Accept-Encoding
| Keep-Alive: timeout=15, max=200
| Connection: Keep-Alive
| Transfer-Encoding: chunked
| 
| ---response end---
| 301 Moved Permanently
| Registered socket 3 for persistent reuse.
| Location: 
http://free.hands.com/debian-backports/pool/main/x/xorg-server/xorg-server_1.10.4-1~bpo60%201.dsc
 [following]
| ] done.

which obviously 404's later on (%20 = space).

Various tries on IPv4 returned URLs for different mirrors, not encoded,
and non 404-ing.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Grub 2.00 in testing?

[Cyril Brulebois]

Paul Wise  (2013-07-23):
> On Mon, Jul 22, 2013 at 10:14 PM, Cyril Brulebois wrote:
> 
> > Possibly anything popping up in Built-Using. Random example:
> > kibi@arya:~$ \rmadison busybox -s stable,testing,unstable
> 
> Looks correct:
> 
> pabs@quantz:~$ zcat
> /srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
> | grep-dctrl -s Version -XP busybox | sort -u
> Version: 1:1.20.0-7
> Version: 1:1.20.0-8.1
> 
> > Or even worse:
> > kibi@arya:~$ \rmadison linux -s stable,testing,unstable
> 
> Looks correct:
> 
> ftp://ftp.debian.org/debian/pool/main/l/linux/
> 
> and this:
> 
> pabs@quantz:~$ zcat
> /srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
> | grep-dctrl -s Version -XP  linux | sort -u
> Version: 3.10.1-1
> Version: 3.2.32-1
> Version: 3.2.39-2
> Version: 3.2.41-2
> Version: 3.2.41-2+deb7u2
> Version: 3.2.46-1
> Version: 3.9.6-1
> Version: 3.9.8-1
> 
> > I've just noticed that #699268 is supposed to be fixed, but last I heard
> > about somebody from QA, that was during the last stages of the wheezy
> > release cycle, and while the issue was known back then, I think not
> > everyone agreed it was the right time to try and get that fixed (that
> > conversation probably happened on #debian-release if memory serves,
> > which I doubt).
> 
> Hmm, ok. So you want madison to hide versions that exist but aren't
> the latest version? The Debian archive has had the ability to have
> multiple versions in the same suite for quite a while, I'm a bit
> surprised this is coming up now. I seem to remember that Built-Using
> isn't the only case where this can happen - library transitions can
> too IIRC.

I want rmadison to be a remote madison, meaning a remote dak ls… which
is what it's supposed to be! That means behaving like dak ls, and
showing what matters, that is: not the extra sources.

I hope it clarifies the above "correctness" you mentioned. rmadison
might currently reflects what's in Sources file, but that isn't the
point, or its job.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130723090112.ga22...@mraw.org

Re: Grub 2.00 in testing?

[Cyril Brulebois]

(Adding -qa@ to the loop.)

Paul Wise  (2013-07-22):
> On Mon, Jul 22, 2013 at 10:03 AM, Cyril Brulebois wrote:
> 
> > rmadison now defaults to querying UDD by default
> 
> There is a projectb mirror accessible from qa.d.o, so we could rewire
> the madison CGI to look at that. It is written in Perl though so it is
> unlikely I'll ever be motivated to do that. Hopefully someone else
> will be willing to make it use projectb when appropriate...

With more than 24 hours a day, I would certainly like to do that… Not in
this life I'm afraid (at least not those weeks).

> > [UDD] is on crack in a bunch of cases.
> 
> Any info about these? Lucas and other UDD folks would probably want to
> fix the issues.

Possibly anything popping up in Built-Using. Random example:
kibi@arya:~$ \rmadison busybox -s stable,testing,unstable
 busybox | 1:1.20.0-7   | wheezy | source, amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 busybox | 1:1.20.0-7   | jessie | source
 busybox | 1:1.20.0-7   | sid| source
 busybox | 1:1.20.0-8.1 | jessie | source, amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 busybox | 1:1.20.0-8.1 | sid| source, amd64, armel, armhf, hurd-i386, 
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, 
sparc
kibi@arya:~$ rmadison busybox -s stable,testing,unstable
   busybox |1:1.20.0-7 | stable | source, amd64, armel, armhf, i386, 
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
   busybox |  1:1.20.0-8.1 |testing | source, amd64, armel, armhf, i386, 
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
   busybox |  1:1.20.0-8.1 |   unstable | source, amd64, armel, armhf, 
hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, 
s390, s390x, sparc

Or even worse:
kibi@arya:~$ \rmadison linux -s stable,testing,unstable
 linux | 3.2.32-1| jessie | source
 linux | 3.2.32-1| sid| source
 linux | 3.2.39-2| jessie | source
 linux | 3.2.39-2| sid| source
 linux | 3.2.41-2| wheezy | source
 linux | 3.2.41-2| jessie | source
 linux | 3.2.41-2| sid| source
 linux | 3.2.41-2+deb7u2 | wheezy | source
 linux | 3.2.41-2+deb7u2 | jessie | source
 linux | 3.2.41-2+deb7u2 | sid| source
 linux | 3.2.46-1| wheezy | source
 linux | 3.2.46-1| jessie | source
 linux | 3.2.46-1| sid| source
 linux | 3.9.6-1 | jessie | source
 linux | 3.9.6-1 | sid| source
 linux | 3.9.8-1 | jessie | source
 linux | 3.10.1-1| sid| source
kibi@arya:~$ rmadison linux -s stable,testing,unstable
 linux |  3.2.46-1 | stable | source
 linux |   3.9.8-1 |testing | source
 linux |  3.10.1-1 |   unstable | source

(rmadison is a shell alias to an ssh-based dak ls, \rmadison is the
plain command from devscripts with its default configuration.)

I've just noticed that #699268 is supposed to be fixed, but last I heard
about somebody from QA, that was during the last stages of the wheezy
release cycle, and while the issue was known back then, I think not
everyone agreed it was the right time to try and get that fixed (that
conversation probably happened on #debian-release if memory serves,
which I doubt).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Please investigate orphaning/removing the diffmon package

[Cyril Brulebois]

Hello,

looking at dbs-using packages, diffmon looks like something that isn't
really maintained:
 - last maintainer upload in 2002
 - 5 NMUs in a row since then, first in 2006

I'd appreciate being kept in the loop, whatever the outcome is.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Cyril Brulebois]

Jonas Smedegaard  (31/05/2012):
> I have heard before the argument of the sponsor having responsibility,
> but in reality I have *never* heard of sponsors actually being held
> responsible for anything but the concrete upload of a specific
> packaging release.

Suggested reading:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;bug=672117
  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;bug=672117

The sponsor did almost all the needed work to reduce entropy (see the
thread to see how many packages got delayed/entangled/prevented from
migrating because of the initial upload).

[ Holger, that's fingerpointing. Pointing to how you quickly dealt with
those packages, thanks again. :-) ]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#652840: Build-depends on obsolete lazarus-src-0.9.30

[Cyril Brulebois]

Luca Falavigna  (20/12/2011):
> Package: facturlinex2
> Version: 2.0.1-1
> Severity: serious
> 
> Your package build-depends on lazarus-src-0.9.30, no longer built on top of
> lazarus source package. Consider replacing it with lazarus-src-0.9.30.2
> instead.

Trying with that latter package:
| $ debuild -b -d
|  dpkg-buildpackage -rfakeroot -d -us -uc -b
| dpkg-buildpackage: source package facturlinex2
| dpkg-buildpackage: source version 2.0.1-1
| dpkg-buildpackage: source changed by Nicolas Lopez de Lerma Aymerich 

|  dpkg-source --before-build facturlinex2-2.0.1
| dpkg-buildpackage: host architecture i386
|  fakeroot debian/rules clean
| dh_testdir
| dh_testroot
| rm -f build-stamp install-stamp
| rm -f Fuentes/Bin/*
| dh_clean
|  debian/rules build
| dh_testdir
| touch build-stamp
|  fakeroot debian/rules binary
| dh_testdir
| dh_testroot
| dh_prep
| /usr/bin/fpc -MDelphi -Sgi -O1 -gl -vewnhi -l 
-Fu/usr/lib/lazarus/0.9.30/lcl/units/i386-linux/ 
-Fu/usr/lib/lazarus/0.9.30/lcl/units/i386-linux/gtk2/ -Fu./Fuentes/powerpdf/ 
-FU./Fuentes/Bin/ -FE./Fuentes/Bin/ -dLAZ_POWERPDF -dLCL -dLCLgtk2 
./Fuentes/powerpdf/PowerPdf.pas
| Hint: Start of reading config file /etc/fpc.cfg
| Hint: End of reading config file /etc/fpc.cfg
| Free Pascal Compiler version 2.6.0-1 [2012/01/13] for i386
| Copyright (c) 1993-2011 by Florian Klaempfl and others
| Target OS: Linux for i386
| Compiling ./Fuentes/powerpdf/PowerPdf.pas
| Compiling ./Fuentes/powerpdf/PReport.pas
| Fatal: Can't find unit LCLType used by PReport
| Fatal: Compilation aborted
| Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not 
specify a source file to be compiled)
| make: *** [install] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
2
| debuild: fatal error at line 1350:
| dpkg-buildpackage -rfakeroot -d -us -uc -b failed

Candidate for a removal?
 
Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#633393: galan must use shlibs for the recommends

[Cyril Brulebois]

Adrian Bunk  (09/07/2011):
> Package: galan
> Version: 0.3.0+beta4-2.1
> Severity: serious
> 
> <--  snip  -->
> 
> $ grep ^Recommends: debian/control 
> Recommends: ladspa-plugin, libasound2, esound, libesd0, libvorbis0a, 
> libvorbisfile3, libgl1-mesa-swx11, libglu1-mesa, libgtkgl2.0-1, jack-rack, 
> jackd, libjack0, fftw2
> $ 
> 
> <--  snip  -->
> 
> This is just plain wrong, please generate these through shlibs.

Oh yeah, and the packaging is like oh-so-old, with DH_COMPAT=3 and the
like. I think it would be worth investigating the removal of this
package.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Description-less packages file

[Cyril Brulebois]

Philipp Kern  (08/02/2012):
> On Wed, Feb 08, 2012 at 08:30:47AM +0100, Andreas Tille wrote:
> > Regarding squeeze:  Could somebody give some reasons for refusing an
> > additional field in the Packages files?  It is hard to cope with "it
> > is unlikely".  A yes or no would be more helpful to find a
> > reasonable decision for the UDD importer.
> 
> It possibly breaks stuff.  Like tasksel[1].  Sadly there are many
> implicit assumptions in a release, hence we're not switching on any
> new features in Packages/Sources/Contents post-release.

One recent example of stable-related collateral damage is the addition
of InRelease files. And even that shouldn't have happened©®™ given
squeeze was supposed not to be affected! We ended up having to perform
stable updates to cope with it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

ISE on qa.d.o through rmadison

[Cyril Brulebois]

Hi,

as requested in the following message:
| k...@bowmore:~$ rmadison xserver-xorg-video-glide
| 
| 
| 500 Internal Server Error
| 
| Internal Server Error
| The server encountered an internal error or
| misconfiguration and was unable to complete
| your request.
| Please contact the server administrator,
|  debian-qa@lists.debian.org and inform them of the time the error occurred,
| and anything you might have done that may have
| caused the error.
| More information about this error may be available
| in the server error log.
| 
| Apache Server at qa.debian.org Port 80
| 
| k...@bowmore:~$ date -R
| Tue, 09 Nov 2010 22:35:46 +0100

Please Cc me, I'm no longer subscribed.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Removing mlview?

[Cyril Brulebois]

Hi,

I just came across mlview which seems to be a candidate for removal:
#500940 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500940#10
in particular. It's been almost 2 years now, time to get rid of it
entirely?

(Cc welcome if you want me to read your replies.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: gob2_2.0.16-3_amd64.changes ACCEPTED

[Cyril Brulebois]

Mark Brown  (28/04/2010):
> I'm orphaning the package.  What part of that makes you think I'm
> going to be interested in fixing random lintian warnings?

Random lintian warnings (and errors) like the ones you're generating
by orphaning the package in an improper manner? If you're not used to
that process, you probably should have even more reasons to use that
tool and fix those things.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#576240: say what ITP means right there in the report

[Cyril Brulebois]

Holger Levsen  (08/04/2010):
> I believe our webpages should be self sustained and understandable
> without external parties.

Like by typing “ITP” in the “search” box on http://www.debian.org/
which leads to http://www.debian.org/devel/wnpp/index.*.html pages?
That makes me think we're performing quite good here.

One might object that Accepted-Languages might get higher priority or
might even be used to limit the results. But that's another topic.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#496490: Please investigate removal of adolc

[Cyril Brulebois]

Barak A. Pearlmutter  (15/12/2009):
> > even though Neil Williams tried to give him a hand.
> 
> He did?  I'd be happy to have a co-maintainer.

He did: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496490#8

Mraw,
KiBi.


signature.asc
Description: Digital signature

Please investigate removal of adolc

[Cyril Brulebois]

Hi,

please investigate removal of adolc, which has been RC-buggy since
August 2008 (#496490), without any single reply from the maintainer,
even though Neil Williams tried to give him a hand.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Please investigate removal of basilisk2

[Cyril Brulebois]

Hi,

basilisk2 was already spotted once as being in a very bad shape[1]. It
is currently only built on a few architectures[2], and has been
FTBFSing for 1.5 year[3]. Riky is also wondering[4].

 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;bug=309501
 2. https://buildd.debian.org/status/package.php?suite=unstable&p=basilisk2
 3. http://bugs.debian.org/483277
 4. http://bugs.debian.org/524155

Please investigate its removal.

(No need to Cc me, I read -qa@, thanks.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#559626: experimental buildd link possibly broken?

[Cyril Brulebois]

Jay Berkenbilt  (05/12/2009):
> For the last week or more, the "exp" buildd link at
> packages.qa.debian.org doesn't work since experimental.debian.net is
> not responding.  I don't know if experimental.debian.net is just
> temporarily down or whether there has been some change to the
> infrastructure that has not been reflected in the code that powers
> packages.qa.debian.org.

http://lists.debian.org/debian-wb-team/2009/12/msg2.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Time for a new maintainer for Auctex?

[Cyril Brulebois]

David Bremner  (13/08/2009):
> I guess two of the NMUs are internationalization issues, so I don't
> really how indicative they are of lack of maintanence.  On the other
> hand, the package has 22 lintian warnings, and sits at policy 3.7.2,
> which makes it likely to have some RC bugs.

Don't talk about possible RC bugs. Open them.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#541013: O: at -- Delayed job execution and batch processing

[Cyril Brulebois]

Alexander Reichle-Schmehl  (11/08/2009):
> Anyone interested in co maintaining that?  Upstream is non existent,
> there are quite some bugs in the bts and the package is priority
> standard.  Doesn't sound like a package someone should adopt all alone.

If time permits, yes.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Lucas Nussbaum  (05/08/2009):
> Actually, the counter-argument is that we don't want to make it
> *harder* to do a QA upload. Currently, it's "apt-get source ; make
> change ; dput". If we used a VCS, we would have to create: - a process
> to auto-import orphaned packages into the VCS - procedures to commit
> changes to VCS before doing QA uploads
> 
> I don't have numbers about that, but a fair share of QA uploads are done
> by one- or two-timers, even a majority of uploads is done by QA folks.
> We don't want to make it harder for those one-timers to improve the
> status of orphaned packages.

Just to clarify, I meant moving collab-maint/foo.git to e.g.
collab-maint/orphaned/foo.git to make it obvious to folks browsing the
repository that it's orphaned, while retaining the history. Not
suggesting to put everything under $VCS. Sorry for the bad phrasing.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Stefano Zacchiroli  (02/08/2009):
> This seems to be a recurring proposal. I raised it 1 year ago (IIRC,
> sorry I'm too lazy right now to look the reference) and Raphael
> Hertzog pointed out to me that way before he advanced the same
> proposal.

Sorry for that, missed it/them.

> The counter-argument I received 1 year ago is that we do not want to
> make any easier to "maintain" orphaned packages, e.g., via QA uploads.
> While I somehow understand that point of view, I still consider the
> proposal a good idea, mainly because it technically facilitates
> resurrecting the packages for the future maintainer.

Well, orphaning something because one is running out of time, and
because some packages need a lot of attention is I guess a valid
situation (hint: see the blender thread on dd@). I would personally hate
that someone has to start the packaging and the patching from scratch.

Anyway, it's probably too hot a topic for me. I guess I'll just shut up.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Thomas Viehmann  (02/08/2009):
> The packages are still on archive.d.o if they ever made a release (and
> soon more finely grained on snapshots). The typical package did not
> get nontrivial updates in a release cycle before it was removed, so
> the version on archive.d.o will be just as good as the version you
> want to stuff into experimental.

I can think of three packages (maintained until now by Pabs and myself)
that may deserve being kept "somewhere" as they currently are, so that
people can still jump in and not start again from scratch. I believe the
current packages could be better than the last released ones (read: the
ones one could find on archive.debian.org). I guess that having that
kind of packages still available on snapshot.debian.org might be a bit
more useful than only archive.debian.org; but well, VCSes might still be
alive for some time, and that might be enough. Not everyone's using
VCSes anyway.

Speaking of which it might be nice to have some area in collab-maint's
VCSes where to put orphaned (and even removed) packages, so that it's
cleared they're kind-of-dropped.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debconf QA BOF summary / handling of orphaned packages

[Cyril Brulebois]

Lucas Nussbaum  (31/07/2009):
> On 30/07/09 at 17:16 +0200, Sven Hoexter wrote:
> > IMHO it would be nice to aim at a release without oraphaned packages.
> 
> That's totally unrealistic.

Indeed. Quick examples which may come to mind:
 - xulrunner and all gecko-based pakages.
 - webkit and all depending packages.

Ha!

(Looks like people got interested lately, but you get the idea.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#485538: xcb: FTBFS: Using imake without Build-Depends on xutils-dev

[Cyril Brulebois]

tag 485538 patch
thanks

Daniel Schepler  (09/06/2008):
> Package: xcb
> Version: 2.4-4
> Severity: important
> User: schep...@debian.org
> Usertags: ftbfs-xutils

Here's the patch for my NMU.

-qa@, probably a package that could/should be removed.

Mraw,
KiBi.
diff -u xcb-2.4/debian/changelog xcb-2.4/debian/changelog
--- xcb-2.4/debian/changelog
+++ xcb-2.4/debian/changelog
@@ -1,3 +1,14 @@
+xcb (2.4-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS by replacing xutils with xutils-dev in Build-Depends
+(Closes: #485538).
+  * Fix FTBFS by using “rm -f Makefile” instead of “rm Makefile” in the
+clean target (Closes: #533965).
+  * debian/control: Move the Homepage where it belongs.
+
+ -- Cyril Brulebois   Sun, 19 Jul 2009 03:30:22 +0200
+
 xcb (2.4-4) unstable; urgency=low
 
   * Applied patch from CVS (http://software.schmorp.de/)
diff -u xcb-2.4/debian/control xcb-2.4/debian/control
--- xcb-2.4/debian/control
+++ xcb-2.4/debian/control
@@ -2,8 +2,9 @@
 Section: x11
 Priority: optional
 Maintainer: Michael Schiansky 
-Build-Depends: debhelper (>> 3.0.0), xutils (>= 4.0.1), libxaw7-dev | libxaw-dev 
+Build-Depends: debhelper (>> 3.0.0), xutils-dev, libxaw7-dev | libxaw-dev 
 Standards-Version: 3.6.1
+Homepage: http://www.goof.com/pcg/marc/xcb.html
 
 Package: xcb
 Architecture: any
@@ -17,2 +17,0 @@
- Homepage: http://www.goof.com/pcg/marc/xcb.html
-
diff -u xcb-2.4/debian/rules xcb-2.4/debian/rules
--- xcb-2.4/debian/rules
+++ xcb-2.4/debian/rules
@@ -30,7 +30,7 @@
 
 	([ ! -f Makefile ] && xmkmf -a ||true)
 	-$(MAKE) clean
-	rm Makefile
+	rm -f Makefile
 	rm -f debian/xcb.1x
 
 	dh_clean


signature.asc
Description: Digital signature

Re: Bug#534281: nosql: uninstallable on ia64, alpha, GNU/kFreeBSD

[Cyril Brulebois]

Jan Hauke Rahm  (30/06/2009):
> That would be an idea, low popcon and so on... I can provide a (hopefully)
> fixed package, tough. If anyone of the QA team is willing to upload it, find
> it here:
> 
> http://downloads.jhr-online.de/qa/

Got uploaded, and built properly, thanks!

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534281: nosql: uninstallable on ia64, alpha, GNU/kFreeBSD

[Cyril Brulebois]

Petr Salinger  (23/06/2009):
> Package: nosql
> Severity: serious
> Version: 4.0.14-4
> User: glibc-bsd-de...@lists.alioth.debian.org
> Usertags: kfreebsd
>
> Hi,
>
> current version have hardcoded dependency on libc
> as Depends: libc6 (>= 2.2.3-1).
> This cannot be satisfied on some architectures.
> It have been introduced in
>
>  nosql  (4.0.14-2) unstable; urgency=low
>* add dependency to libc (warning from lintian)
>
> Please at least drop this dependency or generate
> correct one during build using i.e. dh_shlibdeps.

Hi,

cc'ing -qa@ because I won't be fixing the whole package, and it really
needs it. I think it'd be a nice exercise for a wannabe packager to make
it use debhelper instead of that broken homebrew stuff.

Hint: one needs to get rid of debian/substvars, at the very least.

Another idea might be to get rid of the package itself, but I won't be
judging that here.

Thanks for your time.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Debian Science taking over cimg-dev?

[Cyril Brulebois]

Andreas Tille  (29/05/2009):
> I realised that cimg-dev package was not updated since nearly two
> days.

OH MY! :D

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: debian/watch sf redirector docs ?

[Cyril Brulebois]

Olivier Berger  (12/05/2009):
> Le lundi 11 mai 2009 à 12:33 +, Bart Martens a écrit :
> > Not that I know of.  DD's can read the source code.
> 
> And non-DDs ? ... something available somewhere in SVN on alioth by any
> chance ?

http://svn.debian.org/viewsvn/qa/trunk/wml/watch/

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: debian/watch sf redirector docs ?

[Cyril Brulebois]

Olivier Berger  (11/05/2009):
> Hi.

o<

> Is there any docs about the "Debian qa sf redirector" that can be used
> in debian/watch (apart from man uscan) ?
> 
> I'm looking for a way to state which "package" must be selected...
> 
> For instance, for mantis, using
> "http://sf.net/mantisbt/mantisbt-(.+)\.tar\.gz" would report versions
> like 1.2.0a3 where as one would like to select only versions among the
> ones available in package "mantis-stable" as listed in
> http://sourceforge.net/project/showfiles.php?group_id=14963

not sure it's feasible. As a quick workaround, since the -devel ones
seem to always have some letters (a for alpha, or rc), you could
restrict your pattern to only match digits and dots:
| -(cy...@talisker pts/3)-(/tmp/mantis-1.1.6+dfsg)
| $ cat debian/watch 
| version=3
| opts="dversionmangle=s/\+dfsg//" \
| http://sf.net/mantisbt/mantisbt-([0-9.]+)\.tar\.gz
| -(cy...@talisker pts/3)-(/tmp/mantis-1.1.6+dfsg)
| $ uscan --report-status
| Processing watchfile line for package mantis...
| Newest version on remote site is 1.1.7, local version is 1.1.6+dfsg
|  (mangled local version number 1.1.6)
| mantis: Newer version (1.1.7) available on remote site:
|   
http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/m/ma/mantisbt/mantisbt-1.1.7.tar.gz
|   (local version is 1.1.6+dfsg, mangled local version number 1.1.6)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bugs tagged edos-relation-warning

[Cyril Brulebois]

Holger Levsen  (18/04/2009):
> I wonder why you filed these bugs with severity "normal":
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-relation-warning;users=trei...@debian.org

Looking at this list:
 - #468423 and #468425 got minor, rationale was given.
 - #404339 is normal, but the same rationale would apply.
 - #285040 still applies, but the Policy (now 5.6.12) still says should.
 - #518400 probably will go away, but I'd say that providing an illegal
   package name might not do as much harm as a buggy version number, so
   it probably wouldn't deserver more than important.

> I'd expect that illegal package names and version numbers could break
> some tools, so I would have filed them as important as least, also
> since very few packages are affected.

Those tools should raise appropriate errors, not just “break”.

> Can you explain your reasoning? Is it because you haven't experienced
> any breakage?

Look at the actual bugreports?

(Arguing normal vs. important looks like time loss to me, but YMMV.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#523282: Re: Bug#523282: qa.debian.org: Email address in package overview is case-specific

[Cyril Brulebois]

jeffrey.ratcli...@gmail.com  (16/04/2009):
> What about some possibility for the QA software to recognise multiple
> email addresses as belonging to the same person? Every DD that
> switches to using a @debian.org address must have this irritation.

login=Surname usually helps.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Raphael Geissert  (28/01/2009):
> So, what exactly should be checked? and what's the status of this
> proposal?

Dunno for others, but I for one am busy processing NMs and fixing RC
bugs, I don't think any immediate action is needed at this point.

(But moving on would be appropriate once lenny is out, AFAICT.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Cyril Brulebois  (21/12/2008):
> OK, since it doesn't look like useless, I'll look into it and report
> back in a moment.

Attached, a list (103 source packages) based on the contents of
gluck:/org/lintian.debian.org/laboratory/source/*/debfiles/shlibs.local

(generated by the Makefile in ~kibi/shlibs-check.git, on gluck.)

As mentioned by Raphaël on IRC: a number of those are probably due to a
previous limitation of dpkg WRT generation of intradependencies
(binaries from the same source package).

Mraw,
KiBi.
adns:
=
libadns 1 libadns1


adolc:
==
libadolc 0 libadolc0


barnowl:

libzephyr 3 libzephyr3


blas:
=
libblas 3gf libblas3gf | libblas.so.3gf | libatlas3gf-base


cdebconf:
=
libdebconf 1.0 libdebconf1


console-tools:
==
libconsole  0   libconsole (= ${Source-Version})
libcfont0   libconsole (= ${Source-Version})
libctutils  0   libconsole (= ${Source-Version})


control-center:
===
libgnome-window-settings 1 libgnome-window-settings1 (>= 1:2.17.5)


courierpassd:
=
libcourierauth 0 courier-authlib (>= 0.58-3)


courierpasswd:
==
libcourierauth 0 courier-authlib (>= 0.58-3)


courieruserinfo:

libcourierauth 0 courier-authlib (>= 0.58-3)


diagnostics:

libdiagnostics 0 libdiagnostics0


e2fsprogs:
==
libext2fs   2
libe2p  2
libuuid 1
libcom_err  2
libss   2
libblkid1


eb:
===
libeb 12 libeb12


elmo:
=
# Dpkg shlibs override file
#
# Entries in this file will override all others, only use if you
# are really sure that is what you want!
# 
# For more information see the dpkg-shlibdeps manual page. 
#
# The format used is:
# 
#
# Example:
#   libfoo 1libfoo1 (>= 1.0-1)
#
libncurses  libncurses.so.5 libncurses5 (>= 5.3.20030719-1)


festival:
=
libestools 1.2 libestools1.2 (>= 1:1.2.96~beta-2)


freecell-solver:

libfreecell-solver 0 libfreecell-solver0 (>= 2.0.0)


ftplib:
===
# Make ftplib-dev depend on the exact version (Policy section 8.5).
# Other packages will use the shlibs file generated by dh_makeshlibs.
libftp  3   ftplib3 (= ${Source-Version})


gail:
=
libgailutil 18 libgail18 (>= 1.9.1)


gatos:
==
libgatos 0 libgatos0 (>= 0.0.5)


geoip:
==
libgeoip1 1.4.4 libgeoip1 (>> 1.4.4-0), libgeoip1 (<< 1.4.4-99)


glew:
=
libGLEW 1.5 libglew1.5


gnome-randr-applet:
===
libXrandr   r   xlibs (>> 4.3.0)


gnucash:

libgncgnome 0
libgw-core-utils 0
libcore-utils 0
libgw-gnc 0
libgncmodule 0
libgnc-app-file-gnome 0
libgnc-business-ledger 0
libgncmod-app-file 0
libgncmod-app-utils 0
libgncmod-backend-file 0
libgncmod-binary-import 0
libgncmod-business-backend-file 0
libgncmod-business-core 0
libgncmod-business-gnome 0
libgncmod-business-utils 0
libgncmod-calculation 0
libgncmod-dialog-tax-table 0
libgncmod-engine 0
libgncmod-generic-import 0
libgncmod-gnome-search 0
libgncmod-gnome-utils 0
libgncmod-ledger-core 0
libgncmod-locale-reports-us 0
libgncmod-network-utils 0
libgncmod-ofx 0
libgncmod-qif-import 0
libgncmod-register-core 0
libgncmod-register-gnome 0
libgncmod-report-gnome 0
libgncmod-report-system 0
libgncmod-standard-reports 0
libgncmod-stylesheets 0
libgncmod-tax-us 0
libgncmod-utility-reports 0
libgw-app-file 0
libgw-app-utils 0
libgw-binary-import 0
libgw-business-core 0
libgw-business-gnome 0
libgw-dialog-tax-table 0
libgw-engine 0
libgw-gnc-module 0
libgw-gnome-search 0
libgw-gnome-utils 0
libgw-kvp 0
libgw-register-core 0
libgw-report-gnome 0


gsnmp:
==
libgsnmp0 0.1.0 libgsnmp0 (>> 0.1.0-0), libgsnmp0 (<< 0.1.0-99)


guile-gnome-platform:
=
libguile-gnome-gobject-0 0 guile-gnome0-glib


hotkeys:

libdb2  2   libdb2 (>= 2.7.7)
libxml2 2   libxml2 (>= 2.2.8)


iaxclient:
==
libspeex 1 libspeex1 (>= 1.1.10-1)


iceape:
===
libnss3 0d libnss3-0d (>= 3.11.5-1)
libsmime3 0d libnss3-0d (>= 3.11.5-1)
libsoftokn3 0d libnss3-0d (>= 3.11.5-1)
libssl3 0d libnss3-0d (>= 3.11.5-1)


im-sdk:
===
libiiimcf 3 libiiimcf3 (>= 12.3)
libiiimp 1 libiiimp1 (>= 12.3)


itcl3:
==
libitcl3.2  1   
libitk3.2   1   


itcl3.1:

libitcl3.1  1   
libitk3.1   1   


jack-audio-connection-kit:
==
libjack 0 libjack0 (= ${Source-Version})


kdepim:
===
libakregatorprivate 0
libkmailprivate 0
libknodecommon 0


keynote:

libkeynote 0 libkeynote0 (>> 2.3-0)


kmymoney2-plugin-aqbanking:
===
libkmm_mymoney 0 kmymoney2 (>= 0.9.2)
libkmm_plugin 0 kmymoney2 (>= 0.9.2)


lam:

liblam 4 liblam4
liblam++ 4 liblam4
liblamio 4 liblam4


lapack:
===
liblapack 3gf liblapack3gf | liblapack.so.3gf | libatlas3gf-base


leptonlib:
==
libleptonlib 1.36 le

Re: Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Loïc Minier  (21/12/2008):
> I'm all for it; over time I came across a bunch of broken packages
> due to shlibs.local files, or simply with the risk of these files
> bitrotting and causing issues later.

OK, since it doesn't look like useless, I'll look into it and report
back in a moment.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Hello,

context: debian/shlibs.local can be used to work around broken shlibs
files (Policy §8.6.5). Bugs are supposed to be filed, then fixed, and
shlibs.local files should then disappear.

I'm wondering whether it might be a good idea to track those in source
packages, so as to make sure bugs got filed, and that those files go
away. Having a fixed shlibs file would be profitable to all packages
linking against this library, rather than having a single package
getting its dependencies properly, through its shlibs.local file.

Do you think it'd be worse the effort? (Didn't check the amount of such
files yet, still performing my first AM steps.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Suggested removal: xwhois [was: Bug#507944: xwhois: segfaults on start in get_servers()]

[Cyril Brulebois]

Submitter put back in recipient list…

Steve Cotton <[EMAIL PROTECTED]> (06/12/2008):
> xwhois.h:
> #define BUFSIZE 1024
> 
> struct serverent {
>   char *name;
>   char *comment;
> } servers[256];
> 
> 
> get_servers():
>   /*
>* Set all struct members to NULL.
>*/
> 
>   for (i=0 ; i < BUFSIZE ; i++)
> {
>   servers[i].name = servers[i].comment = NULL;
> }
> 
> After setting BUFSIZE to 256, the app started OK.
> 
> But pressing "Scan" locked the app up.  I fired up Wireshark, 90
> seconds later it's still sending out SYN packets to servers that
> don't respond.  After a couple of minutes, it displayed the
> results.  They're mostly along the lines of "server did not
> respond", "query format not supported", "this server only has the
> .FOO and .BAR TLDs".
> 
> Popcon is 63 installs, 14 votes, and it has a dependency on GTK-1.2.
> Personally, I think this isn't one to fix.

Agreed, looks like a candidate for removal from testing (-release@ Cc'd
for that), and maybe even from unstable (-qa@ Cc'd for that).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#507288: mails to $pkg@p.d.o should also be send to Uploaders:

[Cyril Brulebois]

Holger Levsen <[EMAIL PROTECTED]> (30/11/2008):
> > Why? Uploaders are probably subscribed to the PTS, *or* the
> > maintainer is a mailing list.
> 
> not always.

dpkg-reconfigure $user, then. Not a PTS bug, at least seen from here.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Orphaned packages that were not part of etch, take 2

[Cyril Brulebois]

Christoph Berg <[EMAIL PROTECTED]> (01/11/2008):
> Except for qtparted the popcon numbers are all pretty low.

I just had a very quick look upstream, and last activity seems to have
happened in 2004.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#501660: Package list for my login is incomplete

[Cyril Brulebois]

Daniel Leidert <[EMAIL PROTECTED]> (09/10/2008):
> [1] http://qa.debian.org/[EMAIL PROTECTED]&comaint=yes

See , it very much
looks like something's wrong, given the “Packages overview for <>”.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#500744: qa.debian.org: no more popcon graph since move of people.debian.org

[Cyril Brulebois]

Damien Raude-Morvan <[EMAIL PROTECTED]> (01/10/2008):
> Since move of p.d.o to a new machine [1], popcon graph are "404 Not
> Found" [2].
> 
> Those reports was hosted on Ian "igloo" Lynagh account on p.d.o for a
> long time and I would like to thanks him for this service.
> 
> But, IMHO, thoses graphs should be directly hosted on qa.debian.org
> machine to avoid this kind of unavailability and to keep things
> related together.

Hi Damien,

see Bill's message in #500310; at least people should be aware already.
;-)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: How to implement QA web pages for a certain set of packages

[Cyril Brulebois]

Paul Wise <[EMAIL PROTECTED]> (25/09/2008):
> Not entirely sure, but I think in the QA CVS repo:
> http://cvs.debian.org/wml/developer.wml?root=qa&view=markup

I guess it could be pruned? (Assuming migration to SVN kept history.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: adopting maxima

[Cyril Brulebois]

David Bremner <[EMAIL PROTECTED]> (27/07/2008):
> Riku Voipio kindly uploaded my NMU, so there is no reason to rush the
> adoption.  If Camm does not veto the idea in the next few (2? 3? 4?)
> weeks, I propose take over as maintainer (along with anyone who wants
> to help) under the umbrella of debian-science team.

You could still keep the previous maintainer in Uploaders for some time.
I think it's a quite usual practice when you're still waiting for an
answer from the previous maintainer.

Mraw,
KiBi.


signature.asc
Description: Digital signature

[DONE] Re: RFS: cmatrix (updated package, QA upload)

[Cyril Brulebois]

Sandro Tosi <[EMAIL PROTECTED]> (26/07/2008):
> I am looking for a sponsor for the new version 1.2a-3
> (QA upload) of package "cmatrix".

Uploaded, thanks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: RFS: kino (NMU) fixes 2 goal for lenny bashism and piuparts warning

[Cyril Brulebois]

Francesco Namuri <[EMAIL PROTECTED]> (20/07/2008):
> The upload would fix these bugs: 455021, 489619
>
> I would be glad if someone uploaded this package for me.

As former NM, I'd advise Cc-ing the RFS to the package maintainers. Some
will veto the NMU, and it's better if they do so in reply to the RFS
than only on the bugs, since that can lead to miscoordination. Some will
ACK the NMU in advance, which means that possible sponsors might be more
enclined to upload the NMU. Some will even sponsor the NMU themselves.

In piem's case, I've been sponsoring his own packages since he had GPG
troubles. AFAICT, that's being resolved (he got a new key signed last
week), so I'd suggest coordinating with him before uploading.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#490683: qa.debian.org: package ktechlab has no new bugs

[Cyril Brulebois]

Georges Khaznadar <[EMAIL PROTECTED]> (13/07/2008):
> Here are the two wrong assertions:
> 
> 1- ktechlab (source, i386, alpha, amd64, arm, armel, hppa, ia64, mips, 
>mipsel, powerpc, s390, sparc) has new bugs!
> 
> The link points to 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=ktechlab&sev-inc=critical&sev-inc=grave&sev-inc=serious
> which contains a reference to bug #474842, which is now resolved since 
> the 10th June.

Not on every arch:
$ rmadison -s unstable ktechlab
  ktechlab |  0.3-8 |  unstable | sparc
  ktechlab |  0.3-9 |  unstable | source, alpha, amd64, arm, armel, 
hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390

> 2- Updating ktechlab introduces new bugs: #474842
> 
> This is wrong again (same reason: updating ktechlab from version 0.3-5
> to 0.3-9 closes the bug, which was found with version 0.3-8, and fixed
> in version 0.3-9, as correctly stated in the page 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474842)

Same reason as above, the bug isn't yet fixed in 0.3-9, so forcing it
into testing would introduce a new bug.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: RFS: goal-dash NMU's

[Cyril Brulebois]

Vincent Bernat <[EMAIL PROTECTED]> (03/07/2008):
> I will upload them as soon as ftp-master is back.

Just in case, you can always use the DELAYED/* queues on gluck.

Mraw,
KiBi.


signature.asc
Description: Digital signature

[PTS] Tiny glitch (extra space ) on “All bugs” count

[Cyril Brulebois]

Hi,

on the right side of the PTS pages, one can notice there's a space
between “All bugs (graph)” and the following “:”. It looks like it's due
to the following lines in the XSL file:
[ ./pts/www/xsl/pts.xsl ]
331   )
332 

which leads to a considered-meaningful space at least under konqueror
and iceweasel. For those wondering, the “:” is added through CSS, see
[ ./wml/revamp.css ]
130 td.labelcell:after {
131 content: ":";
132 }

A solution would be to put  right after the closing “)”, but ISTR
there's some way to specify in XSLT that one should collapse all
spaces, or something like, which would be nicer and wouldn't break the
logical structure of the tags in the XSL file.

(I felt it was OK to mention that on the list only, but I can also open
a bug if that's preferred.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: RFS: QA Upload: eterm-themes -- Themes for Eterm, the Enlightened Terminal Emulator

[Cyril Brulebois]

On 29/03/2008, Laszlo Boszormenyi wrote:
> First, was the debhelper compatibility upgrade necessary? I think
> leaving it at level 4 makes backporting easier.

$ rmadison debhelper
 debhelper | 4.2.32 | oldstable | source, all
 debhelper | 5.0.42 | etch-m68k | source, all
 debhelper | 5.0.42 |stable | source, all
 debhelper |  6.0.5 |   testing | source, all
 debhelper | 6.0.10 |  unstable | source, all

So, unless you're backporting for oldstable, that's quite safe.

-- 
Cyril Brulebois


pgp79HWW8qJ1K.pgp
Description: PGP signature

Re: Where to find manpages to work on?

[Cyril Brulebois]

Hi all,

David is looking forward to helping write a manpage for a program,
wondering which one he could choose, and how to write it. I'm
answering that we're on an English list, poiting to missing manpages,
and to perlpod examples. Finally, I'm pointing to the French l10n
list.

Cheers,

-- 
Cyril Brulebois


On 26/02/2008, David Montanes wrote:
> Bonsoir,

Bonsoir,

> je vous écris en tant que jeune étudiant en Master informatique dans
> le cadre d'un projet de Logiciel Libre.

cette liste est anglophone, merci de bien vouloir rédiger un message
en anglais la prochaine fois. ;-)

> Mon but est d'écrire par exemple une page Man pour un des logiciel
> dont vous disposez et de vous la soumettre. Ainsi pour ce faire je
> voudrais bien savoir en quel langage cette page doit_etre programmée
> et notamment si vous avez une en exemple de page qui
> peut m'aider en exemple.

On peut obtenir une liste en se rendant sur [1], puis en choissant
« Packages which need man pages » [2]. Pour les exemples, on peut en
trouver dans plein de paquets, par exemple libpano13. J'utilise pour
ma part la syntaxe perlpod, et pod2man pour convertir les fichiers en
des fichiers *roff. On peut ensuite les lire avec « man -l fichier.1 »
sans avoir à les installer dans /usr/share/man/….

 1. http://qa.debian.org/
 2. http://qa.debian.org/man-pages.html

Cf. debian/manpages/*.pod du paquet libpano13 (disponible dans
unstable et testing) pour des exemples, et debian/rules, sous le
commentaire « Build manpages for each binary » pour un exemple de
commande pod2man pour les générer.

Une page de manuel est en général rédigée en anglais, mais on peut
aussi vouloir contacter [EMAIL PROTECTED] pour ce
qui est des traductions.

Cordialement,

-- 
Cyril Brulebois


pgpz69IHQcCbV.pgp
Description: PGP signature

Bug#443189: PTS: 443189: please use jeroen's buildd pages

[Cyril Brulebois]

On 07/02/2008, Stefano Zacchiroli wrote:
> URL please 

Random examples:

http://buildd.debian.org/~jeroen/status/package.php?p=ecj
http://people.debian.org/~igloo/status.php?packages=ecj

notice the “for” column, the links to the build logs, the display of
the failed builds, P-a-s entries (if any, I don't have examples by
hand), etc.

> If not, please compare the informative content of what you are
> proposing with igloo's and give us a hint about whether yours can
> replace igloo's.

the shortcoming I see is that Jeroen's pages only display a package at
a time, while igloo's can display all packages of a given maintainer.
But I really love Jeroen's.

Cheers,

-- 
Cyril Brulebois


pgp7ge3sTBnhd.pgp
Description: PGP signature

Bug#463949: Buildd logs (more) "can't find package rott_ in the database."

[Cyril Brulebois]

(with neither PTS or DDPO hat on, just a porter passing by.)

On 04/02/2008, Fabian Greffrath wrote:
> Hello,

Hi,

> On the PTS page for this package [1] there is a link called '(more)'
> to the right of 'Buildd logs'. The link points to the following
> site, which tells me that it "can't find package rott_ in the
> database.": http://experimental.debian.net/build.php?pkg=rott

because your package wasn't ever uploaded to experimental, or to
backports, hence no log in the experimental.ftbfs.de database.

Note that kfreebsd-* and hurd-i386 used to be referenced there as
well, and armel recently, and that they moved to debian-ports some
weeks (months already?) ago.

I guess that tracking the “this package is in that wanna-build
database would be a bit tedious”, and that it doesn't harm very much
to keep all links available. Maybe a “subtitle” might be added to
distinguish “unstable”, “experimental+bpo”, and “ports”, so that it
gets a bit more clear?

> however, on my maintainer QA page [2] there is a similar link called
> 'Buildd' in the Buildd part of the table for the rott package. This
> link points to the following site, which indeed lists all available
> buildd logs for the rott package:
> http://buildd.debian.org/build.php?pkg=rott

But only official ones, for unstable.

> Additionally, on the QA page there is another link called 'More'
> just beneath the 'Buildd' link. This does however not point to the
> same site as the 'more' link from the PTS page.

I guess that part can be adjusted, as said above.

> Instead it points to the following site, which contains some useful
> information about the package status on the different architectures:
> http://people.debian.org/~igloo/status.php?packages=rott

> This page is very interesting and I suggest adding it to the PTS
> page. But then, please do not call it 'more' again... ;)

Indeed, it's a quite good overview of build states.

Cheers,

-- 
Cyril Brulebois


pgpwPIPG45NKF.pgp
Description: PGP signature

Re: RFS: QA Uploads

[Cyril Brulebois]

On 26/01/2008, Frank Lichtenheld wrote:
> On Thu, Jan 24, 2008 at 09:01:22PM -0500, Barry deFreese wrote:
> > http://mentors.debian.net/debian/pool/main/l/libapache2-mod-xmlrpc2/libapache2-mod-xmlrpc2_2.2.1-3.dsc
> > Fairly intrusive but makes it build and fixes 2 important bugs.
> 
> debdiff between the old and new binary:
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: {+apache2.2-common,+} libc6 (>= [-2.3.6-6), libdb4.3 (>= 4.3.28-1), 
> libexpat1 (>= 1.95.8), libruby1.8 (>= 1.8.4), libxmlrpc-c3, apache2-common 
> (>= 2.0.50)-] {+2.7-1), libuuid1, libxmlrpc-c3+}
> Installed-Size: [-72-] {+124+}
> Maintainer: [-Andres Salomon <[EMAIL PROTECTED]>-] {+Debian QA Group <[EMAIL 
> PROTECTED]>+}
> Version: [-2.2.1-2-] {+2.2.1-3+}
> 
> So the dependencies on libdb4.3, libexpat1, libruby1.8 vanished? Is that
> correct?

At least from a .so point of view:
Symbol diff:

  ./usr/lib/apache2/modules/mod_xmlrpc.so:
@@ -1,13 +1,10 @@
   NEEDED  libxmlrpc.so.3
+  NEEDED  libxmlrpc_util.so.3
   NEEDED  libxmlrpc_xmlparse.so.3
   NEEDED  libxmlrpc_xmltok.so.3
+  NEEDED  libuuid.so.1
   NEEDED  librt.so.1
-  NEEDED  libm.so.6
   NEEDED  libcrypt.so.1
-  NEEDED  libnsl.so.1
   NEEDED  libpthread.so.0
   NEEDED  libdl.so.2
-  NEEDED  libdb-4.3.so
-  NEEDED  libexpat.so.1
   NEEDED  libc.so.6
-  NEEDED  libruby1.8.so.1.8

Since the previous (-2) revision can't be rebuilt (FTBFS), I only
applied the CMakeLists.txt diff, and both (the rebuilt one and the
“Barry one”) binaries are the same. Could it be that these NEEDED
dependencies previously came from extra linking and/or from extra Libs
in pkgconfig files (or similar), now moved to Libs.private?

Note that xmlrpc-c is in a strange shape (build states), I'm contacting
seanius through private mail about that.

Cheers,

-- 
Cyril Brulebois


pgpBUZFBDTfcJ.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 11/01/2008, Raphael Geissert wrote:
> There "MUST" be something wrong with the package then, how is that
> i386's and amd64's md5sum are exactly the same?

I don't see this that way. There *might* be a problem in your script or
so.

,---[ let's check ]---
| [EMAIL PROTECTED]:/tmp/grub$ wget -q 
http://ftp.de.debian.org/debian/pool/main/g/grub/grub_0.97-29_i386.deb
| [EMAIL PROTECTED]:/tmp/grub$ wget -q 
http://ftp.de.debian.org/debian/pool/main/g/grub/grub_0.97-29_amd64.deb
| [EMAIL PROTECTED]:/tmp/grub$ for i in amd64 i386; do ar x grub_0.97-29_$i.deb 
control.tar.gz; tar xfz control.tar.gz; mv control control.$i; mv md5sums 
md5sums.$i; rm control.tar.gz; done
| [EMAIL PROTECTED]:/tmp/grub$ diff -u md5sums.* | diffstat 
|  md5sums.i386 |   72 
+--
|  1 file changed, 36 insertions(+), 36 deletions(-)
`---

Note that the i386 package has the following additional Depends line,
compared to the amd64 one.
| +Depends: libc6 (>= 2.5-5), libncurses5 (>= 5.4-5)

I guess your scripts are somehow assuming that if one has an empty
Depends line, the other has an empty line as well, or something similar.

Back to grub: Unfortunately, there's no amd64 log (source upload along
with the built binaries…), but it might be that ${shlibs:Depends}
weren't computed correctly or so, so that the Depends line was left
empty.

Indeed, checking a cowbuilder build log:
| dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}

In an amd64 chroot, looking closer:
| $ file debian/grub/usr/bin/mbchk
| usr/bin/mbchk:ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
for GNU/Linux 2.6.8, statically linked, stripped

That's also the case for the other binaries, so it results apparently
(I'm no grub maintainer at all) correctly in an empty Depends: line.


> Did you notice the "(U)"? ;)

Yes. I actually expected somehow that you could have noticed that it was
about “grub”.

> I'm, again, sorry for those false positives (didn't expect them by
> comparing md5sums of two different architectures).

I'm not blaming because of false positives. I'd expect more common
sense. Either grub is architecture-dependent, being a low-level stuff,
probably written in C (I know, that might sound like a cliché, but…), or
it is just made out of supercowpowered architecture-independent shell
scripts, but then one might wonder a bit. Seen where it belongs in a
boot sequence?

Reviewing such a short list takes some minutes (to compare with the time
you spent on setting up these scripts), using the main measure when it
comes to being “Architecture: all” or “Architecture: any”: its *content*
(but you know that, I've been repeating this from the very beginning).

-- 
Cyril Brulebois


pgpepixF2jE2I.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 11/01/2008, Raphael Geissert wrote:
> Note that this is the raw output of the script, packages which MUST be
> arch all (debian-installer is excluded, because of technical reasons)
> are listed below the list.

*MUST*, ahah.

> And here's the list of packages which after comparing the md5sum files
> show no reason why they aren't arch all:
> 
> Grub Maintainers <[EMAIL PROTECTED]>
>grub

Again, there is a very good reason:
| /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
GNU/Linux 2.6.1, dynamically linked (uses shared libs), stripped

> Camm Maguire <[EMAIL PROTECTED]>
>hol88-library

So, again, *how* do you find it possible to list this package as MUST be
Architecture: all, while it has things like that inside?
| … cut …
| /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB 
relocatable, Intel 80386, version 1 (SYSV), not stripped
| /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB 
relocatable, Intel 80386, version 1 (SYSV), not stripped
| usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB 
relocatable, Intel 80386, version 1 (SYSV), not stripped
| … cut …

> Robert Millan <[EMAIL PROTECTED]>
>grub (U)

Again…

> Masahito Omote <[EMAIL PROTECTED]>
>libuim-data

Sounds reasonable.

> Otavio Salvador <[EMAIL PROTECTED]>
>grub (U)
> Jason Thomas <[EMAIL PROTECTED]>
>grub (U)

Again…

> As usually, feedback is welcome.

Reiterating…

-- 
Cyril Brulebois


pgpeKtkuFhZHz.pgp
Description: PGP signature

Re: RFS: zynaddsubfx

[Cyril Brulebois]

On 09/01/2008, Robert Vogel wrote:
> Couldn't find this link...Is it ok ?

Uploaded already:
| Subject: Accepted zynaddsubfx 2.2.1-4.1 (source i386)

Keeping only lists in To:, list policy blah blah.

-- 
Cyril Brulebois


pgpxH6VuOSzfM.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Michael Biebl wrote:
> Now, adding a Depends on all those 4 binary packages in tracker-dbg
> seems wrong to me. I don't want to force people to install
> tracker-search-tool if they only want to debug tracker.

What about being a bit more subtle and play around with Recommends: (or
maybe even Suggests:)? By using e.g. Recommends: you ensure every
package is installed in the normal/default/whatever_you_call_it case,
but still leave the possibility to the user to only install what s/he
really needs.

Cheers,

-- 
Cyril Brulebois


pgpPoTF1gGbMC.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Colin Watson wrote:
> While the breakage would be obvious in the case of packages containing
> ELF binaries, […]

Not necessarily, one could remember of RC bugs opened for some months
due to arch: all packages containing shared objects, and its maintainer
wondering what was happening on 64-bit architectures, where 32-bit
shared objects were (unsuccessfully) tried to be used.

-- 
Cyril Brulebois


pgpfwRfoIussv.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Pierre Habouzit wrote:
>   Though after a second thought, -dbg should probably not have empty
> Depends line.

After a third thought, I still fail to see what that has to do with
being Architecture: all or any.

-- 
Cyril Brulebois


pgpTQTr7Qidre.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Raphael Geissert wrote:
> Forgot to mention that, based on the binary-amd64 Packages file of the
> main, contrib and non-free sections.

> I didn't check the content of the packages because that's something
> linda/lintian should do

Wondering why, I asked what they were supposed to catch:
20:51:10 [ KiBi] Atomo64: What are linda/lintian supposed to catch?
20:51:49 [ KiBi] That an Architecture: any package rightfully contains 
architecture-dependent data?
20:51:57 [ Atomo64] KiBi: !arch: all packages not containing any arch-dependent 
file

You might have missed the point, trying again: your list contains plenty
of “Architecture: any” packages that are *rightfully* “any” because they
*do* contain architecture-dependant stuff (see e.g. icecc as already
pointed out).

> this is just a simple/quick list of packages and as I said it may
> contain some false positives (although there's usually a reason/bug
> causing the package to be listed).

Maybe there's rather a bug in your process. Instead of speaking of
“plenty of greps”, you might want to expose the code / algorithm you
used.

-- 
Cyril Brulebois


pgpZsXlXzkGjZ.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Raphael Geissert wrote:
> > Your list seems to contain alot of packages that do have a Depends
> > field.
> 
> Like which one? I used a lot of grepping so maybe something was left
> in.

Take any random package, let's say icecc:
$ apt-cache show icecc|grep ^Depends: 
Depends: libc6 (>= 2.6-1), libgcc1 (>= 1:4.2-20070516), libstdc++6 (>= 
4.2-20070516), debconf (>= 0.5) | debconf-2.0, adduser, lsb-base

A quick look at its content should also convince you that having binary
objects under /usr/bin, /usr/lib, /usr/sbin isn't really a reason to ask
for making it become an Architecture: all package…

-- 
Cyril Brulebois


pgpnLpdLvfZDx.pgp
Description: PGP signature

Re: List of packages which should probably be Architecture: all

[Cyril Brulebois]

On 02/01/2008, Raphael Geissert wrote:
> Hello all,

Maw.

> I've written a script which tries to detect packages which should be
> architecture all based on the fact that they don't contain a Depends
> field.  This is usually bug either because of a missing Depends or
> because the package should be Architecture: all.

Hm, what about checking their *content*? What about listing *binary*
packages?

Cheers,

-- 
Cyril Brulebois


pgpUJCSRAnypb.pgp
Description: PGP signature

Re: Feature request for edos.debian.net

[Cyril Brulebois]

On 02/12/2007, Ralf Treinen wrote:
> should be working starting with this night's run (23:40 CET).

Perfect, thanks!

I was wondering how much resources it consumes, and whether it would be
feasible to have an edos run after each dinstall run, so as to keep a
close track of uninstallable packages. From my (very humble) point of
view, that'd help speed up the (automatic) give-backs.

I'm currently testing my scripts in a “real environment” with
kfreebsd-*, although more work is still needed.

Cheers,

-- 
Cyril Brulebois


pgpVWSZBbPr0D.pgp
Description: PGP signature

Re: Feature request for edos.debian.net

[Cyril Brulebois]

On 01/12/2007, Ralf Treinen wrote:
> No problem. You just need the symlink in the filesystem, right?

That's it, right.

> Or do you also wish a html link on the generated html pages?

No thanks, I'll just use the static URL with latest/ to fetch the
updates of the history.xml file, then do some comparisons, and feed
that data into a database tracking the (un)installability of the build
dependencies.

Cheers,

-- 
Cyril Brulebois


pgp8xsGa7Ayi7.pgp
Description: PGP signature

Feature request for edos.debian.net

[Cyril Brulebois]

Hi,

I'd like to know whether it would be feasible to have a symlink from
e.g. [1] pointing to the latest run, so that we can fetch the diffs
directly without having to parse the summary page [2] to get the
timestamp or the links to the diffs.

 1. http://edos.debian.net/edos-debcheck/results/unstable/latest/
 2. http://edos.debian.net/edos-debcheck/unstable.php

The idea is to use those diffs to try and trigger give-backs for
packages that FTBFS'd because of B-D being uninstallable.

TIA. Cheers,

-- 
Cyril Brulebois


pgpknwalwprj0.pgp
Description: PGP signature

Re: Updated Debian Maintainers Keyring

[Cyril Brulebois]

On 22/11/2007, Pierre Habouzit wrote:
> > http://ftp-master.debian.org/dm-uploaders.txt
> 
>   Thanks. Now that'd be great if DDPO could have those informations as
>   well :)

Hi from Mérida,

I'm planning to integrate that in DDPO/PTS webpages. Cc'ing -qa to avoid
possible duplicates.

Cheers,

-- 
Cyril Brulebois


pgpbNs95DsQp5.pgp
Description: PGP signature

Re: Mole web interface?

[Cyril Brulebois]

On 22/11/2007, Raphael Hertzog wrote:
> It's not disabled: http://qa.debian.org/cgi-bin/mole

Hmm, I must have overlooked this when checking several URLs. Thanks.

> I have been advertising the URL for downloading "symbols" files lately:
> http://qa.debian.org/cgi-bin/mole/seedsymbols

Since I'm no early adopter WRT several-package-build-breaking tools or
features, I skipped that part.

-- 
Cyril Brulebois


pgpDxVLKaUec8.pgp
Description: PGP signature

Mole web interface?

[Cyril Brulebois]

Hi,

I'm currently having a look at mole so as to prepare a bit some ideas before
the meeting, and it looks like there should be a web interface hosted on merkel
([1,2]). Is there any reason why it has been disabled?

 1. http://wiki.debian.org/Mole
 2. http://qa.debian.org/cgi-bin/mole.py?source=apache2 [Not found]

Cheers,

-- 
Cyril Brulebois


pgp1m8qVHV8Y7.pgp
Description: PGP signature