Your message dated Sun, 31 Jul 2016 11:45:22 +0800 with message-id <1469936722.6337.45.camel@debian.org> and subject line Re: Bug#831829: RFS: self-destructing-cookies/0.4.10-1 [ITP] -- delete cookies and LocalStorage after tabs using them have been closed has caused the Debian Bug report #831829, regarding RFS: self-destructing-cookies/0.4.10-1 [ITP] -- delete cookies and LocalStorage after tabs using them have been closed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 831829: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831829 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: RFS: self-destructing-cookies/0.4.10-1 [ITP] -- delete cookies and LocalStorage after tabs using them have been closed
- From: Sean Whitton <spwhitton@spwhitton.name>
- Date: Tue, 19 Jul 2016 16:25:59 -0700
- Message-id: <[🔎] 20160719232559.GA18106@hephaestus.silentflame.com>
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package self-destructing-cookies. With this addon installed, Firefox will delete cookies and LocalStorage when there are no longer any open tabs using those cookies or LocalStorage entries. Sites whose cookies or LocalStorage you want to keep may be whitelisted. As upstream puts it, this addon implements a new cookie policy. It's like Firefox's built in capacity to delete all cookies when the browser is closed, except that it acts even sooner to remove cookies that might be used to track the user in undesirable ways. It provides a layer of privacy protection for those of us who care about lingering cookies but don't want to regularly restart our browsers. I intend to maintain this package as part of the pkg-mozext team. * Package name : self-destructing-cookies Version : 0.4.10-1 Upstream Author : Ove <sdc@elektro-eel.org> * URL : https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/ * License : GPL-2+ Section : web Download with dget: dget -x http://mentors.debian.net/debian/pool/main/s/self-destructing-cookies/self-destructing-cookies_0.4.10-1.dsc Or build it with gbp: gbp clone --pristine-tar https://anonscm.debian.org/git/pkg-mozext/self-destructing-cookies git checkout debian/0.4.10-1 git verify-tag debian/0.4.10-1 # if you have my key gbp buildpackage Thanks. -- Sean WhittonAttachment: signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
- To: Sean Whitton <spwhitton@spwhitton.name>
- Cc: 831829-done@bugs.debian.org
- Subject: Re: Bug#831829: RFS: self-destructing-cookies/0.4.10-1 [ITP] -- delete cookies and LocalStorage after tabs using them have been closed
- From: Paul Wise <pabs@debian.org>
- Date: Sun, 31 Jul 2016 11:45:22 +0800
- Message-id: <1469936722.6337.45.camel@debian.org>
- In-reply-to: <[🔎] 20160730211551.GA26116@hephaestus.silentflame.com>
- References: <[🔎] 20160719232559.GA18106@hephaestus.silentflame.com> <[🔎] CAKTje6Fab2Ltbp_C_9Y9Xp9C8OF3NnPM9SMYcEtnxz=s_z4iSw@mail.gmail.com> <[🔎] 20160730211551.GA26116@hephaestus.silentflame.com>
On Sat, 2016-07-30 at 14:15 -0700, Sean Whitton wrote: > Of course, other people might prefer doing things in the way you > > suggest, but it seems like the problem is a hard one.[2] Anyway, I've > > forwarded your suggestion to upstream. Thanks for that. > It's in unstable now, but could you explain why this was something we > had to wait on? I thought that DAK would do the right thing if we went > > ahead and uploaded. It would FTBFS in pbuilder for me unless I fiddled with my chroot :) > According to [1], JPM is a simple command-line tool to make developing > addons easier. It doesn't perform any building other than packing the > source into an .xpi, for which we have dh_xul-ext. > > I confirmed with upstream that there is no source code repository other > than the contents of the .xpi file that I obtained from > addons.mozilla.org. There is no build process that converts some other > source code into the contents of the .xpi file. > > So in summary the changelog entry probably shouldn't be there; it's like > saying "the author of this python library now uses pylint during > > development" in a changelog.[3] Thanks for clarifying, that satisfies my concerns. I do wonder if JPM and dh_xul-ext produce binary-identical .xpi files. Reading the JPM getting started guide, I think that looks useful to have in Debian for extension authors. I would probably use it myself, especially if it is updated for WebExtensions when that happens. > Upstream sent me a copy, and I've included it in > debian/missing-sources/. They will include all .svg files in the next > release. Great. > Patched and forwarded. Perfect. > I would prefer to install both of them. I can imagine a user browsing > to the directory in a graphical file manager and wanting to open the > HTML file, and a user of a different temperament using a terminal pager. Fair enough I guess. > Done, and I filed a wishlist bug against Lintian to have it suggest > > adding upstream metadata. Great :) The Repository link should probably be Repository-Browse though. Any idea if Mozilla uses actual git/cvs repositories? > Somebody already has: #807270. Aha. > It downloads it as RSS (XML), and then converts this. amo-changelog > does not expose its conversion functions, so rather than come up with an > ad hoc solution for this package, I've filed #833008. Great! > Overridden. Suggested to upstream. I would suggest only overriding it if upstream refuses to sign tarballs. > This is in a code comment, so I'm not going to prepare a patch. Could you mention this to upstream next time you contact them? > I don't want to patch these files since the fixes will get overwritten > by amo-changelog, but I have informed upstream of the error. Ack, thanks. > I believe that upstream has this empty file to satisfy Mozilla packaging > conventions. My package does not install it. Fair enough. > Switched to https in the Debian copyright file. Rather than break > anything in the actual codebase, I've forwarded the list to upstream and > suggested they look into changing it. Thanks. > False positive. The .asc is in the query string and this URI is a link > to the .xpi file. Filed #833012. Aha, great! > Package updated on mentors and in my git repository. Uploaded to NEW. -- bye, pabs https://wiki.debian.org/PaulWiseAttachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---