Re: [Tails-dev] Release versioning

2015-05-30 Thread Daniel Kahn Gillmor
On Sat 2015-05-30 04:22:00 -0400, intrigeri wrote: Daniel Kahn Gillmor wrote (29 May 2015 15:51:09 GMT) : i'd also be fine with only reserving (targeting for non-immediate changes) a.b, and treating any a.b.c release as an intermediary release. This would remove the ability to distinguish

[Tails-dev] Build failed in Jenkins: build_Tails_ISO_feature-jessie #510

2015-05-30 Thread tails-sysadmins
See https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie/510/ -- [...truncated 12305 lines...] ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR:

Re: [Tails-dev] Unique Hardware Information

2015-05-30 Thread intrigeri
Hi, [please don't Cc me, I read the list.] temp238...@ruggedinbox.com wrote (29 May 2015 17:34:44 GMT) : If someone can get an shell on Tails, they can get a lot of hardware information without root. Dmesg is stopped, but any user can run 'cat /proc/cpuinfo' 'lsusb' and 'lspci', which

Re: [Tails-dev] Release versioning

2015-05-30 Thread intrigeri
Daniel Kahn Gillmor wrote (29 May 2015 15:51:09 GMT) : On Fri 2015-05-29 11:19:17 -0400, intrigeri wrote: it popped up to my mind that our current versioning scheme is a bit painful whenever we need to insert an unexpected release: e.g. when we've put out 1.3.1, it stole a version number that