Re: New package tracker - old one going?
Hi, On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote: > Another option is to base your team thing on UDD. > > https://udd.debian.org/ While I have no idea about the specific purpose but I'd recommend to use UDD as source of information. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916074056.ge4...@an3as.eu
Re: New package tracker - old one going?
Hi, On Mon, 15 Sep 2014, Iain R. Learmonth wrote: > I notice that packages.qa.debian.org is advertising the new package tracker. > Does this mean the old package tracker there is going to disappear? At some point, yes. > I was going to build something for tracking team packages using the RDF > generated by the tracker at packages.qa.debian.org but if it's going to > disappear I'll have to find another way. The new tracker.d.o has a concept of teams[1] grouping multiple packages already. Right now it's only useful to subscribe to all packages of the team at once but I would like to see this extended to feature a full blown tracker like PET. What kind of features were you planning into your own tracker? [1] https://tracker.debian.org/teams/ Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916075847.ge25...@x230-buxy.home.ouaza.com
Aborting installation on unsupported systems
On Mon, Sep 15, 2014 at 09:28:45PM +0100, Barak A. Pearlmutter wrote: > The package "ikarus", another programming language implementation, > also requires SSE2 support. > There is a check in the preinst script which aborts installation if > sse2 is unavailable. One of my packages works only on certain CPUs and by design it fails to start on others. The package starts its initscript on install, so the installation fails on unsupported hardware. I have a grave bug #738927 asking me to fix this behavior and I was told by someone on IRC to leave it as is. Now I see there are other people doing this so I think I should ask here for more opinions. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916082549.ga23...@belkar.wrar.name
Re: Trimming priority:standard
On Sep 16, James McCoy wrote: > The very informed/knowledgeable user isn't the one that soured my > perception of the choice to have vim-tiny provide /usr/bin/vim. It's Still, as I explained it is very useful since the footprint of the full vim is an order of magnitude bigger. It is not clear to me what you are trying to solve by killing vim-tiny. -- ciao, Marco signature.asc Description: Digital signature
teams in Re: New package tracker - old one going?
Hi, On Dienstag, 16. September 2014, Paul Wise wrote: > https://tracker.debian.org/teams/ how is that fed with data? I notice most teams from wiki.d.o/Teams/ are missing :/ cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: teams in Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote: > how is that fed with data? https://tracker.debian.org/teams/+create/ > I notice most teams from wiki.d.o/Teams/ are missing :/ Up to each team if they want to use the tracker, few have chosen to do so. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6e-jmhcpq7wpgwpnq_ucmtqquojsveada8ryrht3+9...@mail.gmail.com
Re: Aborting installation on unsupported systems
Hi, Andrey Rahmatullin: > On Mon, Sep 15, 2014 at 09:28:45PM +0100, Barak A. Pearlmutter wrote: > > The package "ikarus", another programming language implementation, > > also requires SSE2 support. > > There is a check in the preinst script which aborts installation if > > sse2 is unavailable. > One of my packages works only on certain CPUs and by design it fails to > start on others. The package starts its initscript on install, so the > installation fails on unsupported hardware. I have a grave bug #738927 > asking me to fix this behavior and I was told by someone on IRC to leave > it as is. Now I see there are other people doing this so I think I should > ask here for more opinions. > IMHO it's perfectly reasonable to be able to install a package which cannot immediately run. Another example would be a program which needs a lot of RAM or disk space to work. Or a reachable database server. But when I prepare a VM image for that program, I may not yet have the RAM available, or I pre-generate a backup system image, or … You might want to pop up a preinst debconf notice which tells the admin that the package will not run here (with an option to fail the install if it's an honest mistake). -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916100224.gc2...@smurf.noris.de
Re: teams in Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 05:54:15PM +0800, Paul Wise wrote: > On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote: > > how is that fed with data? > https://tracker.debian.org/teams/+create/ > > > I notice most teams from wiki.d.o/Teams/ are missing :/ > Up to each team if they want to use the tracker, few have chosen to do so. Yeah well, I suspect most teams simply don't know about this feature. AFAICT tracker.d.o as a whole (let aside the team feature) has not even been announced to d-d-a yet. Maybe it's time to do that, highlighting specific opt-in features such as team claiming? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re:Chinese factory of wire strip cut crimp machine debian-devel
Hi Manager, Good day my friend. How is your wire harness machine business going? Cheers Electronic Technical Co., LTD here, exporting wire harness machines with good quality and competitive price in China. Main products: Terminal Crimping Machine,Wire Stripping and Cutting Machine,Tube & Pipe Cutting machine and relative wire and cable processing machines. Call me, let's talk details. Best Regards Betty * Cheers Electronic Technical Co., LTD Add: NO.145, 1051, Shenbin Road, Minhang District, Shanghai City, China, 200200. Tel: 86-15960260425 Fax: 86-21-60734575
Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote: > It will go away eventually once the new tracker has equivalent functionality. I know it's nothing to be abandoning the new tracker over, but the new one hurts my eyes. The old one is quite pretty. > If you could help port the RDF work to the new tracker that would help > the transition move faster and also give you a reliable source of data > for both Debian and derivatives who also use the same software. If it still needs to be done the next time I find myself short of things to do, I will take a look. > Another option is to base your team thing on UDD. > https://udd.debian.org/ Did not know about this, this looks to be a useful source of information. > BTW we already have several team things, could you just use those? I didn't know about these but I've had a look at them and they're not really what I'm looking for. I was thinking something similar to the blends web sentinels, but with a focus on being useful for end users too. Grouping the packages into categories for the functions they provide similar to the blends "tasks" so you can get an easy overview of all the packages in an area, and then contibutors can also see where areas are needing work. Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: +447875886930 c: MM6MVQ g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpnF0V8_KL19.pgp Description: PGP signature
Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote: > I didn't know about these but I've had a look at them and they're not really > what I'm looking for. I was thinking something similar to the blends web > sentinels, but with a focus on being useful for end users too. Grouping the > packages into categories for the functions they provide similar to the > blends "tasks" so you can get an easy overview of all the packages in an > area, and then contibutors can also see where areas are needing work. Saying this, if the ham radio team is willing to look into becoming a blend, then we would gain this anyway, and any missing features I was thinking of could be added to the blends web sentinel. Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: +447875886930 c: MM6MVQ g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpdeQhZX4Znf.pgp Description: PGP signature
Re: New package tracker - old one going?
On 16/09/14 11:46, Iain R. Learmonth wrote: > Saying this, if the ham radio team is willing to look into becoming a blend, > then we would gain this anyway, and any missing features I was thinking of > could be added to the blends web sentinel. At the moment the team doesn't even seem to have time to maintain the groups packages. Until I started work on them a couple of months ago most of them hadn't been touched for several years since Joop retired. I'm not sure how many of the team are actually active any more. Colin -- Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x38C9D903 signature.asc Description: OpenPGP digital signature
Re: New package tracker - old one going?
Hi, On Tue, 16 Sep 2014, Iain R. Learmonth wrote: > On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote: > > It will go away eventually once the new tracker has equivalent > > functionality. > > I know it's nothing to be abandoning the new tracker over, but the new one > hurts my eyes. The old one is quite pretty. That's not a very actionable feedback. The main differences are: - white background instead of gray one - more whitespace between panels - smaller font-size (this has already been reported in #756721 What parts are actually problematic in your opinion ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916114436.ge23...@x230-buxy.home.ouaza.com
Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 01:44:36PM +0200, Raphael Hertzog wrote: > On Tue, 16 Sep 2014, Iain R. Learmonth wrote: > > I know it's nothing to be abandoning the new tracker over, but the new one > > hurts my eyes. The old one is quite pretty. > > That's not a very actionable feedback. The main differences are: > What parts are actually problematic in your opinion ? It's just a bit too bright. Maybe it is the change in background colour that's done this, coupled with the red. It's possible this is just my laptop screen. I think before the grey background helped to seperate out the boxes and make it easier to read too. Also, the spacing seems to be off, buttons misaligned, all the things that generally go wrong when you hack something together with bootstrap without a degree in web design. These are things that bug me but don't affect my ability to use it and probably do not need to be fixed unless someone really wants to. Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: +447875886930 c: MM6MVQ g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpnwyB08eojp.pgp Description: PGP signature
Bug#761868: ITP: moonshot-gss-eap -- A GSS-API Mechanism for the Extensible Authentication Protocol
package: wnpp severity: wishlist owner: hartm...@debian.org x-debbugs-cc: debian-devel@lists.debian.org source: git://git.project-moonshot.org/mech_eap.git license: BSD-3-Clause Description: Project moonshot provides federated access to a wide range of applications. This package adds a GSS-API mechanism supporting EAP authentication and provides the core of Moonshot authentication and authorization. This package provides federated access for applications such as Ssh, NFS, LDAP and IMAP. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslioknlpax@mit.edu
Re: New package tracker - old one going?
On September 16, 2014 7:44:36 AM EDT, Raphael Hertzog wrote: >Hi, > >On Tue, 16 Sep 2014, Iain R. Learmonth wrote: >> On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote: >> > It will go away eventually once the new tracker has equivalent >functionality. >> >> I know it's nothing to be abandoning the new tracker over, but the >new one >> hurts my eyes. The old one is quite pretty. > >That's not a very actionable feedback. The main differences are: >- white background instead of gray one >- more whitespace between panels >- smaller font-size (this has already been reported in #756721 > >What parts are actually problematic in your opinion ? In mine, the top center panel being taken up by information about the new tracker makes it quite difficult to really get a feel for how readable/usable the new site is. Is there some way to make that removable? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0135d94d-20ae-4a3e-8a9b-fe03b82fb...@email.android.com
Re: teams in Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 12:09:22PM +0200, Stefano Zacchiroli wrote: > > https://tracker.debian.org/teams/+create/ > > > > > I notice most teams from wiki.d.o/Teams/ are missing :/ > > Up to each team if they want to use the tracker, few have chosen to do so. > > Yeah well, I suspect most teams simply don't know about this feature. +1 I just created the Debian Med team. What I did not is to add members to the tracker. IMHO it should be somehow doable to drain team members from alioth rather than adding people to the a team twice (on alioth and in tracker). > AFAICT tracker.d.o as a whole (let aside the team feature) has not even > been announced to d-d-a yet. Maybe it's time to do that, highlighting > specific opt-in features such as team claiming? +1 Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916134540.gr4...@an3as.eu
Re: New package tracker - old one going?
Hi Iain, On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote: > > If it still needs to be done the next time I find myself short of things to > do, I will take a look. Ahh, if you are again in this situation please tell me - I might have some other thrilling tasks. ;-)) > > Another option is to base your team thing on UDD. > > https://udd.debian.org/ > > Did not know about this, this looks to be a useful source of information. Uhmm, perhaps I did not mentioned it prominently enough in our Debian Med sprint but all the Blends you might know from Debian Med and Debian Games stuff is directly rendered from UDD. Very nifty assemblage of very valuable data. If you are missing data there you can write a new importer (been there, done that). > > BTW we already have several team things, could you just use those? > > I didn't know about these but I've had a look at them and they're not really > what I'm looking for. I was thinking something similar to the blends web > sentinels, but with a focus on being useful for end users too. Grouping the > packages into categories for the functions they provide similar to the > blends "tasks" so you can get an easy overview of all the packages in an > area, and then contibutors can also see where areas are needing work. So why not simply creating a Blend in the area you are considering? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916135046.gs4...@an3as.eu
Re: New package tracker - old one going?
Hi Iain, On Tue, Sep 16, 2014 at 11:46:53AM +0100, Iain R. Learmonth wrote: > On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote: > > I didn't know about these but I've had a look at them and they're not really > > what I'm looking for. I was thinking something similar to the blends web > > sentinels, but with a focus on being useful for end users too. Grouping the > > packages into categories for the functions they provide similar to the > > blends "tasks" so you can get an easy overview of all the packages in an > > area, and then contibutors can also see where areas are needing work. > > Saying this, if the ham radio team is willing to look into becoming a blend, > then we would gain this anyway, and any missing features I was thinking of > could be added to the blends web sentinel. Considering Colin's answer you might be in the same situation as I was two years ago facing that Debian Games would deserve the Blends stuff but has not. I created the needed framework when sitting inside the Debian Games BoF at DebConf 11 in Banja Luka. It remained untouched for 2.5 years. Now Markus adopted it to something very useful. So just start doing something you might consider useful and if it really is people will start using and enhancing it. I'm really keen on seeing what exactly you want to add to the Blends web sentinel to get this available for all Blends! Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916135520.gt4...@an3as.eu
Re: New package tracker - old one going?
On Tue, Sep 16, 2014 at 03:50:46PM +0200, Andreas Tille wrote: > So why not simply creating a Blend in the area you are considering? This is now something being considered. Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: +447875886930 c: MM6MVQ g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpk4_ZQexT8A.pgp Description: PGP signature
Re: New package tracker - old one going?
Hello, On 16 September 2014 13:44, Raphael Hertzog wrote: > - white background instead of gray one > - more whitespace between panels > - smaller font-size (this has already been reported in #756721 I personally dislike all of the three. Grey background adds some contrast, little whitespace makes panels more compact so I don't need to scroll the page while having bigger font size means I don't have troubles reading the text. So, basically, I'd like the new tracker to have the same stylesheet as the old one. At least, make it an option (cookie-enabled, maybe?) -- Cheers, Andrew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACujMDM-2A2HnkQcM8FSXrwPb-=sntemtgocv6z4jwev-xs...@mail.gmail.com
Re: New package tracker - old one going?
On Tue, 16 Sep 2014, Scott Kitterman wrote: > In mine, the top center panel being taken up by information about the > new tracker makes it quite difficult to really get a feel for how > readable/usable the new site is. Is there some way to make that > removable? That panel is not displayed if you don't come from the old PTS. In other words, start using the new tracker as reference and you won't see that. Just try it: http://tracker.debian.org/pkg/dpkg Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916151212.gd12...@x230-buxy.home.ouaza.com
Re: Aborting installation on unsupported systems
On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote: > You might want to pop up a preinst debconf notice which tells the admin > that the package will not run here (with an option to fail the install > if it's an honest mistake). This may require reimplementing some part of the program in shell (in my case it's parsing of /proc/cpuinfo, so it's at least possible, but still). -- WBR, wRAR signature.asc Description: Digital signature
Re: Trimming priority:standard
On Sunday, 14 de September de 2014 17:04:10 Stefano Zacchiroli escribió: > On Sat, Sep 13, 2014 at 11:17:34AM -0700, Josh Triplett wrote: > > I'm not arguing that "standard" should have nothing in it; it should > > have things that the vast majority of users will 1) expect to find > > present without having to install them and 2) actually use or care > > about. > > I sympathize with the sentiment, but AFAICT the only way to implement > such a specification would be to actually *ask* our users, and (by > definition) a thread on -devel cannot work to that end. It seems to me > that the only way to implement that spec would be something like a > broadly advertised user survey, with specific questions about the > packages you are interested in. > > Cheers. Here it can come back my idea about a desktop survey/poll app. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Thursday, 11 de September de 2014 08:00:57 Marc Haber escribió: > On Thu, 11 Sep 2014 00:04:07 -0300, Martinx - ? > > wrote: > > Also, during Debian 8 installation, please, provide an "altinit" option ( > > > >http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can > >choose between systemd / sysvinit (before 1st boot). I know that it seems > >easy to just "apt-get install sysvinit-core" after install (1st boot) but, > >at least, Debian users will have an option to select a well tested, init > >system, while it is fully supported. > > Please note that our init scripts are going to be a lot less reliable > in a world where only a fraction of our users will actually use them. > > Many maintainers will reduce their priority on the to-do list. > > Greetings > Marc Thay _you_ will reduce their priority in your to-do list does not mean that many will do. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wednesday, 10 de September de 2014 21:26:50 Matthias Urlichs escribió: > Hi, > > Steve Langasek: > > On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote: > > > What about cases when init scripts doesn't come from any package but > > > are crafted by hand? > > > > It's straightforward to check for init scripts that are not owned by any > > packages. > > … and besides, systemd should just work with them. > If they descend from /etc/init.d/skeleton, that is. > > Not having the requisite metadata at the top of the script might me a more > reliable indicator than not belonging to a package. I would bet that most hand made init scripts do not descend from /e/i/skeleton, and they have runlevels and such crafted also by hand on the specific system where they are deployed. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Aborting installation on unsupported systems
On Tue, 16 Sep 2014, Andrey Rahmatullin wrote: > On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote: > > You might want to pop up a preinst debconf notice which tells the admin > > that the package will not run here (with an option to fail the install > > if it's an honest mistake). > This may require reimplementing some part of the program in shell (in my > case it's parsing of /proc/cpuinfo, so it's at least possible, but still). Well, depends on how strict you want that parsing to be: grep -q '^flags.*\' /proc/cpuinfo && echo "SSE2 possible" This is good enough on i686 and x86-64, as the architecture itself does not tolerate any difference in the flags set between processors. Maybe enhance it a little so that it won't trigger on "^flags_new" or somesuch. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916193700.ga9...@khazad-dum.debian.net
Re: Trimming priority:standard
On 13698 March 1977, Didier Raboud wrote: >> > One thought... there will probably be trademark concerns with >> > "unix".[1] So we might have to choose a name for the tasksel task >> > to be someting like "unix-like". >> Or we could just call it "standard system". > Could we make sure the full "vim" is in that then? I miss it on every > new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too, cos I miss that way more than any vi* ever. With vi actually being the first thing to get removed, so that would be better way out of standard *IMO* (*lala*) -- bye, Joerg I wish mrvn stopped supporting 3.0 (quilt), it's a recipe for failure -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioknxo1s@gkar.ganneff.de
Re: Allow encfs into jessie?
On Fri, Sep 12, 2014 at 11:58:04AM -0500, John Goerzen wrote: > On 09/12/2014 06:46 AM, Jan Niehusmann wrote: > > A common use case for disk encryption is to protect a lost or stolen > > laptop. And the adversary is not some powerful agency, but a curious > > person browsing through the hard disk before formatting it. > > > > I see no reason to assume that encfs is not good enough for that use > > case, at the moment. > > There is, of course, also the problem of: what will people replace it > with? I would suggest that some level of protection is better than > none, and that the most likely outcome of removing encfs is no > protection at all for a majority of users. > > Probably the most common suggestion, and only real option I am aware of, > is ecryptfs. (LUKS and dm_crypt solve different problems.) Compared to I did most of the work in forking and rewriting Cryptfs as eCryptfs. I designed its encryption and key management, and I also wrote most of the initial release of the userspace toolchain. > encfs, ecryptfs is extremely difficult to use. For instance, by > default, unlike encfs, you cannot change the password of ecryptfs data > because the passphrase is directly transformed into the encryption key. Each file gets its own randomly generated data encryption key known as a FEK. This key is wrapped with the wrapping key (FEKEK) retrieved from the user's session keyring. The signature for the FEKEK to use for newly created files is the ecryptfs_sig= mount option. By having the old FEKEK and the new FEKEK in the user session keyring and by mounting with the new FEKEK as ecryptfs_sig=, you will role both the FEK and FEKEK when you make a copy of any file. This isn't documented and there's no toolchain available to automate this at the moment. > After poring over poorly-documented things, I found a suggestion of how > to work around this: Agreed. Much documentation is definitely lacking. > 1) Generate an encryption key with > > od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \ > sed "s/^000//" | sed "s/\s*//g" > > 2) Pipe (I think!) the output from the above into > ecryptfs-wrap-passphrase to encrypt it > > 3) Before mounting, run ecryptfs-insert-wrapped-passphrase-into-keyring > pointing to the file saved in step 2 > > 4) Save your precise mount options; in my case, > ecryptfs_unlink_sigs,ecryptfs_fnek_sig=longstringhere,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_sig=anotherlongstring > > 5) Use those precise mount options later > > (These steps are rough; they may need a little tweaking but are close to > the mark.) > > This is not friendly. At all. Agreed. Ubuntu distilled the complexity into a single checkbox in the installer, which gives a much more reasonable story for the typical desktop user. However there's still far too much technical detail exposed to the user, which has resulted in many users shooting themselves in the foot -- e.g., by naively deleting their ~/.ecryptfs directories in a misguided attempt to free up disk space. I'm taking the lessons learned from years of experience with eCryptfs out in the wild and seeing if I can do a better job in a file system native solution. > Additionally, although the ecryptfs audit at > https://defuse.ca/audits/ecryptfs.htm produces fewer red flags than the > encfs audit did, still its conclusion says "there are some red flags > indicating it was not designed by a cryptographer." The design was reviewed by industry-recognized cryptographers at IBM Research. > I also found mysterious bugs attempting to share the decrypted view of > an ecryptfs volume using NFS. The ideal of stacking in Linux was a nice fantasy, but it hasn't been realized in practice. NFS is one of several examples where it just hasn't worked out. That's one of the reasons why I'm currently working on a file system native solution. > Finally, encfs has an interesting reverse crypto mode where it > presents an encrypted FUSE view over a plaintext mountpoint. With eCryptfs, you would accomplish this by unmounting and then reading the encrypted files directly from the lower file system. > I can't find anything in the ecryptfs manpages about whether they're > using SHA or MD5, but this RedHat bug from 2009 suggests it's using MD5. > https://bugzilla.redhat.com/show_bug.cgi?id=490918 I do not know > immediately why this was a red flag in encfs but not ecryptfs. MD5 has known weaknesses for specific applications. Those weaknesses have not been shown to apply to eCryptfs' use of MD5 in such a way so as to substantially reduce its security. That said, crypto attacks only get better, and so it's well advised to use a hash that isn't known to have significant weaknesses. I'm not motivated to update eCryptfs since I honestly would like to see it deprecated. > I should also note that even if the authenticity features of encfs are > less than perfect, it doesn't mean the package is useless. A person > may, for instance, car
Re: Trimming priority:standard
On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: > On 13698 March 1977, Didier Raboud wrote: > >> > One thought... there will probably be trademark concerns with > >> > "unix".[1] So we might have to choose a name for the tasksel task > >> > to be someting like "unix-like". > >> > >> Or we could just call it "standard system". > > > > Could we make sure the full "vim" is in that then? I miss it on every > > new installation and I'm quite sure that's not uncommon. > > ONLY if we put emacs there too, cos I miss that way more than any vi* > ever. With vi actually being the first thing to get removed, so that > would be better way out of standard *IMO* > > (*lala*) Trying to start another flamewar? Let's stop this here. There are vi lovers and emacs lovers, and having the freedom to choose is great. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Can a leaf package require SSE2 on i386?
On Tue, Sep 16, 2014 at 7:05 AM, Samuel Thibault wrote: > Thomas Goirand, le Mon 15 Sep 2014 20:45:27 +0800, a écrit : >> On 09/15/2014 05:17 PM, Samuel Thibault wrote: >> > Thomas Goirand, le Mon 15 Sep 2014 16:53:25 +0800, a écrit : >> >> I suppose (according to what's above) that using >> >> /usr/lib/sse4.2/x86_64-linux-gnu isn't supported (yet), right? >> > >> > I guess it shouldn't be hard to add the support, once the need is >> > expressed :) >> > >> > Samuel >> >> Really? Ok... then *I NEED IT* ! :) > > As a bug report against libc6, I meant. > > Samuel > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > https://lists.debian.org/20140915230525.ga2...@type.youpi.perso.aquilenet.fr > I meet the similar problem: a package (shine) set itself as mips32r2. I found it when I try dig out why it ftbfs on mips64el. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cakcpw6xcheuauh44+przyhbfkau0xz10eg6zro9j1nkh98l...@mail.gmail.com
Re: Aborting installation on unsupported systems
On Tue, Sep 16, 2014 at 04:37:00PM -0300, Henrique de Moraes Holschuh wrote: > > > You might want to pop up a preinst debconf notice which tells the admin > > > that the package will not run here (with an option to fail the install > > > if it's an honest mistake). > > This may require reimplementing some part of the program in shell (in my > > case it's parsing of /proc/cpuinfo, so it's at least possible, but still). > > Well, depends on how strict you want that parsing to be: http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git/tree/mcelog.c#n479 -- WBR, wRAR signature.asc Description: Digital signature
Re: Allow encfs into jessie?
Hi, Michael Halcrow: > > Finally, encfs has an interesting reverse crypto mode where it > > presents an encrypted FUSE view over a plaintext mountpoint. > > With eCryptfs, you would accomplish this by unmounting and then > reading the encrypted files directly from the lower file system. > This is not a replacement for encfs' Reverse Mode. Rev mode means that there _is_ no encrypted "lower file system". Reverse Mode means that you translate an unencrypted directory tree to an encrypted one, instead of vice versa. This is very useful for creating backups of critical data (which I cannot store on an encrypted FS, as that would be much too slow) to 'unsafe' remote media. > The incidentally lost or misplaced laptop is just about the only > adversarial model that the currently available data-at-rest encryption > options available for Linux can effectively address. > … or USB stick. > Do not expect any currently available encryption solutions to help you > much if you are individually targeted. > You need non-encrypted data to actually work with them. Thus an encrypted file system cannot and will not help make anything more secure if the FS in question is mounted anyway. That's pretty much a truism. In any case, yes encfs is not 100% safe, but frankly it's still much better than not encrypting data at all (esp. if the data to be stored is not controlled by an adversary) – and there currently is no better solution for a couple of important use cases. Thus, please bring it back. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917051019.gd2...@smurf.noris.de
Re: Trimming priority:standard
Noel Torres writes: > On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: >> On 13698 March 1977, Didier Raboud wrote: >> >> > One thought... there will probably be trademark concerns with >> >> > "unix".[1] So we might have to choose a name for the tasksel task >> >> > to be someting like "unix-like". >> >> >> >> Or we could just call it "standard system". >> > >> > Could we make sure the full "vim" is in that then? I miss it on every >> > new installation and I'm quite sure that's not uncommon. >> >> ONLY if we put emacs there too, cos I miss that way more than any vi* >> ever. With vi actually being the first thing to get removed, so that >> would be better way out of standard *IMO* >> >> (*lala*) > > Trying to start another flamewar? Let's stop this here. There are vi lovers > and > emacs lovers, and having the freedom to choose is great. That's why *both* should be installed by default. Then everybody will be happy. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/851traivhk@tsukuyomi.43-1.org
