Bug#1001076: cue2toc: Absolute index timestamps don't work with cdrdao (1.2.4)

[Asheesh Laroia]

Thanks Brendon! I appreciate you testing that out. I'll look into this
more in a little bit.

Bug#1001076: cue2toc: Absolute index timestamps don't work with cdrdao (1.2.4)

[Asheesh Laroia]

Hi Brendon!

Thanks for reporting this. I'm looking at the issue, and wondering if
"cuetools" simply does not have this bug.

Would you be willing to test that? If so, I'd be grateful. One option
is that I can retire this Debian package entirely.

cuetools is also in Debian: https://packages.debian.org/search?keywords=cuetools

Best,

Asheesh.

Bug#976059: Migrate to udd-mirror.debian.net hostname

[Asheesh Laroia]

Happy that we've reached a satisfying conclusion! I've been a little
worried about the migration, so that really helps.

Great to hear your kind words about the UDD mirror! :D

Bug#976059: Migrate to udd-mirror.debian.net hostname

[Asheesh Laroia]

On Sun, Nov 29, 2020 at 3:10 PM Andreas Tille  wrote:
>
> Hi Asheesh,
>
> I admit I applied your patch while beeing on a very poor connection and
> I thought this would be the reason for a failure.  But now beeing behind
> a normal connection I get:
>
> LC_ALL=C psql postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd -t 
> udd -c "select version from packages where package = 'abacas' ; "
> psql: error: could not connect to server: Connection timed out
> Is the server running on host "udd-mirror.debian.net" (147.75.35.146) 
> and accepting
> TCP/IP connections on port 5452?
>
> Is this a temporary issue or is something wrong with the query?

Sorry for the trouble! I think the problem is that you're connecting
to this server on a non-standard postgres port number.

The issue appears to be that UDD itself is on port 5452 [1], but
postgres's default is 5432 [2]. I'm not sure what causes your script
to use port 5452 -- perhaps the PGPORT variable is being used?

The simplest approach might be to add the port number to the URL. The
cleanest approach (IMHO) is to only use the PGPORT= environment
variable in the case that you're using real UDD, and/or to use a URL
to access real UDD.

FWIW, I can reproduce the timeout with these commands.

$ LC_ALL=C psql
postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net:5452/udd -t
udd -c "select version from packages where package = 'abacas' ; "

$ PGPORT=5452 LC_ALL=C psql
postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd -t udd -c
"select version from packages where package = 'abacas' ; "

When I try these commands, there's no timeout:

$ LC_ALL=C psql
postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net:5432/udd -t
udd -c "select version from packages where package = 'abacas' ; "

$ PGPORT=5452 LC_ALL=C psql
postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net:5432/udd -t
udd -c "select version from packages where package = 'abacas' ; "

Given all that, the simplest approach would probably be to add the
port number (5432) to the script.

Happy to give further advice or chat more. I'm open to reconfiguring
udd-mirror to listen on port 5452 if that ends up being the best
approach.

Asheesh.

1. https://wiki.debian.org/UltimateDebianDatabase/

2. 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=postgres

Bug#976060: Migrate to udd-mirror.debian.net

[Asheesh Laroia]

Package: debian-games
Version: 3.2
X-Debbugs-CC: mat...@debian.org

Hi there!

I looked through Debian for mentions of the
public-udd-mirror.xvm.mit.edu hostname, which Mattias and I are
deprecating in favor of udd-mirror.debian.net. See also
https://lists.debian.org/debian-qa/2020/11/msg00011.html

I discovered it in debian-games via this search:
https://codesearch.debian.net/search?q=public-udd-mirror

For many years, both hostnames have worked. We now expect the old
hostname to stop working eventually.

I'm attaching a patch, which I have tested by manually running
`src/debian_games_updater.py` and validating that a list of games
appears in the file games_all.

There's some chance the patch is mangled; if so, I apologize. The
intent should be reasonably clear.

Best regards,

Asheesh.


debian-games.patch
Description: Binary data

Bug#976059: Migrate to udd-mirror.debian.net hostname

[Asheesh Laroia]

Package: dh-r
Version: 20201117
X-Debbugs-CC: mat...@debian.org

Hi there!

I looked through Debian for mentions of the
public-udd-mirror.xvm.mit.edu hostname, which Mattias and I are
deprecating in favor of udd-mirror.debian.net. See also
https://lists.debian.org/debian-qa/2020/11/msg00011.html

I discovered it in dh-r via this search:
https://codesearch.debian.net/search?q=public-udd-mirror

For many years, both hostnames have worked. We now expect the old
hostname to stop working eventually.

I'm attaching a patch, which I have tested by manually running psql
with similar flags as how the script would run it:

$ psql postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd -t
udd -c "select version from new_packages where package =
'libnest2d-dev' ;"
 0.4-26-g4d6fb4d-1

This matches what I see at https://ftp-master.debian.org/new.html .

In the patch, I chose to use a postgresql:// URL to specify how to
access the mirror. In my opinion, this improves clarity
by avoiding the need for the PGPASSWORD environment variable.

There's some chance the patch is mangled; if so, I apologize. The
intent should be reasonably clear.

Best regards,

Asheesh.


dh-r.patch
Description: Binary data

Bug#976058: Migrate to udd-mirror.debian.net hostname

[Asheesh Laroia]

Package: debian-med
Version: 3.6
X-Debbugs-CC: mat...@debian.org

Hi there!

I looked through Debian for mentions of the
public-udd-mirror.xvm.mit.edu hostname, which Mattias and I are
deprecating in favor of udd-mirror.debian.net.

I discovered it in debian-med via this search:
https://codesearch.debian.net/search?q=public-udd-mirror+package%3A%5CQdebian-med%5CE=1

For many years, both hostnames have worked. We now expect the old
hostname to stop working eventually.

I'm attaching a patch, which I have tested by running the shell script
and validating that it provides some output. I chose to use the
URL-based approach to referring to the mirror. This improves clarity
in my opinion.

There's some chance the patch is mangled; if so, I apologize. The
intent should be reasonably clear.

Best regards,

Asheesh.


debian-med.patch
Description: Binary data

Bug#966649: Merge request for minimal, tested Python 3 port

[Asheesh Laroia]

Hi all,

I submitted a merge request here with code that should work for a Python 3
port: https://salsa.debian.org/qa/udd/-/merge_requests/26

It relies on the current approach: rsync'd historic mboxes & a
.current mbox. It should operate identically to the bitrotted munge_ddc.py.
Good advice, Lucas, on focusing on the existing code, and Andreas, thanks
for helping me see it really is important to have this in UDD for your work.

Long-term I think that there are other changes I'd make, but I may as well
focus on restoring service first, then other improvements second.

Happy for any feedback. Cheers.

Asheesh.

Bug#966649: Request for feedback on upload_history re-implementation

[Asheesh Laroia]

Hi Andreas!

You noticed that the date column was an integer. That's fixed now; if you
update from git, and if you delete upload_history.sqlite on your machine,
and re-run the tool, the upload_history column will use a datetime for the
date column. It won't do many HTTP queries, so it's peaceful to do that.
(In case you're curious, the integer was "epoch time", seconds since Jan 1
1970.) More info here:
https://github.com/paulproteus/debian-devel-changes-history-extractor/issues/5

You noticed I'm storing message_id in the upload_history table. It's that I
probably don't need that. I'll see if I can get rid of it. For now, my
advice is to ignore it; I'll work on getting rid of it.

You also noticed I'm storing the full changelog paragraph. I removed that a
moment ago -- if you get a fresh copy from git, it should be gone. You're
right that I was storing it for debugging reasons, and I don't need it in
upload_history.

As for signed_by* -- working on it next.

Thanks!

Bug#966649: Request for feedback on upload_history re-implementation

[Asheesh Laroia]

Great!

It sounds to me like if we use the *mtime* of /srv/
udd.debian.org/email-archives/debian-devel-changes/debian-devel-changes.current
(but not its contents), that would smoothly and solidly overcome the
worries about unnecessary polling. If the file's mtime is the same as the
last time the tool ran, then no need to run any import process (no matter
if the import process involves HTTP or not). If we are only relying on
mtime (and we're the only consumer), we can truncate it before looking at
it. :)

For the XZ mbox files, it sounds to me like they're currently not reliable
-- their existence on ullmann.debian.org depends on disk space stuff.

Related question: My code requires a 4-5GB cache file if it stores all data
from all years of debian-devel-changes. Is that workable? If not, it's easy
to cut it down. Is 1GB appropriate to expect as cache storage space? If
not, what about approx 400MB? (Context: 2020's data so far takes up 208MB
in my cache format.)

I need a few days to find my Debian GPG key (I moved house as well as
primary computer recently), which will allow me to reset my Debian SSH key,
which will allow me to SSH to ullmann and check these things directly. I
hope that explains why I'm not just ssh-ing to the host and finding out
what "df -h" outputs. I'm mildly embarrassed to be in this confused GPG key
situation, but that's the situation, so there you go.

Grateful,

Asheesh.

Bug#966649: Request for feedback on upload_history re-implementation

[Asheesh Laroia]

Hi Lucas!

I'm rereading this, and I have a follow-up question.

It looks to me, based on reading the bug carefully, that /srv/
udd.debian.org/email-archives/debian-devel-changes/debian-devel-changes.current
on ullmann successfully receives any new emails to debian-devel-changes. Is
that accurate?

If so, excellent -- I can incorporate that into my design.

If not, then I can talk to DSA to discuss what might be best (polling
lists.debian.org over HTTPS once per 2 min vs. fixing that file).

Cheers!

Asheesh.

Bug#966649: Request for feedback on upload_history re-implementation

[Asheesh Laroia]

On Thu, Aug 20, 2020, 05:45 Lucas Nussbaum  wrote:

> Hi Asheesh,
>

Hi! :)


>
> I think that the changes compared to the current table structure should
> be minimized, to avoid rewrite all tools that use this data.
> Improvements are welcomed of course, but please don't make changes if
> there's no good reason for them.
>

Good call. I'll prioritize that.


> Did you confirm with DSA that parsing the online list archives is the
> preferred way to go? I fear that we will hit some HTTP rate limiting at
> some point and will have to reconsider the implementation.
>

I haven't yet! I can do so. I will try to optimize the current approach
first since I'm enthusiastic about it, but good call on checking with DSA.


> How optimized is your code for running every few minutes? Ideally we
> would like near-real-time updates of this data, we will require polling
> the list archives (previously, email was received directly on
> ullmann.debian.org via a special email address)
>

It's a good question. Let me update you about that once I've optimized
further. I think I can get down to one HTTP call at start when nothing
changes (mailing list index page) and down to 2 (index page plus message
page) if there is a change.

Running every 2 min (say) would mean 24*30 = 720 requests per day, which
seems well below any rate limit I can think of, but obviously 0 unnecessary
requests is nicer. It's a good topic to discuss with DSA, and I can do that.

Even if the inbound email is used for fresh data, historic data needs to
come from somewhere. I think the email archives on the web are a good place
to import those, based on my preference to develop in a context that
doesn't require any special setup.

Hope you're doing well!

Asheesh.

>

Bug#966649: Request for feedback on upload_history re-implementation

[Asheesh Laroia]

Hi Andreas & Lucas & all,

Lucas -- I'm making progress on re-implementing this. I'd love your input
by email or IRC about my approach, but if you're busy, feel free to ignore
this and I'll mention you again when I submit a patch.

Andreas -- The codebase at
https://github.com/paulproteus/debian-devel-changes-history-extractor can
be run on your system and generate a "upload_history" table. Would you be
willing to try it out and let me know if it meets your needs?

The README at the URL above has some information about how to use it.

https://drive.google.com/drive/folders/1hF_zuc_03m3a_VwOO5hpjp5vETNjVxMx?usp=sharing
is a Google Drive folder (owned by me) which contains an
upload_history.sqlite file you can use. This would allow you to query the
current database without using the code to create it. (Feel free to also
use the code to create your own DB.)

I'm happy to discuss by IRC or private email or BTS email what you would
need next. I do hope to resolve the issues listed in the bug tracker on
GitHub, but I haven't yet, and feedback will help me prioritize.

Per the info in the README, I'd like to get this merged into UDD in the
long run, and be happy to have a discussion about the best way to do so.
There are a few issues I want to fix before formally submitting it -- see
https://github.com/paulproteus/debian-devel-changes-history-extractor/issues
for
a list.

Cheers,

Asheesh.

Bug#966649: Taking a look

[Asheesh Laroia]

Just a quick note that I'm taking a look at this.

It seems to me that accessing the mbox data is mildly annoying, and that
the same data is available by the public archives (in HTML form), so for my
own development convenience, I'm going to rewrite this code to be based on
the public HTML archives of debian-devel-changes.

I hope to have a more detailed update in a few days.

Informally, you can find some code here --
https://github.com/paulproteus/debian-devel-changes-history-extractor .

Cheers!

Bug#882424: rsh-command

[Asheesh Laroia]

Thanks for doing, and documenting, all this debugging!

Bug#851054: alpine: Please migrate to openssl1.1 in buster

[Asheesh Laroia]

Thanks for the report! Acknowledged.

Bug#828231: alpine: FTBFS with openssl 1.1.0

[Asheesh Laroia]

Hi! Thanks!

I'll schedule some time to look into this on Tuesday this week; hopefully
that will work out, and I'll keep this bug up to date with my progress.

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Asheesh Laroia]

On Mon, Sep 19, 2016 at 2:39 AM, Raphael Hertzog  wrote:

> On Sun, 18 Sep 2016, Thomas Schmitt wrote:
> > When i discussed the hint on debian-mentors i got the advise to file
> > a bug because the detail information is supposed to be visible without
> > toggle if the browser has no Javascript enabled.
> >   https://lists.debian.org/debian-mentors/2016/09/msg00305.html
>
> Well, it's visible if you don't have CSS IIRC and as such in text browsers
> that don't have javascript, it's visible. But if you apply CSS, you get
> the hidden by default and you need javascript to unhide the folded entry.
>
> I'm not sure if we can add CSS that apply only when javascript is
> disabled...
>

There are two technical things strategies worth considering here.

1. Use JS to modify the className of the body element

One technique for doing this is to use Javsacript, to add/remove a CSS
class from the body of the page. For example:

https://web-design-weekly.com/snippets/add-class-to-body-f-javascript-is-enabled/

https://css-tricks.com/snippets/javascript/css-for-when-javascript-is-enabled/

You could have the page start out with



document.documentElement.className = "js";


And now your CSS rules can switch based on this body class.

2. Create show/hide behavior that relies on CSS, not Javascript

For this particular case, a non-JS solution that fits the desired behavior
might be something along these lines:

http://www.inserthtml.com/2012/04/css-click-states/

For a long discussion of other options that achieve the same thing, see:
http://stackoverflow.com/questions/19170781/show-hide-divs-on-click-in-html-and-css-without-jquery

If operating without JS is a design goal, but CSS is OK, then these might
be a really good fit. If the site's UI needs can be implemented via CSS,
then you can provide the dynamic interface you want without having to build
two different interfaces or think about fallbacks. Going that route might
allow you to skip the BODY class thing.

3. Conclusion

I'm hoping that this technical contribution is useful, but I know that I
don't have the full context on what everyone here needs, so if not useful,
then thanks for reading it anyway!

I sympathize with you Raphael when you say it's not the kind of work you
find really useful/enjoyable. I surf the web with JS enabled. I think it'd
be nice if the non-JS users could submit patches to make sure the app works
in their environment.

I would find it supremely interesting to have a set of people get together
and publish a set of technical suggestions/recommendations for Debian
websites, with tricks like the above. That way, the people who want
websites to work with JS disabled can do the education work once, and the
people building the websites can look at a quick reference and write code
that works once without surprises down the road. I can't commit time to
that at the moment, but I would attend a sprint, for example.

Bug#836618: ccd2iso: please drop the build dependency on hardening-wrapper

[Asheesh Laroia]

Thanks. Will do.

Bug#791923: alpine: please make the build reproducible

[Asheesh Laroia]

Oops, not yet. ETA 1 week.​ Apologies.

Bug#791923: alpine: please make the build reproducible

[Asheesh Laroia]

Seems reasonable to me. I should be able to do so tomorrow.​

Bug#295386: Discussion & proposal

[Asheesh Laroia]

I notice in the original bug report, Steve Langasek asked for, "I think it
would be better to either not offer users the choice of RC severities in
novice mode, or to only allow users to choose bug severities by
*description* rather than by name."

Then reportbug changed to remove the RC severities entirely, and Steve
remarked, "I said that, in novice mode, users should not be presented with
a list of severities *by name* to pick between because they won't have read
the documentation and won't know what the correct severity is."

Steve, I think that you changed your mind between filing the bug and adding
that comment. However I'm sympathetic to your desire to show RC bug
severities to novice users in a way that allows them to choose them, but
prevents them from choosing them merely due to a sense of self-importance.

I also noticed that the bug severities are listed most-severe first. See
below for a transcript from reportbug (some lines removed). I believe that
this puts the word "critical" at front & center of newcomers' minds, and
that this is a bad idea because it encourages choosing that option.

Therefore, I propose the following change:

- For non-novice users: show the lowest severity first and highest severity
last.

- For novice users: either (A) show the same as we show for all users, now
sorted with lowest severity first, or (B) skip the severity prompt, since
novice users are mostly unable to choose accurately, and tell novice users,
"If you need to change the severity, you can do so after the bug is filed,
or by changing your reportbug configuration level."

Steve, what is your preference between these options? Sandro Tosi, what is
yours?

My personal preference is to change the sorting for non-novice users as
described above, and also to do change the novice form according to option
(B).

Steve, I noticed that you suggested showing the RC bug severities without
their names. I attempted to create a proposed transcript that does that,
but I could not come up with a way to format it that still looked
reasonable to me. So if you can come up with a proposal, great! Until then
I am going to assume there is no reasonable way to do it.

Here's the transcript of current behavior.


$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?

1 criticalmakes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security hole
on systems where you install the package.
2 grave   makes the package in question unusable by most or all
users, or causes data loss, or introduces a security hole allowing access
to the accounts of users who use the package.
3 serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive); may or may not
affect the usability of the package. Note that non-severe policy violations
may be
  'normal,' 'minor,' or 'wishlist' bugs. (Package
maintainers may also designate other bugs as 'serious' and thus
release-critical; however, end users should not do so.). For the canonical
list of issues worthing a
  serious severity you can refer to this webpage:
http://release.debian.org/testing/rc_policy.txt .
4 important   a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.
5 does-not-build  a bug that stops the package from being built from
source. (This is a 'virtual severity'.)
6 normal  a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu item.
7 minor   things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
8 wishlistsuggestions and requests for new features.

Please select a severity level: [normal]



Here's my proposal instead:


$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?

1 wishlistsuggestions and requests for new features.
2 minor   things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
3 normal  a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu 

Bug#830229: dracut preinst script complains about dpkg compare-versions syntax

[Asheesh Laroia]

Package: dracut
Version: 044+105-2
Severity: normal

Hello Thomas! I'm at your BoF at Debconf, and grateful to you for answering all 
my random
questions today.

I experienced a problem which I thought would be best reported as a Debian bug.

Note that I am on a mixed jessie/sid system, so I am installing dracut from sid
even though dpkg is version 1.7.27.

I installed dracut-core from sid, and then I decided I liked it, so I then 
decided to install
dracut. Then I saw this:

Preparing to unpack .../dracut_044+105-2_all.deb ...
dpkg: error: --compare-versions takes three arguments:   


Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dracut depends on:
ii  dracut-core  044+105-2

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#828085: When running monkeysphere against Clint's key, monkeysphere fails to do anything useful due to a GPG bug maybe

[Asheesh Laroia]

Package: monkeysphere
Version: 0.37-2

I am trying to learn how to use monkeysphere. I figured one good first-step
would be to get the SSH key corresponding to Clint Adams .

So I ran:

$ monkeysphere u "Clint Adams "

in an attempt to get a "ssh-rsa..." line out, which would demonstrate to me
that monkeysphere generally works.

Instead, I got this output:

paulproteus@slittingmill:~$ monkeysphere u "Clint Adams "
ms: Failure (2) receiving keyids (0x2100A32C46F895AF3A08783AF6D3495BB0AE9A02
ms: 0x2806F67A363A1F9C3EBFD274C3A844D76AE3B737
ms: 0x995314085A0EC967941DCE9DE66D2EEBAB963370
ms: 0x5DB29C847F07FD4F60A8728070AEBD21B13DEAF7
ms: 0xA3B4A1C6DBED847F
ms: 0xF88942139018FAD6EB7EC4735EDBAE5BB98FC0C8
ms: 0x91A285AE301B7D6B
ms: 0x1927D3053E30A739) from keyserver pool.sks-keyservers.net

However, I can seemingly download at least of those keys A-OK from the key
server:

paulproteus@slittingmill:~$ echo | gpg --quiet --batch --with-colons
--command-fd 0 --keyserver pool.sks-keyservers.net --recv-keys
0x2100A32C46F895AF3A08783AF6D3495BB0AE9A02 ; echo $?
gpg: requesting key B0AE9A02 from hkp server pool.sks-keyservers.net
0

Discussion with jrollins on #monkeysphere suggests that the fact that GPG
refuses to accept some of the keys, or maybe downloads too much, or prints
too many warnings, is part of the problem:

19:41 < jrollins> hrm
19:41 < jrollins> gpg: key 0x: rejected by import filter
19:41 < jrollins> gpg: Note: signatures using the MD5 algorithm are rejected

19:45 < jrollins> Clint: check out this key: 0x91A285AE301B7D6B
19:45 < jrollins> what's up with that?
19:46 < jrollins> dkg: we seem to have a gpg issue that i'm not sure how to
deal with.  gpg won't import all of the
  key ids that monkeysphere is trying to retrieve, which
causes monkeysphere to fail

19:50 < jrollins> gpg --search ="Clint Adams "
19:50 < jrollins> returns:
19:50 < jrollins> (5)IClint Adams (ElG)  2048 bit ELG
key 0xA3B4A1C6DBED847F, created: 1998-05-1

Some strace output follows. Thanks for reading this bug report!

paulproteus@slittingmill:~$ MONKEYSPHERE_LOG_LEVEL=DEBUG strace -ff -e
execve monkeysphere u "Clint Adams "
execve("/usr/bin/monkeysphere", ["monkeysphere", "u", "Clint Adams <
sch...@debian.org>"], [/* 38 vars */]) = 0
execve("/home/paulproteus/dnlds/google-cloud-sdk/bin/bash", ["bash",
"/usr/bin/monkeysphere", "u", "Clint Adams "], [/* 38
vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/local/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint
Adams "], [/* 38 vars */]) = -1 ENOENT (No such file or
directory)
execve("/usr/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint Adams
"], [/* 38 vars */]) = -1 ENOENT (No such file or
directory)
execve("/bin/bash", ["bash", "/usr/bin/monkeysphere", "u", "Clint Adams <
sch...@debian.org>"], [/* 38 vars */]) = 0
Process 1 attached
[pid 1] execve("/usr/bin/basename", ["basename",
"/usr/bin/monkeysphere"], [/* 38 vars */]) = 0
[pid 1] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13334 attached
[pid 13334] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13334,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13335 attached
[pid 13335] execve("/bin/date", ["date", "-u", "+%FT%T"], [/* 41 vars */])
= 0
[pid 13335] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13335,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13336 attached
[pid 13336] execve("/bin/mkdir", ["mkdir", "-p", "-m", "0700",
"/home/paulproteus/.monkeysphere"], [/* 41 vars */]) = 0
[pid 13336] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13336,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13337 attached
[pid 13337] execve("/bin/mkdir", ["mkdir", "-p", "-m", "0700",
"/home/paulproteus/.gnupg"], [/* 42 vars */]) = 0
[pid 13337] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13337,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13338 attached
Process 13339 attached
[pid 13338] +++ exited with 0 +++
[pid 13339] execve("/bin/sed", ["sed", "s/^/ms: /"], [/* 45 vars */]) = 0
ms: processing: Clint Adams 
[pid 13339] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13338,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 13340 attached
Process 13341 attached
[pid 13340] +++ exited with 0 +++
[pid 13341] execve("/bin/sed", ["sed", "s/^/ms: /"], [/* 45 vars */]) = 0
ms: key file: -
[pid 13341] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13340,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
Process 

Bug#803956: alpine: Editing a postponed message breaks 'git format-patch --thread'

[Asheesh Laroia]

Thanks for reporting this! It's on my list now.

Most especially thanks for finding this workaround! I didn't know about it.

Bug#805991: Have an upload prepared, but uploaded it with the wrong orig.tar.xz checksum

[Asheesh Laroia]

should be fixing that in the next 1-2 days

Bug#805991: alpine: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Asheesh Laroia]

Thanks! I'll aim to look at this in the next 10 days or so.​

Bug#805648: qa.debian.org: Provide a way to share an ignore list (for team dashboard)

[Asheesh Laroia]

One option is to store data in the window.location.hash (or equivalently
html5 pushstate).

See e.g.:

http://yuilibrary.com/yui/docs/router/

For docs on a library that uses this.

This avoids server-side storage and still gives permalinkable state.

Bug#792075: ITP: git-lfs -- Git Large File Support. An open source Git extension for versioning large files

[Asheesh Laroia]

Hi Stephen! I'm excited to see this land in Debian.

I'm curious if you know if there a free software backend that is compatible
with the git-lfs protocol.​ If so, that'd be great to see in Debian as well
one day.

If not, if I understand Policy correctly, you would need to take care to
set the package's section to contrib. See
https://www.debian.org/doc/debian-policy/ch-archive.html for more
information.

(As I understand policy, if there *is* a git-lfs compatible backend that is
free software, it's fine to have git-lfs in main, even if that backend
isn't currently available in Debian.)

Again, nice to see your enthusiasm, and I hope you can find a sponsor for
this package.

Bug#791923: alpine: please make the build reproducible

[Asheesh Laroia]

Hi! Thanks ​for filing this.

I hope to address this over the next 10 days. If not, please feel free to
NMU this.

Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).

[Asheesh Laroia]

On Thursday, February 5, 2015, Roelof Berg rb...@berg-solutions.de wrote:

 Thanks for the links and the welcoming words. This is the motivation I
 need :) I'm currently busy with making my .deb package compatible to
 launchpad ppa as a quality measure.


Great! (-:



 Am I allowed to use full optimization (-Ofast) ? Or is it mandatory to use
 -O2 ?


Per https://www.debian.org/doc/debian-policy/ch-files.html -- there's a lot
in 10.1, but it concludes, It is up to the package maintainer to decide
what compilation options are best for the package. So -- go for it.

But preferably run some benchmarks to find out if this actually makes a
difference!



 I hope, this will find a sponsor. I contacted the Imagemagick package
 maintainers at first, before I submit a sponsorship-request. Wish me luck :)


Great!

Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).

[Asheesh Laroia]

Hi Roelof! I'm excited you want to work on this.

On Tuesday, February 3, 2015, Roelof Berg rb...@berg-solutions.de wrote:


 I developed this application as part of a scientific project. It offers 2D,
 grayscale, rigid image registration with a powerful
 derivative based approach and operates very fast and memory efficient
 (compared
 to traditional derivative-based aproaches).

 OpenCV is used to load and store the image data. The user can either
 output the
 registered image (image aligned/shifted/rotated upon another one)
 or it can output the numeric registration result (x-shift, y-shift and
 rotation).


Awesome.


 I want to develop this application further and want to maintain the .deb
 package. Furthermore
 I will publish the functionality as a library in an additional lib.deb and
 lib-
 dev.deb package.
 When the lib.deb package has been released I want to add it to imagemagik.
 This
 would enable people to register images just by using imagemagik :)


That'd be splendid.



 I'm not aware of any other package offering image registration (if at all)
 in
 this speed and quality. Our mathematical aproach (regarding speed and
 memory
 usage) is very new and
 it is extremely unlikely that any other package can offer it. We just
 published
 it in a scientific magazine.
 Preprint: http://www.embedded-software-
 architecture.com/Berg2014Highly_Preprint.pdf

 Applications:
 HDR-Photograpy, Industrial Imaging (compare an actual photography to a
 reference picture), Medical Imaging (align images from different times or
 sensors), motion detection/compensation, and many more ...

 I will put as much effort in the packaging as necessary. As I'm an
 experienced
 software developer (e.g. Embedded Linux) my skills will be sufficient.
 The effort is low as it is only a small command line tool (yet ;) and I
 can do
 it alone.

 However, I'm new to Open Source and to the packaging. Do I need a sponsor
 to
 get the package accepted ? Also a review from an experienced packager
 would be
 required as this is my first step into Open Source contribution.



As always, in Debian, if you're not a Developer in Debian yet, you'll need
a sponsor to get the package accepted.

In many things, and in Debian packaging too, I recommend trying to get
something working first, then good, then great.

My bandwidth for mentorship on this might not be huge, but I hope you can
find a sponsor and a reviewer. If you have trouble, send me an email.

Happy hacking!

Asheesh, aka paulproteus at debian.org.

Bug#768006: Thank you for this report

[Asheesh Laroia]

Hi Sean,

As a Debian developer, I wanted to take a moment to say -- thank you
for being the kind of person who would file such a high quality bug
report against Debian.

Specifically, here are some great things about your bug report:

* It relates to the systemd transition, which needs all the review it
can get before the next release, in order to help other users avoid
problems like these.

* It uses matter-of-fact tone and is very easy to read, in terms of
(1) lucidly laying out technical facts and (2) describing what could
easily be a very painful situation for you without laying personal
blame or making the reader feel blamed.

* It provides high-quality technical information about your situation,
including the (presumably manually created by you) text dump from the
journal and the package-specific info. The package-specific info
likely comes to us due to reportbug, but I know first-hand that
reportbug is not trivial to use, so the fact that you did so is a huge
help.

* It is filed against nfs-common, the package that (I agree) is most
likely to relate to the problem, rather than other packages that may
be related, such as systemd, which are likely to receive lots of
reports mistakenly assigned to it. Your awareness of the Debian system
and your care to file bugs where they can probably be most easily
acted-upon is an asset to the Debian project.

I'm not a maintainer of nfs-utils, but I wanted to express my
gratitude and say that reading bug reports like this makes me grateful
that I am part of a Debian community that includes people like you.

Sincerely,

Asheesh.


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

Bug#657405: I sent a request to NM to add Matija Nalis to Alioth

[Asheesh Laroia]

For what it's worth! Hopefully I did it right.


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

Bug#753698: Thanks for the patch to make it build on HURD

[Asheesh Laroia]

Hi Svante and all on the Debian bug tracker,

Thanks for the patch to make it build on Debian GNU/Hurd!

I read through the HURD porting guidelines 
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html and I agree
that the patch is reasonable.

Eduardo -- I've made two small changes to Svante's patches, and I've just
uploaded that to Debian now. If the GNU Hurd build daemons like this
package, I'd love if you can take the two patches.

You can find them here:

http://anonscm.debian.org/cgit/collab-maint/alpine.git/tree/debian/patches/10_hurd_build.patch
http://anonscm.debian.org/cgit/collab-maint/alpine.git/tree/debian/patches/10_hurd_build_continued.patch

Thanks! I'll try to send you a separate email once we've confirmed the
patches actually work, but I wanted to send you this heads-up as soon as I
could.

-- Asheesh.

Bug#710511: Improving passfile support

[Asheesh Laroia]

Hi Eduardo,

I know you've been working a lot on alpine lately, and I wanted to pass
this along.

I haven't dug into the source code, but one Debian user reports that the
-passfile option seems to have no effect.

Another reports that -passfile works fine so long as the file already
exists before alpine starts.

I presume that the latter understanding is accurate, and the first one is a
user confused by Alpine's behavior.


It seems to me that users would be best-served if alpine was willing to
create passfile files. Or, if not, users would be second-best-served by
alpine exiting with an error, asking the user to create the file.

What do you think?

Thanks!

-- Asheesh.

Bug#532380: Permitting viewing application/octet-stream attachments

[Asheesh Laroia]

Hi Eduardo,

Here's another Debian bug that I wanted to get your input on --
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532380 .

Do you think it makes sense for future Alpine editions to allow people to
View application/octet-stream attachments? It seems harmless, and clearly
desired in some cases.

(I myself have desired this!)

Let me know what you think. It'd be great if you keep the bug in the CC:
line, too, if you're willing to have the conversation be public.

Thanks, as always!

-- Asheesh.

Bug#725296: alpine: Please reconsider: should work with GPG

[Asheesh Laroia]

Hi Axel,

First of all, thank you for filing a bug against the Alpine package in
Debian! It's always exciting to get input from people using the software.

The UW-based Alpine team only ever implemented S/MIME, but there's no
reason in principle Alpine couldn't grow GPG support. I myself am unlikely
to write it, due to a shortage of time.


There are some GPG support tools for alpine. Particularly, topal is one
such set: http://homepage.ntlworld.com/phil.brooke/topal/rel-72/README.html

Another is https://dougbarton.us/PGP/ppf/

Both have different perspectives. Unit 193 has been working on packaging
the latter of these, and you can find it here:
http://anonscm.debian.org/cgit/collab-maint/pine-pgp-filters.git

Axel, the one thing that the pine-pgp-filters package needs (it seems) is
high-quality instructions on how to use it with the Alpine package in
Debian. Working on that, plus filing the ITPs etc., is our next step.

If that's a package you'd be interested in trying out, and helping us work
on instructions for it, that'd be great.

Thanks again!

-- Asheesh.

Bug#755459: RFS: lucene/4.9.0-1 [put in ITP, ITA, RC, NMU if applicable]

[Asheesh Laroia]

Hi Raaj + bug,

I noticed that some of the areas of the template aren't filled in, such as:

* your most recent changelog entry

* [fill in name and email of upstream]

And so on.

Can you send a follow-up mail to the bug with that information? If so, I'll
be happy to take a look at this.

I'm always excited when people are interested in maintaining software
within Debian, so I hope you'll reply!
​

Bug#744097: stdeb: pypi-install broken due to python.org URL change

[Asheesh Laroia]

Package: python-stdeb
Version: 0.6.0+20100620-2
Severity: grave
File: stdeb


Currently, due to a website reorganization within python.org, 
the find_tar_gz() function crashes with:

File /usr/lib/python2.7/xmlrpclib.py, line 1312, in single_request
response.msg,
xmlrpclib.ProtocolError:

https://github.com/astraw/stdeb/pull/72 (patch there)
addresses the problem by using the canonical URL of PyPI.

-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 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-stdeb depends on:
ii  debhelper 9.20120419~bpo60+1 helper programs for debian/rules
ii  python2.7.5-5interactive high-level object-orie
ii  python-setuptools 0.6.49-2   Python Distutils Enhancements (set
ii  python2.6 2.6.6-8+b1 An interactive high-level object-o
ii  python2.7 2.7.5-8Interactive high-level object-orie

Versions of packages python-stdeb recommends:
ii  apt-file  2.5.1  search for files within Debian pac
ii  dpkg-dev  1.16.10Debian package development tools
ii  python-all2.7.5-5package depending on all supported

Versions of packages python-stdeb suggests:
pn  python-all-devnone (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#724355: patch

[Asheesh Laroia]

Hi Eric! Thanks for this. If you want to NMU upload it, that'd be OK by 
me. Otherwise I plan to get to this on Friday.



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

Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process

[Asheesh Laroia]

On Fri, 16 Aug 2013, Guillem Jover wrote:

The same will apply when building that deb package multiple times, the 
timestamps will change for the ar headers. And I don't really want to 
lose that data, because currently is the only place were the build time 
information is recorded. Do you only care that the members themselves 
are deterministic or the whole deb package?


I think I'd be fine with not storing the timestamps in the compressed 
members themselves, but not about the ar container.


Thanks for the speedy replies! I'm excited and pleased by your 
responsiveness to the general ideas and specific issues.


I would prefer to keep even the 'ar' container free of those timestamps, 
but there are some workarounds I can imagine if you don't want to do that 
for now.


We could perhaps let 'dpkg' accept an argument to set that timestamp, 
and/or we could use 'faketime' when trying to reproduce a build, if we 
know what timestamp to reproduce. (My notion here is that it should be 
easy for someone to create the same bits that we publish in Debian, even 
if that reproducing effort is slightly different than just doing a fresh 
build.)


Another way that we could do it is to store the last debian/changelog 
timestamp in the ar header. That would be my favorite approach.


-- Asheesh.


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

Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process

[Asheesh Laroia]

On Fri, 16 Aug 2013, Guillem Jover wrote:

dpkg has not used the gzip command for a very long long time (prior to 
dpkg 1.9.x), and zlib does not initialize the gzip header, so the 
timestamp should be 0. If there are differences these should come from 
something else, like different tar files fo example.


I can of course add the option to the fallback command code, just out of 
correctness, but that will not fix any difference you are currently 
seeing.


Interesting. I wonder if the problem is slightly different timestamps in 
the contents of data.tar.gz then, and this is a red herring.


Adding this to the fallback code sounds great, but yeah, I agree it's not 
super related to what I'm seeing. (-:


Thanks!

-- Asheesh.


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

Bug#719845: dpkg-source: Make file order within {data,control}.tar.gz deterministic

[Asheesh Laroia]

On Fri, 16 Aug 2013, Guillem Jover wrote:


Indeed, that's something that has been on the back of my mind for some
time now, and that I was/am planning on fixing during the 1.17.x cycle.
This will also be part of a two step process to guarantee the dpkg
database is also more deterministic, dpkg would need to sort
(preserving symlinks at the end) the files when dumping them on the
database (to cater for older unsorted debs).


Awesome.

I am thrilled that this is already on your radar, and the generally 
during this cycle time-frame is completely satisfying.



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

Bug#719845: dpkg-source: Make file order within {data,control}.tar.gz deterministic

[Asheesh Laroia]

Package: dpkg
Version: 1.16.10
Severity: normal

*** Please type your report below this line ***

Summary: To move toward https://wiki.debian.org/ReproducibleBuilds for 
maintainers who want their binary packages to be able to be reproduced 
bit-for-bit, it would be needed for dpkg to sort the files before adding 
them to the tar files of {data,control}.tar.{xz,bz2,gz}.


That way, the creation of the data.tar.gz would be deterministic.


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

Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process

[Asheesh Laroia]

Package: dpkg
Version: 1.16.10
Severity: normal

*** Please type your report below this line ***

Summary: In lib/dpkg/compress.c, I would like it if dpkg did not store 
timestamps in the gzip files. That way, the creation of the data.tar.gz 
would be deterministic.


In particular, when I build a binary package with the very same contents 
twice, I see that data.tar.xz and control.tar.gz are both different 
although they have the same contents (even timestamps).


Binary files one/control.tar.gz and two/control.tar.gz differ
Binary files one/data.tar.xz and two/data.tar.xz differ

In 1.16.10 I would add '-n' to the call to 'gzip' in a pipe. In curent 
dpkg git, I believe this may be fixed, but I am not sure. I am filing this 
bug so there is a clear statement of the general problem in the BTS, at 
least!




-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 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 dpkg depends on:
ii  libbz2-1.0 1.0.5-4   high-quality block-sorting 
file co
ii  libc6  2.17-3Embedded GNU C Library: 
Shared lib

ii  liblzma5   5.1.1alpha+20120614-2 XZ-format compression library
ii  libselinux12.0.96-1  SELinux runtime shared 
libraries
ii  tar1.23-2.1  GNU version of the tar 
archiving u

ii  zlib1g 1:1.2.7.dfsg-13   compression library - runtime

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt   0.9.7.8commandline package manager

-- 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#719848: should call gzip with '-n' when compressing manpage and changelog

[Asheesh Laroia]

Package: hello
Version: hello: 2.8-3
Severity: normal
Tags: patch


In the interest of using the 'hello' package as a demo of great
packaging practices, and because I've become interested in creating
binary-reproducible builds in Debian, I propose the following very
simple patch:

--- hello-2.8/debian/rules  2013-02-13 11:27:19.0 +0100
+++ hello-2.8/debian/rules  2013-08-14 23:38:01.0 +0200
@@ -58,9 +58,9 @@
cp -a NEWS debian/copyright $(docdir)
cp -a debian/changelog $(docdir)/changelog.Debian
cp -a ChangeLog $(docdir)/changelog
-   cd $(docdir)  gzip -9 changelog changelog.Debian
-   gzip -r9 debian/tmp/usr/share/man
-   gzip -9 debian/tmp/usr/share/info/*
+   cd $(docdir)  gzip -9 -n changelog changelog.Debian
+   gzip -r9 -n debian/tmp/usr/share/man
+   gzip -9 -n debian/tmp/usr/share/info/*
dpkg-shlibdeps debian/tmp/usr/bin/hello
dpkg-gencontrol
chown -R 0:0 debian/tmp


-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#715216: qa.debian.org: collab-qa/upload-history: Software trusts Date headers which are sometimes set wrong

[Asheesh Laroia]

On Wed, 10 Jul 2013, Lucas Nussbaum wrote:


Hi Asheesh,

Sorry for the delayed reply. Thanks a lot for your work on this.

I've added you to collab-qa, so you should be able to push your code 
yourself.


Yay! Thanks!

Now, one comment on your changes: it would be better if everything you 
do is versioned in git (for example, 
/srv/udd.debian.org/email-archives/README isn't, same for scripts in 
/srv/udd.debian.org/upload-history/). You could put them under 
/srv/udd.debian.org/udd/scripts/upload-history/, for example.


I totally agree. Thanks for this note.

Along those lines:

Is it reasonable for the email-archives/ directory to live in 
git://git.debian.org/collab-qa/udd.git even though it won't have any data 
(just the README indicating why it has no data in VCS) except on the 
deployment? I figure that is fine, but thought I'd ask.


The upload-history scripts are actually a checkout of an svn repo. What's 
the best way to put that into udd git, if at all? In particular:


svn+ssh://lu...@svn.debian.org/svn/collab-qa/upload-history

I could just move them into 
/srv/udd.debian.org/udd/scripts/upload-history/ but that wouldn't really 
put them in git; it would just mean an svn checkout lives in a git 
directory, which is a bit odd.


Should we (I) add that code to git entirely, and ditch the svn repo? I can 
do that and leave a note in the svn repo explaining where the code has 
gone, if that is best.


I've taken this moment to 'svn commit' those changes, although perhaps 
I'll migrate the history to git. (I'm familiar enough with git-svn that I 
can try to use that for converting the history.)


Thanks!

-- Asheesh.


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

Bug#715216: qa.debian.org: collab-qa/upload-history: Software trusts Date headers which are sometimes set wrong

[Asheesh Laroia]

New proposed fix:

In collab-qa/upload-history/munge_ddc.py , if the Message-Date we were 
going to emit is not within the year of the envelope From, plus/minus one 
year, we drop Message-Date.


This permits the udd/upload_history_gatherer.py code to use its existing 
logic about dropping replacing Message-Date with Date when 
Message-Date is visible.


I've tested that on a subset of debian-devel-changes.201307 and confirmed 
the patched code has identical output, and that the crazy The year is 
2019 message has N/A as its Message-Date. So I believe the behavior is 
correct.


I've also tested the performance of this. I re-ran the patched + unpatched 
code until runtimes were close to consistent (in an attempt to remove disk 
or other caches as the difference) and then I got these numbers after one 
run of each:


Unpatched: 22.994sec

➜  upload-history  time python munge_ddc.py 
/tmp/debian-devel-changes/debian-devel-changes.201307  
/tmp/debian-devel-changes.201307.out.without-patch


17.93s user 4.59s system 97% cpu 22.994 total

Patched: 22.983sec

➜  upload-history  time python munge_ddc.py 
/tmp/debian-devel-changes/debian-devel-changes.201307  
/tmp/debian-devel-changes.201307.out.with-patch


18.00s user 4.52s system 97% cpu 22.983 total


I'm not realistically arguing that my code runs faster than the original 
code, but I believe there is less than 1% runtime difference between the 
two, and probably way less than 1%.


Patch attached for munge_ddc.py. Please review and merge, if you like!

-- Asheesh.Index: munge_ddc.py
===
--- munge_ddc.py	(revision 2767)
+++ munge_ddc.py	(working copy)
@@ -105,6 +105,55 @@
 
 return ret
 
+def get_message_date_if_it_is_sane(msg, rc):
+# See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715216 for the reason
+# this function exists at all.
+raw_msg_date = msg['Date']
+message_date = normalize_date(msg['Date'])
+
+# If there is no usable message date, then we should bail out.
+# This is preferable to emitting any other value as the message date;
+# the other date data is also emitted (look for Message-Date vs. Date
+# in munge_ddc()), so downstream consumers of this data can decide for
+# themselves how to proceed.
+if message_date is None:
+return raw_msg_date
+
+# If there is a message date, we want to check how that compares
+# to the date embedded in the Envelope from, if there is one.
+#
+# In the past, there have been situations where the message date
+# is far ahead of the actual date, probably due to a server error
+# somewhere.
+envelope_from = msg.get_unixfrom()
+
+# If we have no envelope from, then we cannot do the sanity check. So we
+# let the original data through.
+if envelope_from is None:
+return raw_msg_date
+
+# If the we have an envelope from, try to find a date. If we don't have
+# one, then we also have to bail out.
+envelope_from_date = None
+if envelope_from.count(' ') = 2:
+envelope_from_date = normalize_date(
+envelope_from.split(' ', 2)[2])
+if envelope_from_date is None:
+return raw_msg_date
+
+# Given that we have both, we use the following heuristic: if the
+# Message-Date is more than one year different from the date in the
+# envelope From, we assume the Message-Date is corrupt.
+message_date_year = emailutils.parsedate_tz(message_date)[0]
+envelope_from_year = emailutils.parsedate_tz(envelope_from_date)[0]
+
+# If the message date year is within a sane range, we return it.
+if ((envelope_from_year - 1)  message_date_year 
+(envelope_from_year + 1)):
+return raw_msg_date
+else:
+return 'N/A'
+
 def build_keyring_list(dir):
  Scan dir and return a list of every file ending with .gpg or .pgp 
 keyrings = []
@@ -141,7 +190,7 @@
 c['Signed-By'] = 'N/A'
 
 c['Message-Id'] = str(msg['Message-Id']).strip('\n')
-c['Message-Date'] = str(msg['Date']).strip('\n')
+c['Message-Date'] = get_message_date_if_it_is_sane(msg, rc)
 
 	if not set(['Source', 'Architecture', 'Version', 'Date', 'Changes']).issubset(rc.keys()):
 sys.stderr.write(Required fields not found, skipping.\n)

Bug#715216: qa.debian.org: collab-qa/upload-history: Software trusts Date headers which are sometimes set wrong

[Asheesh Laroia]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

I've found (and reproduced) an issue in the collab-qa/upload-history code. 
(By that, I mean the stuff you can get from here: 
svn+ssh://paulprot...@svn.debian.org/svn/collab-qa/upload-history )


I was reading the upload_history table, and noticed that one package was 
supposedly uploaded on 2019-02-07. Further research indicates that the 
file with the bad data is debian-devel-changes.199902.gz.


Looking at 
https://lists.debian.org/debian-devel-changes/1999/02/msg00707.html you 
can see one such offending email -- the Date header claims the email was 
sent in 2019.


I can reproduce this bad data getting output by upload_history by running 
collab-qa/upload-history/munge_ddc.py on a one-message sample file that 
represents that email.


Given that, we have a few options.

1. Declare garbage in, garbage out and make no attempt to clean up the 
data.


2. Do something very rigid to, instead of looking at the Date: header 
which is user-specifyable, look at the mbox file envelope, which says when 
the mail system received the message. (Downside: This can be different 
based on if people are using email data from master.debian.org's archives 
vs. other archives, since it amounts to the eit is


3. Do something like (2) but look at the first Received header involving 
debian.org. (This can be spoofed if people try, but I think that in 
general we are only addressing misconfiguration, not intentional aims to 
mislead.)


4. Use the Date header that is in the changes file itself -- for example, 
that is Date: Tue, 24 Nov 1998 12:28:30 -0500 on 
https://lists.debian.org/debian-devel-changes/1999/02/msg00707.html , 
which is sane, even though the 2019 date appears in the email message's 
Date: header


Of these, I like option (4) the best. I will implement that and submit a 
patch here. If there is strong disagreement, later on I can redo the work 
with a different error-correction strategy.


-- Asheesh.


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

Bug#715216: qa.debian.org: collab-qa/upload-history: Software trusts Date headers which are sometimes set wrong

[Asheesh Laroia]

(Sorry about a not fully formed thought on numeral 2 in the numbered list 
in the last message. Typing and thinking too fast.)


Anyway, as an update to this: further research indicates that 
upload-history is simply spitting out the data from the email in a 
Message-Date field. I can't blame the upload-history code for spitting 
out the garbage it got as input data.


However, in udd/upload_history_gatherer.py in udd.git, there is machinery 
to insert the value of Message-Date into the field, rather than the 
changes file's Date header.


I suggest the following untested patch:

diff --git a/udd/upload_history_gatherer.py 
b/udd/upload_history_gatherer.py

index 4091eec..fe485e6 100644
--- a/udd/upload_history_gatherer.py
+++ b/udd/upload_history_gatherer.py
@@ -54,5 +54,5 @@ class upload_history_gatherer(gatherer):
 VALUES ($1, $2, $3, $4) % (self.my_config['table'] + '_closes'))

-query = EXECUTE uh_insert(%(Source)s, %(Version)s, %(Message-Date)s, 
\

+query = EXECUTE uh_insert(%(Source)s, %(Version)s, %(Date)s, \
   %(Changed-By)s, %(Changed-By_name)s, %(Changed-By_email)s, \
   %(Maintainer)s, %(Maintainer_name)s, %(Maintainer_email)s, %(NMU)s, 
\


(sorry about some patch mangling here by email)

The key question for us is: Are we okay with changing the definition of 
date in the upload-history table to mean the date within the changes 
file, rather than the email message's date?


One downside to this is that for sponsored packages, we see when the 
sponsoree did the work, rather than when the package got uploaded. The 
current behavior, of keeping the upload_history table's contents being the 
date of the message, results in a best-effort attempt to measure when the 
upload seemed to actually get processed. So I like the current behavior, 
and I now would reject my patch.



Okay.


At that point if the goal is, The date field represents, to the best 
effort we can approximate, the time that the upload was successfully 
processed by the Debian servers, we have a few different options. I'm 
going to do some further research here and get back to the bug with a 
recommendation, but as a surely-incomplete list of options:


1. We could try to implement a very conservative fixup strategy like, If 
the Message-Date field is more than one year different from the Date 
field, go with whichever of (Message-Date, Date) is closest to the 
envelope From.


2. We could create a fixups list by hand of package uploads and actual 
dates, manually maintained, that overrides the data in the mbox files. 
That is probably the easiest, since I suspect there are not very many 
packages with this problem.


3. We could store both Message-Date and Date in UDD, and then tell users 
of UDD that they will have to deal with this problem of bad data. (This is 
the option I like the least.)


Of these, I like option 1 the most. I will work on implementing that.

-- Asheesh.


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

Bug#702085: debian-devel-changes is importing correctly

[Asheesh Laroia]

A more full report is forthcoming. I wanted to first declare success here, 
and then explain how things work for benefit of later readers (or current 
UDD maintainers with opinions on how to change them).


I created a query that conveniently limits the width of the query to = 
80 characters, to avoid email wrappering. I also want to note:


This query demonstrates that the transition from the 
debian-devel-changes.201307 file to the debian-devel-changes.current (AKA 
inbound mail) is smooth.


We also might want to fix the code to avoid the historical problem with 
believing that some packages were submitted in 2018 and 2019.


Anyway! See:

paulproteus@ullmann:~$ psql service=udd
psql (9.1.9)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type help for help.

udd= select SubStr(source || ' ' || version::text, 0, 20), date::date, 
file from upload_history order by date desc limit 140;


   substr|date| file
-++--
 libhtml-embperl-per | 2019-02-07 | debian-devel-changes.199902
 data-dumper 2.10-2  | 2019-02-06 | debian-devel-changes.199902
 custom 1.9962-2 | 2019-02-05 | debian-devel-changes.199902
 libcompress-zlib-pe | 2019-02-05 | debian-devel-changes.199902
 alias 2.31-2| 2019-02-05 | debian-devel-changes.199902
 xqf 0.8.7.2-1   | 2019-02-05 | debian-devel-changes.199902
 libhtml-tree-perl 0 | 2019-02-05 | debian-devel-changes.199902
 data-dumper 2.10-1  | 2019-02-05 | debian-devel-changes.199902
 kernel-patch-2.0.35 | 2018-10-29 | debian-devel-changes.199810
 debian-goodies 0.63 | 2013-07-05 | debian-devel-changes.current
 jakarta-jmeter 2.8- | 2013-07-05 | debian-devel-changes.current
 bygfoot 2.3.2-1.1   | 2013-07-05 | debian-devel-changes.current
 djvusmooth 0.2.14-1 | 2013-07-05 | debian-devel-changes.current
 gearman-interface 0 | 2013-07-05 | debian-devel-changes.current
 cp2k 2.3.0-1| 2013-07-05 | debian-devel-changes.current
 debian-edu-artwork  | 2013-07-05 | debian-devel-changes.current
 libcpan-perl-releas | 2013-07-05 | debian-devel-changes.current
 trickle 1.07-10 | 2013-07-05 | debian-devel-changes.current
 secure-delete 3.1-6 | 2013-07-05 | debian-devel-changes.current
 cairo-dock-plug-ins | 2013-07-05 | debian-devel-changes.current
 wdq2wav 0.9.0-1 | 2013-07-05 | debian-devel-changes.current
 starpu-contrib 1.0. | 2013-07-05 | debian-devel-changes.current
 cairo-dock-plug-ins | 2013-07-05 | debian-devel-changes.current
 mididings 0~2012041 | 2013-07-05 | debian-devel-changes.current
 flim 1:1.14.9+0.201 | 2013-07-05 | debian-devel-changes.current
 pygobject 3.8.3-1   | 2013-07-05 | debian-devel-changes.current
 wl-beta 2.15.9+0.20 | 2013-07-05 | debian-devel-changes.current
 xmhtml 1.1.7-19 | 2013-07-05 | debian-devel-changes.current
 openimageio 1.2.0~b | 2013-07-05 | debian-devel-changes.current
 myproxy 5.9-2   | 2013-07-05 | debian-devel-changes.current
 latex-cjk-chinese-a | 2013-07-05 | debian-devel-changes.current
 sigrok 0.2-2| 2013-07-05 | debian-devel-changes.current
 zeroinstall-injecto | 2013-07-05 | debian-devel-changes.current
 php-net-ipv4 1.3.4- | 2013-07-05 | debian-devel-changes.current
 apel 10.8+0.2012042 | 2013-07-05 | debian-devel-changes.current
 sigrok-cli 0.4.0-1  | 2013-07-05 | debian-devel-changes.current
 ocamlbricks 0.90+bz | 2013-07-05 | debian-devel-changes.current
 beignet 0.2-1   | 2013-07-05 | debian-devel-changes.current
 debian-edu 1.710| 2013-07-05 | debian-devel-changes.current
 dicom3tools 1.00~20 | 2013-07-05 | debian-devel-changes.current
 openturns 1.1-7 | 2013-07-05 | debian-devel-changes.current
 cuetools 1.3.1-13   | 2013-07-05 | debian-devel-changes.current
 qt4-x11 4:4.8.5+dfs | 2013-07-05 | debian-devel-changes.current
 xdemorse 1.3-7  | 2013-07-05 | debian-devel-changes.current
 mew-beta 7.0.50~6.5 | 2013-07-05 | debian-devel-changes.current
 python-whoosh 2.5.1 | 2013-07-05 | debian-devel-changes.current
 privoxy 3.0.21-1| 2013-07-05 | debian-devel-changes.current
 procenv 0.24-1  | 2013-07-05 | debian-devel-changes.current
 libiscwt-java 5.3.2 | 2013-07-05 | debian-devel-changes.current
 apel 10.8+0.2012042 | 2013-07-05 | debian-devel-changes.current
 beignet 0.2-2   | 2013-07-05 | debian-devel-changes.current
 neko 2.0.0-1| 2013-07-05 | debian-devel-changes.current
 sdpa 7.3.9+dfsg-1   | 2013-07-05 | debian-devel-changes.current
 media-player-info 1 | 2013-07-05 | debian-devel-changes.current
 mhc 0.25.1+20130612 | 2013-07-05 | debian-devel-changes.current
 tbb 4.1~20130516-1. | 2013-07-05 | debian-devel-changes.current
 krb5-auth-dialog 3. | 2013-07-05 | debian-devel-changes.current
 gnuradio 3.7.0-2| 2013-07-05 | debian-devel-changes.current
 sane-backends 1.0.2 | 2013-07-05 | debian-devel-changes.current
 libvigraimpex 1.9.0 | 2013-07-05 | debian-devel-changes.current
 starpu 1.0.1-4  | 2013-07-05 | debian-devel-changes.current
 

Bug#702085: Report on what is changed to solve this bug

[Asheesh Laroia]

Here is what I did.

== Configured inbound email ==

I did what was suggested in the earlier comment to configure inbound 
emails to debian-devel-changes to arrive in 
/srv/udd.debian.org/incoming-mail/changes .


== Copy archives to ullmann ==

I copied the archives on master to: 
/srv/udd.debian.org/email-archives/debian-devel-changes/


I also created a symlink in 
/srv/udd.debian.org/email-archives/debian-devel-changes/ for a virtual 
archive mailbox called current that points to 
/srv/udd.debian.org/incoming-mail/changes . This way, no further mailing 
list archive syncing is needed.


I documented this somewhat in 
/srv/udd.debian.org/email-archives/ and if other email archives are 
needed, they can go in that directory one day.


== Reconfigure config-ullmann.yaml accordingly ==

You all saw this patch, probably.

== Store the upload-history code in /srv/udd.debian.org/upload-history ==

I created /srv/udd.debian.org/upload-history which is a copy of 
~lucas/public_html/upload-history from master.debian.org.


paulproteus@ullmann:/srv/udd.debian.org/upload-history$ svn info | grep Root
Repository Root: svn+ssh://lu...@svn.debian.org/svn/collab-qa

This is that same old code, with a trivial change to 'Makefile' to adjust 
it to find the mbox (or mbox.gz) files in 
/srv/udd.debian.org/email-archives/debian-devel-changes/.


== Adjust cron accordingly ==

I added a job to update the *.out files that live in 
/srv/udd.debian.org/upload-history:


udd@ullmann:~$ crontab -l | grep make
49 */6 * * * (( cd /srv/udd.debian.org/upload-history ; make ) ;  $UAR 
upload-history ubuntu-upload-history) | 
/srv/udd.debian.org/udd/scripts/filter-output.rb

This is prefixed to the cron job as uses udd.py to import 
upload-history.


== Thanks ==

That's all I have for now. It seems stable and sane. Feedback welcome.


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

Bug#702085: I have configured this to work via cron

[Asheesh Laroia]

I'll test tomorrow if it remains working, but so far, it seems reasonable.

If it seems to keep working tomorrow, I will document on this bug what all 
I changed. Lucas, you might want me to rearrange some files/directories; 
I'm not sure what idioms there are with regard to /srv/udd/.


-- Asheesh.


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

Bug#702085: A report (no sudo used)

[Asheesh Laroia]

Thanks for this. I'm on the job now.

Some parts are taking a while, so it might take until tomorrow to fully 
fix.



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

Bug#702085: I am going to attempt to execute these instructions

[Asheesh Laroia]

Lucas: I am also working on a project where I want to use the 
upload_history table, so I want to fix this as well.


I hope it's OK if, to implement the plan described here, I use sudo on 
ullmann to switch into the 'udd' user.


I have very rarely logged into Debian machines, but it seems from 
https://db.debian.org/ I can configure sudo for ullmann.


I will definitely not use sudo to switch into 'lucas' or any other 
personal accounts.


I will keep this bug updated as I progress. I am only getting things set 
up so far, and have not actually done anything that requires sudo yet.



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

Bug#702085: A report (no sudo used)

[Asheesh Laroia]

Hey all,

This will probably come as no surprise to Lucas, but I can report that 
with the current scripts, and data copied from 
/home/lucas/public_html/ddc-parser on master, I can generate a reasonable 
upload_history table on my laptop.


Given that, I'm happy to be given whatever keys are necessary (membership 
in group uddadm ?) if that simplifies me actually doing work the work 
described in this ticket. I would be very happy to fix this in actual UDD 
now that I know how those tools work.


-- Asheesh.


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

Bug#706678: status of mentors.d.n data in UDD

[Asheesh Laroia]

On Thu, 27 Jun 2013, Paul Wise wrote:


On Thu, 2013-06-27 at 08:56 +0200, Lucas Nussbaum wrote:


I made some progress on importing mentors.d.n data in UDD. Rather than
importing the Sources file, I imported the SQL data directly, in
mentors_raw_* tables, providing a mentors_most_recent_package_versions
view for convenience.


Excellent.


I built a CGI that demonstrates what can be done:
http://localhost/udd/cgi-bin/mentors.cgi


I guess you mean this, looks good.

http://udd.debian.org/cgi-bin/mentors.cgi


Paul, you suggested to import Sources file. Do you have a use case that
requires Sources to be imported, or do you think that we can close
#706678?


I didn't think there was any other data export than the Sources files,
so yes I think that bug can be closed now.


Yay! Amazing work.

I'm CC:ing paultag and David Lu, who I'm working with this GSoC, on 
metrics around mentorship, first within Debian, and second across other 
projects. I doubt they have time to address the two bugs you mentioned, 
but I thought they'd be interested to hear about this.


-- Asheesh.


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

Bug#692870: Thanks

[Asheesh Laroia]

Hi Eduardo,

It is great to see you active on this Debian bug, and to indicate that 
it's fixed in 2.10!



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

Bug#674067: Thanks!

[Asheesh Laroia]

Hi Eduardo,

Just a quick note to say thanks for publishing and sharing this fix ages 
ago, and for rolling it into the alpine 2.10 release.


Sorry about the oddity with your patches site triggering email rejection. 
I will see what I can do about that.


-- Asheesh.


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

Bug#702198: I confirm the suggested fix addresses the problem

[Asheesh Laroia]

It would be nice if package metadata indicated this conflict.

Regardless, I ran this command and got this output, and my crash went 
away.


$ sudo apt-get install libwebkitgtk-1.0-0/unstable 
libwebkitgtk-3.0-0/unstable libjavascriptcoregtk-3.0-0/unstable


Reading package lists... Done
Building dependency tree
Reading state information... Done
libwebkitgtk-1.0-0 is already the newest version.
Selected version '1.8.1-3.4' (Debian:unstable [amd64]) for 'libwebkitgtk-1.0-0'
Selected version '1.8.1-3.4' (Debian:unstable [amd64]) for 'libwebkitgtk-3.0-0'
Selected version '1.8.1-3.4' (Debian:unstable [amd64]) for 
'libjavascriptcoregtk-3.0-0'
The following packages were automatically installed and are no longer required:
  libgstreamer-plugins-base1.0-0 libgstreamer1.0-0
Use 'apt-get autoremove' to remove them.
The following packages will be DOWNGRADED:
  libjavascriptcoregtk-3.0-0 libwebkitgtk-3.0-0
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 240 not upgraded.
Need to get 5,760 kB of archives.
After this operation, 3,078 kB disk space will be freed.
Do you want to continue [Y/n]?
Get:1 http://mirror.mit.edu/debian/ sid/main libwebkitgtk-3.0-0 amd64 1.8.1-3.4 
[4,755 kB]
Get:2 http://mirror.mit.edu/debian/ sid/main libjavascriptcoregtk-3.0-0 
amd64 1.8.1-3.4 [1,005 kB]

Fetched 5,760 kB in 14s (406 kB/s)
dpkg: warning: downgrading libwebkitgtk-3.0-0 from 1.10.2-2 to 1.8.1-3.4
(Reading database ... 583128 files and directories currently installed.)
Preparing to replace libwebkitgtk-3.0-0 1.10.2-2 (using 
.../libwebkitgtk-3.0-0_1.8.1-3.4_amd64.deb) ...

Unpacking replacement libwebkitgtk-3.0-0 ...
dpkg: warning: downgrading libjavascriptcoregtk-3.0-0 from 1.10.2-2 to 
1.8.1-3.4
Preparing to replace libjavascriptcoregtk-3.0-0 1.10.2-2 (using 
.../libjavascriptcoregtk-3.0-0_1.8.1-3.4_amd64.deb) ...

Unpacking replacement libjavascriptcoregtk-3.0-0 ...
Setting up libjavascriptcoregtk-3.0-0 (1.8.1-3.4) ...
Setting up libwebkitgtk-3.0-0 (1.8.1-3.4) ...


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

Bug#649579: Yes, please take this upstream

[Asheesh Laroia]

Thanks for the bug report!


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

Bug#692870: the PREFDATETIME token (fwd)

[Asheesh Laroia]

On Mon, 19 Nov 2012, Martin Ziegler wrote:


Dear Asheesh,

I forward you an email from Eduardo Chappa. I tested his patch with 
alpine2.02. It resolves the issue.


Hi Martin,

That's great to know!

Mr. Chappa and the re-alpine team (and myself) seemed to experience a 
disagreement over copyright licensing in the past, and as far as I know, 
that's not yet resolved. So I think we can't put his patches into the 
Debian package. (Eduardo, let me know if there's an update to that, or if 
I'm mis-remembering.)


Thinking about a next step...

Perhaps Martin, if you're literate in C, you can write a note in plain 
English to this bug report summarizing what the core problem is that 
Eduardo's patch fixes, and if someone else who hasn't seen Eduardo's work 
wants to write a patch that fixes the issue, and that person is willing to 
license the patch under the terms of the Apache License 2.0 so it can be 
put into the main re-alpine project, and also distributed with the Debian 
package.


I'm hoping not to fan any flames. I realize this can be a touchy subject.

-- Asheesh.


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

Bug#692870: alpine: Wrong weekday if _PREFDATETIME_ is used in reply

[Asheesh Laroia]

On Sat, 10 Nov 2012, Martin Ziegler wrote:


Package: alpine
Version: 2.02+dfsg-2
Severity: normal

If the variable reply-leadin contains _PREFDATETIME_, as for example

   reply-leadin=On _PREFDATETIME_ you wrote:

the weekday in the reply is alway sunday, as for example

   On Sun Nov  7 13:48:00 2012 you wrote:


Interesting! Thank you for this bug report, and we'll look into it 
shortly.


If you're a C programmer, you'll probably find that the bug is simply that 
PREFDATETIME is somehow initialized to 0 and never set to the right 
value. Feel free to check out the upstream re-alpine source and beat me to 
the punch of fixing the issue.


Either way, the bug report is helpful and I'll get on identifying the 
issue as time permits.


Cheers,

-- Asheesh.


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

Bug#691736: I'm looking forward to this list

[Asheesh Laroia]

ACK

In the future, I expect list traffic from 'users' to dominate 'developer' 
discussion, and that we might have to split the list. For now, I think 
debian-cloud is a good start. If we need a new list called 
debian-cloud-devel then we can make that when the time comes.



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

Bug#687398: Now FTBFS...?

[Asheesh Laroia]

I just tried to build my debdiff and do an NMU, and it ends with this 
message:


Finished tests in 0.001844s, 2711.3306 tests/s, 15725.7175 assertions/s.

5 tests, 29 assertions, 0 failures, 0 errors, 0 skips
make[1]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings'
/usr/bin/make -C bindings build 
LIBRHASH_INC=-I/tmp/buildd/rhash-1.2.9/debian/tmp 
LIBRHASH_LD=-Wl,--as-needed -L/tmp/buildd/rhash-1.2.9/debian/tmp 
BINDINGS=mono

make[1]: Entering directory `/tmp/buildd/rhash-1.2.9/bindings'
make -C mono
make[2]: Entering directory `/tmp/buildd/rhash-1.2.9/bindings/mono'
gmcs -target:library -define:UNIX -out:RHash.dll -debug -keyfile:RHash.snk 
AssemblyInfo.cs Bindings.cs Hasher.cs HashType.cs

make[2]: gmcs: Command not found
make[2]: *** [RHash.dll] Error 127
make[2]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings/mono'
make[1]: *** [build-mono] Error 2
make[1]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings'
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//16252 and its 
subdirectories


...why is gmcs not findable in my pbuilder chroot? I checked, and 
mono-gmcs is still a dependency.


Not sure. Heading to bed for now.


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

Bug#687398: More information on how to reproduce the `dlopen' issue

[Asheesh Laroia]

On Wed, 24 Oct 2012, gregor herrmann wrote:

The debdiff arrived some minutes later, but I don't see an upload. 
What's the status?


Oh, snap, I neglected to upload the actual NMU. I will do that tonight, 
unless someone (gregoa?) beats me to it.



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

Bug#653420: Info from Robert Tomsick

[Asheesh Laroia]

-- Forwarded message --
Date: Tue, 2 Oct 2012 16:54:03
From: Robert Tomsick
To: ashe...@asheesh.org
Subject: alpine bug #653420

Asheesh:

I saw you addressed the DES/AES bug that I filed.  Thanks!

Unfortunately that fix won't matter much for users, as encrypted+signed 
messages are currently broken (see bug #653420).


Since that bug's been fixed upstream for a long time now (I linked the patch in 
my report) is there any chance that we can get it in in time for Wheezy?


Thanks,
Rob


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

Bug#682519: Quick notes

[Asheesh Laroia]

First of all, let me say thank you for beginning the work to package 
this in Debian!


Wow... this is a solid package:

* You have a man page.

* It's lintian clean.

* /usr/bin/fbcmd doesn't have a .php extension.

How did you even manage to make such an excellent package!?

I can't find anything terribly wrong with it.

A few questions:

* You embed a copy of a jsonwrapper PHP module in 
/usr/share/fbcmd/facebook/jsonwrapper. Should that be in PEAR? and/or does 
fbcmd work with PHP's built-in JSON stuff? Just trying to minimize 
dependencies, especially embedded copies of them.


* A few scripts seem not useful for Debian users, namely: 
/usr/share/fbcmd/fbcmd_update.php /usr/share/fbcmd/support/test_php.php -- 
should those simply not be installed?


* Why does 'man fbcmd' not mention LOADINFO but 
/usr/share/fbcmd/support/sample-loadinfo-text.php does?


* Is /usr/share/doc/fbcmd/filelist.txt relevant to Debian users?

This is looking great. Great work on the copyright file, too. Hope you can 
answer those questions, and again amazing work.


-- Asheesh.


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

Bug#631758: Why I consider this 'serious'

[Asheesh Laroia]

Hi Holger and all,

This bug makes alpine in the package maintainer's... opinion, 
unsuitable for release, as per 
http://www.debian.org/Bugs/Developer#severities


(I will say I'm open to discussion on the topic.)

The first thing that every new alpine user will see is an enthusiastic 
message which, upon execution, leads to an error in their inbox in short 
order. That's just absurd.


I'm working on untangling my changes in VCS from the NMU that recently 
took place, and will then bring this up to the release team.


Other thoughts welcome!


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

Bug#689251: unblock: alpine/2.02+dfsg-2

[Asheesh Laroia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello, dear release team,

Please unblock package alpine.

I'd like to ask you for a freeze exception for a few fixes to alpine. 
Some might say they are cosmetic fixes, but I want to try to convince 
you that they matter to alpine users.

The -2 release adds two patches to fix two bugs. Attached, please find 
the debdiff against testing.

#631758 -- Broken usage tracking

Right now, when alpine launches, it asks you if you if you want to be 
tracked as a user of alpine. If you say yes, it then emails a 
nonexistent server and you get a bounce message.

This is not really suitable for release.

Discussion with upstream is still ongoing as to the right fix. For now:

Fix: Add a patch that removes the phone-home code.

#414264 -- If you use mbox format, you receive a scary warning about data 
corruption

Right now, when alpine reads an mbox folder on Debian, it tells you the 
permissions are wrong. However, the permission are right, according to 
policy. The warning comes from alpine's ability to use 'mlock' to lock 
the mbox file as needed.

Fix: Add one dependency for alpine: mlock

I am but a humble maintainer, asking for changes past the freeze. I'm 
uploading to unstable now, and attaching the debdiff. Again, sorry 
about the late handling of these issues.

Thank you.

unblock alpine/2.02+dfsg-2

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru alpine-2.02+dfsg/debian/changelog alpine-2.02+dfsg/debian/changelog
--- alpine-2.02+dfsg/debian/changelog	2012-09-08 08:07:59.0 -0700
+++ alpine-2.02+dfsg/debian/changelog	2012-09-30 11:56:54.0 -0700
@@ -1,3 +1,17 @@
+alpine (2.02+dfsg-2) unstable; urgency=low
+
+  * Adding patch from Geoffrey Thomas to disable broken phone-
+home functionality. (Thank you!) (Closes: #631758)
+  * Adding dependency on mlock so that alpine no longer warns
+the user about permissions on /var/spool/mail (or /var/mail).
+(In theory, this new dependency is only required if you are using
+an mbox file, but since reading system mail is within the core
+functionality of alpine, it seems sensible that alpine should do that
+without warnings out of the box.) (Closes: #414264)
+  * ACKing NMU by Johnathan McCrohan. Thank you!
+
+ -- Asheesh Laroia ashe...@asheesh.org  Sun, 26 Aug 2012 13:23:07 -0700
+
 alpine (2.02+dfsg-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru alpine-2.02+dfsg/debian/control alpine-2.02+dfsg/debian/control
--- alpine-2.02+dfsg/debian/control	2012-07-02 16:45:53.0 -0700
+++ alpine-2.02+dfsg/debian/control	2012-08-29 08:31:10.0 -0700
@@ -14,7 +14,7 @@
 
 Package: alpine
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: mlock, ${shlibs:Depends}, ${misc:Depends}
 Recommends: alpine-doc
 Suggests: aspell, mail-transport-agent | exim4
 Conflicts: pine 
diff -Nru alpine-2.02+dfsg/debian/patches/80_remove_phone_home.patch alpine-2.02+dfsg/debian/patches/80_remove_phone_home.patch
--- alpine-2.02+dfsg/debian/patches/80_remove_phone_home.patch	1969-12-31 16:00:00.0 -0800
+++ alpine-2.02+dfsg/debian/patches/80_remove_phone_home.patch	2012-09-30 11:14:06.0 -0700
@@ -0,0 +1,349 @@
+From 01674610679e4af4a6c6d890659573133609cec5 Mon Sep 17 00:00:00 2001
+From: Geoffrey Thomas geo...@ldpreload.com
+Date: Sun, 13 Nov 2011 22:12:38 -0500
+Subject: [PATCH] Remove phone_home code (that sends usage counts to UW)
+
+Presumably the usage counts did nothing to encourage UW to keep developing
+pine. :-( Also, in any case, the address bounces...
+
+Signed-off-by: Geoffrey Thomas geo...@ldpreload.com
+---
+ alpine/mailview.c |   10 -
+ alpine/newuser.c  |   26 +++
+ alpine/send.c |   60 -
+ alpine/send.h |1 -
+ pith/filter.c |2 --
+ pith/pine.hlp |   38 -
+ pith/send.c   |   42 -
+ pith/send.h   |2 --
+ pith/state.h  |1 -
+ 9 files changed, 3 insertions(+), 179 deletions(-)
+
+diff --git a/alpine/mailview.c b/alpine/mailview.c
+index a7eb839..783e965 100644
+--- a/alpine/mailview.c
 b/alpine/mailview.c
+@@ -177,7 +177,6 @@ struct view_write_s {
+ int	url_local_nntp(char *);
+ int	url_local_news(char *);
+ int	url_local_file(char *);
+-int	url_local_phone_home(char *);
+ static int  print_to_printer(SCROLL_S *);
+ int	search_text(int, long, int, char **, Pos *, int *);
+ void	update_scroll_titlebar(long, int);
+@@ -1697,7 +1696,6 @@ struct view_write_s {
+ 	{news:;, 5

Bug#687398: More information on how to reproduce the `dlopen' issue

[Asheesh Laroia]

wRAR, thank you for your excellent detective work.

Here's how you reproduce this build issue without even enabling parallel 
build.


(Sadly I can't actually reproduce the brokenness from within 
dpkg-buildpackage by setting parallel build options; maybe my machine 
doesn't have as many cores as the EC2 machines. But the fix described 
below does clarify the build process which should take care of the 
problem.)


$ (rhash-1.2.9) rm rhash
$ (rhash-1.2.9) make rhash
gcc calc_sums.o hash_print.o common_func.o hash_update.o file_mask.o 
file_set.o find_file.o hash_check.o output.o parse_cmdline.o rhash_main.o 
win_utils.o -o rhash -Llibrhash -lrhash

librhash/librhash.a(plug_openssl.o): In function `load_openssl_runtime':
/tmp/rhash-1.2.9/librhash/plug_openssl.c:141: undefined reference to 
`dlopen'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to 
`dlsym'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to 
`dlsym'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to 
`dlsym'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:149: undefined reference to 
`dlsym'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:149: undefined reference to 
`dlsym'
librhash/librhash.a(plug_openssl.o):/tmp/rhash-1.2.9/librhash/plug_openssl.c:149: 
more undefined references to `dlsym' follow

librhash/librhash.a(plug_openssl.o): In function `load_openssl_runtime':
/tmp/rhash-1.2.9/librhash/plug_openssl.c:142: undefined reference to 
`dlopen'
/tmp/rhash-1.2.9/librhash/plug_openssl.c:143: undefined reference to 
`dlopen'

collect2: error: ld returned 1 exit status
make: *** [rhash] Error 1

When SHARED_TRG is just 'rhash', then the build gets confused in parallel 
mode, I suppose. In principle, it's within its right to be confused; 
you're asking it to do 'make rhash', after all.


So what I'm going to do is:

* Adjust debian/rules to *not* specify SHARED_TRG

* Right after rhash_shared is built, use 'mv' to rename it to 'rhash'

That's all it should take to fix this, I believe.

I'll prepare a 1-day delayed NMU for that. Maintainer, please feel free to 
remove it; I don't mean to step on your toes, just to move this bug along.


I'll attach the debdiff here before doing the upload.


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

Bug#687398: (no subject)

[Asheesh Laroia]

debdiff attached, as promised!diff -Nru rhash-1.2.9/debian/changelog rhash-1.2.9/debian/changelog
--- rhash-1.2.9/debian/changelog2012-06-17 05:11:36.0 -0700
+++ rhash-1.2.9/debian/changelog2012-09-30 15:18:59.0 -0700
@@ -1,3 +1,14 @@
+rhash (1.2.9-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Slight simplification of debian/rules that aims to fix
+parallel builds. In particular, we used to build a dynamically
+linked rhash binary as 'rhash'; now, we build it as 'rhash-shared'
+like the default of the upstream build system, and later rename it
+to 'rhash' as needed. (Closes: #687398)
+
+ -- Asheesh Laroia ashe...@asheesh.org  Sun, 30 Sep 2012 15:16:28 -0700
+
 rhash (1.2.9-7) unstable; urgency=low
 
   * Fixed dependencies of ruby-rhash
diff -Nru rhash-1.2.9/debian/rules rhash-1.2.9/debian/rules
--- rhash-1.2.9/debian/rules2012-06-15 21:54:00.0 -0700
+++ rhash-1.2.9/debian/rules2012-09-30 15:20:21.0 -0700
@@ -63,7 +63,10 @@
 build-rhash:
# Compile static/shared libraries and the program.
+$(MAKE) lib-static lib-shared rhash-shared CFLAGS=$(CFLAGS) 
LDFLAGS=$(LDFLAGS) \
-   LIBCFLAGS=$(LIBCFLAGS) LIBLDFLAGS=$(LIBLDFLAGS) 
SHARED_TRG=rhash
+   LIBCFLAGS=$(LIBCFLAGS) LIBLDFLAGS=$(LIBLDFLAGS)
+   # Move the rhash_shared binary to be called rhash, so that the tests 
use that
+   # (and also since that is the binary name we will install into /usr/bin)
+   mv rhash_shared rhash
# Compile language bindings.
mkdir -p $(DESTDIR)  ln -fs $(CURDIR)/librhash $(DESTDIR)/rhash
ln -fs $(CURDIR)/librhash/librhash.so.0 $(DESTDIR)/  ln -fs 
$(DESTDIR)/librhash.so.0 $(DESTDIR)/librhash.so

Bug#687931: JPEG 2000, signed ints, and C

[Asheesh Laroia]

I can reproduce the crash.

Note that openjpeg-tools does not crash on this file. Demonstration:

Run these:

sudo apt-get install openjpeg-tools

wget 
http://bugs.debian.org/cgi-bin/bugreport.cgi\?msg\=5\;filename\=jas_image_readcmpt2_SIGABRT.j2k\;att\=1\;bug\=687931 
-O bugreport.j2k


Then when you run this command:

j2k_to_image -i bugreport.j2k -o rofl.tif

You get this output:

[INFO] tile 1 of 1
[INFO] - tiers-1 took 0.076004 s
[INFO] - dwt took 0.004001 s
[INFO] - tile decoded in 0.080005 s
Generated Outfile rofl.tif

rofl.tif is all black, 888x458 pixels. (Roland, is that what you were 
expecting?)



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

Bug#666176: Suggesting disabling tracker-miner-evolution

[Asheesh Laroia]

Hey all,

Given the lack of movement by upstream on this issue, and the fact that 
they acknowledge the bug, and that 
https://bugzilla.redhat.com/show_bug.cgi?id=733523 has been open for about 
a year with no evidence of resolution coming soon, I would suggest simply 
not building the (known-bad) tracker-miner-evolution binary package.


One day, when that code works again, we can enable it. (Alternately, a 
testing-proposed-updates version of src:tracker could disable the binary 
package, and then sid could keep it enabled awaiting the day that it works 
again.)


I would suggest just disabling it in sid, though.

Michael, is that a resolution you'd be willing to accept?

Thanks!

-- Asheesh.


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

Bug#682519: Still looking for sponsor?

[Asheesh Laroia]

Hi there,

I'm a Debian Developer and possibly interested in reviewing and sponsoring 
this! Are you still looking?


Cheers,

-- Asheesh.


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

Bug#687582: alpine: deadlock in signal handler

[Asheesh Laroia]

Thank you for this excellent bug report. I've run into this issue before, 
and your diagnosis is very helpful!



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

Bug#657046: alpine: diff for NMU version 2.02+dfsg-1.1

[Asheesh Laroia]

On Sat, 8 Sep 2012, Ulrich Dangel wrote:


Dear maintainer,

I've prepared an NMU for alpine (versioned as 2.02+dfsg-1.1). The diff 
is attached to this message.


Hi Ulrich, and Jonathan,

Thank you for improving this package, and sorry I didn't do this yet! I 
will be working on requesting a freeze exception for this shortly.


I'm honored that you have improved Debian, and sorry if my own latency has 
delayed that.



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

Bug#685961: pu: package alpine/2.00+dfsg-6+squeeze1

[Asheesh Laroia]

On Wed, 29 Aug 2012, Adam D. Barratt wrote:

I assume from reading through the bug report that the issue does not 
affect the version of alpine currently in wheezy / sid?  If so, please 
add an appropriate fixed version to make this clear.


It doesn't look like this happened yet?


Just did; sorry about the delay.


I've prepared a minimal package update that adds the patch that fixes the
issue. I've tested that it builds fine in a stable pbuilder; before 
uploading,

I have tested it on a machine running stable, where it works fine.


Assuming my comment above about the issue not affecting wheezy and sid
is correct, please feel free to go ahead with the upload, having updated
the bug report as above.


I checked the source of 2.02 myself to confirm that the bug is fixed there so 
have flagged the package for acceptance; thanks.


Thank you!

Sorry to make you do that check.

-- Asheesh.


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

Bug#414264: Fixed shortly

[Asheesh Laroia]

tags 414264 pending
thanks

This warning can be fixed by simply adding a dependency on 'mlock' within 
the packaging, so that is what I have done. It's a simple solution. Thanks 
to all for the discussion!


I've committed the packaging changes to the Subversion repository I use 
for alpine packaging, which can be found here in case someone needs the 
fix sooner:


svn://svn.debian.org/svn/collab-maint/ext-maint/alpine/trunk

-- Asheesh.


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

Bug#657046: (no subject)

[Asheesh Laroia]

Thanks for this bug report!

I can confirm the issue, and I believe this is very important. Upstream 
has a patch that fixes it, but we should try to get the updated version 
into the upcoming release of Debian.


I will work on that. Thank you again for the report.


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

Bug#685961: pu: package alpine/2.00+dfsg-6+squeeze1

[Asheesh Laroia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu

Hi stable release team,

(This is my first stable proposed update, so if I get a process item wrong,
please pardon me and help me correct it. Thanks!)

Bug #653238 describes a crasher bug, possibly a security vulnerability, in
alpine. The security team has indicated on the bug that they're not going to
open a Debian Security Advisory for the alpine bug, and indicate, You/the
maintainer may choose to fix it in (old)stable through a point update, or leave
it at this. I choose to update stable through a point update.

I've prepared a minimal package update that adds the patch that fixes the
issue. I've tested that it builds fine in a stable pbuilder; before uploading,
I have tested it on a machine running stable, where it works fine.

I wanted to get your approval to upload the package to stable.

As a footnote: I believe the process on my end is:

* Get y'all's approval
* Upload the package using dput ftp-master alpine_2.00+dfsg-6+squeeze1.dsc
(with a binary package, as usual in Debian)
* Watch it flow through into squeeze-updates with no further effort from me

If I have some of that wrong, then let me know. I've read the documentation and
believe I understand, but want to be careful to not mess anything up.

Thanks!

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores)
diff -u alpine-2.00+dfsg/debian/changelog alpine-2.00+dfsg/debian/changelog
--- alpine-2.00+dfsg/debian/changelog
+++ alpine-2.00+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+alpine (2.00+dfsg-6+squeeze1) squeeze; urgency=low
+
+  * Fix a crash in the embedded copy of UW-IMAP, CVE-2008-5514.
+(Closes: #653238)
+
+ -- Asheesh Laroia ashe...@asheesh.org  Sun, 26 Aug 2012 16:58:01 -0700
+
 alpine (2.00+dfsg-6) unstable; urgency=low
 
   * Add diversion for pico and remove conflict with nano.
diff -u alpine-2.00+dfsg/debian/patches/series alpine-2.00+dfsg/debian/patches/series
--- alpine-2.00+dfsg/debian/patches/series
+++ alpine-2.00+dfsg/debian/patches/series
@@ -9,0 +10 @@
+60_fix_embedded_uw_imap.patch
only in patch2:
unchanged:
--- alpine-2.00+dfsg.orig/debian/patches/60_fix_embedded_uw_imap.patch
+++ alpine-2.00+dfsg/debian/patches/60_fix_embedded_uw_imap.patch
@@ -0,0 +1,21 @@
+diff -urN alpine-2.00/imap/src/c-client/rfc822.c alpine-2.00.fixed/imap/src/c-client/rfc822.c
+--- alpine-2.00/imap/src/c-client/rfc822.c	2008-06-04 11:46:10.0 -0700
 alpine-2.00.fixed/imap/src/c-client/rfc822.c	2012-08-26 17:12:39.678307877 -0700
+@@ -1351,6 +1351,7 @@
+ 
+ static long rfc822_output_char (RFC822BUFFER *buf,int c)
+ {
++  if ((buf-cur == buf-end)  !rfc822_output_flush (buf)) return NIL;
+   *buf-cur++ = c;		/* add character, soutr buffer if full */
+   return (buf-cur == buf-end) ? rfc822_output_flush (buf) : LONGT;
+ }
+@@ -1374,7 +1375,8 @@
+   len -= i;
+ }
+ /* soutr buffer now if full */
+-if (len  !rfc822_output_flush (buf)) return NIL;
++if ((len || (buf-cur == buf-end))  !rfc822_output_flush (buf))
++  return NIL;
+   }
+   return LONGT;
+ }

Bug#680407: unblock: liblicense/0.8.1-3

[Asheesh Laroia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release time,

I kindly request an unblock for package liblicense.

This 0.8.1-3 (and its predecessor, 0.8.1-2) was prepared before the freeze, and
is only delayed because of a delay in its sponsorship since a co-maintainer is
not a DD.

The changelog for 0.8.1-2 and 0.8.1-3:

diff -Nru liblicense-0.8.1/debian/changelog liblicense-0.8.1/debian/changelog
--- liblicense-0.8.1/debian/changelog   2012-03-03 09:24:24.0 -0600
+++ liblicense-0.8.1/debian/changelog   2012-06-25 20:23:04.0 -0600
@@ -1,3 +1,31 @@
+liblicense (0.8.1-3) unstable; urgency=low
+
+  * Adding a Replaces / Breaks line to liblicense-dev's control, since
+we moved the .a static libs from the liblicense package to -dev.
+Thanks, Andreas! (Closes: #673803)
+  * Adding a development symbolic link.
+
+ -- Paul Tagliamonte paul...@debian.org  Mon, 21 May 2012 16:24:59 -0400
+
+liblicense (0.8.1-2) unstable; urgency=low
+
+  * Acknowledge NMU. (Closes: #662015)
+  * Drop NMU diff, rewrite rules to use dh9, and overrides where needed.
+- By using the short-style rules, we restore build-arch sanity.
+  (Closes: #655003)
+- Bumped b-d on debhelper up to 9
+  * Add patch against modules/io/gsf.c, rename the clone function to
+gsf_clone. (Closes: #669451)
+  * Move -cli to utils from libs. (Closes: #663074)
+  * Build for all versions of Python (Closes: #662012)
+  * Remove brace-expansion.
+- Move the .a files into the -dev package
+  * update to debian/liblicense3.dirs.
+  * Dropped the lintian overrides, since the issues were resolved upstream.
+  * Update to policy 3.9.3. No further changes.
+
+ -- Paul Tagliamonte paul...@ubuntu.com  Tue, 08 May 2012 16:47:21 -0400

The rest of the debdiff follows:

diff -Nru liblicense-0.8.1/debian/compat liblicense-0.8.1/debian/compat
--- liblicense-0.8.1/debian/compat  2012-03-03 08:21:31.0 -0600
+++ liblicense-0.8.1/debian/compat  2012-05-21 14:24:07.0 -0600
@@ -1 +1 @@
-5
+9
diff -Nru liblicense-0.8.1/debian/control liblicense-0.8.1/debian/control
--- liblicense-0.8.1/debian/control 2012-03-03 08:21:31.0 -0600
+++ liblicense-0.8.1/debian/control 2012-06-25 20:13:16.0 -0600
@@ -2,10 +2,10 @@
 Section: libs
 Priority: extra
 Maintainer: Asheesh Laroia ashe...@asheesh.org
-Uploaders: Paul Tagliamonte paul...@ubuntu.com
-Standards-Version: 3.9.2
+Uploaders: Paul Tagliamonte paul...@debian.org
+Standards-Version: 3.9.3
 X-Python-Version: = 2.5
-Build-Depends: debhelper (= 5.0.38), dh-autoreconf, libcurl4-gnutls-dev,
+Build-Depends: debhelper (= 9.20120115~), dh-autoreconf, libcurl4-gnutls-dev,
  libvorbis-dev, libtag1-dev, libflac-dev, libraptor-dev, libexempi-dev,
  libid3-3.8.3-dev, libgsf-1-dev, python-all-dev (= 2.5), libglib2.0-dev,
  xsltproc, docbook-xsl, libtool, libexpat-dev
@@ -16,6 +16,8 @@
 Package: liblicense-dev
 Section: libdevel
 Architecture: any
+Replaces: liblicense3 ( 0.8.1-3)
+Breaks: liblicense3 ( 0.8.1-3)
 Depends: liblicense3 (= ${binary:Version}), ${misc:Depends}
 Description: Development headers for the liblicense package
  An implementation of the Creative Commons metadata standards for saving
@@ -51,6 +53,7 @@
- license properties, as described by ccREL

 Package: liblicense-cli
+Section: utils
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Command line interface for license metadata
diff -Nru liblicense-0.8.1/debian/liblicense3.dirs
liblicense-0.8.1/debian/liblicense3.dirs
--- liblicense-0.8.1/debian/liblicense3.dirs2012-03-03 08:21:31.0
-0600
+++ liblicense-0.8.1/debian/liblicense3.dirs2012-05-21 14:24:07.0
-0600
@@ -1,3 +1,3 @@
 usr/lib
-usr/lib/liblicense/0.8/io
-usr/lib/liblicense/0.8/config
+usr/lib/liblicense/0.8.1/io
+usr/lib/liblicense/0.8.1/config
diff -Nru liblicense-0.8.1/debian/liblicense3.install
liblicense-0.8.1/debian/liblicense3.install
--- liblicense-0.8.1/debian/liblicense3.install 2012-03-03 08:21:31.0
-0600
+++ liblicense-0.8.1/debian/liblicense3.install 2012-05-21 14:24:07.0
-0600
@@ -1,2 +1,2 @@
 usr/lib/liblicense.so.*
-usr/lib/liblicense/*/*/*.{so,a}
+usr/lib/liblicense/*/*/*.so
diff -Nru liblicense-0.8.1/debian/liblicense3.lintian-overrides
liblicense-0.8.1/debian/liblicense3.lintian-overrides
--- liblicense-0.8.1/debian/liblicense3.lintian-overrides   2012-03-03
08:32:59.0 -0600
+++ liblicense-0.8.1/debian/liblicense3.lintian-overrides   1969-12-31
18:00:00.0 -0600
@@ -1,4 +0,0 @@
-liblicense3 binary: extra-license-file
-# This is actually a F-P. This was fixed in Lintian it's self
-# with revision `8543ed2db3e1efd74d4f2fd8126d9570dbe33d73'.
-# (VCS Commit diff:
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commit;h=8543ed2db3e1efd74d4f2fd8126d9570dbe33d73
)
diff -Nru liblicense-0.8.1/debian/liblicense-cli.lintian-overrides
liblicense-0.8.1/debian

Bug#680141: This seems fine to upload

[Asheesh Laroia]

John Stamp, can you clear the debdiff with the release team in an email to 
debian-release? Just email them the debdiff and ask if that would be okay, 
and if they say yes, I will upload this.


(If you already have a sponsor lined up, then that's fine, too.)

Thanks!



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

Bug#680141: RFS: liblastfm/0.4.0~git20090710-2 [RC]

[Asheesh Laroia]

I'm concerned by the following lintian warnings on mentors,
which I can reproduce locally:

W: liblastfm-fingerprint0: hardening-no-fortify-functions 
usr/lib/x86_64-linux-gnu/liblastfm_fingerprint.so.0.4.0
W: liblastfm0: hardening-no-fortify-functions 
usr/lib/x86_64-linux-gnu/liblastfm.so.0.4.0

Other than that, this seems reasonable so far!



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

Bug#383853: (no subject)

[Asheesh Laroia]

I suggest that we rename 'rred' to 'apply-pdiff'.

If that is a suitable solution, I can try to implement it.

(I honestly found it quite surprising, nearly scary, that apt was printing 
this non-word. It made me suspicious that an attacker had compromised my 
machine. Not super rational of me, but you can only imagine how non-DDs 
feel about it, then.)




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

Bug#676478: cuetools: please consider depending on id3v2 | python-mutagen

[Asheesh Laroia]

Excerpts from Rogério Brito's message of Thu Jun 07 04:30:02 -0400 2012:
 Package: cuetools
 Version: 1.3.1-12
 Severity: wishlist
 
 Hi.
 
 cuetools depends on id3v2 which is currently badly broken (see its
 bugreports and their age).
 
 OTOH, mid3v2 from python-mutagen is a drop-in replacement for id3v2 with
 many fixes (and is actively maintained upstream).
 
 Therefore, it would be great to have cuetools be updated to have its
 dependencies be satisfied by python-mutagen instead of forcing a broken
 package on the users.
 
 Regards.
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (350, 'experimental')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.4-trunk-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages cuetools depends on:
 ii  id3v2  0.1.12-2
 ii  libc6  2.13-33
 
 Versions of packages cuetools recommends:
 ii  flac  1.2.1-6
 
 cuetools suggests no packages.
 
 -- no debconf information
 

Interesting!

I maintain cue2toc.

I wonder if I can write a patch for cuetools that provides a
binary with the same interface as cue2toc, and also fix this
dependency on /usr/bin/id3.

It seems quite likely, actually, that both are true.

There's only one hit for 'id3' in the entire upstream git repo:

➜  cuetools git:(master) git grep id3
src/tools/cuetag.sh:id3()
src/tools/cuetag.sh:# see http://id3lib.sourceforge.net/id3/idev1.html
src/tools/cuetag.sh:id3 $trackno $file

Anyway, whether or not I'm the one to do it, it should be an easy
fix. The only reference to id3 is in that shell script.

-- Asheesh.



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

Bug#674067: alpine: include patch to properly display folder names with special characters

[Asheesh Laroia]

Sadly, Eduardo Chappa does not give us permission to share his work under 
the terms of the Apache 2.0 License, so we can't include it.


If there is another way to improve the Debian package to have this bug 
fixed, that'd be great. One way is as follows:


In particular, if you can describe the fix in English in a way that does 
not include copyrighted code by Mr. Chappa, then someone in the Debian 
community can reimplement it.


I have not yet read that patch file, so I could implement it if you did 
that and it was a fairly simple change.


-- Asheesh.



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

Bug#669451: liblicense: FTBFS: gsf.c:105:1: error: conflicting types for 'clone'

[Asheesh Laroia]

Thanks for reporting this bug! Will handle shortly.

Bug#641479: Ping: alpine: Contains non-free code

[Asheesh Laroia]

On Sat, 3 Mar 2012, Edward Allcutt wrote:

This is RC and appears to need a maintainer upload with a repacked upstream 
tarball, regardless of whether upstream will accept patches.


Are any of the maintainers planning to handle this soon?


You're right that in the near term, a fresh upload is required. I will 
work on that soon.




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

Bug#662012: python-liblicense: Please build for all Python versions

[Asheesh Laroia]

On Sat, 3 Mar 2012, Simon McVittie wrote:


Package: python-liblicense
Version: 0.8.1-1.1
Severity: wishlist

The Debian Python policy is to build Python modules for all supported Python
versions. This is non-trivial in an Autotools package, so I didn't think it
was appropriate for an NMU. See python-dbus for an example (which might not
be perfect, but it seems to work), or ask around in the Python team(s) for
more exemplary examples.


Thanks for this. I'll investigate python-dbus.

If you feel like submitting a patch, I would enthusiastically 
review/upload. I will get to this eventually even if you don't, so no 
worries.




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

Bug#661565: Offer to mentor

[Asheesh Laroia]

Hi Jonathan,

Thanks for filing this ITP. I think this will be a great package to have 
in Debian.


When the packaging is ready for review, feel free to specially send it to 
me. I will set aside time to review the package, and if it is good, upload 
the package to the Debian archive.


Looking forward to it!

-- Asheesh.



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

Bug#655003: liblicense: broken build-{arch,indep} targets

[Asheesh Laroia]

I ACK this bug. Thanks for filing it!

It's amazing the kind of nonsense I used to do. I'll fix this up. (-:



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

Bug#655004: liblicense: broken binary-indep target

[Asheesh Laroia]

I ACK this bug.



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

Bug#655006: python-liblicense: doesn't depend on python

[Asheesh Laroia]

I ACK this bug. Thanks for filing it!



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

Bug#653238: alpine vulnerable to CVE-2008-5514

[Asheesh Laroia]

Thanks for reporting this. I will investigate shortly and work with the 
appropriate security teams to ship an update as needed.
-- 
Please excuse my brevity.

Jonathan Sailor jsai...@cs.brown.edu wrote:

Package: alpine
Version: 2.00+dfsg-6
Severity: grave
Tags: security
Justification: user security hole

The alpine package does not include a fix for CVE-2008-5514.

Vulnerable: lenny lenny-backports squeeze
Fixed in upstream: wheezy sid

The patch is available at [1]. Note since that version is written for
uw-imap, the path to rfc822.c is imap/src/c-client/rfc822.c.

[1] 
http://people.debian.org/~nion/nmu-diff/uw-imap-2007b~dfsg-1_2007b~dfsg-1.1.patch

~jon.


-- System Information:
Debian Release: 6.0.3
APT prefers stable
APT policy: (750, 'stable'), (70, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages alpine depends on:
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libgssapi-krb5-2 1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries - k
ii libkrb5-3 1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries
ii libldap-2.4-2 2.4.23-7.2 OpenLDAP libraries
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
ii libpam0g 1.1.1-6.1+squeeze1 Pluggable Authentication Modules l
ii libssl0.9.8 0.9.8o-4squeeze4 SSL shared libraries

alpine recommends no packages.

Versions of packages alpine suggests:
ii aspell 0.60.6-4 GNU Aspell spell-checker
ii postfix [mail-transport 2.7.1-1+squeeze1 High-performance mail transport ag

-- debconf-show failed

Bug#645768: alpine ignores /etc/mailname

[Asheesh Laroia]

On Tue, 18 Oct 2011, Petr Baudis wrote:


Package: alpine
Version: 2.00+dfsg-6
Severity: normal


In case there is no user-domain variable setting in alpine configuration
file, alpine seems to default on the hostname of the machine,
disregarding /etc/mailname, which is the default way to specify
mail domain in organizations with many workstations. Other MUAs respect
this but alpine needs to be configured separately.


Interesting, thank you. In the near term I will take this up with 
upstream.




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

Bug#123150: This seems to be a libmikmod issue

[Asheesh Laroia]

I can reproduce this problem running modern pulseaudio.

When I disable pulseaudio's esound compatibility, the problem goes away. I 
also tested recompiling libmikmod without the esd driver enabled; the 
problem goes away then, too. (libmikmod then uses ALSA output, which works 
great.)


This suggests to me that the problem is in libmikmod's esd driver. For 
that reason, I reassigned the bug to libmikmod.


I would suggest that someone remove the ESD driver, but alas, libmikmod is 
orphaned.


I wrote a long-form request for adoption here: 
http://www.asheesh.org/note/debian/rfbp.html


But even if my web page is down, this bug now contains approximately all 
the information necessary for someone to come to same conclusion as I have 
come to!


-- Asheesh.



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

Bug#643349: alpine: FTBFS: flocklnx.c:60:7: error: format not a string literal and no format arguments [-Werror=format-security]

[Asheesh Laroia]

Thanks for filing this bug. I will take a look and see what the best fix 
is.




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

Bug#609592: Any updates on this?

[Asheesh Laroia]

Hi dear bug and maintainer,

I was hoping to run MySQL 5.5, and noticed that there is even an 
(UNOFFICIAL) source package here: 
http://people.debian.org/~nobse/mysql-5.5/mysql-5.5_5.5.13-2.dsc


Is there a reason this isn't in Debian? If it, for example, needs certain 
kinds of testing, I could work on that.


Let me know how I can help push this forward.

-- Asheesh.



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