[Tails-dev] Fix in tails-greeter
Hi, I just want to start contributing to Tails, so I selected an easy task: https://labs.riseup.net/code/issues/5332 I have attached a patch for this. cheers, kurono From cb204e5019823fcefca2d3191dc8ebacc3e64d96 Mon Sep 17 00:00:00 2001 From: kurono Date: Wed, 4 Sep 2013 00:13:10 +0200 Subject: [PATCH] Feature #5332 --- glade/persistencewindow.glade |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glade/persistencewindow.glade b/glade/persistencewindow.glade index f4d8487..278ea7d 100644 --- a/glade/persistencewindow.glade +++ b/glade/persistencewindow.glade @@ -300,7 +300,7 @@ True False -gtk-info +gtk-warning 1 -- 1.7.9.5 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/unmount-persistent-volume-on-shutdown (#6228)
03/09/13 20:36, intrigeri wrote: >> 2. Next, let me cite your git commit message: > >>> The upstream live-boot initscript (shipped by live-config) doesn't know >>> about >>> our persistent mounts (/live/persistence/*), since they are performed from >>> GDM, >>> and not further moved to the same place as mounts done during initramfs are >>> (/lib/live/mount/persistence/*). > >> So, instead of patching boot-init.sh, why don't we make Tails Greeter >> mount its persistent volumes in the same directory as live-boot? My >> understanding is that our mount point is just an artifact of us using an >> old (development) version of live-boot, which used that directory, at >> the time Tails Greeter was extended with persistence support, but I may >> be wrong. > > I cannot find where *we* would be specifying /live/persistence as the > mountpoint -- isn't live-boot doing this all by itself, and > mount'ing --move to /lib/live/mount/persistence later? I was confusing the fact that Tails Greeter, not live-persist, unlocks the LUCKS volume with a similar-looking fantasy where it's Tails Greeter, not live-persist, that mounts the unlocked volume. In the latter case the live-boot code that live-persist runs would actually reuse the mountpoint, and we'd get what I suggest. Sorry for the confusion, I should have looked it up. >> so I merged this into stable (and devel). > > Great! I've updated the ticket accordingly, so that you know how to do > it yourself next time: > https://labs.riseup.net/code/issues/6228#note-12 > > However... I can't see this branch merged into stable and devel. > I see other branches that were merged today, but not this one. > Perhaps you forgot to push? I did push... with the wrong branch merged. This is now reverted and the correct branch is merged and pushed. Sorry for making it more difficult to write the 0.20.1 changelog... Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Limiting i2psvc to UDP through firewall
03/09/13 18:53, intrigeri wrote:
> Hi,
>
> sajol...@pimienta.org wrote (31 Aug 2013 14:00:08 GMT) :
>> A Whisperback bug report is suggesting us to limit the user i2psvc to
>> send UDP through the firewall.
>
> Looks mostly good (once it has comments), only one question below.
>
>> Here is a patch for that.
Unfortunately the premise of this patch is wrong; I2P uses *both* UDP
and TCP transport over the "clear" Internet [1]. If anything this change
will make Tails I2P clients stand out.
[1] http://www.i2p2.de/protocols.html (see the "Transport layer" bullet)
>> It also adds missing ports 7654 7658 for the
>> user amnesia to access some i2p services.
>
> Once some commit message tells me what problem this solves, and what
> "some i2p services" are, then I'm happy to review this part.
> The design doc would need an update, likely, but this can probably
> wait for a future iteration.
For the record, the I2P FAQ has a comprehensive list of all ports (local
and external) used by I2P:
http://www.i2p2.de/faq.html#ports
TCP lo port 7654 is for I2CP [1], a client protocol, that no application
shipped in Tails depends on. I don't see any harm in white-listing it,
but it'll only be useful for users that actually install some
(non-supported) application that uses I2CP, and hence I don't see much
of a reason to either.
[2] http://www.i2p2.de/i2cp
TCP lo port 7658 gives local access to the I2P web server that can be
enabled to serve a personal eepsite (i.e. it's akin to a http Tor hidden
service), but a placeholder site is shown it's disabled. Note that the
I2P webserver is disabled by default in Tails. I suppose this would be
handy for users that enable it, but I'm not sure we want to support
that, especially since we're in hidden mode.
>> +outerface ! lo mod owner uid-owner i2psvc {
>> +proto udp ACCEPT;
>> +}
>
> Any specific reason to only restrict on !lo?
> In other words, does I2P need to do TCP on the loopback interface?
I2P doesn't start any UDP lo listeners so such a restriction looks like
a valid firewall lockdown step. I think i2psvc at least needs access to
the service wrapper (TCP lo port 32000+, the first free one) for being
able to shut down cleanly.
---
While the above makes it clear that there's room for some more
fine-grained white-listing of which lo ports i2psvc (and debian-tor for
that matter) can access, I sadly think there's nothing in this patch
really worth merging at this point. Sorry, anonymous contributor. :(
Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/unmount-persistent-volume-on-shutdown (#6228)
hi, anonym wrote (03 Sep 2013 17:43:42 GMT) : > My tests show that an old Tails install that consistently had to do > recovery after boot consistently didn't have to do recovery once > upgraded to a version with the fix. With "consistently" I mean something > like "three reboots", in boot cases (well, an extra we're you get a > recovery for the latter scenario since it'd have to do deal with the > mess from the last shutdown with the older version). I'm glad you confirm this patch fixes the problem. > I do, however, have a two questions: > 1. I don't see how this unmounting performed in boot-init.sh deals with > removing LUKS' DM mappings, which should prevent TailsData from being > unmounted cleanly. The mappings are unmounted, and after that there's a > sync, but is that enough? I don't see any mentions of recovery for the > TailsData partition in syslog, so maybe it's all fine. Just something > for consideration. I believe that umount is enough to ensure the data is written to disk. > 2. Next, let me cite your git commit message: >> The upstream live-boot initscript (shipped by live-config) doesn't know about >> our persistent mounts (/live/persistence/*), since they are performed from >> GDM, >> and not further moved to the same place as mounts done during initramfs are >> (/lib/live/mount/persistence/*). > So, instead of patching boot-init.sh, why don't we make Tails Greeter > mount its persistent volumes in the same directory as live-boot? My > understanding is that our mount point is just an artifact of us using an > old (development) version of live-boot, which used that directory, at > the time Tails Greeter was extended with persistence support, but I may > be wrong. I cannot find where *we* would be specifying /live/persistence as the mountpoint -- isn't live-boot doing this all by itself, and mount'ing --move to /lib/live/mount/persistence later? > so I merged this into stable (and devel). Great! I've updated the ticket accordingly, so that you know how to do it yourself next time: https://labs.riseup.net/code/issues/6228#note-12 However... I can't see this branch merged into stable and devel. I see other branches that were merged today, but not this one. Perhaps you forgot to push? > Sorry for the delay! No worries, we're still far enough from the freeze to handle a one-liner patch :) Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
On Tue, Sep 03, 2013 at 08:03:48PM +0200, intrigeri wrote: > Hi, > > berta...@ptitcanardnoir.org wrote (02 Sep 2013 10:59:48 GMT) : > > Branch: feature/More_uniq_built_iso_name_in_jenkins > > Ticket: #6248 (https://labs.riseup.net/code/issues/6248) > > > 64f39f1 Use more unique iso name when building from jenkins. > > > This commit introduces more unique iso name when building in jenkins so > > that we will be able to keep several isos per day in our CI environment. > > Yeah :) > > [...] All remarks have been corrected in a commit pushed in the same branch. Didn't want to debate :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Impossible to install some packages on Tails through plain apt
Hi, sajol...@pimienta.org wrote (31 Aug 2013 14:21:44 GMT) : > So we might want to either: > - Say this is a problem in general, and instead remove all those > packages at the end of the build than setting them a -1 > pin priority. OK, and sorry for causing this mess in the first place. Well, I guess it was a useful optimization for a while. And perhaps some day, live-build (or whatever we use by then) will support preferences.d, and we can drop these -1 sections into a dedicated file that we delete at the end of the build. > - Review this list of packages on an ad-hoc basis. I don't get what would be the goal of this review. > I'm ready to propose a branch to implement any of those options. Awesome! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Trash on persistent volume
Hi, On Sat, 31 Aug 2013 15:43:13 +0200 sajol...@pimienta.org wrote: > As pointed out in a Whisperback report, there is currently no way of > emptying the trash stored in the persistent volume without interacting > with hidden files. I think that's an important usability issue. > I confirm this issue and filed it as https://labs.riseup.net/code/issues/6254 > When deleting a file from the Persistent folder it goes into a folder > named `.Trash-1000` in the same Persistent folder. > > Doing right-click on the Trash icon on the desktop, and choosing > "Empty Trash" does not remove those files. Restarting Tails does not > remove those files either. You have to know where those files are and > navigate to that hidden folder in order to free space on your USB > stick. > > Without talking about the implementation details, what we could do is: > > - Keep this trash on the USB stick, and have it persistent. But still > have it taken into account when doing "Empty Trash". That's what I would expect. That's in trash-spec[1] and is supposed to be GNOME defaults behaviour on removable devices. > - Move files out of the persistent volume into the main trash when > doing "Move to trash" on the Persistent folder. So that trash won't be > persistent and will be merged with the main trash. The files are > removed whenever Tails is shut down. Why not, but it's not what I would expect. That's also supported by Freedesktop "Trash Can" specification[1]. > - Automatically empty the trash of the Persistent folder when shutting > down; right before unmounting the persistence volume. I understand > that this will not work when doing an emergency shutdown. > I don't think this idea is as user friendly as the others are. I'm up to have a look at this but I don't promise any deadline for now. It someone feels like doing it, don't hesitate! [1]. http://freedesktop.org/wiki/Specifications/trash-spec/ Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/unmount-persistent-volume-on-shutdown (#6228)
03/09/13 15:08, intrigeri wrote: > intrigeri wrote (22 Aug 2013 13:25:18 GMT) : >> please review'n'merge bugfix/unmount-persistent-volume-on-shutdown, >> that fixes ticket #6228, into stable and devel. My tests show that an old Tails install that consistently had to do recovery after boot consistently didn't have to do recovery once upgraded to a version with the fix. With "consistently" I mean something like "three reboots", in boot cases (well, an extra we're you get a recovery for the latter scenario since it'd have to do deal with the mess from the last shutdown with the older version). I do, however, have a two questions: 1. I don't see how this unmounting performed in boot-init.sh deals with removing LUKS' DM mappings, which should prevent TailsData from being unmounted cleanly. The mappings are unmounted, and after that there's a sync, but is that enough? I don't see any mentions of recovery for the TailsData partition in syslog, so maybe it's all fine. Just something for consideration. 2. Next, let me cite your git commit message: > The upstream live-boot initscript (shipped by live-config) doesn't know about > our persistent mounts (/live/persistence/*), since they are performed from > GDM, > and not further moved to the same place as mounts done during initramfs are > (/lib/live/mount/persistence/*). So, instead of patching boot-init.sh, why don't we make Tails Greeter mount its persistent volumes in the same directory as live-boot? My understanding is that our mount point is just an artifact of us using an old (development) version of live-boot, which used that directory, at the time Tails Greeter was extended with persistence support, but I may be wrong. If this makes sense, perhaps we should re-work feature/consistent-peristence-path (also in the Tails Greeter repo) to use the same persistence path, and then drop this chroot patch? --- Even if 1 is something we care about this branch only makes the situation better, and 2 is something we'd want in a new feature for a major release, not a bugfix release like 0.20.1, so I merged this into stable (and devel). >> I've assigned the ticket to anonym for review, since he's the one who >> knows our persistence code best, but I'm sure many others would be >> able to grep for "recovery" in dmesg output, and confirm this patch >> does what it pretends to :) > > Ping? anonym, do you think you can do this in time for the freeze, or > should I nag someone else? Sorry for the delay! Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
Hi,
berta...@ptitcanardnoir.org wrote (02 Sep 2013 10:59:48 GMT) :
> Branch: feature/More_uniq_built_iso_name_in_jenkins
> Ticket: #6248 (https://labs.riseup.net/code/issues/6248)
> 64f39f1 Use more unique iso name when building from jenkins.
> This commit introduces more unique iso name when building in jenkins so
> that we will be able to keep several isos per day in our CI environment.
Yeah :)
> +# * if jenkins build from a branch:
> tails-$ARCH-$BRANCH-$VERSION-$COMMIT-$TIME.iso
s/jenkins/Jenkins/
s/build/builds/ for consistency with the above lines.
> +if [ ! -z "$JENKINS_URL" ]; then
`! -z' can simply be called `-n'.
> +
> BUILD_BASENAME="tails-${LB_ARCHITECTURE}-${CLEAN_GIT_BRANCH}-${AMNESIA_VERSION}-${GIT_SHORT_ID}-${AMNESIA_NOW}"
I'd rather see the time/date ($AMNESIA_NOW) inserted *before* the
commit ID, so that lexical sorting is still equivalent (among builds
from a given branch * version) to time-based sorting.
> +AMNESIA_NOW="`TZ=UTC date '+%Y%m%dT%H%MZ'`"
`date --utc' looks more robust to me, but it surely can be debatted.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Improving Tails USB Installer messages when upgrading
Hi, On Tue, 27 Aug 2013 19:44:16 +0200 sajol...@pimienta.org wrote: > Someone sent us a Whisperback bug report to point the fact that the > message of Tails USB Installer should be more reassuring when doing an > upgrade on a USB stick with persistence. > > "Your device already contains a LiveOS. > If you continue, this will be overwritten. > Press 'Next' if you wish to continue." > > The installer doesn't actually specify that the persistent storage > will be kept. This seems to be an important UX problem. > I agree. > A suggestion would be to have Tails USB Installer look at the USB > stick and see if there's already a persistence volume. If there is, > it should warn you that the Tails OS will get overwritten but the > persistence volume will remain the same. > Not sure I find it relevant to put energy to implement the checks. But why not? > Otherwise, without even changing the logic, the installer could have a > line somewhere saying that the persistent storage will not be erased. > That seems me easy and improving the situation (nearly) as much as the other proposal; Something like: Your device already contains a live operation system like Tails. If you continue, this will be overwritten by a new Tails version. Your persistent partition will be preserved. Press 'Next' if you wish to continue. > If we agree on that, I volunteer to do a preliminary patch. > Either way you choose, i'll be happy to review it. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installing Tails onto USB-Stick
Hi, > > > * I believe some kind of `sync' must be issued with `dd' too, > > perhaps with oflags or something, isn't it? > > I never experienced the need to do anything more than plain `dd`. Did > you? I know Alan is a big `dd` fan, so I'm putting him in explicit > copy as well so he speak out. > No idea. I just use `dd && sync`. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Trash on persistent volume
Possibly related: https://bugzilla.gnome.org/show_bug.cgi?id=604015 (Note the trash-cli package, if we need to go this far.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Should we avoid using the word bug?
Hi, winterfa...@riseup.net wrote (25 Aug 2013 11:03:50 GMT) : > I want to propose some wording improvements for whisperback and > corresponding documentation. I'm glad you do :) > Right now, the desktop icon read as "Report a bug". Bug is a real and > recognized word for software error, but it is also a real and recognized > word for a kind of surveillance device secretly recording audio [1]. I > therefore believe that the word "bug" may be confusing in the context of > Tails. > I don't know what applies for English, but in Swedish non-technical people > tend to believe you talk about the listening device when you say "bugg". I > think this mistake may exist in more languages, so I propose to change the > desktop icon to read as "Report an error" instead. > Likewise I want the text inside whisperback that now reads "Help us fix > your bug!" to read "Help us fix your software error!" or even "Help us fix > your software bug!". And similar for other instances of the word "bug". I've no strong opinion about the whole thing, but I'd rather use "problem" than "error". Most "bugs" reported to Tails are really features (as in: result from design choices), or problems caused by sub-optimal documentation and reading. In both cases, they are real problems in the experience of the reporter, but are not really software bugs. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Trash on persistent volume
hi, sajol...@pimienta.org wrote (31 Aug 2013 13:43:13 GMT) : > As pointed out in a Whisperback report, there is currently no way of > emptying the trash stored in the persistent volume without interacting > with hidden files. I think that's an important usability issue. Agreed. > Without talking about the implementation details, what we could do is: > - Keep this trash on the USB stick, and have it persistent. But still > have it taken into account when doing "Empty Trash". Hmm. This looks perfect. I guess upstream has already discussed this 3 times and decided against it for some good reason, or? > - Move files out of the persistent volume into the main trash when doing > "Move to trash" on the Persistent folder. So that trash won't be > persistent and will be merged with the main trash. The files are removed > whenever Tails is shut down. This is likely too heavy on memory to be a reasonable solution, unfortunately. > - Automatically empty the trash of the Persistent folder when shutting > down; right before unmounting the persistence volume. I understand that > this will not work when doing an emergency shutdown. This would seem acceptable to me. I'd be happier if we didn't have to add more code to get some reasonable result, though. Another way would be to just disable Trash on the persistent volume. I've not read the Trash specification [1], and I've not tested it either, but I've seen $someone_on_the_Internet suggest that creating $PERSISTENCE/.Trash and/or $PERSISTENCE/.Trash-1000 as *regular* files would be enough to achieve this. [1] http://standards.freedesktop.org/trash-spec/trashspec-latest.html Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Limiting i2psvc to UDP through firewall
Hi,
sajol...@pimienta.org wrote (31 Aug 2013 14:00:08 GMT) :
> A Whisperback bug report is suggesting us to limit the user i2psvc to
> send UDP through the firewall.
Looks mostly good (once it has comments), only one question below.
> Here is a patch for that.
> It also adds missing ports 7654 7658 for the
> user amnesia to access some i2p services.
Once some commit message tells me what problem this solves, and what
"some i2p services" are, then I'm happy to review this part.
The design doc would need an update, likely, but this can probably
wait for a future iteration.
> +outerface ! lo mod owner uid-owner i2psvc {
> +proto udp ACCEPT;
> +}
Any specific reason to only restrict on !lo?
In other words, does I2P need to do TCP on the loopback interface?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Point the "Report a bug" desktop launcher to "Help & Support"?
Hi, I hereby propose we have the "Report a bug" desktop shortcut link to the local version of the "Help & Support" web page (either in Yelp or in Iceweasel, I guess). WhisperBack could still be started from the Applications menu. (Below, I'm freely quoting someone else to support this proposal. I hope you don't mind!) The path we would like to see users go through is visiting the Tails web site, and: Help & Support → Found a problem? → Found a bug? This path includes: checking whether the problem is known already, upgrading if needed, reading the bug reporting guidelines, etc. Alternatively, we could simply remove this launcher on the grounds that we already have a "Tails documentation" one. Thoughts? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Improving Tails USB Installer messages when upgrading
Hi, sajol...@pimienta.org wrote (27 Aug 2013 17:44:16 GMT) : > The installer doesn't actually specify that the persistent storage will > be kept. This seems to be an important UX problem. Agreed. > A suggestion would be to have Tails USB Installer look at the USB stick > and see if there's already a persistence volume. If there is, it should > warn you that the Tails OS will get overwritten but the persistence > volume will remain the same. This looks slightly over-engineered to me. > Otherwise, without even changing the logic, the installer could have a > line somewhere saying that the persistent storage will not be erased. I like it: let's just add something along the lines of "Any persistent volume on this stick will remain unchanged" (rephrased by our Great Master of the Style Guide :) at upgrade time, regardless of whether persistence is present or not. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_virtualbox_dkms_build
Hi, sajol...@pimienta.org wrote (25 Aug 2013 12:23:20 GMT) : > If we think it is too hackish, we might try to apply the patch the > hopefully fixes the build directly on older versions: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704130 > https://www.virtualbox.org/changeset/39224/ I think the "install libc6 and friends from unstable, then downgrade" process is too hackish, and I don't want to be a release manager when it breaks horribly due to changes in Debian unstable eight hours before I build the final ISO. > I need some guidance on what we think the best strategy would be here. I propose we rebuild VirtualBox 4.2.16-dfsg-1~bpo70+1 in a Squeeze + Xorg/squeeze-backports environment, upload the result to squeeze-sloppy-backports, and use it: no version mismatch, we get closer to what we'll get once based on Wheezy, we get closer to #5606 (add virtualbox host software), and we don't have to carry the packages in our APT repository. I'm glad to provide some guidance to anyone who wants to do it, and I'll do the uploads as needed. What do you think? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/unmount-persistent-volume-on-shutdown (#6228)
intrigeri wrote (22 Aug 2013 13:25:18 GMT) : > please review'n'merge bugfix/unmount-persistent-volume-on-shutdown, > that fixes ticket #6228, into stable and devel. > I've assigned the ticket to anonym for review, since he's the one who > knows our persistence code best, but I'm sure many others would be > able to grep for "recovery" in dmesg output, and confirm this patch > does what it pretends to :) Ping? anonym, do you think you can do this in time for the freeze, or should I nag someone else? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fwd: Bug#719297 closed by Jérémy Bobbio (Bug#719297: fixed in ruby-packetfu 1.1.8-1)
hi, ruby-packetfu was accepted in unstable => anonym, I'll let you update the blueprint & tickets accordingly. --- Begin Message --- This is an automatic notification regarding your Bug report which was filed against the wnpp package: #719297: ITP: ruby-packetfu -- PacketFu is a mid-level packet It has been closed by Jérémy Bobbio . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Jérémy Bobbio by replying to this email. -- 719297: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719297 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: ruby-packetfu Source-Version: 1.1.8-1 We believe that the bug you reported is fixed in the latest version of ruby-packetfu, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 719...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. J�r�my Bobbio (supplier of updated ruby-packetfu package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Aug 2013 19:25:47 +0200 Source: ruby-packetfu Binary: ruby-packetfu Architecture: source all Version: 1.1.8-1 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers Changed-By: J�r�my Bobbio Description: ruby-packetfu - PacketFu is a mid-level packet manipulation library for Ruby Closes: 719297 Changes: ruby-packetfu (1.1.8-1) unstable; urgency=low . * Initial release. (Closes: #719297) Checksums-Sha1: 2e38645c227f5a4c0f41b27b644a10f4abfc6169 2094 ruby-packetfu_1.1.8-1.dsc 8e58d0ff4b34ad9c75b51b63b87daafa23e8629d 750686 ruby-packetfu_1.1.8.orig.tar.gz 7fe275eba27ca2193280fc34c6a230efdc329a3e 2786 ruby-packetfu_1.1.8-1.debian.tar.gz 80a5ceb40121fe41b0e3e695f2b2966464b9e3e5 682248 ruby-packetfu_1.1.8-1_all.deb Checksums-Sha256: dde5e9c7ca09ee427332c57fc830eab8d05398db8e3ed6a33386f653e7a4ede8 2094 ruby-packetfu_1.1.8-1.dsc 648c6d7c8764db2b14bdfc89f2b74f00c8c324556a9cc550afd1798c6e0a7be6 750686 ruby-packetfu_1.1.8.orig.tar.gz d512c4f4418fb881ee45a08622eccc153fa473c82a2a8d992efb0d852c6abd60 2786 ruby-packetfu_1.1.8-1.debian.tar.gz 233e7c52cb51af19f6f2c2f9c3d6f0388cbd2bf0d5d830a8a497b1dab0d1659e 682248 ruby-packetfu_1.1.8-1_all.deb Files: cc7495bdede675022514c2d784072309 2094 ruby optional ruby-packetfu_1.1.8-1.dsc d7f4a01f4cb24e446be59296e55e0e44 750686 ruby optional ruby-packetfu_1.1.8.orig.tar.gz fd688eca534e9fb4438877176b27991d 2786 ruby optional ruby-packetfu_1.1.8-1.debian.tar.gz abebdd0ef3e0da3759f6f0df57b731d3 682248 ruby optional ruby-packetfu_1.1.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSGO0SAAoJEEgU3sIrMHw8WMgQALdiIiXXdFc48pwjk6nalCas /dap1i0hk25DH0itjoyRGTK2bEJO0TIFt9DlWApcCjSpezhZshLj3fwhKOscCPD4 YQCzb9liwvjP7fHu4bkhQ5vbGl3NMXyJX9vRHU8ZeroQtPchagxqdFh2VE8AQCsO 1ARu6cTbzx0hxb7Xw37eRWLYBcFNQN86zBoUo8P5xl8gXfSEwGrvWYcVW+16mbr5 UeKdQ23VQpTd4wTia1vX4omGxjHxysFzX8AQWBbpWJlyWVStri/SBCXCJNhm2PSY tzdr5q05q53GSPCH97/wMBgUcREdDT7ZULIQUhKBEYnsus9HVhYKnoy56ThXOA80 VbqLAs0oBkOPIaVzbtTXt8kovWUwPnQYdsgSZN6LHy4Tvp7XJ/YATQXOiuoUIey8 gzWgMGaAE4q9j9L/aKfqA3lQtB7Z5O6j0+AyWmXMHCRT1XjC/63ZXquoHF2yAo9C dgInKbK6IJGBdbyD0oGcrwgq9b9lWYcfDe/m326LwsKI36QCpJzTV7T4JDcLjaAe jCe2rFXrNa5SkO2uB+HVH9yafVn5cibrhtYfGtGlMOg/zJAfj4TxYycGhZ34yO2M 646WOXCYgdWaiGbI8AQq4OZOBFaqT2ITo6X3GQKLnFviKKyQFA+x+x/uBo1nCrh8 35xmWvlVHc1AzosynZ6g =Tjbx -END PGP SIGNATURE End Message --- --- Begin Message --- Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, tails-dev@boum.org * Package name: ruby-packetfu Version : 1.1.8 Upstream Author : Tod Beardsley * URL or Web page : https://github.com/todb/packetfu & https://rubygems.org/gems/packetfu * License : BSD Description : PacketFu is a mid-level packet manipulation library for Ruby We at Tails [1] are using packetfu as part of our Cucumber-powered test suite. Teaser: you can help anonymity online today -- maintain packetfu in Debian, and help us automatically ensure that Tails does not leak any non-Tor connection :) [1] https://tails.boum.org/ Cheers, -- intrigeri --- End Message --- --- End Message --- -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum
[Tails-dev] Fwd: Bug#719301 closed by Jérémy Bobbio (Bug#719301: fixed in ruby-rjb 1.4.8-1)
hi, ruby-rjb is now in Debian unstable :) anonym, I'll let you update the blueprint (and possibly relevant tickets) accordingly. --- Begin Message --- This is an automatic notification regarding your Bug report which was filed against the wnpp package: #719301: ITP: rjb -- RJB is a Ruby Java Bridge It has been closed by Jérémy Bobbio . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Jérémy Bobbio by replying to this email. -- 719301: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719301 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: ruby-rjb Source-Version: 1.4.8-1 We believe that the bug you reported is fixed in the latest version of ruby-rjb, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 719...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. J�r�my Bobbio (supplier of updated ruby-rjb package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 13 Aug 2013 23:30:16 +0200 Source: ruby-rjb Binary: ruby-rjb Architecture: source amd64 Version: 1.4.8-1 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers Changed-By: J�r�my Bobbio Description: ruby-rjb - Ruby-Java bridge using Java Native Interface Closes: 719301 Changes: ruby-rjb (1.4.8-1) unstable; urgency=low . * Initial release (Closes: #719301) Checksums-Sha1: 0587c46f31adb3778050afceff35be9ae3125f7b 1999 ruby-rjb_1.4.8-1.dsc 9589935ace3c8d84ed054eabeeb4737262ec166a 66244 ruby-rjb_1.4.8.orig.tar.gz 22d6277fed1e95ee472b6a6d9060299d6120af8a 5482 ruby-rjb_1.4.8-1.debian.tar.gz 69554e81450154608c5f1ed36f1746e9f1d7110f 53190 ruby-rjb_1.4.8-1_amd64.deb Checksums-Sha256: cb5203394ea1754e30ad98e66f4993cd4626021836816864b45d6318f406b732 1999 ruby-rjb_1.4.8-1.dsc f1cf8fd18f186e37d0060b09a431d4fbf6177c1c8edd61a214b4cf1ab4d1e90e 66244 ruby-rjb_1.4.8.orig.tar.gz ec28e19ce30bc1cc27278f2ce16c7e7df2a0fee87513fea1dd89555a8fd55243 5482 ruby-rjb_1.4.8-1.debian.tar.gz 49dd36c2d3e9d59db991b6d62486a16312ba42bb022629c0a89281b5863e2b26 53190 ruby-rjb_1.4.8-1_amd64.deb Files: 35aa21a6c4429a7209838041c30ed16e 1999 ruby optional ruby-rjb_1.4.8-1.dsc 42a618bb467dd33a869638d5adada8a9 66244 ruby optional ruby-rjb_1.4.8.orig.tar.gz da1f21dd2c772c32c13f60d9fda73768 5482 ruby optional ruby-rjb_1.4.8-1.debian.tar.gz ef407a620ac8e72f4e61fd5791fb7d2f 53190 ruby optional ruby-rjb_1.4.8-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSCqXUAAoJEEgU3sIrMHw8QJsQAMqpT/kFc/F38fNDVzF7dpAM cDB8ADQU2okVMTxSS2Lsj5gaV6iEOXTcQAv4rYQexEv/RQcBtrqWRxi6hV8mP8/c ghLkSh88WONEhNjnyqPQKdkEZVWjOU1e7xmKMVCpBY+TEYrqRyG4vF6x+jiZHbWJ rEmIZdxN81l12pQTfQKB9Nx1Xlp+N5dHy5+Zt0xCMvlOnA5su+egw+Nd3Eqs93eg pweHphbBh3+Fk2xpIu2IQZAjqSrrEC/Zej7u20eVhRu01g60bCXJ4It5SG8KYF3p 2cwz3LLSDKfGX0Ibx0Aa2m02ALGfU4nBStpr1HKOolg8wqFB4JLqH7R4gjoC3CtN QKn05OwQVYggJO6b6Ojhuvv85eLJcNdFKDbIt+GN2aE8RBbLlQT2eA1KXRDr83gF ze7VetjASwrzUGKW+zXo49bq2d7xgUKzz3B7+fjXrXseJ5fBRa+vEDQiVMkCiJnJ gQNMIR1+onglFlqXNwep0fdvDmWyPw55je0su9siH2eVk5pPHXFd8+BjDBhL7s94 1UuZoJdtRk/2DxD2tl5UU9cQwvFJRZjyjtKe4wNyuDCu1EdHB5OtB4Sa2+czkGDD Nopq71eI+9Dqgzc9loEEMtp5lrjBLHZoSFNlWMXTI6izXD0webCE+UhIwigONAxH qhIuADd5OZ7st2f2yDYx =R/Mz -END PGP SIGNATURE End Message --- --- Begin Message --- Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, tails-dev@boum.org * Package name: rjb Version : 1.4.5 Upstream Author : arton Tajima * URL or Web page : http://rjb.rubyforge.org/ * License : LGPL Description : RJB is a Ruby Java Bridge We at Tails [1] have been porting the Sikuli gem to use RJB instead of JRuby, as the latter is becoming totally unmaintainable for us. Teaser: help us streamline the Tails dev / test / release process, so that we spend less time preparing releases (every 6 weeks!), and have more time to develop useful features :) [1] https://tails.boum.org/ Cheers, -- intrigeri --- End Message --- --- End Message --- -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.20 release schedule
anonym wrote (29 Aug 2013 11:41:54 GMT) : >> Could you please update tickets that were fixed by the release (start >> with "Fixed commiting" ones, we have a custom query ready to list >> them)? > Done. Thanks :) >> If the release doc wasn't updated after the Redmine migration, >> please ping me (or do it :). > Done, see commit dced30f. Great. Improved and (hopefully) completed with 9783fac and fb05159. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
