Bug#1037230: htmldoc converts non-breaking space into "Â" in PDF
Package: htmldoc Version: 1.9.7 All "" in the webpage are converted to visible  (U+00C2) in PDF. with htmldoc -t pdf --webpage --quiet --no-title --textfont helvetica --left 16 --bottom 8 --top 8 --browserwidth 800 --headfootsize 8.0 --fontsize 7.0 --header xtx --footer xd/ --outfile output.pdf input.html (as called from within AWStats Advanced Web Statistics 7.9 build 20230108) Here is an example: "http://www.w3.org/TR/html4/loose.dtd;> http://www.awstats.org)"> Statistik fr freiburghaus.com (2023-06) - main | | | | cellpadding="2" border="0"> Zusammenfassung class="aws_blank"> border="1"> Zeitraumclass="aws" colspan="5">Monat Juni 2023 Erster Zugriff 01.06.2023 - 00:35 Letzter Zugriff 07.06.2023 - 09:15 bgcolor="#FFAA66">Unterschiedliche Besucherbgcolor="#F4F090">Anzahl der Besuchebgcolor="#4477DD">Seitenbgcolor="#66DDEE">Zugriffebgcolor="#2EA495">Bytes gesehener Traffic*3538(1.08Besuche/Besucher)52(1.36Seiten/Besuch)54(1.42Zugriffe/Besuch)200.98 KB(5.28KB/Besuch) nicht gesehener Traffic*colspan="2"> 72163498.42 KB looks like this in Firefox: looks like this in PDF: I suggest that conversion of "" should be corrected. I am using Ubuntu Linux 20.04.6, Linux 5.4.0-150-generic on x86_64 Best regards, Andreas U. Freiburghaus, M.D. * MedConsulting MedConsulting Dr. A.U. Freiburghaus * im Chramen 9 medconsulting.ch * CH-8712 Staefa * Switzerland * Tel. +41-(0)44 796 42 10 * UID: CHE-108.604.886 Google Maps <http://maps.google.ch/maps?f=q=s_q=de==%22medconsulting%22+%228712+St%C3%A4fa%22=4=154c=47.2379,8.731857=0.008887,0.012531=UTF8=14=B> * * Medical & Scientific Ghostwriting * Database & Software Coaching * Business Consulting, Communications * * * * * * * * * smime.p7s Description: S/MIME Cryptographic Signature
Bug#987878: release.debian.org: libffi6 is not included in bullseye, it is in buster and again in sid
Package: release.debian.org Severity: normal X-Debbugs-Cc: fr...@geoinfo.tuwien.ac.at it is included in buster and then again in sid. lacking libffi6 breaks installation routines of other programs, which are asking for it (e.g. ghcup - which could also be included in debian). thank you for building bullseye!
Bug#965055: onionshare man page: "crypto key lives in /tmp/onionshare/tmpXXX/private_key"
Hi, On 16.07.20 22:52, Jakub Wilk wrote: > * Jakub Wilk , 2020-07-15, 11:30: >> The onionshare(1) man page says: "the crypto key lives in >> /tmp/onionshare/tmpXXX/private_key". I don't belive this is correct. > > The onionshare-gui(1) man page includes this sentence too. Yes, I'm well aware of it and fixed that in my commit from two days ago :) Ulrike
Bug#939112: tails-installer: Python2 removal in sid/bullseye -- drop python-distutils-extra build dependency
Hi! On 02.09.19 15:51, Chris Lamb wrote: > So, tails-installer will need to be ported "upstream" to Python 3 > first but thanks for filing this tracking bug. :) Tails Installer will be removed from Debian by the end of the year. i.e. let's not bother with this for Debian. However, as we will continue to ship the package in Tails for cloning Tails devices, it might be relevant there. Cheers! u.
Bug#908068: [Pkg-privacy-maintainers] Bug#908068: torbrowser-launcher fails with torbrowser 8.0
Hi! intrigeri: > I have a fix ready somewhere, not sure I've pushed this to the > upstream Git repo yet. I'll try to fix that upstream by the end of > the week. thanks, intrigeri. Ulrike
Bug#851236: Ping?
Hi Russell, if this problem is not present anymore, I suggest we close this bug. Cheers! u.
Bug#814190: [Pkg-privacy-maintainers] Bug#814190: Ping
Salut Antoine, Antoine Beaupré: > Control: found 814190 5.0.6+dfsg-1~bpo9+1 > It *looks* like it mostly finished correctly, but failed to > unmount. Here's the output in the text area: It basically failed exactly at the two moments (writing the MBR and unmounting the device) where polkit it called :) > ['/sbin/sgdisk', '--print', '/dev/sdc'] > Problem opening /dev/sdc for reading! Error is 13. > You must run this program as root or use sudo! > > ['/sbin/sgdisk', '--zap-all', '/dev/sdc'] > Problem opening /dev/sdc for reading! Error is 13. > You must run this program as root or use sudo! > Problem opening '' for writing! Program will now terminate. > Warning! MBR not overwritten! Error is 2! > /usr/bin/pkexec /usr/bin/syslinux -d syslinux /dev/sdc1 > polkit-agent-helper-1: pam_authenticate failed: Authentication failure > Error executing command as another user: Not authorized > > This incident has been reported. > > Un problème est survenu lors de l'exécution de la commande suivante : > `/usr/bin/pkexec /usr/bin/syslinux -d syslinux /dev/sdc1` > Authentication is needed to run `/usr/bin/syslinux' as the super user > Authenticating as: Antoine Beaupre,,, (anarcat) > Password: > AUTHENTICATION FAILED === > Exception in thread Thread-2: > Traceback (most recent call last): > File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner > self.run() > File "/usr/lib/python2.7/dist-packages/tails_installer/gui.py", line 264, > in run > self.live.log.exception(unicode(e)) > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: > ordinal not in range(128) > > > I did enter my password at the prompt, but it failed to do the right > thing. What does `pkexec whoami` tell you? Cheers! u.
Bug#903117: tails-installer: Mistakes in packages.debian.org list of files?
Kenichiro MATOHARA: First of all, I think my previous reply did not address your findings correctly. Good news though: I've had a closer look at this issue today. > I was operating while looking at the Tails page. > >> Start Tails Installer: >> tails-installer-launcher > https://tails.boum.org/install/expert/usb/index.en.html I've fixed this in the Tails documentation. Thanks for noticing! > When trying to start up with tails-installer-launcher, this command was not > found. > tails-installer existed. Correct. Tails previously called the tails-installer-launcher executable, because calling tails-installer directly did not provide the possibility to give a device on the command line. This was dropped with commit 799b272ea9c1eff3e200476bc291ab9fbaca9003. > The list of files on packages.debian.org is tails-installer-launcher. > >> $ w3m -dump >> https://packages.debian.org/stretch-backports/amd64/tails-installer/filelist|grep >> bin >> /usr/bin/tails-installer-launcher >> $ w3m -dump >> https://packages.debian.org/buster/amd64/tails-installer/filelist|grep bin >> /usr/bin/tails-installer-launcher >> $ w3m -dump >> https://packages.debian.org/sid/amd64/tails-installer/filelist|grep bin >> /usr/bin/tails-installer-launcher > I think that tails-installer is correct, so in that case can I fix it? When I locally execute dpkg -L tails-installer I correctly get: /usr/bin/tails-installer Now, indeed, as you mentioned, "packages.debian.org" shows something else in the file list. However, I believe this must rather be a bug related to packages.debian.org, and seems unrelated to the packaging. If you agree, I think we should reassign this bug to packages.debian.org or simply close it. But maybe I miss something? Cheers! u.
Bug#903117: tails-installer: Mistakes in packages.debian.org list of files?
Hi! Kenichiro MATOHARA: > I was operating while looking at the Tails page. > >> Start Tails Installer: >> tails-installer-launcher > https://tails.boum.org/install/expert/usb/index.en.html > When trying to start up with tails-installer-launcher, this command was not > found. > tails-installer existed. Seems like a bug in the Tails documentation :) I'll fix it there. >> $ dpkg-query -S tails-installer|grep bin >> tails-installer: /usr/bin/tails-installer >> $ ls -l /usr/bin/tails-installer* >> -rwxr-xr-x 1 root root 4847 Jun 28 16:28 /usr/bin/tails-installer > > > The list of files on packages.debian.org is tails-installer-launcher. Yes, note that this is an older version of the installer. I will upload the new version soon and it should behave the same way. > I think that tails-installer is correct, so in that case can I fix it? This simply needs to be fixed in the Tails documentation, I'll do that once I have uploaded a more recent backport. Ack? Cheers! u.
Bug#814190: Ping
Hi Antoine, in order to eventually close this bug sometime, could you reply to intrigeri's last question? Thanks & cheers! u.
Bug#538692: Hoia
Hola, mi nombre es Gen.Jessica U Meir, soldado del estado norteamericano de Estados Unidos, tengo algo muy importante que discutir contigo, por favor mándame un correo electrónico (jessicaumei...@gmail.com) para que sepa si recibes mi correo o tú me puede enviar su dirección de correo electrónico para que lo contacte gracias.
Bug#882375: Thanks
Hi! thanks for your patch, I will try to add this as soon as I can, once reviewed. Cheers! u.
Bug#878040: tails-installer: Creates non-bootable USB sticks on current testing/sid
Hi! intrigeri: > intrigeri: >> So we're now only waiting for the tails-installer fixes to be released >> upstream > > Done in 5.0.2, that's been packaged as 5.0.2+dfsg-0tails1 for Tails already. > I've tested it on Debian sid and it works fine for me. > >> and then uploaded to Debian. > > … so this is the only remaining step. Almost there, woohoo! > > Ulrike, do you think you can take care of it before this package gets > auto-removed from testing (November 17)? Let me know if you need help: > I'll be super busy next week but I can probably sneak this in if needed. I actually planned to work on it either tomorrow or wednesday, so it should be fine :) Cheers! u.
Bug#858034: Reopening
Well, apparently I've read too fast. Reopening for further discussion.
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Hello Roger, Roger Shimizu: > Dear Maintainer, > > Is it time to upload backports of 0.2.7-3 to stretch? > I'm also wondering why it didn't hit testing yet. I agree with you and will take care of it this month. Cheers! u.
Bug#864733: Temporary fix
Hi! the great news is that Georg Koppen and Nicolas Vigier from the Torproject have been very helpful and created a temporary fix for this situation. Nicolas even committed a pull request for torbrowser-launcher to use the new URL to check for updates (see https://github.com/micahflee/torbrowser-launcher/pull/279). So thanks to them <333, this works again right now in torbrowser-launcher 0.2.7 and once Micah Lee, the upstream author, includes Nicolas' commit, we'll have this change in Debian, too. Cheers, Ulrike
Bug#864733: Bug reported upstream
Hi, Thanks for reporting this bug. It looks like this bug has been reported upstream here: https://github.com/micahflee/torbrowser-launcher/issues/276 It's due to the fact that TBB 7.0 has been released but in https://dist.torproject.org/torbrowser/update_2/release/ only the old version is listed, even though it is not downloadable anymore. I'll try to see what can be done. Cheers! u.
Bug#864733: Error: "Download error: Download Error: 404 Not Found", Debian stable
Hi Sebastian, > Package: torbrowser-launcher > Version: 0.1.9-1+deb8u3 > Severity: grave > Justification: renders package unusable > version 0.1.9+deb8u3 > Renders torbrowser-launcher unusable to most users on stable ... Indeed, this version is totally outdated. Until I prepare a newer backport, you might want to use torbrowser-launcher from sid: https://tracker.debian.org/pkg/torbrowser-launcher torbrowser-launcher will not be available in Stretch anymore by the way. Cheers! u.
Bug#864130: [Pkg-privacy-maintainers] Bug#864130: pidgin-otr: Please stop Build-Depending on libgcrypt11-dev transition package
Hi Andreas, Andreas Metzler: > Source: pidgin-otr > Version: 4.0.2-1 > Severity: normal > > pidgin-otr build-depends on libgcrypt11-dev. This is a transition > package, please use libgcrypt20-dev instead. Thanks for sharing this. I'll take care of it. Cheers! u.
Bug#864093: [Pkg-privacy-maintainers] Bug#864093: libotr: Please stop (Build-)Depending on libgcrypt11-dev transition package
Hi Andreas, Andreas Metzler: > Source: libotr > Version: 4.1.1-2 > Severity: normal > > libotr build-depends and libotr5-dev depends on libgcrypt11-dev. This is > a transition package, please use libgcrypt20-dev instead. Thanks, will do. Cheers, ulrike
Bug#849227: Unreproducible
Hi Henrik, I cannot reproduce this. It works perfectly for me. The server is not stopped when I uncheck the box. Can you please try using oionshare 0.9.2 and confirm if this still persists or not? Cheers! ulrike
Bug#860297: [Pkg-privacy-maintainers] Bug#860297: Patch
Hi Bernd, > Please understand, the problem is not, to run multiple Tor Browsers as > the same user. > The problem is to run multiple Tor Browsers, each from a different user > at the same time on the same machine. Yes, I had perfectly understood this the first time I read your bug report, no worries. > After investigation I found, that this is because of a fixed SOCKSPORT > and and fixed CONTROLPORT. > But each user needs his own SOCKSPORT and CONTROLPORT. > > To fix this, the upstream script which is installed at > ~/.local/share/torbrowser/tbb/x86_64/tor-browser_de/Browser/start-tor-browser > has to be changed for each user. The patch is attached. > > The patch first searches for free ports and then modifies the config > files to use the free ports. > > I have build a wrapper script for torbrowser-launcher to apply the > patch, if it isn't already applied. > But I hope it will be fixed by upstream. I'll open an issue upstream to ask for review / inclusion of your patch or a modified version thereof. Cheers! u.
Bug#863407: Removing rdeps
Hi, removing rdeps is needed & desired. Please note that this bug is blocked by #863409 which you might want to act upon first. Cheers! ulrike
Bug#863409: RM: onionshare/0.9.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi, onionshare is marked for autoremoval on 22 June 2017: 861744" because of it's dependency on torbrowser-launcher. This is correct and wanted. However, it looks like Stretch might already be out at that date. So I'm hereby asking you to remove the package from testing manually, in order to be sure that it won't be part of Stretch. I've already uploaded a newer version of onionshare (0.9.2-1) (and moved it from contrib to main, with the torbrowser-launcher dependency removed). This package is currently in NEW. It could be part of Stretch, but we'd rather concentrate our efforts on having this function well in Buster and stretch-backports. I'm simply writing this here in case you stumble on this second version and wonder what's going on.. If this newer version has not gone through NEW yet, please simply remove onionshare from Stretch. Thanks & cheers, Ulrike -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#863407: RM: torbrowser-launcher/0.2.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi, torbrowser-launcher is marked for autoremoval on 22 June 2017: 861744". This is correct and wanted. However, it looks like Stretch might already be out at that date. So I'm hereby asking you to remove the package from testing manually, in order to be sure that it won't be part of Stretch. Thanks & cheers, Ulrike -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#849227: Onionshare: CLI works but GUI doesn't
Hi Henrik, I've just tried what you report here and for me it works perfectly fine. Let me explain what I did: - I start onionshare using the GUI to share a file. - I download the file over Tor using Tor Browser. - In the GUI I now get a message "Time elapsed: 1second" on a turquoise background. - Now when I try to reload the URL in TorBrowser, it does not work, because the server has been stopped successfully. However, the OnionShare GUI window stays open and does not explicitly tell me that the server has been shut down. I believe that this is a UX problem which you may eventually want to report upstream: https://github.com/micahflee/onionshare/issues I'll upload a newer version of OnionShare later, please try it out. If you agree that this is not actually a bug but a UX problem, we can close this bug report. Thank you, Ulrike
Bug#862391: [Pkg-privacy-maintainers] Bug#862391: onionshare: Please ensure onionshare is in Stretch
Hi! intrig...@debian.org: > Package: onionshare > Version: 0.9.1-1 > Severity: normal > > Hi, > > unless we do something about it, onionshare will be auto-removed from > testing soon as it depends on torbrowser-launcher that itself won't > make it into Stretch. > > There are plans to address the root cause of the problem in Buster > (thanks to onion-grater), but for Stretch I suggest we: > > 1. demote "Depends: torbrowser-launcher" to Recommends > 2. document in README.Debian that to use onionshare, one needs >either: >a) to install and run torbrowser-launcher so onionshare uses this > instance >b) to configure access to the control port of a system-wide Tor, > and point onionshare to it > > … which would allow us to ship onionshare in Stretch, with sub-optimal > usability, sure, but still better than not having it at all IMO. > > What do you think? Sounds doable? Thanks for caring and coming up with this plan. I'll handle it that way. This will also allow adding some upstream modifications that were made recently. Cheers! u.
Bug#796295: Reopen
Control: reopen 796295 Hi, I'd like to reopen this bug, it's a call for help and it still applies as long as the software is in the archive. Cheers! u.
Bug#860297: Impossible to launch tor instance
Hi Bernd, I believe that the problem is due to torbrowser-launcher not only launching the browser, like when you launch Firefox, but also launching it's own instance of tor. When this instance is already running under your current user, you won't be able to launch a second instance using the same SOCKS port. Holger Levsen has created a how to run torbrowser-launcher as another user in another X environment: https://anonscm.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git/tree/debian/examples?h=debian/sid It's also possible to run a second TorBrowser configured to use system tor, which might be a workaround for the tor instance problem. Some other ideas: https://tor.stackexchange.com/questions/2006/how-to-run-multiple-tor-browsers-with-different-ips I've not tested any of these myself. If you do, please report back. Although I find this very interesting, I'd like to close this bug, as I believe that it exceeds the intended usage of this package and is not a bug in the packaging itself. This should either be reported upstream or documented on the Debian wiki. What do you think? Cheers! u.
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Package: torbrowser-launcher Severity: serious I'm opening this RC bug in order to prevent torbrowser-launcher from migrating to testing. Currently, the design of the software makes the package very often unusable, as soon as TorBrowser upstream gets signed with a different OpenPGP key or the SSL certificate of the server changes. This is not reliable and normal users will be unable to workaround these issues themselves. It'll be easier and safer to provide up-to-date versions to users using stable-backports. This shall be documented on the Debian wiki. Cheers! u. signature.asc Description: OpenPGP digital signature
Bug#845989: [Pkg-privacy-maintainers] Bug#845989: Bug#845989: Bug#845989: Bug#845989: marked as done (browser can't be downloaded because of invalid SSL certificate)
Hi, thank you very much for your remarks. I'd certainly appreciate some help by fellow members of the Privacy team, as well as insight, since I suddenly became the de-facto maintainer of this package. Holger Levsen: > On Wed, May 03, 2017 at 08:29:00AM +0000, u wrote: >> As you might know, the version in Jessie is 1.9.x - very outdated and >> one should always use the version from jessie-backports. > > no. > > the version in jessie should be fixed or torbrowser-launcher should be > removed from jessie. > both can be done, but needs someone doing it. (just sadly the timeframe > to get this fixed in the next pointrelease just passed. so hopefully this > will be fixed for the pointrelease after.) I'm currently trying to get 0.2.7 into the archive. > using stable-backports to "fix" bugs in stable is *not* the way to go. I'm not sure in which part of my previous email you were reading that I was suggesting this. > (it might be the way to go for a user to workaround bugs in Debian though :) That's pretty much what I intended to say and what the email from Lev seemed to be about. Cheers! u.
Bug#845989: [Pkg-privacy-maintainers] Bug#845989: Bug#845989: marked as done (browser can't be downloaded because of invalid SSL certificate)
Hi Lev, Lev Lazinskiy: >> For the record, I can still reproduce this in Debian jessie, which is >> pretty bad - shouldn't a stable update be shipped for this already? >> > > I just installed a fresh copy of jessie and tried to use the > torbrowser-launcher and ran into the same issue. Does anyone know what > the workaround is for jessie? We should at least document it in the > wiki[1] so that future users are able get this to work properly. Thank you for your reply. I think you are correct, I'll update the wiki page. As you might know, the version in Jessie is 1.9.x - very outdated and one should always use the version from jessie-backports. However, currently, this one is not up-to-date either. So, meanwhile, you should install the version from unstable or even experimental. I'll try to upload a newer backport today. Cheers! u.
Bug#851236: python-twisted version
As this error looked familiar to me, I stumbled across a previous very similar bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794847 This report stated that the error you reported might be linked to a problem in Python Twisted. May you please also tell us which version of python-twisted is installed on your system? The patch supplied was included upstream, so we'd need to investigate if this problem is not linked to the python-twisted version you use. Cheers!
Bug#851236: torbrowser-launcher version
Hi Russell, your bug report initially says that your version of torbrowser-launcher is 0.2.0. On some other channel I've seen you saying that the problem still persists. May you please tell us if this concerns the current version 2.6.3 or the old one? Cheers, ulrike
Bug#855346: (no subject)
Sorry for writing three emails for one problem.. I forgot to mention that if the upstream patch gets integrated, we would need to copy this into the Debian AppArmor profile too.
Bug#855016: [Pkg-privacy-maintainers] Bug#855016: onionshare: system daemon integration
Hi, thanks for your bug report. Upstream has partly implemented this in a newer version of onionshare. It has also been implemented in Tails. I'm working on getting it to Debian, but I did not have the time yet to test everything well. However, it shall happen! :) Cheers! u.
Bug#855522: [Pkg-privacy-maintainers] Bug#855522: torbrowser-launcher: torbrowser won't start because of apparmor
Hi, Julien AUBIN: > Package: torbrowser-launcher > Version: 0.2.6-3 > Severity: grave Thanks for your bug report. Instead of working around this by disabling the profile, here is the modification which was done upstream: https://github.com/micahflee/torbrowser-launcher/pull/243/commits/a29f2d98484f43b123a7452f89a4f2342771594e This is fixed in the next version which I will try to upload to experimental during the next days. It was not uploaded to unstable because of the freeze. Maybe you could try it and tell us if it fixes the problem for you? I'm using this new version, 0.2.7-1, on Jessie with AppArmor enabled without any problem. Cheers! u.
Bug#849642: Duplicate of #855522
I believe this bug is a duplicate of 855522
Bug#854346: tails-installer: Should not be part of Stretch
Package: tails-installer Severity: serious I'm opening this RC bug in order to prevent tails-installer from migrating to testing. The Tails ISO format might change, and upstream is not sure whether the current installer will still be able to install Tails images in ~2 years. That's why upstream doesn't want it to be in Debian stable. This bug is opened in coordination with upstream. It'll be easier and safer to provide new versions to users using stable-backports. See upstream bug https://labs.riseup.net/code/issues/11945 Cheers! u.
Bug#852732: [Pkg-privacy-maintainers] Bug#852732: Bug#852732: Bug#852732: torbrowser-launcher: upon upggrade 6.0.8 to 6.5: "SIGNATURE VERIFICATION FAILED: You might be under attack ..."
Hi, intrigeri: > u: >>> Package: torbrowser-launcher Version: 0.1.9-1+deb8u3 > >> First of all, this looks like a *very* old version of >> torbrowser-launcher. You should probably update your system once in a >> while :) > > FWIW that's the one available in current Debian stable + security, > without backports. Right. I mistakenly thought it was only for oldstable. Cheers! u.
Bug#852732: torbrowser-launcher: sig verification failed: also for first time download
Hi, Micah Lee: > On 01/26/2017 03:23 PM, Gregor Zattler wrote: >> Package: torbrowser-launcher >> Version: 0.2.6-3 >> Followup-For: Bug #852732 >> >> Dear Maintainer, >> >> I have the very same problem as Sebastian Niehaus with >> torbrowser-launcher from debian testing while trying to download >> tbb for the very first time. >> >> Most probably the problem is with the files on the tor projects >> server but ATM there is nothing at the tor mailinglist archives about >> the problem. >> >> Thanks, Gregor > > I have fixed this issue upstream and made a new release: > https://github.com/micahflee/torbrowser-launcher/releases/tag/v0.2.7 oh great, that's even better than a patch :) Cheers!
Bug#852732: [Pkg-privacy-maintainers] Bug#852732: torbrowser-launcher: upon upggrade 6.0.8 to 6.5: "SIGNATURE VERIFICATION FAILED: You might be under attack ..."
Hi, thanks for this report. Sebastian Niehaus: > Package: torbrowser-launcher Version: 0.1.9-1+deb8u3 Severity: > normal First of all, this looks like a *very* old version of torbrowser-launcher. You should probably update your system once in a while :) > I now get an error message: > > "SINATURE VERIFICATION FAILED! You might be under attack, or there > might be a networking problem. Click Start try the download again" Upstream has a ticket about this: https://github.com/micahflee/torbrowser-launcher/issues/260 In short, torbrowser-launcher includes the IDs of the keys used to sign torbrowser releases. However, the latest release was signed with a new key. We'll prepare a patched version for Debian, however, this will not be available for old stable unless someone backports it there. Cheers! ulrike
Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?
Hi Carlos, Carlos Maddela: > On 09/01/17 20:29, intrigeri wrote: >> Carlos Maddela: >>> I had been thinking of adopting this package myself, but since you'd >>> like to adopt it too, I've opted for a QA upload instead. >> How about joining pkg-privacy and participating in the maintenance of >> this package there? Ulrike also expressed interest in taking care of >> this package, so you two could help each other :) > I'd be happy to do that. Great! Please tell me your Alioth handle if you have one, or create it and click the "Request to join" button on https://alioth.debian.org/projects/pkg-privacy/ >>> If you're >>> interested in my changes, they are available here: >>> https://mentors.debian.net/debian/pool/main/s/seahorse-nautilus/seahorse-nautilus_3.11.92-2.dsc, >>> https://github.com/e7appew/pkg-seahorse-nautilus.git or the attached >>> debdiff. >> Great, thanks! Do you think these changes are appropriate / safe for >> Stretch? If you think so, then I'm happy to upload after someone has >> reviewed your changes and made the additional ones that are necessary >> adopted the package under the team's umbrella. Ulrike, perhaps? I can look at it this week. > Most of the changes are related to the packaging itself, which most > end-users would not care about. The changes that would have the greatest > impact on the end-user are the updates to translations, and possibly if > problems to the code are exposed due to the hardened build, which I > haven't detected any so far. I don't know if the changes are that > important to be introducing them to Stretch at this late juncture. Thanks for working on this, Carlos. Cheers! ulrike
Bug#849227: [Pkg-privacy-maintainers] Bug#849227: CLI works but GUI doesn't
Hi! Henrik Ahlgren: > However I still cannot get the "stop server automatically" checkbox > in the GUI to work as expected. thank you for your bug report. I'll look into it soon. Cheers! u.
Bug#845989: Downgrading forwarded bug
Hi, thanks for your investigations. I think this bug is not release critical, so I've downgraded it now. Cheers! u.
Bug#845203: Test script & case
Hi! while trying to provide a test case for this bug, we've noticed that the problem only occurs when using @7z@ from testing or sid (provided by the @p7zip-full@ package version >16). It does not happen when using the Jessie version (currently 9.20.1~dfsg.1-4.1+deb8u2). So it might actually be that this bug will need to be reassigned to p7zip-full, but I'm in not position to judge this. The headers are created nonetheless, and thus this might still represent a problem when using @dh-stripnondeterminism@. Cheers! u. (The script is a fast dirty hack, I did not write it myself.) zip-ntfs-header-test.sh Description: application/shellscript
Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hi Christian & anonym, does Christian's patch fix this issue (% it'll be merged upstream)? If yes, can we close this Debian bug on Icedove and not modify the Icedove profile itself? Or is there anything else left to add to the Icedove profile now? If so, can you update your initial patch please? Cheers! u.
Bug#845203: Example output
FWIW, one can see the contents of those header fields as follows (only visible on directories as it looks like): @unzip -ZTv $some_zip@ Example output: entral directory entry #1: --- chrome/ offset of local header from start of archive: 0 (h) bytes file system or operating system of origin: Unix version of encoding software: 6.3 minimum file system compatibility required: Unix minimum software version required to extract: 2.0 compression method: none (stored) file security status: not encrypted extended local header: no file last modified on (DOS date/time): 2016 Nov 21 12:48:18 32-bit CRC value (hex): compressed size:0 bytes uncompressed size: 0 bytes length of filename: 7 characters length of extra field: 0 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: binary Unix file attributes (040700 octal):drwx-- MS-DOS file attributes (10 hex):dir There is a local extra field with ID 0x5855 (old Info-ZIP Unix/OS2/NT) and 8 data bytes (GMT modification/access times only). There is no file comment.
Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hi! > (adding back u. to CC - sorry, I didn't realize mails for this bugreport > don't get delivered to pkg-apparmor when cleaning up the recipients) Thanks! > So here's the patch I hereby propose upstream: Thank you very much Christian! :)) Take care, ulrike
Bug#838817: Cannot reproduce
Hi Shirish, thanks for reporting this. I can't reproduce this on a stable system using the latest torbrowser-launcher from jessie-backports. Did you test this on a clean installation? Cheers! u.
Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hi! anonym: > Package: icedove > Version: 1:45.4.0-1 > As a KDE user I want Icedove to look like a native application despite > it using GTK, which can be achieved with the gtk2-engines-pixbuf package > and some gtk*-engines-* package (e.g. gtk3-engines-breeze). However, the > current Icedove AppArmor profile blocks the paths used by these packages. Looks good. > The attached patch fixes the profile for me. A proper solution for > AppArmor upstream might be to add the new lines to the appropriate > abstraction file (perhaps abstractions/gnome?). I've put the upstream list and the original author of the profile in Cc:. @Upstream, what do you think? Cheers! u.
Bug#505173: Any update
Hi, Ben Finney: > On 16-Nov-2016, u wrote: >> Well, dput is supposed to work with SFTP simply by specifying >> "method = sftp" in any dput config file such as ~/.dput.cf. > > That has never been the case for the ‘dput’ package. > This bug is a request for a new feature that ‘dput’ doesn't yet have. I see. >> Hence, my question actually is: why can't Debian's dput work with >> SFTP now? > > If you mean: why can't Dput do that now? The answer is: because the > feature is not yet implemented. > > If you mean: why not just add that feature the same way Ubuntu has > done? The answer is, because this feature and others are better > addressed by a differently designed API. I'm not keen to add more code > to the legacy API for that reason. Ack, thanks a lot for your answer. Cheers! u.
Bug#835675: [nmu] debdiff
Hi,
built and tested the binary. Looks good!
Cheers!
u.
diff -Nru seahorse-nautilus-3.11.92/debian/changelog
seahorse-nautilus-3.11.92/debian/changelog
--- seahorse-nautilus-3.11.92/debian/changelog 2014-09-15 21:35:21.0
+0200
+++ seahorse-nautilus-3.11.92/debian/changelog 2016-11-16 21:34:02.0
+0100
@@ -1,3 +1,10 @@
+seahorse-nautilus (3.11.92-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Really remove add-correct-flag-for-reaping-the-progress-child.patch.
+
+ -- Ulrike Uhlig <u...@451f.org> Wed, 16 Nov 2016 21:31:26 +0100
+
seahorse-nautilus (3.11.92-1) unstable; urgency=medium
[ Clément Hermann (nodens) ]
diff -Nru
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
---
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
2014-03-23 00:20:50.0 +0100
+++
seahorse-nautilus-3.11.92/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From: Stef Walter <st...@redhat.com>
-Date: Fri, 16 Aug 2013 17:24:11 +
-Subject: Add correct flag for reaping the progress child
-Origin:
https://git.gnome.org/browse/seahorse-nautilus/commit/?id=c41f07cf5785b2d755b85f20bf0546c6ce2ebb02
-
-This fixes the WARNING about ECHILD that comes from some versions
-of glib. The WARNING was removed in later versions of glib, but this
-is also a good fix.
-
-https://bugzilla.gnome.org/show_bug.cgi?id=697895
-diff --git a/tool/seahorse-tool-progress.c b/tool/seahorse-tool-progress.c
-index 613e82f..c039118 100644
a/tool/seahorse-tool-progress.c
-+++ b/tool/seahorse-tool-progress.c
-@@ -217,7 +217,7 @@ seahorse_tool_progress_start (const gchar *title)
- argv[2] = (gchar *)title;
- argv[3] = NULL;
-
--ret = g_spawn_async_with_pipes (NULL, argv, NULL,
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH,
-+ret = g_spawn_async_with_pipes (NULL, argv, NULL,
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD,
- NULL, NULL, _pid, _fd,
NULL, NULL, );
-
- if (!ret) {
---
-cgit v0.9.2
diff -Nru seahorse-nautilus-3.11.92/debian/patches/gpg21.patch
seahorse-nautilus-3.11.92/debian/patches/gpg21.patch
--- seahorse-nautilus-3.11.92/debian/patches/gpg21.patch1970-01-01
01:00:00.0 +0100
+++ seahorse-nautilus-3.11.92/debian/patches/gpg21.patch2016-11-16
21:30:02.0 +0100
@@ -0,0 +1,29 @@
+Description: Accept GnuPG 2.1
+ This is the minimum change to fix the build,
+ upstream fixed this as part of a bigger change in 3.18
+Author: Adrian Bunk <b...@stusta.de>
+Bug-Debian: https://bugs.debian.org/835675
+Forwarded: not-needed
+
+--- seahorse-nautilus-3.11.92.orig/configure.ac
seahorse-nautilus-3.11.92/configure.ac
+@@ -57,7 +57,7 @@ AC_ARG_ENABLE(gpg-check,
+ DO_CHECK=$enableval, DO_CHECK=yes)
+
+ if test "$DO_CHECK" = "yes"; then
+- accepted_versions="1.2 1.4 2.0"
++ accepted_versions="1.2 1.4 2.0 2.1"
+ AC_PATH_PROGS(GNUPG, [gpg gpg2], no)
+ ok="no"
+ if test "$GNUPG" != "no"; then
+--- seahorse-nautilus-3.11.92.orig/configure
seahorse-nautilus-3.11.92/configure
+@@ -14879,7 +14891,7 @@ fi
+
+
+ if test "$DO_CHECK" = "yes"; then
+- accepted_versions="1.2 1.4 2.0"
++ accepted_versions="1.2 1.4 2.0 2.1"
+ for ac_prog in gpg gpg2
+ do
+ # Extract the first word of "$ac_prog", so it can be a program name with
args.
diff -Nru seahorse-nautilus-3.11.92/debian/patches/series
seahorse-nautilus-3.11.92/debian/patches/series
--- seahorse-nautilus-3.11.92/debian/patches/series 2014-09-15
21:31:16.0 +0200
+++ seahorse-nautilus-3.11.92/debian/patches/series 2016-11-16
21:30:02.0 +0100
@@ -0,0 +1 @@
+gpg21.patch
Bug#505173: Any update
Hi! Ben Finney: > Thanks for your interest. > > On 15-Nov-2016, u wrote: > >> I'd like to be able to use SFTP to upload from Debian to a Ubuntu >> PPA too. > > What tools already exist to do this? Well, dput is supposed to work with SFTP simply by specifying "method = sftp" in any dput config file such as ~/.dput.cf. However, when specifying this method, dput throws this error: "Unknown upload method: sftp" There is an answer to this here: https://bugs.launchpad.net/launchpad/+bug/251685/comments/12 claiming "The dput package on Ubuntu installs a /usr/share/dput/sftp.py file - maybe you can copy it to your Debian instance although I'm surprised if it's not in Debian's dput by now?" Hence, my question actually is: why can't Debian's dput work with SFTP now? I understand that besides this problem there is a dependency on bzr - which seems unnecessary. Hence my second question: there are some patches attached to this bug - will they be integrated and what's the ETA for that? Currently, I'm able to use dput only using FTP, which seems slightly insecure to me :) Cheers! u.
Bug#505173: Any update
Hi! I'd like to be able to use SFTP to upload from Debian to a Ubuntu PPA too. Is there any progress / ETA on integrating this patch into Debian's dput? Thanks & cheers! u.
Bug#818554: (no subject)
I cannot reproduce this bug on a Gnome system. Therefore I strongly suspect that this issue is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814190 It looks like policykit-1 is installed on your system, just as is on anarcat's (described in the above mentioned bug report). Please make sure that polkit is running. Can you try running the installer using gksudo? Can you please report back on what "pkexec whoami" gives you? Cheers, u.
Bug#842021: torbrowser-launcher: Installer crashes if trying to enforce installation of EN version on non-EN user session
Hi Andreas, thank you for your bug report. I confirm this broken behaviour. We have seen this before, as mentioned here: https://github.com/micahflee/torbrowser-launcher/issues/241 I've not yet investigated in detail what's common here and what's not, but I'm on it. Cheers! u.
Bug#842832: Consider adding a manpage for git-remote-gcrypt
Package: git-remote-gcrypt Version: 0.20130908-7 Severity: wishlist Dear Maintainer, @man git-remote-gcrypt@ should result in showing a manpage instead of making the user search for a README.rst file somewhere on the system. Please consider adding a manpage to make Debian a little bit more userfriendly. Thank you, u.
Bug#839068: [Pkg-privacy-maintainers] Bug#839068: mat: no pdf support anymore?
Hi! Fulano Diego Perez: > > Package: mat > Version: 0.6.1-3 > Severity: normal > > > when was PDF support removed and why ? Why it has been removed: https://digitalcourage.de/blog/2016/using-tails-be-careful-embedded-metadata And: https://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20160919/001023.html Basically, there is no fix yet and instead of leaving people with a false sense of security, this has been removed, according to a decision mentioned here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826101 You might want to retitle this bug report as "Please bring back PDF support to mat"? Cheers! u.
Bug#832717: package [ openjdk-8-jdk-headless ] tags 794502 + patch
Thanks Matthias, I wasn't aware of these packaging policies, please suggest me a possible way to handle this case. Regards, Avinash HPE
Bug#832718: package [ openjdk-8-jdk-headless ] tags 794502 + patch
Thanks Matthias, I wasn't aware of these packaging policies, please suggest me a possible way to handle this case. Regards, Avinash HPE
Bug#776527: OpenJDK Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Version : 8u102-b14.1 Package: openjdk-8-jre-headless Tags: patch Reproducer: Installation of openjdk-8-jre-headless on i386 or sparc. Patch: Warning occurs due to the usage of -XX:PermSize=128m with java during postinst script of jre-headless package and PermSize; support was removed in 8.0 diff --git a/debian/JB-jre-headless.postinst.in b/debian/JB-jre-headless.postinst.in index 1f86eeb..0d4bd5b 100644 --- a/debian/JB-jre-headless.postinst.in +++ b/debian/JB-jre-headless.postinst.in @@ -110,7 +110,7 @@ configure) case @archdir@ in i386|sparc) rm -f $basedir/jre/lib/@archdir@/client/classes.jsa log=$(tempfile) - if ! $basedir/bin/java -client -Xshare:dump -XX:PermSize=128m > $log; then + if ! $basedir/bin/java -client -Xshare:dump > $log; then cat >&2 $log rm -f $log # this may fail on some machines/configurations, just ignore it. Verified the fix, and it works fine. Thanks, Avinash UB HPE
Bug#835479: [Pkg-privacy-maintainers] Bug#835479: Doesn't start with tor profile in enforce mode
Hi,
Julian Andres Klode:
> On Fri, Aug 26, 2016 at 11:16:45AM +0200, intrigeri wrote:
>> Hi,
>>
>> Guido Günther:
>>> torbrowser-launcher would not start with
>>
>>> '/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Tor/tor'
>>
>>> set to enforce mode. I get the "Tor launcher" "Tor exited during
>>> startup..." dialog. Restarting doesn't help but setting the above
>>> profile to complain mode does the trick (note that
>>
>> FWIW I don't use the bundled tor so don't count on me to help maintain
>> this profile. It might be that the sanest solution at this point is to
>> stop including it in the Debian package? Confining the browser itself
>> is what matters most IMO, so I'd rather focus our efforts there :)
>
>
> It's simple to fix, add:
>
> owner
> @{HOME}/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Data/Tor/
> r,
>
> (we only had permissions for Tor/* before).
Great, that works. I've created a pull request upstream with this
modification: https://github.com/micahflee/torbrowser-launcher/pull/243
Cheers!
u.
Bug#833742: icedove: apparmor breaks -ProfileManager
Hi! Ximin Luo: > Package: icedove > Version: 1:45.2.0-2 > Severity: important > The apparmor profile breaks -ProfileManager. Here is the audit log: > > [ +28.591676] audit: type=1400 audit(1470655963.593:12587): apparmor="DENIED" > operation="exec" profile="icedove" name="/usr/lib/icedove/icedove" pid=10080 > comm="icedove" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 Thanks for this bug report. I'll look into it. Also Cc:ing Simon Déziel who is the original author of the profile. Cheers! u.
Bug#822348: Re : openjdk-8-jre-headless: prerm checks for wrong file before deregistering binfmt
Hi James, Would you please share the more info / reproducer steps and Warning logs what you noticed? Thanks. > The prerm is looking for /var/lib/binfmts/@basename@ (e.g., openjdk-8) but the > files under /var/lib/binfmts are named after the binfmt being registered, not > the package. > This means that users which have upgraded from openjdk-7 to openjdk-8 will > always see a warning message about openjdk-7 already having registered the > binfmt when a new openjdk-8 update is installed.
Bug#794502: Patch for jdk7 and jdk8 debian/rules
Tags : patch update-rules-jdk8.diff.patch<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=794502;filename=update-rules-jdk8.diff.patch;msg=20> update-rules-jdk7.diff.patch<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=794502;filename=update-rules-jdk7.diff.patch;msg=25> On Thu, 28 Jul 2016 11:59:02 + "U B, Avinash" <avinash@hpe.com> wrote: > Package: Package: openjdk-7-jdk > Source: openjdk-7 > Version: 7u101-2.6.6-2~deb7u1 > Severity: minor > On Thu, 28 Jul 2016 11:55:08 + "U B, Avinash" <avinash@hpe.com> wrote: > Package: openjdk-8-jdk-headless > Source: openjdk-8 > Version: 8u91-b14-1 > Severity: minor > Thanks, Avinash UB Hewlett Packard Enterprise.
Bug#832719: package [ openjdk-7-jdk ] tags 794502 + patch
Package: Package: openjdk-7-jdk Source: openjdk-7 Version: 7u101-2.6.6-2~deb7u1 Severity: minor Issue: adequate openjdk-7-jdk openjdk-7-jdk:arm64: broken-symlink /usr/lib/jvm/java-7-openjdk-arm64/src.zip -> ../openjdk-7/src.zip Dynamic symbolic link will get created only after installation of openjdk-7-source. and get removed after uninstallation of openjdk-7-source. --- a/debian/rules +++ b/debian/rules 1952c1952 < echo '$(TOP)/$(basename)/src.zip $(basedir)/src.zip' >> $(d_jdk).links --- > echo '$(TOP)/$(basename)/src.zip $(basedir)/src.zip' >> $(d_src).links Thanks, Avinash. update-rules-jdk7.diff.patch Description: update-rules-jdk7.diff.patch
Bug#832717: package [ openjdk-8-jdk-headless ] tags 794502 + patch
Package: openjdk-8-jdk-headless Source: openjdk-8 Version: 8u91-b14-1 Severity: minor Issue: $ adequate openjdk-8-jdk-headless openjdk-8-jdk-headless:arm64: broken-symlink /usr/lib/jvm/java-8-openjdk-arm64/src.zip -> ../openjdk-8/src.zip Dynamic symbolic link will get created only after installation of openjdk-8-source. and get removed after uninstallation of openjdk-8-source. --- a/debian/rules +++ b/debian/rules @@ -2087,7 +2087,7 @@ endif ) > $(d_jdk).links # doesn't work, no package dependency ifneq (,$(DEB_HOST_MULTIARCH)) - echo '$(TOP)/$(basename)/src.zip $(basedir)/src.zip' >> $(d_jdkhl).links + echo '$(TOP)/$(basename)/src.zip $(basedir)/src.zip' >> $(d_src).links endif : # create docdir symlinks for $(p_dbg) Thanks, Avinash. update-rules-jdk8.diff.patch Description: update-rules-jdk8.diff.patch
Bug#829731: Correct repository
Hi!
Carsten Schoenert:
> Am 25.07.2016 um 16:05 schrieb u:
>>> Could you please, if needed, prepare a new patch against the already
>>> commited changes?
>>
>> I'll take care of it tomorrow.
>
> we queue the upload then to get the actual profile in. Thanks!
Here's the patch.
Thanks for your work,
Cheers!
u.
From 39a732fbc1aa36da2c789b2807aa66eb9b02c62c Mon Sep 17 00:00:00 2001
From: Ulrike Uhlig <u...@451f.org>
Date: Tue, 26 Jul 2016 16:32:27 +0200
Subject: [PATCH] Refresh AppArmor profile.
A change was made in order to support gpg2 in Thunderbird 45.
Upstream commit: https://git.launchpad.net/~sdeziel/+git/apparmor-profiles/commit/?h=thunderbird-45-refresh=5cb3c94d0bce7c1421299a7b9d1c4c855a5dab12
---
debian/apparmor/usr.bin.icedove | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/apparmor/usr.bin.icedove b/debian/apparmor/usr.bin.icedove
index 11ac830..2da4ea5 100644
--- a/debian/apparmor/usr.bin.icedove
+++ b/debian/apparmor/usr.bin.icedove
@@ -229,6 +229,8 @@ profile icedove /usr/lib/icedove/icedove {
deny owner @{HOME}/.icedove/**/*.msf w,
deny owner @{HOME}/.cache/icedove/**/_CACHE_* w,
+/usr/share/xul-ext/enigmail/chrome/enigmail.jar r,
+
# For smartcards?
/dev/bus/usb/ r,
/dev/bus/usb/[0-9]*/ r,
--
2.1.4
Bug#829731: Correct repository
Hi, Carsten Schoenert: > Hello intri, > > On Sat, Jul 23, 2016 at 02:45:19PM +0200, intrigeri wrote: >> FWIW, a profile refresh for Thunderbird 45 has been proposed there: >> https://code.launchpad.net/~sdeziel/+git/apparmor-profiles/+ref/thunderbird-45-refresh > > due this reflect some needed changes to the apparmor profile for > Icedove? I think so, nor? > Guido added the suggested patch from this report with a small addition > for the dh_install section. > > https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?id=b24bbaa782da7b416f40943931bf994000ea006b > https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?id=6fe4897bbe86dc74a74aa1747454adbcacbf2e7f > > Could you please, if needed, prepare a new patch against the already > commited changes? I'll take care of it tomorrow. Cheers! u.
Bug#706603: For your view only
For your view only United Nations Compensation Uni1.docx Description: Binary data
Bug#830864: torbrowser-launcher: delete downloaded torbrowser when uninstalling
Package: torbrowser-launcher Severity: normal I've realized that when I run @apt remove --purge torbrowser-launcher@ the downloaded files in ~/.local/share/torbrowser-launcher are not deleted. Which is expected: they are not listed in /var/lib/dpkg/info/torbrowser-launcher.list and are not part of the packaging itself. However, when I uninstall I might actually want to get rid of the downloaded browser, history, bookmarks etc. or at least i'd like to know that I should/could delete/wipe this folder manually. This bug report is here simply to keep track of this issue. Cheers! u.
Bug#829731: Correct repository
Upstream has recently moved to Git, and the URL i've linked to earlier points still to the old repository. The new one is here: https://code.launchpad.net/~apparmor-dev/apparmor-profiles/+git/apparmor-profiles And the direct link to the profile is: https://git.launchpad.net/apparmor-profiles/tree/ubuntu/16.10/usr.bin.thunderbird Cheers!
Bug#829740: [Pkg-privacy-maintainers] Bug#829740: RFP: corridor - a Tor traffic whitelisting gateway
Hi, Patrick Schleizer: > Is someone from the PkgPrivacyMaintainers team interested / willing to > help get corridor [4] [5] [6] into Debian? I'm not sure how useful this is exactly. It's still beta? > I got a working prototype of a Debian package which is almost free of > lintian warnings. [1] [2] [3] There are just some remaining --pedantic > lintian warnings that are fixable. First questions... > > 1) > > I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph at > line 3 > > https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright > > Any idea what is wrong in the debian/copyright file? https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-paragraph Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it. More general paragraphs should therefore be given first, followed by more specific overrides. So I suppose the problem is that you declare * after Files/* and that overrides the first paragraph. > 2) > > Would a combined manpage, i.e. 'man corridor', symlinked to the > individual command names (corridor-init-forwarding, corridor-init-snat, > ...) be acceptable by Debian policy and otherwise or should a separate > man page per binary be provided? https://www.debian.org/doc/debian-policy/ch-docs.html "Each program, utility, and function should have an associated manual page included in the same package. [..] Manual pages for protocols and other auxiliary things are optional." Symlinking man pages is allowed, as described in this policy, but I do not have an example in mind where this has been done. Cheers! u.
Bug#829731: icedove: Please add an AppArmor profile for Icedove
Package: icedove
Severity: normal
Hi,
I've prepared a patch against current master which adds an AppArmor
profile for Icedove. I've tested this profile for several months, but
I've not tested to build Icedove with this patch.
The profile comes from upstream's latest revision 169:
http://bazaar.launchpad.net/~apparmor-dev/apparmor-profiles/master/view/head:/ubuntu/16.10/usr.bin.thunderbird
May you please try to add this to future versions of Icedove?
Documentation on how to use AppArmor is available here:
https://wiki.debian.org/AppArmor/HowToUse
Documentation on debugging the profile is available here:
https://wiki.debian.org/AppArmor/Debug
I'm happy to help with any testing, for this and future versions. I'll
also happily help to update this profile when upstream modifies it and
when Debian bug #816679 is resolved.
Cheers!
u.
From f7ca341b9abea2d88de14518e3aab45679a7791d Mon Sep 17 00:00:00 2001
From: Ulrike Uhlig <u...@451f.org>
Date: Tue, 5 Jul 2016 17:54:01 +0200
Subject: [PATCH] Add rebranded apparmor profile from upstream.
The profile was taken from commit 169. All occurences of the brand name have
been renamed to Icedove.
debian/rules: Add rules to copy the profile.
debian/control: Add build dependency and suggests.
---
debian/apparmor/usr.bin.icedove | 276
debian/control | 2 +
debian/rules| 3 +
3 files changed, 281 insertions(+)
create mode 100644 debian/apparmor/usr.bin.icedove
diff --git a/debian/apparmor/usr.bin.icedove b/debian/apparmor/usr.bin.icedove
new file mode 100644
index 000..11ac830
--- /dev/null
+++ b/debian/apparmor/usr.bin.icedove
@@ -0,0 +1,276 @@
+# vim:syntax=apparmor
+# Author: Simon Deziel
+# This apparmor profile is derived from firefox profile
+# by Jamie Strandboge <ja...@canonical.com>
+
+# Declare an apparmor variable to help with overrides
+@{MOZ_LIBDIR}=/usr/lib/icedove
+
+#include
+
+profile icedove /usr/lib/icedove/icedove {
+ #include
+ #include
+ #include
+ # TODO: finetune this for required accesses
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+
+ # for crash reports?
+ ptrace (read,trace) peer=@{profile_name},
+
+ # Pulseaudio
+ /usr/bin/pulseaudio Pixr,
+
+ owner @{HOME}/.{cache,config}/dconf/user rw,
+ owner /run/user/[0-9]*/dconf/user rw,
+ owner @{HOME}/.config/gtk-3.0/bookmarks r,
+ deny owner @{HOME}/.local/share/gvfs-metadata/* r,
+
+ # potentially extremely sensitive files
+ audit deny @{HOME}/.gnupg/** mrwkl,
+ audit deny @{HOME}/.ssh/** mrwkl,
+
+ # rw access to HOME is useful when sending/receiving attachments
+ owner @{HOME}/** rw,
+
+ # Required for LVM setups
+ /sys/devices/virtual/block/dm-[0-9]*/uevent r,
+
+ # Addons (too lax for icedove)
+ ##include
+
+ # for networking
+ network inet stream,
+ network inet6 stream,
+ @{PROC}/[0-9]*/net/if_inet6 r,
+ @{PROC}/[0-9]*/net/ipv6_route r,
+ @{PROC}/[0-9]*/net/dev r,
+ @{PROC}/[0-9]*/net/wireless r,
+
+ # should maybe be in abstractions
+ /etc/ r,
+ /etc/mime.types r,
+ /etc/mailcap r,
+ /etc/xdg/*buntu/applications/defaults.listr, # for all derivatives
+ /etc/xfce4/defaults.list r,
+ /usr/share/xubuntu/applications/defaults.list r,
+ owner @{HOME}/.local/share/applications/defaults.list r,
+ owner @{HOME}/.local/share/applications/mimeapps.list r,
+ owner @{HOME}/.local/share/applications/mimeinfo.cache r,
+ owner /tmp/** m,
+ owner /var/tmp/** m,
+ /tmp/.X[0-9]*-lock r,
+ /etc/udev/udev.conf r,
+ # Doesn't seem to be required, but noisy. Maybe allow 'r' for 'b*' if needed.
+ # Possibly move to an abstraction if anything else needs it.
+ deny /run/udev/data/** r,
+
+ /etc/timezone r,
+ /etc/wildmidi/wildmidi.cfg r,
+
+ # icedove specific
+ /etc/icedove/ r,
+ /etc/icedove/** r,
+ /etc/xul-ext/** r,
+ /etc/xulrunner-2.0*/ r,
+ /etc/xulrunner-2.0*/** r,
+ /etc/gre.d/ r,
+ /etc/gre.d/* r,
+
+ # noisy
+ deny @{MOZ_LIBDIR}/** w,
+ deny /usr/lib/icedove-addons/** w,
+ deny /usr/lib/xulrunner-addons/** w,
+ deny /usr/lib/xulrunner-*/components/*.tmp w,
+ deny /.suspended r,
+ deny /boot/initrd.img* r,
+ deny /boot/vmlinuz* r,
+ deny /var/cache/fontconfig/ w,
+ deny @{HOME}/.local/share/recently-used.xbel r,
+ deny @{HOME}/.* r,
+
+ # TODO: investigate
+ deny /usr/bin/gconftool-2 x,
+
+ owner @{PROC}/[0-9]*/mountinfo r,
+ owner @{PROC}/[0-9]*/stat r,
+ owner @{PROC}/[0-9]*/task/[0-9]*/stat r,
+ /sys/devices/pci[0-9]*/**/uevent r,
+ /etc/mtab r,
+ /etc/fstab r,
+
+ # Needed for the crash reporter
+ owner @{PROC}/[0-9]*/environ r,
+ owner @{PROC}/[0-9]*/auxv r,
+ /etc/lsb-release r,
+ /usr/bin/expr ix,
+ /sys/devices/system/cpu/ r,
+ /sys/devices/system/cpu/** r,
+
+ # about:memory
+ owner @{PROC}/[0-9]*/statm r,
+ owner @{PROC}/[0-9]*/smaps r,
+
+ # Needed for container to work in xul builds
+ /usr/lib/xulrun
Bug#811825: Patch
Hi!
> On 07/02/2016 10:37 AM, u wrote:
>> Here's a debdiff which fixes this bug.
>> I've tested building in a chroot using gcc-6.
>>
>> One might want to consider setting up a Git repository for this package :)
>
> Thanks!
Actually, it did not build correctly, I was a bit too optimistic here.
The error seemed to be that:
/usr/include/c++/6/bits/stl_iterator.h:304:5: note: template argument
deduction/substitution failed:
ppl_pips.cc:561:51: note: 'std::ostream {aka
std::basic_ostream}' is not derived from 'const
std::reverse_iterator<_Iterator>'
if (output_stream_p && *output_stream_p != std::cout)
^~~~
In file included from /usr/include/c++/6/bits/stl_algobase.h:64:0,
from /usr/include/c++/6/bits/char_traits.h:39,
from /usr/include/c++/6/ios:40,
from /usr/include/c++/6/ostream:38,
from /usr/include/c++/6/iostream:39,
from ../../src/ppl.hh:746,
from ppl_pips.cc:34:
/usr/include/c++/6/bits/stl_pair.h:376:5: note: candidate:
template constexpr bool std::operator!=(const
std::pair<_T1, _T2>&, const std::pair<_T1, _T2>&)
operator!=(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
So in a second try I also applied upstream commit
832e1e5b0c48d89588b4d2c20150473a308e3298 but i still get an error which
I've not yet completely identified.
> Indeed the best of all would be to upgrade to PPL 1.2.
Agreed. No idea if the maintainer plans on doing so :)
Cheers!
Bug#803171: [Pkg-privacy-maintainers] Bug#803171: Bug#803171: this only affects one profile in complaint mode
Hi Holger, Holger Levsen: > On Thu, Jun 30, 2016 at 12:32:58AM +0200, Nicolas Braud-Santoni wrote: >> Tested independently by U and myself. > > I'm looking forward for the next upstream release. I started preparing some patches for the current version. I'll not be able to test that today, but as soon as I do, we can maybe upload this so that this package will work again for AppArmor users? What do you think? Cheers! u.
Bug#811825: Patch
Hi,
Here's a debdiff which fixes this bug.
I've tested building in a chroot using gcc-6.
One might want to consider setting up a Git repository for this package :)
Cheers,
u.
diff -Nru ppl-1.1/debian/changelog ppl-1.1/debian/changelog
--- ppl-1.1/debian/changelog 2015-12-11 22:07:13.0 +0100
+++ ppl-1.1/debian/changelog 2016-07-01 12:22:22.0 +0200
@@ -1,3 +1,10 @@
+ppl (1:1.1-7.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply upstream patch to build with GCC6. Closes: #811825.
+
+ -- Ulrike Uhlig <u...@451f.org> Fri, 01 Jul 2016 12:03:57 +0200
+
ppl (1:1.1-7.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru ppl-1.1/debian/patches/build-with-gcc6 ppl-1.1/debian/patches/build-with-gcc6
--- ppl-1.1/debian/patches/build-with-gcc6 1970-01-01 01:00:00.0 +0100
+++ ppl-1.1/debian/patches/build-with-gcc6 2016-07-02 10:27:38.0 +0200
@@ -0,0 +1,16 @@
+Description: ppl should build from source when using gcc-6.
+Origin: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=fe5b8f435d431d9d64e0174c752aa856d1c61132
+Applied-Upstream: commit: fe5b8f435d431d9d64e0174c752aa856d1c61132
+Author: Patrik Pomelli <patrik.pome...@bugseng.com>
+
+--- a/demos/ppl_pips/ppl_pips.cc
b/demos/ppl_pips/ppl_pips.cc
+@@ -538,7 +538,7 @@
+
+ void
+ set_input(const char* file_name) {
+- if (input_stream_p && *input_stream_p != std::cin)
++ if (input_stream_p && (input_stream_p != ::cin))
+ delete input_stream_p;
+
+ if (file_name) {
diff -Nru ppl-1.1/debian/patches/series ppl-1.1/debian/patches/series
--- ppl-1.1/debian/patches/series 2015-12-07 22:06:22.0 +0100
+++ ppl-1.1/debian/patches/series 2016-07-01 12:47:25.0 +0200
@@ -1,4 +1,4 @@
-# empty
+build-with-gcc6
latex-header.diff
link-tests-with-libmpq.diff
doxygen-update.diff
signature.asc
Description: OpenPGP digital signature
Bug#824460: works
I confirm that using the profiles from the commit/pull request which intrigeri linked to, work correctly on Jessie. thanks!
Bug#824640: shadowsocks: Shadowsocks upstream has removed available public source code
Hi! thanks for your quick answer. Shell Xu: > Hi, u: > > That's very interesting. Let's see what happened one by one. > > First of all, source code are not been "deleted". It's just a branch > called "rm". If you switch branch to master, code is still been there ( > https://github.com/shadowsocks/shadowsocks/tree/master). You're correct. My mistake. However this branch has been set as main branch. > Next thing is really interesting. You can find my commit in repository ( > https://github.com/shadowsocks/shadowsocks/commit/3b242bee5eb191599a0d051497003127986ea290). > But if you click "Browse files", and pull to the end. It tunes out at the > time I did the packaging job, the repository address is " > https://github.com/clowwindy/shadowsocks/wiki; (its wiki), and License is > MIT. > Yes, I did the right job at that time. The repository is modified, > translated to someone else, and license changed. ack. Thanks for clarifying this. I actually did not see a release of this version at all. > I followed commit logs, and here is the log which license changed. ( > https://github.com/shadowsocks/shadowsocks/commit/ce805f0aeaea03646e01b623c4e2185f63a3562f). > The whole project are re-licensed to Apache to protect the name of > contributors. It's happened far after my work, even after Debian accept it. > (according here: https://packages.qa.debian.org/s/shadowsocks.html, it's > 2014-09-16) In this situation, I think the old code still can be used under > MIT, and new code can only be used under Apache. So I should use new > license if package new one. But I don't have to update package to follow > the new license. Correct. > As you might noticed, shadowsocks is a software which designed to > broken the GFW. So it's not weird that government wanna erase this whole > project. The main author (clowwindy) was found by police, and have a little > conversation. (which we call it "drink tea") He is forbidden to maintain > the project, even talk about it. So I don't trust any commit after that > time. (just before 2015-08-20) Because government might inject something in > it after that time. Thanks for clarifying this. > Here is the thing I wanna do. > > I'll update the package to version 2.8.2 in stretch. (of course, it's > not a "release", because the author never planed to release at the time > been called for "tea". and of course, under Apache License) That will be > the final version. Any "new" version after that time should been review > carefully. Fair enough. > And, I'll remove this project from Debian in next release (after > stretch). Because we should had something new at that time. (Or hopefully, > we can finally get ride of GFW at that time) Let's hope so! I'll retitle this bug report accordingly then. Cheers!
Bug#824640: shadowsocks: Shadowsocks upstream has removed available public source code
Package: shadowsocks Severity: important Dear Maintainer, upstream (https://github.com/shadowsocks/shadowsocks) has deleted available source code for shadowsocks. Thus, it appears to me that this package does not comply with Debian Policy anymore. Also, the "Homepage: https://github.com/clowwindy/shadowsocks; field in debian/control is not correct. Upstream code was available at this homepage: https://github.com/shadowsocks/shadowsocks. The License information provided in debian/copyright (expat) also seems incorrect: https://github.com/shadowsocks/shadowsocks/commit/7c08101ce8a673fafb22477e8ad720aa57114a1f. Here it is written that this software was released under an Apache license. It's unclear to me where the 2.1.0 version exactly comes from, it's not listed in the releases on https://github.com/shadowsocks/shadowsocks/releases. The latest version of shadowsocks was 2.8.1. So this package is also completely outdated. Cheers! u.
Bug#812115: Merged upstream
This has been merged upstream today.
Bug#749494: New upstream version
As stated on http://crypto.cat, a complete software rewrite is been done currently. In the meantime, there won't be any updates to the source code which has been unmaintained since 19 months. I am waiting for this to happen before continuing to work on the packaging. cheers! signature.asc Description: OpenPGP digital signature
Bug#815006: Icedove -> Thunderbird
Hi, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#5, you state that similar discussions are going on for the renaming of Icedove. Are those publicly trackable somewhere? Cheers! u.
Bug#814190: [Pkg-privacy-maintainers] Bug#814190: Bug#814190: tails-installer: tails installer fails to authentication
Hi, intrigeri: > Kenichiro MATOHARA wrote (09 Feb 2016 16:14:55 GMT) : >> > I tried the "Tails Installer" in Gnome. It was operating normally. >> > It seems to be a problem that occurs in the "awesome wm" environment. > So you're running a minimal X environment, without support for current > widespread desktop technologies like polkit. It's a fine choice, but > it means that some desktop software that requires elevated permissions > (such as Tails Installer) won't be able to work properly, and that > you're on your own to figure out what's missing when it happens. > > I'm now hesitating between closing this bug report, or documenting in > README.Debian the need for a complete desktop environment. Ulrike, and > other team-mates, any opinion? > Thanks for reporting this issue and thanks for investigating it! I think it should indeed be documented in README.Debian and the manpage - I can handle this. Cheers! u.
Bug#812115: (no subject)
I've modified your email address and issued a new pull request.
Bug#749494: (no subject)
Packaging is more or less ready but blocked by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81 I did not yet have the time to look at this in detail.
Bug#812115: [Pkg-privacy-maintainers] Bug#812115: helo_argument IP should be encapsulated in []'s
Hi, Chris Knadle: > u: >> Hi Chris, > > Hey, u. ;-) > >> Chris Knadle: >>> Package: xul-ext-torbirdy >>> Version: 0.1.4-1 >>> Severity: normal >>> Tags: patch >>> >>> Torbirdy sets mail.smtpserver.default.hello_argument = "127.0.0.1" which is >>> nonconformant with RFC 5821 §4.1.3: >>> >>>https://tools.ietf.org/html/rfc5321#section-4.1.3 >>> >>> I'm attaching a patch which fixes this. >>> >>> The issue that this is causing is that I have mail servers I run close >>> connections that use raw IP addresses in the HELO/EHLO, and that happens >>> prior to any SMTP AUTH. I was having to reset this setting on every Icedove >>> startup until I found where it was being set. >> >> thank you very much. >> >> I'll forward this bug & patch upstream. I think it belongs there > > Yep I agree. > >> unless you want to do that yourself? In that case, please go ahead :) > > It looks like there's a ticket open on an aspect of this issue already, but > the discussion instead (of being about the lack of IP encapsulation) is > about the choice of EHLO identifier, but this still seems like it might be > the right place to talk about this bug? > >https://trac.torproject.org/projects/tor/ticket/13006 I've created a pull request for this: https://github.com/ioerror/torbirdy/pull/27 I'll need to test possible leaks on the EHLO anyway and will report back. Cheers!
Bug#812115: helo_argument IP should be encapsulated in []'s
Hi Chris, Chris Knadle: > Package: xul-ext-torbirdy > Version: 0.1.4-1 > Severity: normal > Tags: patch > > Torbirdy sets mail.smtpserver.default.hello_argument = "127.0.0.1" which is > nonconformant with RFC 5821 §4.1.3: > >https://tools.ietf.org/html/rfc5321#section-4.1.3 > > I'm attaching a patch which fixes this. > > The issue that this is causing is that I have mail servers I run close > connections that use raw IP addresses in the HELO/EHLO, and that happens > prior to any SMTP AUTH. I was having to reset this setting on every Icedove > startup until I found where it was being set. thank you very much. I'll forward this bug & patch upstream. I think it belongs there - unless you want to do that yourself? In that case, please go ahead :) Cheers! u. signature.asc Description: OpenPGP digital signature
Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js
Package: lintian Version: 2.5.38.1 Severity: normal In the packaging for the Cryptocat extension, there is a false positive. The file is source code but contains a very long line that is a cryptographic constant cryptocat source: source-is-missing chrome/content/data/js/lib/otr.js https://anonscm.debian.org/cgit/pkg-mozext/cryptocat.git/ Cheers! -- System Information: Debian Release: stretch/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#745399: Taking over the ITP
Hey Alexandre, Alexandre Viau: > Unless you object, I intend to take over this ITP. > > I am in contact with upstream and we have already begun working on it > together. No objections :) Cheers!
Bug#808033: policykit-1: When invoked while screen locker is active the polkit, authorization window overlays the screen locker window
Package: policykit-1 Version: 0.105-14 Severity: normal Dear Maintainer, In a package (tails-installer, currently in Debian NEW queue), we use polkit to ask the user for authorization to rewrite the MBR of a USB stick and to use syslinux. When the screen locker is active though, the authorization window asking for the root password overlays the screen locker window. I'd have expected that this window would not appear over my locked screen, but only be accessible only when the screen is unlocked. Not sure if this bug report should go against Gnome screen locker instead? Cheers! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages policykit-1 depends on: ii dbus 1.10.4-1 ii libc6 2.19-22 ii libglib2.0-0 2.46.2-1 ii libpam-systemd 215-17+deb8u2 ii libpam0g 1.1.8-3.1 ii libpolkit-agent-1-00.105-14 ii libpolkit-backend-1-0 0.105-14 ii libpolkit-gobject-1-0 0.105-14 policykit-1 recommends no packages. policykit-1 suggests no packages.
Bug#803171: [Pkg-anonymity-tools] Bug#803171: torbrowser-launcher: AppArmor profiles broken with latest Tor Browser
Hi, thanks for your bug report! I'll check and update the profiles accordingly (upstream even). Cheers! u.
Bug#802013: [Pkg-anonymity-tools] Bug#802013: Bug#802013: torbrowser-launcher: change or add .png images in addition or replacement of xpm so torbrowser-launcher can show up in gnome-software.
Hi, shirish शिरीष: > On 17/10/2015, u <u...@451f.org> wrote: >> shirish शिरीष: >> >>> Can you change or add .png images in addition or replacement of xpm >>> so that torbrowser-launcher can show up in gnome-software. > This is specifically running gnome-software in mate. About > gnome-software, the short and long description :- Thanks for the precisions. In that case I believe this bug should be treated upstream first. Does gnome-software use the .desktop files? Does it specifically delete those files on installation? Your initial bug report said the file does not exist. Could you confirm this again please? Thanks! u.
Bug#802013: [Pkg-anonymity-tools] Bug#802013: torbrowser-launcher: change or add .png images in addition or replacement of xpm so torbrowser-launcher can show up in gnome-software.
Hi, shirish शिरीष: > Can you change or add .png images in addition or replacement of xpm > so that torbrowser-launcher can show up in gnome-software. > > Otherwise I get fires like this whenever i run tor-browser. > > (org.gnome.Software:21282): GsPlugin-WARNING **: failed to load stock > icon /usr/share/pixmaps/torbrowser80.xpm: Icon > '/usr/share/pixmaps/torbrowser80.xpm' not present in theme (null) Thanks for your bug report. Is this specific to running Gnome Shell in Stretch? On a Jessie installation I do not have this problem, the xmp icons show up fine. Cheers u.
Bug#733860: Debian Pond Packages
Ximin Luo:
> On 11/01/15 19:25, intrigeri wrote:
>> Ximin Luo wrote (11 Jan 2015 16:34:40 GMT) :
>>> I spoke to upstream (agl) at 31c3 and explained to him what
>>> Debian experimental is, and he is happy for it to be packaged
>>> there for now.
>>
>> Woohoo! \o/
>>
>
> Preliminary package is here:
>
> https://mentors.debian.net/package/pond
>
> but with the GUI disabled because of that pending GTK issue.
>
> I just need to write man pages for {client,editstate,server} then I
> will go upload it.
whoo :)))
Thanks!
Bug#801297: [Pkg-anonymity-tools] Bug#801297: torbrowser-launcher: Don't starts.
tags 801297 + moreinfo Hi Vladimir, Vladmimir Stavrinov: > Package: torbrowser-launcher > Version: 0.2.0-2 > Severity: normal > > Dear Maintainer, > > It try to do update on start but hangs forever. Even pressing button "Exit" > don't cause any effect Thanks for your bug report. Could you please try to give a little more detail: * Which update is it you are trying to do? The automatic one induced by the package itself? * Did it work before or is this a fresh install? * By default, tbl updates over Tor, could you try if updating without Tor works? In order to do so, run torbrowser-launcher --settings * Can you run torbrowser-launcher from a terminal and send us the output please? * Do you use AppArmor? Thanks! u.
Bug#784041: [Pkg-anonymity-tools] Bug#784041: exceptions.OSError: [Errno 2] No such file or directory
heya, Holger Levsen: >> And before we start fuddling around with this, we should migrate this >> package to the new pkg-privacy-maintainers list, instead of >> pkg-anonymity-tools. Aaaand i'd like to review the branch layout a bit, >> too. Maybe i can do that this week, so we can start working on this >> crippled package again ;) > > well, there are two issues here: a.) how to move forward with the package, > and > b.) how to fix what's in jessie now, which just doesnt work at all. fyi, i updated the branch layout in ssh://git.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git please pull from there now. > And b.) is more urgent IMO, even though the workaround, installing from > jessie-backports is trivial. So is 5f833d7 enough to fix 0.1.9-1+deb8u1 as > it's in the archive? i could try that later if nobody else does it before :) cheers!
Bug#762385: ITP: mailpile -- a modern fast web-mail client with user-friendly encryption and privacy features.
Hi, anarcat: > On Sun, Sep 21, 2014 at 06:21:58PM +0000, u wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Ulrike Uhlig <u...@451f.org> >> >> * Package name: wnpp >> Version: 0.4.0 >> Upstream Author: Mailpile Team <t...@mailpile.is> >> * URL: https://mailpile.is >> * License: AGPL v3 >> Programming Lang: Python >> >> Mailpile is a modern, fast web-mail client with user-friendly encryption >> and privacy features. >> Mailpile's primary user interface is web-based, but it also has a basic >> command-line interface and an API for developers. Using web technology >> for the interface allows Mailpile to function both as a local desktop >> application (accessed by visiting localhost in the browser) or a remote >> web-mail on a personal server or VPS. > > What's the status on this ITP? > > Relevant upstream docs i found were: > > https://github.com/mailpile/Mailpile/wiki/Getting-started-on-linux > https://www.mailpile.is/download/ I've not had the time to do anything yet. Feel free to start something if you want to, and I'd happily contribute. Cheers!
Bug#800706: Packaging needs branch love
Hi, the package has been updated but needs some more <3 https://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20150928/38.html We are on it :) cheers! u. signature.asc Description: OpenPGP digital signature
