[Tails-dev] Fwd: Bug#719301 closed by Jérémy Bobbio lu...@debian.org (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. ---BeginMessage--- 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 lu...@debian.org. 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 lu...@debian.org 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 ---BeginMessage--- 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 lu...@debian.org (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 pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: J�r�my Bobbio lu...@debian.org 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 SIGNATUREEnd Message--- ---BeginMessage--- 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
[Tails-dev] Fwd: Bug#719297 closed by Jérémy Bobbio lu...@debian.org (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. ---BeginMessage--- 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 lu...@debian.org. 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 lu...@debian.org 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 ---BeginMessage--- 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 lu...@debian.org (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 pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: J�r�my Bobbio lu...@debian.org 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 SIGNATUREEnd Message--- ---BeginMessage--- 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 @
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
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] 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
[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] 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
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] 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] 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 options sync`. 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] 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] 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 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] 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
[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 andres.go...@cern.ch 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 @@ object class=GtkImage id=warning_image property name=visibleTrue/property property name=can_focusFalse/property -property name=stockgtk-info/property +property name=stockgtk-warning/property property name=icon-size1/property /object packing -- 1.7.9.5 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
