Re: Finding missing epochs

[Evgeni Golov]

On 07/06/2012 07:10 PM, Tollef Fog Heen wrote:
> ]] Jakub Wilk 
> 
>> I wrote a tool to detect versioned (build-)dependencies with possible
>> missing (or insufficient) epochs. The results for unstable and a
>> DD-list are attached.
> 
> Thanks, this looks like a useful tool.
> 
> results for chef and varnish, while not wrong, are harmless, since
> there's no version too old in the archive to satisfy the requirement,
> even without a version.

I have a couple of these too and wonder what's the best "fix" is?
Bump to the correct epoch'ed version or drop it completely?
As there is no too old version in the archive (>= stable), there would
be no harm droping the version, right?

Regards
Evgeni


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff93d05.6040...@debian.org

scim: problems with libclutter-imcontext*

[Toni Mueller]

Hi,

while working on scim, we found that there's a problem that appears to stem from
libclutter-imcontetext-0.1-dev apparently not being multi-arch'ed. I quote from
an email by Tz-Huan:


-- cut
The scim try to figure out the module directory of clutter-imcontext
in these ways:

* search clutter-libdir via `$PKG_CONFIG --variable=libdir
clutter-imcontext-0.1`,
   if it successes, set the module directory to
$clutter-libdir/clutter-imcontext/immodules
* otherwise, set the module directory to $libdir/clutter-imcontext/immodules
  (libdir is passed when running configure script, so it should be
/usr/lib/${MULTI_ARCH_PATH}
   in debian).

In testing, libclutter-imcontext-0.1-dev doesn't multi-archified itself
(http://packages.debian.org/testing/i386/libclutter-imcontext-0.1-dev/filelist),
so scim get "/usr/lib" from the first step (pkg-config way) and set
the module directory to
/usr/lib/clutter-imcontext/immodules.

However, libclutter-imcontext-0.1-dev does multi-archified in sid
(http://packages.debian.org/sid/i386/libclutter-imcontext-0.1-dev/filelist)
so scim get "/usr/lib/${MULTI_ARCH_PATH}" from pkg-config and set the module
directory to /usr/lib/${MULTI_ARCH_PATH}/clutter-imcontext/immodules.
-- cut

What would be the preferred way to solve this problem, please?

TIA!


Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708122849.ga17...@spruce.wiehl.oeko.net

Re: EFI in Debian

[Wookey]

+++ Steve Langasek [2012-07-07 15:58 -0600]:
> On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote:
 > > * Steve Langasek (vor...@debian.org) [120707 22:54]:
> > > On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
> > > > If OTOH we have to pay a fee just for our software to work on platforms
> > > > that just happen to be using Microsoft’s certificate, this is clearly
> > > > abusive.  I would object to do so, and I believe we would (at least in
> > > > Europe) have a very strong case in court against such practice.
> 
> > > Note that the Windows 8 requirements stipulate that users must in all 
> > > cases
> > > retain the ability to disable Secure Boot on their x86 systems from the
> > > firmware.  It's really a question of ease of installation, and whether
> > > Secure Boot provides any additional security protection that we think it's
> > > worth providing to Debian users out of the box.
> 
> > IIRC it's not the same on embedded hardware.
> 
> The distinction is between x86 and ARM, and the Windows 8 cert requirements
> for ARM appear to have as their goal to prevent any other OS to be bootable
> on that hardware.

Which is pretty outrageous IMHO and may well become a serious problem
once PC-like ARM hardware becomes widely available (laptops and
capable tablets). It is very disappointing that once they agreed to
free-up x86 everyone said, 'oh that's alright then', failing to
appreciate that ARM hardware will (likely) be just as ubiquitous as
x86 quite soon. Hopefully enough people will produce hardware that
isn't crippled in this way, but if Windows 8 is a popular platform one
may get a greatly restricited choice. 

Will Android machines make secure boot turn-offable or another key
installable, or will thay follow the Microsoft lead and lock
everything down too?

A competition case is much harder to bring here because Windows has
almost zero share on ARM and can use that as an excuse. Of course, as
we know in Debian architecture is really irrelevant to the question of
'is this OS dominant and using its dominance in one area to restrict
competition in another'? This makes the ARM/x86 distinction in the
rules a devious scheme to reduce competition, which seems to be
working so far (and in our case prevent us using such computers
usefully at all). 

In an ideal world the fact that can't unlock your device and install
another OS will be seen as a consumer disadvantage and reduce the
supply of hardware with no ability to install alternate keys, but that
seems an unlikely outcome, as most people don't care, or won't until
it's too late. 

I'm not sure what we can actually do about this technically.
Approximately nothing, except look for ways to hack the secure boot
mechanism on interesting hardware. 

I can't recall if the rules for arm actually prevent the bootloader
allowing the loading of other keys, or just prevent turning off secure
boot. I think the latter, but as there is no requirement for this
feature it may be rare in practice. By making this easily available in
UEFI I suppose that may encourage manufacturers to enable it.

> So I don't think you should expect MS to sign any UEFI
> ARM bootloader binaries at all.

Quite.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708131523.gy13...@stoneboat.aleph1.co.uk

Re: scim: problems with libclutter-imcontext*

[Aron Xu]

On Sun, Jul 8, 2012 at 8:28 PM, Toni Mueller  wrote:
>
> Hi,
>
> while working on scim, we found that there's a problem that appears to stem 
> from
> libclutter-imcontetext-0.1-dev apparently not being multi-arch'ed. I quote 
> from
> an email by Tz-Huan:
>
>
> -- cut
> The scim try to figure out the module directory of clutter-imcontext
> in these ways:
>
> * search clutter-libdir via `$PKG_CONFIG --variable=libdir
> clutter-imcontext-0.1`,
>if it successes, set the module directory to
> $clutter-libdir/clutter-imcontext/immodules
> * otherwise, set the module directory to $libdir/clutter-imcontext/immodules
>   (libdir is passed when running configure script, so it should be
> /usr/lib/${MULTI_ARCH_PATH}
>in debian).
>
> In testing, libclutter-imcontext-0.1-dev doesn't multi-archified itself
> (http://packages.debian.org/testing/i386/libclutter-imcontext-0.1-dev/filelist),
> so scim get "/usr/lib" from the first step (pkg-config way) and set
> the module directory to
> /usr/lib/clutter-imcontext/immodules.
>
> However, libclutter-imcontext-0.1-dev does multi-archified in sid
> (http://packages.debian.org/sid/i386/libclutter-imcontext-0.1-dev/filelist)
> so scim get "/usr/lib/${MULTI_ARCH_PATH}" from pkg-config and set the module
> directory to /usr/lib/${MULTI_ARCH_PATH}/clutter-imcontext/immodules.
> -- cut
>
> What would be the preferred way to solve this problem, please?
>
> TIA!
>
>
> Kind regards,
> --Toni++
>
>

Short answer is: wait.

clutter-imcontext package was uploaded to unstable at Jun 28, so it's
not blocked by freeze. Just wait until it migrate to testing then
everything will be fine. If your package haven't been uploaded now,
then you don't need to bother with this issue because it will need
more time to migrate unless release team guaranteeing they will
unblock _and_ force its migration as soon as you upload, which is
almost impossible to happen.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6bqcyepcscoqnxnfhyd0vmp8a076jpxbbh8dx8w1z...@mail.gmail.com

Re: EFI in Debian

[Russell Coker]

On Sun, 8 Jul 2012, Wookey  wrote:
> > The distinction is between x86 and ARM, and the Windows 8 cert
> > requirements for ARM appear to have as their goal to prevent any other
> > OS to be bootable on that hardware.
> 
> Which is pretty outrageous IMHO and may well become a serious problem
> once PC-like ARM hardware becomes widely available (laptops and
> capable tablets). It is very disappointing that once they agreed to
> free-up x86 everyone said, 'oh that's alright then', failing to
> appreciate that ARM hardware will (likely) be just as ubiquitous as
> x86 quite soon. Hopefully enough people will produce hardware that
> isn't crippled in this way, but if Windows 8 is a popular platform one
> may get a greatly restricited choice. 

I expect that by most metrics Android phones outsell PCs nowadays (largely 
because phone contracts encourage replacement every 2 years and some portion 
of the phones break before then).  A significant portion of the Android phones 
sold are locked down such that you can't change which version of the kernel 
you run and can't get root access in any reasonable manner.

The iPhone has a comparable market volume to Android phones and is uniformly 
locked down.

In terms of making ARM systems less free it doesn't seem to me that the MS 
initiative in this regard is making things much worse than they are at the 
moment.

Also it should be noted that while porting Linux to an ARM device designed for 
Windows (such as a Windows phone) would probably take a lot of work it's 
relatively easy to get your own Linux build on an Android phone if it's not 
locked down.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201207090034.03088.russ...@coker.com.au

Re: duplicates in the archive

[Adam Borowski]

On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote:
> On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > > Which wm does that? I know it isn't gnome-shell at least, as I've been
> > > using it quite successfully without nm installed.
> > Have you tried to use evolution without NM?

Evolution seems to work just fine.

> I didn't try but it only suggests network-manager. However some applications 
> do
> behave weird if you just deinstalled n-m (pidgin for instance), because they
> assume that you're not connected. After a reboot (maybe dbus restart is 
> enough)
> they certainly connect again, though.

I tested a good part of Gnome today without n-m and it appears there are no
regressions at all.  The only differences are:

* it gets rid of n-m icon in the systray (duh)

The dependency comes via gnome-core depending on network-manager-gnome.

> 
> Kind regards
> Philipp Kern



-- 
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708144801.ga24...@angband.pl

Re: duplicates in the archive

[Adam Borowski]

WHOOPS, SORRY.  Meant to delete this old draft, not send it.
The issue is valid, but sorry for incomplete mail.

On Sun, Jul 08, 2012 at 04:48:01PM +0200, Adam Borowski wrote:
> On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote:
> > On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > > > Which wm does that? I know it isn't gnome-shell at least, as I've been
> > > > using it quite successfully without nm installed.
> > > Have you tried to use evolution without NM?
> 
> Evolution seems to work just fine.
> 
> > I didn't try but it only suggests network-manager. However some 
> > applications do
> > behave weird if you just deinstalled n-m (pidgin for instance), because they
> > assume that you're not connected. After a reboot (maybe dbus restart is 
> > enough)
> > they certainly connect again, though.
> 
> I tested a good part of Gnome today without n-m and it appears there are no
> regressions at all.  The only differences are:
> 
> * it gets rid of n-m icon in the systray (duh)
[was incomplete]
  * "network settings" deep in the control panel will say the networking on
this system is not compatible


Since n-m breaks actually working software (udev, ifupdown) for non-obscure
uses (connecting a phone via USB, bridged setups, non-basic VPNs, etc), a
desktop environment hard-depending on it is bad, and this really needs to be
a Recommends: relationship instead.

N-M compared to ifupdown:
* makes things easier for new users (good! especially in a default install)
* is said to make wifi easier (when it works...)
And downsides:
* breaks usb0 completely (keeps raising and lowering the interface in a
  loop, no apparent way to tell it to keep its grubby hands away)
* breaks a load of complex setups

"Breaks unrelated software" on the system is a RC severity, and there's no
way one can say a windowing environment is related to core networking. 
Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
Recommends: is a non-intrusive fix.  It will cause n-m to be installed
unless explicitely refused, just like you want it to be.

On the other hand, breaking such setups is not a RC bug in n-m.  Like any
non-core package, there is no requirement for it to be universal:
* not working with complex setups is at most wishlist
* breaking USB networking by flipping the interface is normal
It's just gnome-meta hard-depending on it what's wrong.

-- 
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


signature.asc
Description: Digital signature

Re: EFI in Debian

[Ben Hutchings]

On Sun, 2012-07-08 at 14:15 +0100, Wookey wrote:
[...]
> A competition case is much harder to bring here because Windows has
> almost zero share on ARM and can use that as an excuse. Of course, as
> we know in Debian architecture is really irrelevant to the question of
> 'is this OS dominant and using its dominance in one area to restrict
> competition in another'?
[...]

It's not irrelevant.  OS dominance is dependent on relationships with
hardware manufacturers (not the same for different architectures) and
application developers (often uninterested in porting, however easy it
is).

Did Windows NT take over PowerPC?  No.  Alpha?  Not even after FX!32
provided fast x86 emulation.

And the application developers used to Win32 (or Windows Forms) won't be
able to port to Windows RT without first rewriting for the 'Windows
Runtime' APIs.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


signature.asc
Description: This is a digitally signed message part

Re: CD sizes again (and BoF reminder!)

[Adam Borowski]

On Sat, Jul 07, 2012 at 04:22:58PM -0600, Stefano Zacchiroli wrote:
> On Sun, Jul 08, 2012 at 12:03:44AM +0200, Cyril Brulebois wrote:
> > Ansgar Burchardt  (07/07/2012):
> > > Another question is if the release team would consider unblocking
> > > updated packages (with just the switch to xz for binaries).  I think
> > > it would be nice to be able to get a useful desktop system using just
> > > the first CD, but I'm not sure if they would make an exception for
> > > this.
> > 
> > You may want to actually ask the release team at some point, if you want
> > to know. Just saying…
> 
> Thanks for the brilliant idea! :-)
> 
> Oh all mighty release team,
>   Ansgar has been experimenting with .deb sizes to make the packages
> needed for a minimal desktop installation fit in the first CD. It looks
> like that's doable by switching to xz compression for the involved
> binaries. Would you grant freeze exceptions for packages that only
> changes that?

Note that has been raised in LNG threads twice in less than a year.
So let's rehash the findings:

* XZ is almost always better:
  • xz -0 is twice as fast as gzip, with 78% the size (tested on a random
92MB unstripped amd64 executable)
  • xz -3 is at par with gzip -9's compression speed
  • xz -6 (the default) is a lot slower when compressing, fast when
decompressing, needs only 10MB memory, 58% size
  • xz -9 has very slow compression, takes gobs of memory, 56% size
(Obviously, the "size" numbers are dragged down by uncompressible files
when you look at the whole archive.)
  • It has somewhat slow start: small files may compress better with gzip,
but never to a degree that would justify the complexity of switching
compression algorithms.

* After recompressing the whole archive, it turns out compressing only
  biggest packages is not a good idea: the bulk of space is taken by
  medium-sized packages, which recompress almost as good.  Thus, for best
  effects, xz should be dpkg-deb's default.

* Any native ways to install support xz:
  • dpkg does (squeeze but not lenny)
  • d-i does (via busybox)
* Debootstrap relies on unxz being available on the running system.  Which
  might be not there for ancient ones.

Ie, the only show-stopper is debootstrap on foreign systems.

Here, there are two approaches:

* making sure all .debs debootstrap has to unpack use gzip.
  • explicitely forcing gzip in the packages affected would be error-prone
  • dpkg-deb doesn't know which packages are base, as transitive
dependencies make prority itself not enough
  On the other hand, checking this by hand and rejecting the package only
  during/after upload could work as a short-term solution.

* letting debootstrap handle xz files.
  • using arch-dependent executables is probably a bad idea
  • unxz would be hard to re-implement in Perl or something else typically
available on bare systems, Mirabilos tells me some BSDs don't even have
Perl.  No other reasonable language is likely to be there.
  • having a bunch of unxz executables for every architecture is doable, but
would be damn hard to build in an automated way, especially if we want
debootstrap to handle unofficial ports.  Currently, gcc needs libc6-dev
for the target system to cross-compile.
  • alternatively, one could use stand-alone binaries with some heavy
hackery.  Unxz-embedded can be whipped into working with only three
syscalls: read(), write() and _exit(), perhaps also some way to fetch
memory.  This could be built without any headers, for any architecture
gcc supports.  For an extra bonus, such ultra-static executables would
reduce the number of variants: one file is needed for i386, x32 and
amd64; armel and armhf, etc.  Sadly, the ELF header restricts
architectures, or with a proper trampoline you could even have one
executable work on twenty or more archs :p
  I did not hear Joey Hess or others chime in: would you accept such an
  universal binary into debootstrap?  It already ships a tarball (one with
  required /dev nodes).

* Repacking existing .debs is not a good idea for the main archive (even if
  it works "at home").  I doubt no-recompilation binNMUs would be safe, too.

Also, switching to XZ debs is not just a CD issue, doing so would
drastically reduce the resource usage of mirrors.


-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

Re: EFI in Debian

[Paul Wise]

On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> Will Android machines make secure boot turn-offable or another key
> installable, or will thay follow the Microsoft lead and lock
> everything down too?

Are there any Android devices that aren't *already* bootloader locked
or require jailbreaking to get root? I don't think Microsoft is
creating a trend here, locked down ARM devices are already the norm
AFAICT.

-- 
bye,
pabs

http://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: 
http://lists.debian.org/caktje6e1edc87s6ftxffj1hvr4spobxtcoh6enxgvq3brqh...@mail.gmail.com

Re: CD sizes again (and BoF reminder!)

[Adam Borowski]

On Sat, Jul 07, 2012 at 08:42:07PM +0100, Ben Hutchings wrote:
> On Sat, 2012-07-07 at 16:14 +0200, Bastian Blank wrote:
> - ftp, telnet: mostly redundant with wget and nc, unless you really like
> cleartext authentication

I don't get why anyone would talk about "authentication" in the context of
ftp and telnet in this millennium.  Both do still see some use for authless
services (downloads, dupload, termcast, ...).  For downloads, wget and web
browsers are indeed good alternatives, for termcast you need real telnet but
that's an obscure use.

+1 to dropping them from CD1, of course.

> - jfsutils, reiserfsprogs, ufsutils: obscure

These really need to stay on CD1.  JFS in particular used to be the fastest
filesystem not so long ago (for anything but big linear writes, where XFS
was better), and thus is still in quite wide use.  Being unmaintained these
days, it doesn't make any sense on new systems, but in a rescue/reinstall
situation, you need such packages at hand.

And isn't UFS still the default filesystem on kfreebsd installs?  Of course,
it makes little sense on CD1 on Linux.

> - openssh-server: server, not desktop

Doesn't take much, and for the likes of us, is really useful.  Can be
installed from the network, though.

> - deborphan, debfoster: obscure

debfoster is great whenever you care about disk usage. Sure, that is mostly
the case on vservers and the like rather than desktops, but as libraries,
gnome components, random packages you tried once, etc, accumulate, it's nice
to be able to drop unneeded cruft.


-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

Re: CD sizes again (and BoF reminder!)

[Hideki Yamane]

Hi,

On Sat, 7 Jul 2012 04:47:35 +0100
Steve McIntyre  wrote:
> So, yes - looks like xz will make a difference here for the wheezy
> release, for amd64 at least. It's enough that we'd probably even have
> space for the installation manual and release notes to fit \o/.

 BTW, I'll talk about using xz for whole archive try in this DebConf.
 (now I submit it)

 If you've interested in that, let's discuss :)

-- 
Hideki Yamane 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120708100752.d9bdf7e626c9a34e3b8d5...@iijmio-mail.jp

Bug#680788: ITP: lttng-modules-dkms -- Kernel modules for LTTng (DKMS)

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: lttng-modules-dkms
  Version : 2.0.2
  Upstream Author : Mathieu Desnoyers 
* URL : http://lttng.org/
* License : LGPL
  Programming Lang: C
  Description : Kernel modules for LTTng (DKMS)

The LTTng project aims at providing highly efficient tracing tools for Linux.
Its tracers help tracking down performance issues and debugging problems
involving multiple concurrent processes and threads. Tracing across multiple
systems is also possible.

This package contains the LTTng kernel modules. These provide additional
instrumentation (not found in the mainline kernel), the ring buffer library, the
tracer itself, and some additional utilities.

Installing on kernel versions prior to 2.6.38 might be possible, but has not
been tested.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708171553.GA12586@quintessa

Bug#680789: ITP: babeltrace -- Trace conversion program

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: babeltrace
  Version : 1.0.0
  Upstream Author : Mathieu Desnoyers 
* URL : http://www.efficios.com/files/babeltrace/
* License : MIT
  Programming Lang: C
  Description : Trace conversion program

Babeltrace provides trace reading and writing libraries, as well as a trace
converter. Plugins can be created for any trace format to allow its conversion
to/from any other supported format.

The Common Trace Format (CTF) aims at specifying a trace format based on the
requirements of the industry (through collaboration with the Multicore
Association) and the Linux community.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708171645.GA13111@quintessa

Re: EFI in Debian

[Philipp Kern]

Paul,

am Sun, Jul 08, 2012 at 10:00:05AM -0600 hast du folgendes geschrieben:
> On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> > Will Android machines make secure boot turn-offable or another key
> > installable, or will thay follow the Microsoft lead and lock
> > everything down too?
> Are there any Android devices that aren't *already* bootloader locked
> or require jailbreaking to get root? I don't think Microsoft is
> creating a trend here, locked down ARM devices are already the norm
> AFAICT.

there's a difference between requiring jailbreaking to get root and being able
to flash a random different software image. The Samsung Galaxy S is perfectly
able to get flashed, but with the default image you don't get root. I'm sort
of ok with that because I couldn't care less about the default image. 

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: CD sizes again (and BoF reminder!)

[Wouter Verhelst]

On Sun, Jul 08, 2012 at 01:17:32AM +0200, Bastian Blank wrote:
> On Sat, Jul 07, 2012 at 04:36:34PM -0600, Joey Hess wrote:
[...]
> > > - grub-legacy
> > These are all installed by d-i in various situations.
> 
> Even grub-legacy?

Yes; d-i in expert mode still has the ability to explicitly choose for
grub legacy, if you really want to.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708173704.gs21...@grep.be

Re: CD sizes again (and BoF reminder!)

[Ansgar Burchardt]

Hi

Stefano Zacchiroli  writes:
>   Ansgar has been experimenting with .deb sizes to make the packages
> needed for a minimal desktop installation fit in the first CD. It looks
> like that's doable by switching to xz compression for the involved
> binaries. Would you grant freeze exceptions for packages that only
> changes that?

Based on Sledge's list of packages for the CD images, I prepared a list
of savings-per-binary:

For GNOME, we can save up to 137 MB changing compression up to
task-gnome-desktop (108 MB by changing only 100 out of 969 binaries).
Or up to 252 MB up to task-laptop (183 MB changing only 100 binaries).

For KDE, it is 136 MB up to task-kde-desktop (106 MB for 100 binaries)
or 197 MB up to task-amharic (150 MB changing only 100 binaries).

Please note that these numbers include packages from the base system.
The real gains should be a bit less.

I'm not sure how much savings we need to fit things on CD1, maybe Sledge
can fill this?  Also I'm a bit unsure why Sledge had a bit higher
numbers on -devel earlier[1].

Please take a look at the files in [1] for details.  They list binary
packages, saving for switching this package (in kB) and the sum of
savings switching all packages so far (in kB).

Ansgar

[1] 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipdym8si@marvin.43-1.org

Re: CD sizes again (and BoF reminder!)

[Cyril Brulebois]

Wouter Verhelst  (08/07/2012):
> On Sun, Jul 08, 2012 at 01:17:32AM +0200, Bastian Blank wrote:
> > Even grub-legacy?
> 
> Yes; d-i in expert mode still has the ability to explicitly choose for
> grub legacy, if you really want to.

It looks to me like a current debian-installer build installs grub2,
with no option for grub-legacy, even in expert mode.

Apparently one can skip grub and install lilo instead, or skip
installing any bootloader. Maybe you meant picking up that latter
option, then manually installing grub-legacy?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts

[Vincent Bernat]

 ❦  7 juillet 2012 20:38 CEST, Michael Meskes  :

>> The bug is already closed but I'd like to share another solution: I am
>> using "acpi_fakekey $KEY_COFFEE" which sends XF86ScreenSaver key to the
>> currently displayed X server. This is not foolproof (only one X server,
>> only if it is currently displayed) but it is far simpler than other
>> solutions.
>
> Sorry, but what is "acpi_fakekey $KEY_COFFEE" supposed to accomplish? Sending
> XF86ScreenSaver key? I don't really how this relates to this big report. Could
> you please explain?

Yes, this would send the XF86ScreenSaver which would kick the
screensaver of the currently displayed X session. This is another
(imperfect) way to solve the problem of locking the user's screen
without needing either an entry in /var/run/utmp or consolekit.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)


pgpRBMGfoS9fD.pgp
Description: PGP signature

Re: CD sizes again (and BoF reminder!)

[Joey Hess]

Cyril Brulebois wrote:
> It looks to me like a current debian-installer build installs grub2,
> with no option for grub-legacy, even in expert mode.

grub-legacy is still used for multipath and sataraid.
Something was going to be done to make grub2 support those, but
I don't know the status.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: duplicates in the archive

[Noel David Torres Taño]

> WHOOPS, SORRY.  Meant to delete this old draft, not send it.
> The issue is valid, but sorry for incomplete mail.
> 
> On Sun, Jul 08, 2012 at 04:48:01PM +0200, Adam Borowski wrote:
> > On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote:
> > > On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > > > > Which wm does that? I know it isn't gnome-shell at least, as I've
> > > > > been using it quite successfully without nm installed.
> > > > 
> > > > Have you tried to use evolution without NM?
> > 
> > Evolution seems to work just fine.
> > 
> > > I didn't try but it only suggests network-manager. However some
> > > applications do behave weird if you just deinstalled n-m (pidgin for
> > > instance), because they assume that you're not connected. After a
> > > reboot (maybe dbus restart is enough) they certainly connect again,
> > > though.
> > 
> > I tested a good part of Gnome today without n-m and it appears there are
> > no regressions at all.  The only differences are:
> > 
> > * it gets rid of n-m icon in the systray (duh)
> 
> [was incomplete]
>   * "network settings" deep in the control panel will say the networking on
> this system is not compatible
> 
> 
> Since n-m breaks actually working software (udev, ifupdown) for non-obscure
> uses (connecting a phone via USB, bridged setups, non-basic VPNs, etc), a
> desktop environment hard-depending on it is bad, and this really needs to
> be a Recommends: relationship instead.
> 
> N-M compared to ifupdown:
> * makes things easier for new users (good! especially in a default install)
> * is said to make wifi easier (when it works...)
> And downsides:
> * breaks usb0 completely (keeps raising and lowering the interface in a
>   loop, no apparent way to tell it to keep its grubby hands away)
> * breaks a load of complex setups
> 
> "Breaks unrelated software" on the system is a RC severity, and there's no
> way one can say a windowing environment is related to core networking.
> Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
> Recommends: is a non-intrusive fix.  It will cause n-m to be installed
> unless explicitely refused, just like you want it to be.
> 
> On the other hand, breaking such setups is not a RC bug in n-m.  Like any
> non-core package, there is no requirement for it to be universal:
> * not working with complex setups is at most wishlist
> * breaking USB networking by flipping the interface is normal
> It's just gnome-meta hard-depending on it what's wrong.

First of all I'm not a DD but just a Maintainer of 2 packages and a long time 
user.

Since I fled away from KDE and felt into Gnome in Debian, I'm using it without 
N-M installed. It is only a matter of dpkg -force-depends -P two packages 
every time aptitude "corrects" my system when I install something, and I must 
say I'm more than happy by not having N-M: nothing messes with my network 
configuration (which is non-standard) and also users (my wife, or even myself 
using my normal account) can not disable networking nor break it.

I have not tried Evolution (I use kmail even in Gnome and my wife uses 
Icedove) but I can say that Pidgin works better without N-M than with it.

Regards (and thanks for all the time you spend that makes Debian my distro of 
choice)


signature.asc
Description: This is a digitally signed message part.

Re: Several question about how to help you.

[jose antonio]

2012/7/8 jose antonio :
> (English)
> Hello all,
>
> I have installed Debian on my computer and I have followed the
> maint-guide (http://www.debian.org/doc/manuals/maint-guide/) using the
> sources gentoo-0.19.13 I previously have downloaded.
>
> I have practiced with devhelper and does not seem very complicated.
>
> I have programmed in several languages throughout my working life
> but I do not know to program in c++ and it's something I would like to
> learn. In fact, I am following the manual gtk+ because I want to learn
> to create applications for Linux and especially for Gnome.
>
> That said, I would like to ask if do you think I could help them to
> maintain some gtk++ program by way of introduction? or should I finish
> first the manual and create a small application?
>
> On the other hand, once downloaded the sources of gentoo-0.19.13, I
> installed Anjuta, Geany ... and have not convinced me too. Then, I
> installed eclipse-linuxtools-indigo-SR2-linux-gtk-incubation-x86_64.tar.gz
> and it seemed to be the most advanced IDE. You could see the
> definitions of functions, from the files in which these functions were
> called using F3 and this is useful for learn about how the program was
> written. Also, I liked the ease of use of debug mode.
> But I am afraid that Eclipse could leave a configuration file that
> could affect the project and perhaps may fail the packaging (not
> tested).
>
> What IDE do you use to modify the sources of the projects?
>
>
> Finally, thank you very much for your effort and all your work!
> I like debian and would like to contribute with you, and maybe become
> a Debian Developer in a future! hehe
>
> ---
> (Spanish - Native)
> Hola a todos,
>
> He instalado Debian en mi ordenador y he seguido el maint-guide
> (http://www.debian.org/doc/manuals/maint-guide/) utilizando las
> fuentes gentoo-0.19.13 que previamente ha descargado.
>
> He practicado con devhelper y no parece muy complicado.
>
> He programado en varios lenguajes lo largo de mi vida laboral, pero no
> sé programar en C++ y es algo que me gustaría aprender. De hecho,
> estoy siguiendo el manual de gtk +, porque quiero aprender a crear
> aplicaciones para Linux y en especial para Gnome.
>
> Dicho esto, me gustaría preguntarles si creen que podría ayudarles a
> mantener algún programa gtk+ a modo de aprendizaje? o debo terminar
> primero el manual y crear una pequeña aplicación?
>
> Por otro lado, una vez descargados las fuentes de gentoo-0.19.13, he
> instalado Anjuta, Geany ... y no me han convencido demasiado.
> Entonces, he instalado
> eclipse-linuxtools-añil-SR2-linux-gtk-incubación-x86_64.tar.gz y
> parecía ser el IDE más avanzada. Se podía ver las definiciones de
> funciones, desde los archivos en los que estas funciones se llaman
> usando F3 y esto es útil para aprender sobre cómo se ha escrito el
> programa. Además, me gustó la facilidad de uso del modo de depuración.
> Pero me temo que Eclipse pueda dejar algún archivo de configuración
> que pueda afectar al proyecto y tal vez pueda fallar el empaquetado
> (no comprobado).
>
> ¿Qué IDE utilizáis generalmente para modificar las fuentes de los proyectos?
>
>
> Por último, muchas gracias por tu esfuerzo y tu trabajo!
> Me gusta Debian y le gustaría contribuir con usted, y tal vez
> convertirse en un desarrollador de Debian en un futuro! jeje


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CACp2nML4vcsNidd_7Ba8xF=3nnjsdbntbkd+0z5b5nnbnms...@mail.gmail.com

Re: CD sizes again (and BoF reminder!)

[Jonathan McDowell]

On Sun, Jul 08, 2012 at 02:12:44PM -0600, Joey Hess wrote:
> Cyril Brulebois wrote:
> > It looks to me like a current debian-installer build installs grub2,
> > with no option for grub-legacy, even in expert mode.
> 
> grub-legacy is still used for multipath and sataraid.
> Something was going to be done to make grub2 support those, but
> I don't know the status.

wheezy's grub2 is much better at multipath than squeeze's - I've
switched several production machines to the wheezy variant because It
Just Worked for me, while the squeeze version would fail to figure out
devices whenever update-grub was run.

J.

-- 
101 things you can't have too much of : 27 - Ice cream.


signature.asc
Description: Digital signature

Bug#680892: ITP: radeontop -- radeontop: Utility to show Radeon GPU utilization

[John Paul Adrian Glaubitz]

Package: wnpp
Severity: wishlist
Owner: John Paul Adrian Glaubitz 

* Package name: radeontop
  Version : 0.5.4
  Upstream Author : Lauri Kasanen 
* URL : https://github.com/clbr/radeontop
* License : GPLv3
  Programming Lang: C
  Description : radeontop: Utility to show Radeon GPU utilization

radeontop is a small utility which allows to monitor the utilization of
Radeon GPUs starting from the R600 series and newer using using undocumented
performance counters in the hardware. The utility works with the free
drivers.

It displays the utilization of the graphics pipe, event engine, vertex cache,
vertex group and tesselator, texture addresser and cache, the shader units
and more both with a relative percent value as well as a colorful bar diagram.

It comes with a manpage.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120708222145.14500.35271.reportbug@localhost.localdomain

Re: EFI in Debian

[Ted Ts'o]

On Sun, Jul 08, 2012 at 10:00:05AM -0600, Paul Wise wrote:
> On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> > Will Android machines make secure boot turn-offable or another key
> > installable, or will thay follow the Microsoft lead and lock
> > everything down too?
> 
> Are there any Android devices that aren't *already* bootloader locked
> or require jailbreaking to get root? I don't think Microsoft is
> creating a trend here, locked down ARM devices are already the norm
> AFAICT.

The Galaxy Nexus (and Nexus devices in general) can be unlocked by
simply running the "fastboot oem unlock" command which is distributed
as part of the Android SDK.  The unlock process will erase all of the
user data for security reasons (so that if someone steals your phone,
they can't use the unlock process to break security and grab all of
your data, including silly things like the authentication cookies
which would allow an attacker access to your google eaccount).

HTC and ASUS have also been selling their newer android with an
unlocked bootloader.  Most Samsung devices are shipped with unlocking
tools, so it came as a bit a surprise when the Verizon Samsung Galaxy
S3 came with a locked bootloader.  Some have blamed Verizon, but
there's no proof of that as far as I know.

So in answer to your question, there are plenty of Android devices
which are trivially unlockable.  (And once a Nexus phone is unlocked,
it's you can get a root shell trivially; no jail-breaking necessary.
Of course this is true for an attacker/thief who has managed to steal
your phone, but if you want to unlock the phone, it's easily doable on
many Android devices.)

   - Ted

P.S.  Personally, I recommend that people buy SIM unlocked, and easily
boot-unlocked Android phones; and if you get Google Experience Nexus
that isn't subsidized by Carriers, its firmware updates don't have to
get approved by carriers.  It also means you don't get any
carrier-mandated or handset-manfacturer-mandated bloatware.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708233048.ga24...@thunk.org

Bug#680899: ITP: fs-uae -- fs-uae: Amiga emulator based on the latest WinUAE emulation code with the focus on gaming

[John Paul Adrian Glaubitz]

Package: wnpp
Severity: wishlist
Owner: John Paul Adrian Glaubitz 

* Package name: fs-uae
  Version : 1.2.1
  Upstream Author : Frode Solheim 
* URL : http://fengestad.no/wp/fs-uae
* License : GPLv2
  Programming Lang: C++, Python
  Description : fs-uae: Amiga emulator based on the latest WinUAE emulation 
code with the focus on gaming

fs-uae is a cross-platform Amiga emulator with the focus on gaming. It is based 
on the
latest WinUAE emulation code and comes with an easy-to-use on-screen display 
interface
which allows to load and save game states, control the emulated hardware, swap 
floppy
disk images and much more. All settings can comfortably be controlled with a 
gamepad,
though keyboard control is naturally supported as well.

It features cross-platform online play as well as perfectly smooth scrolling on
50 Hz displays. Floppy images are supported in ADF and IPF formats, CD-ROM
images in ISO or BIN/CUE format and mounting folders on the host computer
as Amiga hard disks. Picasso 96 drivers allow high-color and high-color
Workbench displays.

A free kickstart ROM replacement is included as well, meaning that no 
copyrighted
ROM images are required to use the emulator.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120708233435.16318.86476.reportbug@localhost.localdomain

Re: EFI in Debian

[Ted Ts'o]

On Fri, Jul 06, 2012 at 05:32:44AM +0100, Ben Hutchings wrote:
> 
> 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> only load signed kernel modules and disable the various debug interfaces
> that allow code injection.  I'm aware that David Howells, Matthew
> Garrett and others are working on this.

Matthew Garret believes that this is a requirement; however, there is
no documented paper trail indicating that this is actually necessary.
There are those who believe that Microsoft wouldn't dare revoke a
Linux key because of the antitrust issues that would arise.

This would especially true if the bootloader displayed a spash screen
with a huge penguin on it, and the user was obliged to hit a key
acknowledging the spash screen before the boot was allowed to
continue.  James is working on a signed bootloader which would do
this.

It's not even obvious that the spash screen is needed, BTW.  Canonical
is not using a splash screen and is not signing the kernel or kernel
modules.  It will be *very* interesting if Microsoft dares to revoke
Canonical's certificate, or refuse to issue a certificate.  I'm sure
there are developers in Europe who would be delighted to call this to
the attention of the European Anti-Trust regulators --- you know, the
ones who have already fined Microsoft to the tune of 860 million Euros
($1.1 billion USD).

So personally, I would hope that at least some distributions will
patch out the splash screen, and apply for a certificate.  If we have
multiple distributions using different signing policies and slightly
different approaches (which is the beauty of free/open source boot
loaders; everyone can tweak things slightly), we can see how Microsoft
will react.

It should be entertaining

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120708235244.gb24...@thunk.org