Package: hamster-time-tracker
Version: 3.0.2-4
Severity: important
Dear Maintainer,
I installed hamster-time-tracker on a fresh installation of bookworm.
* What led up to the situation?
Trying to launch hamster from either command line or Gnome, the program fails
to start.
* What was
Hi Richard,
are you still experiencing this issue?
Or did you solve it differently?
(I was just going through bugs to see what can be cleaned up)
Ulrike
Hey,
On 20.01.22 15:10, Antoine Beaupré wrote:
On 2022-01-20 13:09:06, Ulrike Uhlig wrote:
On 19.01.22 16:25, Antoine Beaupré wrote:
On 2018-08-18 10:57:00, Ulrike Uhlig wrote:
https://salsa.debian.org/ulrike/weblate I added you as a maintainer there.
shouldn't we move this to the new
Hi Antoine,
On 19.01.22 16:25, Antoine Beaupré wrote:
On 2018-08-18 10:57:00, Ulrike Uhlig wrote:
Is anybody interested in this?
We (torproject.org) are.
Please do put your stuff on salsa, or alternatively someone could
restore from the alioth backups, but I couldn't find it here
Hi Daniel,
On 22.03.21 19:02, asciiw...@seznam.cz wrote:
On Thu, 23 Nov 2017 14:16:00 + u wrote:
thanks for your patch, I will try to add this as soon as I can, once
reviewed.
is there any progress regarding this? It has been almost three years and the
AppStream metadata file still
Hi Marcelo & Imre,
thank you for the report, patch and testing. I've for now forwarded your
bug report and patch upstream where this should be fixed for real.
https://github.com/micahflee/torbrowser-launcher/issues/552
Care to create a pull request there yourself? Otherwise I can do that.
I
Hello!
As I ran into this issue I am giving here a short summary from what I
understand to avoid that others have to re-read everything again:
AFAIU, there are two issues, one is related to Ghostscript, and one to
ImageMagick itself.
Ghostscript
===
According to
Hello!
intrigeri: IMO, there's no rush and it's OK for us to delay the upgrade (and
dealing with any Tails-specific integration work) until we upgrade to Bullseye.
[11:42:15 AM] intrigeri: If we had any other need/requirement on this front, we
would have let nodens know [11:42:46 AM]
Hello,
On 22.02.21 21:34, Antoine Beaupré wrote:
On 2021-02-22 21:13:40, Diederik de Haas wrote:
On Sat, 14 Nov 2020 23:14:12 +0100 Ulrike Uhlig wrote:
I did not forget about this, but I'm waiting for 2.3 to be released, as
there has been some huge refactoring which concerns the packaging
Hi!
On 10.02.21 13:08, Jonathan Marquardt wrote:
On Wed, Feb 10, 2021 at 12:26:35PM +0100, nodens wrote:
Yes, the apparmor profile shipped with onioncircuit won't allow access
to stuff in /usr/local. So python interpreter can't actually run.
You're right. Just as a test i added
Hi!
On 10.02.21 00:18, Jonathan Marquardt wrote:
On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote:
On 04/02/2021 13:04, Jonathan Marquardt wrote:
On Thu, Feb 04, 2021 at 12:23:17PM +0100, Clément Hermann wrote:
However I found out that it always works (on all of my systems)
Hi!
I did not forget about this, but I'm waiting for 2.3 to be released, as
there has been some huge refactoring which concerns the packaging of
Onionshare, see https://github.com/micahflee/onionshare/pull/1208.
Among other things, what was done there is:
* Renamed onionshare (former CLI) to
Hi!
thank you for the quick reply.
On 19.10.20 17:39, Raphael Hertzog wrote:
> Ulrike, did you restart your computer after the upgrade just to make sure
> that the dbus service was properly using the new code ?
I totally never reboot after installing packages, except for kernel
updates :) But
Package: hamster-time-tracker
Version: 3.0.2-3~bpo10+1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
* What led up to the situation?
I'm trying to start hamster-time-tracker. I have
This was apparently fixed upstream:
https://github.com/micahflee/onionshare/issues/1149#issuecomment-661668433
So it will be in OnionShare 2.3 in Debian.
On 17.07.20 13:11, Jakub Wilk wrote:
> * Ulrike Uhlig , 2020-07-17, 11:18:
>> I've fixed this already in
>> https://salsa.debian.org/pkg-privacy-team/onionshare/-/compare/a97caf90bf600175591c22d5695a62b69d9c8725...6e950f3ad7201836e8dab6080990f94b9384b9d9
>>
>>
On 17.07.20 11:31, Jakub Wilk wrote:
> * u , 2020-07-17, 11:10:
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
Hello,
On 16.07.20 23:11, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
>
> "onionshare --local-only" doesn't start an onion service (as expected),
> but it still connects to the Tor network. This is weird.
Weird indeed. I've forwared that bug upstream.
- ulrike
Hi Jakub!
On 16.07.20 23:21, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: minor
>
> The --website option is not documented in the manual page.
This was missed when the new version was uploaded.
I've fixed this already in
I addressed this issue by rewriting the manpage to make it more
up-to-date and reflect the features of the current version of onionshare.
See
https://salsa.debian.org/pkg-privacy-team/onionshare/-/compare/a97caf90bf600175591c22d5695a62b69d9c8725...6e950f3ad7201836e8dab6080990f94b9384b9d9
for
Hi Jakub!
On 15.07.20 23:04, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: wishlist
>
> onionshare has currently python3-pyqt5 in Depends. But as I understand
> it, this package is only needed for the GUI, whereas the CLI could work
> fine without it. I'd like to run
Hi!
On 15.07.20 11:30, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: minor
>
> The onionshare(1) man page says: "the crypto key lives in
> /tmp/onionshare/tmpXXX/private_key". I don't belive this is correct.
Thank you for reporting this bug.
I guess this phrase is very
Hi Ana!
On 03.04.20 15:36, Ana Custura wrote:
> On 16/03/2020 18:12, Ulrike Uhlig wrote:
>
>> If I understand correctly from a quick look, Yawning distributes his
>> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
>> [https://github.com/refract
Hi Birger!
> it would be great if U2F devices (like a yubikey) would be usable by
> default with torbrowser. I created an upstream merge request to allow
> these devices in the apparmor profile a couple of months ago and it was
> was merged [0] (thanks to intrigeri!), but there was no new
Hi Cecylia!
On 16.03.20 18:24, Cecylia Bocovich wrote:
> On Tue, 7 Jan 2020 10:36:20 +0100 Ulrike Uhlig wrote:
>> On 07.01.20 10:14, Ulrike Uhlig wrote:
>>> On 07.01.20 00:57, Chris Lamb wrote:
>>>> There is a new upstream release of obfs4proxy available (at th
Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-privacy-maintain...@alioth-lists.debian.net
Torbirdy is not compatible anymore with Thunderbird 68+ and the features
of Torbirdy cannot be ported to a new-style Thunderbird addon.
Therefore there is no use in keeping the package in the
Hi!
As Thunderbird 60 is still available in testing, torbirdy should be able
to migrate there. This way, upon updating to TB68, users will at least
get a warning that torbirdy is not compatible anymore instead of having
the package removed automatically, and maybe falsely assuming that they
are
On 07.01.20 10:14, Ulrike Uhlig wrote:
> On 07.01.20 00:57, Chris Lamb wrote:
>> There is a new upstream release of obfs4proxy available (at the time
>> of writing, 0.0.11):>> However, this will require the packaging of at least
>> https://
>> gitlab.com/yawni
Hi!
On 07.01.20 00:57, Chris Lamb wrote:
> Package: obfs4proxy
> Version: 0.0.8-1
> Severity: wishlist
>
> There is a new upstream release of obfs4proxy available (at the time
> of writing, 0.0.11):
>
> https://qa.debian.org/cgi-bin/watch?pkg=obfs4proxy
>
> However, this will require the
Package: xul-ext-torbirdy
Version: 0.2.6-1
Severity: important
Thunderbird is removing support for XUL extensions from version 68.
While there might be a possibility to convert Torbirdy to what
Thunderbird now calls MailExtensions and run the code of the extension
as legacy code, this would only
Package: ftp.debian.org
Severity: normal
The Tor project does not develop nor deploy obfsproxy anymore, see
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/list
(obfs2, obfs3)
Last upstream commit happened 5 years ago.
Package: ftp.debian.org
Severity: normal
Tails has discontinued releasing ISO images for USB sticks at the
beginning of 2019. Because of this, using this package has in fact
become obsolete.
Tails and Ulrike do not want to maintain this package in Debian anymore.
Upstream bug:
Hi!
On 31.07.19 11:30, Samuel Thibault wrote:
> Ulrike Uhlig, le mer. 31 juil. 2019 11:20:38 +0200, a ecrit:
>> On 30.07.19 18:07, Samuel Thibault wrote:
>>> Since python2 packages are being phased out, perhaps we can simply
>>> directly move to python3-dogtail, o
o a Vcs-Git in collab-maint?
>
> A repository was created by Ulrike Uhlig in January. I have now
> populated it a bit more, notably with the packaging history, and added
> the repo URL in its contrib.
Great, thank you!
I have done some work on the packaging locally, but I haven't pushed it
t
Hi again!
Pushed my modifications to salsa.d.o:debian/dogtail → branch debian/sid.
I let you judge what you can reuse and what stinks → please remove it,
as said previously, I did not manage to build, because patches need updates.
Cheers
Ulrike
Hi!
On 12.06.19 23:10, Simon McVittie wrote:
> Source: onioncircuits
> Version: 0.5-4
> Severity: important
> User: debian...@lists.debian.org
> Usertags: flaky
>
> The onioncircuits autopkgtest seems to fail occasionally, then succeed
> when retried. Because the unstable-to-testing migration
No news on this bug since 1 year and unreproducible by Sascha and
intrigeri → I propose to close this bug.
Hi!
On 27.05.19 15:02, Holger Levsen wrote:
> On Mon, May 27, 2019 at 02:18:54PM +0200, Ulrike Uhlig wrote:
>> It would be useful to know with which statements or assumptions you do
>> not agree with and why - so that the discussion may become more
>> productive &am
Hi Holger,
On 27.05.19 11:56, Holger Levsen wrote:
> i'm not sure I agree with the assumptions from this bug report but
It would be useful to know with which statements or assumptions you do
not agree with and why - so that the discussion may become more
productive & helpful.
> anyway, i just
Package: release.debian.org
Version: 0.5.6
Severity: normal
Please unblock package bilibop. I've uploaded 0.5.6 to unstable some
minutes ago.
Two bugs of severity important have been reported against bilibop-lockfs
few days ago and would be fixed by this upload:
-
Hi!
On 02.05.19 08:51, Piviul wrote:
> Il 30/04/19 18:45, Carsten Schoenert ha scritto:
>> Am 30.04.19 um 16:00 schrieb Piviul:
>>> Il 30/04/19 15:00, Carsten Schoenert ha scritto:
[...]
> stop and the cause is an unusual home path of remote users. You show me
> that was possible to add my
Hi!
On 30.04.19 09:31, Piviul wrote:
> Il 30/04/19 07:51, Carsten Schoenert ha scritto:
>> downgrading severity as AppArmor isn't officially supported and
>> activated for the Thunderbird package.
> but I'm not the one that activated apparmor for thunderbird: AFAIK in
> debian stretch (debian
Hi Georg,
On 16.04.19 13:15, Georg Faerber wrote:
> On 19-03-10 15:43:46, Georg Faerber wrote:
>> [...]
>>
>> Therefore, the current version of nautilus-python in testing, 1.2.2-2,
>> needs to be backported first. I've asked the maintainers to provide
>> such a backport, see #924250 for details.
Package: tails-installer
Severity: serious
I'm opening this RC bug in order to prevent tails-installer from
migrating to testing.
The package has effectively no more use in Debian and derivatives (apart
from Tails) anymore, as Tails is now shipping USB images instead of ISO
images.
Cheers!
u.
Hi Jonatan,
On 21.02.19 19:57, Jonatan Nyberg wrote:
> package: onionshare
> severity: normal
>
> Dear Maintainer,
>
> Please consider to upgrade to the current upstream version of onionshare
> (2.0).
It will happen.
Cheers!
u.
Hello!
this issue currently also blocks the migration of tails-installer,
shortly before the freeze.
Cheers!
u.
Hi John!
thank you for this report.
John Scott:
> Package: onionshare
> Severity: minor
>
> The Policy Manual suggests that OnionShare shouldn't depend or
> recommend torbrowser-launcher unless as an alternative to tor
> because it's in main (assuming OnionShare 1.3+ works with that).
Done!
Sorry for taking such a long time :)
Dear Nick,
> I hadn't seen the section of the manpage with the working Tor
> example, though, many thanks for pointing me to that. I have tested
> it, and that solution works fine.
Great!
> I'm closing the bug report, as this method is just as reasonable as
> using torsocks, and is well
This is fixed in the current version of Onionshare (> 1.3).
Hi!
Salvatore Bonaccorso:
> So it will additionally allow potentially denial of service on
> multi-user systems.
>
> Not sure if the grave severity is warranted, though, will leave this
> discussion to you both :)
Ack, grave sounds a bit grave.
> For tracking the issue, I have requested a
This seems to be due to a limit in torsocks that has not yet been
resolved upstream: to resolve an IPv6 address, Tor must listen on the
IPv6 SocksPort and the request must be sent to this SocksPort. As far as
i understand it.
Hi Nick,
does this still occur?
It could be a problem related to multiprocesses in which procmail does
"socket passing" and which torsocks might not handle well, or at all.
mpop seems to have examples working with Tor though:
https://www.mankier.com/1/mpop#Examples Have you contacted the
Hi,
thank you for this bug report. I confirm this behavior and thus I've
forwarded it to Tor's bugtracker.
Cheers
Ulrike
Hi Julian,
while you argue that the error message is clear, and that this is not a
bug, but a support request, I actually disagree with your assessment.
I think this _is_ a bug (and actually it has been filed here: #864640),
because this behavior is not caused by a user having modified something
After some research, this is actually not due to python-twisted but to a
change in the API of python-attrs in 17.1.0
(http://www.attrs.org/en/stable/changelog.html).
But python-twisted from stretch-backports has no versioned dependency on
python-attrs > 17.1.0. Installing python-attrs from
package: python-twisted
severity: normal
Dear Maintainer,
when launching torbrowser-launcher, that relies on python-twisted, I get
the following error:
File "/usr/bin/torbrowser-launcher", line 29, in
import torbrowser_launcher
File
Package: nautilus-wipe
Severity: wishlist
Dear Maintainer,
The current user flow for cancelling a Wipe Available Disk Space process
needs some UX love.
Current situation:
When using the "Wipe Available Disk Space" feature on a 4GB FAT
formatted drive, the process seemed to be taking to long so
Hi Martin!
I just realize right now that we've been in touch before concerning this
package… I guess none of us was interested enough in migrating the
existing packaging to Salsa.
At Tails we are still interested in seeing this packaged, but we have
not tried it ourselves (yet?).
However, we've
Hi!
Simon McVittie:
> Control: tags -1 + patch
> Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=774611
>
> On Fri, 17 Aug 2018 at 14:11:00 +0000, Ulrike Uhlig wrote:
> If you're pinging a bug like this, please keep the subject line that
> identifies which pack
ping ^
Unfortunately upstream has not replied, but you might still be able to
cherry-pick the patches… is that something you'd consider?
Cheers!
Ulrike
Hi!
This happens on my stretch system too.
Randomly. Here is what I have in the kernel log:
Aug 6 10:04:14 panpaniscus kernel: [63602.944141] traps:
gnome-shell[1438] general protection ip:7f7b0f36f95a sp:7ffc5cb45aa0
error:0 in libgobject-2.0.so.0.5000.3[7f7b0f33b000+52000]
Version of
Hi Georg,
with 2.9.3 this works for me without the error you describe (tested on
stretch though).
Interestingly you seem to be using a newer version of python-twisted
(17.9.0-1) than me (16.6.0-2). This error might be due to this. Can you
still reproduce this and if yes with which version of
Hi!
I'm currently using 2.9.3 and I cannot confirm this bug.
Can you update and tell us if it is still present?
Cheers!
u.
Hello!
Philipp Kern:
> On 18.07.2018 20:38, ju xor wrote:
>> Philipp Kern:
>>> On 2018-07-18 18:24, ju xor wrote:
Philipp Kern:
> Should this live in some kind of tor-* namespace?
no
>>> Without any rationale? :(
>> i'm not sure what you mean, but in case it helps, here some
Package: libcryptui
Severity: normal
Hi!
Seahorse relies on libcryptui to display a signature after file
verification. However, this is broken when the signing key has multiple
subkeys. This was reported upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=774611 and a patch was merged
into
Onionshare 1.3 ships a bundled Tor and allows also to use system tor or
TBB's tor. When wanting to use system tor, you
- need to be in the debian-tor group
- open tor's control port
Also see https://github.com/micahflee/onionshare/wiki/Connecting-to-Tor
for more information.
I think we can now
Hello Noël,
Noël Köthe:
> Am Mittwoch, den 26.04.2017, 12:21 + schrieb Ulrike Uhlig:
thanks a lot for the quick answer!
>> I'm trying to connect to a SFTP server on port 22 using lftp.
>> The same connection works fine from a GUI client.
[..]
> It is compiled against
Package: lftp
Severity: normal
Hi,
I'm trying to connect to a SFTP server on port 22 using lftp.
The same connection works fine from a GUI client.
It never works out, and I was wondering if this might be due to lftp not
being compiled with libssl?
Here's what I get with ldd:
ldd /usr/bin/lftp
Hi,
Right, it would not work out of the box without the dependency.
I agree with you that there should be a long term solution such as
creating a vendor specific file. However, right now I have not enough
time to test that in detail and I want to bring out the new upstream
version nevertheless.
Hi!
thanks for pointing this out. Indeed, these (old) patches are actually
not even needed. I've decided to delete them from the packaging. This
will result in
* new users will use the default TorBirdy configuration, which uses port
9150, or TorBrowser's tor.
* every user is able to modify
Hi Mike,
Mike Hommey:
> control: reassign -1 apparmor-profiles
>> Package: firefox
>> Severity: normal
>> as you might know, AppArmor confines programs according to a set of
>> rules that specify what files a given program can access. This approach
>> helps protect the system against both known
Package: firefox
Severity: normal
Hi,
as you might know, AppArmor confines programs according to a set of
rules that specify what files a given program can access. This approach
helps protect the system against both known and unknown vulnerabilities.
In several distributions such as Ubuntu or
Proposed Douglas' patch here:
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+ref/thunderbird/links
Hi Douglas,
>> it's great that you provided modifications to the AppArmor profile in
>> Debian! May I kindly ask you to send these upstream too?
>> If you think that's too much work, please just tag your bug using a
>> usertag. The corresponding tag would be "merge-to-upstream" and then the
>>
Control: forwarded 855346
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276
I've proposed a change upstream here:
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276
Cheers,
ulrike
Control: reopen 855346
Hi Carsten,
I think you meant to close 855343 instead.
I can still reproduce this problem with the latest profile from the
Debian archive. I'll look into it.
Cheers!
u.
Hi!
>> And, would you or someone else with the apparmor background create a
>> sentence about the Apparmor profile in Thunderbird within the new
>> Thunderbird wiki site?
>
>> https://wiki.debian.org/Thunderbird
That was done here: https://wiki.debian.org/Thunderbird#AppArmor_profile
please
Hi Douglas,
it's great that you provided modifications to the AppArmor profile in
Debian [1]! May I kindly ask you to send these upstream too? That way,
they will get reviewed first and then all other distributions using
AppArmor can profit from your improvements.
Debian has some documentation
Hi Carsten,
oh, sorry! For some reason I did not receive this email, or accidentally
deleted it. So answering only now...
> @Ulrike
> Would you point this issue upstream? Need we a also a update for the
> profile of Thunderbird in Debian? If so could you provide a patch?
I'll take care of it
Hi Felipe,
>>> + # install apparmor profile
>>> + cp debian/apparmor/usr.bin.pulseaudio
>>> debian/pulseaudio/etc/apparmor.d/usr.bin.pulseaudio
>>>
>>> This would install the file with whatever umask is currently set.
>>
>> Thanks for making this clear.
>> Yes. root:root 644 is correct.
>
>
Control: tags + patch
Hi!
Felipe Sateler:
> On Wed, Mar 15, 2017 at 11:23 AM, Ulrike Uhlig <ulr...@debian.org> wrote:
>> tags + patch
>>
>> Hi,
>>
>>>> I'll try to prepare a patch to make it easier for you to integrate it.
>>>
>&
tags + patch
Hi,
>> I'll try to prepare a patch to make it easier for you to integrate it.
>
> That would be great.
Please find a patch attached.
The will simply to copy the file to /etc/apparmor.d/ and only if the
user has AppArmor installed and enabled, this will then confine the
pulseaudio
Hi Felipe,
thank you for your answer.
Felipe Sateler:
> On Wed, Mar 15, 2017 at 5:07 AM, Ulrike Uhlig <ulr...@debian.org> wrote:
>> Package: pulseaudio
> I have some doubts:
>
> 1. What is the benefit of shipping the profile info in pulseaudio
> versus shipping
Package: pulseaudio
Severity: normal
Hi,
as you might know, AppArmor confines programs according to a set of
rules that specify what files a given program can access. This approach
helps protect the system against both known and unknown vulnerabilities.
In several distributions such as Ubuntu or
85 matches
Mail list logo
