Re: Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices

[Paul Wise]

On Sat, Nov 10, 2012 at 5:57 AM, Jeremy Bicha wrote:

> There's another ITP that suggested heimdall-flash: 
> http://bugs.debian.org/644520

Marcin Juszkiewicz was also packaging this and I suggested
android-tools-heimdall since we also have android-tools-adb and
android-tools-fastboot.

-- 
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/CAKTje6Fitp5n8Zsi5VDR=3erVxcQm=qpzzwcrm2s6zxavn2...@mail.gmail.com

Re: Where could I upload x32 port bootstrap?

[Guillem Jover]

Hi!

On Fri, 2012-11-09 at 14:06:15 -0800, Daniel Schepler wrote:
> I've asked a couple people in private mail about this, and haven't
> gotten any answer, so I thought I'd ask here for ideas.  Where would
> be a good place to upload what I have so far from bootstrapping an x32
> port of Debian?  So far I have over 13000 source packages built, so
> the total size is likely to be in the dozens of GB...  which means
> probably putting it on people.debian.org would be too much.  Might
> alioth.debian.org have enough storage space for this?

I guess debian-ports.org would be the logical place. Just contact
ad...@debian-ports.org to ask if inclusion would be fine.

thanks,
guillem


-- 
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/20121109224008.ga4...@gaara.hadrons.org

Re: Where could I upload x32 port bootstrap?

[Marco d'Itri]

On Nov 09, Daniel Schepler  wrote:

> I've asked a couple people in private mail about this, and haven't
> gotten any answer, so I thought I'd ask here for ideas.  Where would
> be a good place to upload what I have so far from bootstrapping an x32
> port of Debian?
Nowhere, until we decide if and how we want to use x32.
IIRC there was some agreement that if we decide to support x32 it should 
be as a partial architecture.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#692864: RFP: mdpress -- create Impress.js slideshows with Markdown

[Axel Beckert]

Package: wnpp
Severity: wishlist
Control: block -1 by 623914

* Package name: mdpress
  Version : 0.0.12
  Upstream Author : Aditya Bhargava 
* URL or Web page : https://github.com/egonSchiele/mdpress#readme
* License : MIT
  Description : create Impress.js slideshows with Markdown

mdpress is a commandline tool that converts Markdown files to
presentations using Impress.js.

Markdown is an easy-to-read and easy-to-write markup language with
readability being emphasized above all else.

mdpress uses the Redcarpet library to process Markdown syntax.

=

It seems that all ruby dependencies are either already packaged (Yay! :-)
or at least ITP'ed (#623914). However, Impress.js itself (a presentation
framework based on the power of CSS3 transforms and transitions in
modern browsers and inspired by the idea behind prezi.com -- see
https://github.com/bartaz/impress.js) seems not yet packaged or
WNPP'ed. (I'm not exactly sure how how that dependency looks
like. Upstream does not explicitly mention it as dependency.)


-- 
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/87zk2qe7pm@nemo.deuxchevaux.org

Where could I upload x32 port bootstrap?

[Daniel Schepler]

I've asked a couple people in private mail about this, and haven't
gotten any answer, so I thought I'd ask here for ideas.  Where would
be a good place to upload what I have so far from bootstrapping an x32
port of Debian?  So far I have over 13000 source packages built, so
the total size is likely to be in the dozens of GB...  which means
probably putting it on people.debian.org would be too much.  Might
alioth.debian.org have enough storage space for this?
-- 
Daniel Schepler


-- 
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/cadf0c443jajm-usbup0_czvyzmscrjfq_uehuhacbsholwn...@mail.gmail.com

Re: Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices

[Jeremy Bicha]

On 9 November 2012 16:43, Steve Langasek  wrote:
> * Package name: heimdall
>   Version : 1.4~rc2
>   Upstream Author : Benjamin Dobell
> * URL : http://www.glassechidna.com.au/products/heimdall/
> * License : MIT/X11
>   Programming Lang: C++
>   Description : tool for flashing firmware on Samsung Galaxy S devices
>
> Heimdall is a tool for flashing firmware (aka ROMs) onto Samsung Galaxy S
> devices over a USB connection.  It accomplishes this using the same
> protocol as Odin, Samsung's internal Windows-only firmware updater.
>
>
> The naming of this tool is entirely logical from the upstream's perspective,
> given that there are other related pieces of software called "Odin" and
> "Loke".  However, there's an unfortunate namespace collision here with the
> Kerberos implementation Heimdal.  Suggestions welcome on how to qualify
> the source package name so that the packages are more than one letter off
> from one another...

There's another ITP that suggested heimdall-flash: http://bugs.debian.org/644520

Jeremy


-- 
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/CAAajCMbYue2YsW3n9_qhe_q5Az_4=m7m_zzey_y20dza8tn...@mail.gmail.com

Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices

[Steve Langasek]

Package: wnpp
Severity: wishlist
Owner: Steve Langasek 

* Package name: heimdall
  Version : 1.4~rc2
  Upstream Author : Benjamin Dobell
* URL : http://www.glassechidna.com.au/products/heimdall/
* License : MIT/X11
  Programming Lang: C++
  Description : tool for flashing firmware on Samsung Galaxy S devices

Heimdall is a tool for flashing firmware (aka ROMs) onto Samsung Galaxy S
devices over a USB connection.  It accomplishes this using the same
protocol as Odin, Samsung's internal Windows-only firmware updater.


The naming of this tool is entirely logical from the upstream's perspective,
given that there are other related pieces of software called "Odin" and
"Loke".  However, there's an unfortunate namespace collision here with the
Kerberos implementation Heimdal.  Suggestions welcome on how to qualify
the source package name so that the packages are more than one letter off
from one another...


-- 
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/20121109214334.30256.27664.report...@becquer.dodds.net

Bug#692860: ITP: ITP: gimp-qmlexporter -- GIMP plugin to export layers and Text as QT-Quick (QML)

[Joseph Mills]

Package: wnpp
Severity: wishlist
Owner: Joseph Mills 

* Package name: ITP: gimp-qmlexporter
  Version : 0.0.1-10
  Upstream Author : Jens Bache-Wiig 
* URL : http://qt.gitorious.org/qt-labs/gimp-qmlexporter
* License : (GPLV3+)
  Programming Lang: (Python)
  Description : GIMP plugin to export layers and Text as QT-Quick (QML).
There is a short video on how this works located at
https://www.youtube.com/watch?v=2Hgo9CWV400. My intentions of getting this into
debian is so that it will also get in Ubuntu. Then to open a webservice for
designers that are not programers. So that they can upload exported gimp layers
to qml and then backend designers can do the logic.
 Templeates


-- 
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/20121109211631.1577.80116.reportbug@joseph-12.04

Re: Something like nocompress DEB_BUILD_OPTION

[Guillem Jover]

Hi!

On Fri, 2012-11-09 at 10:16:21 +, Dmitrijs Ledkovs wrote:
> On 9 November 2012 09:37, Simon McVittie  wrote:
> > (It's possible that "faster" presets don't actually give you more
> > performance if the time to write out the .deb is dominated by I/O,
> > though.)
> 
> True about I/O. Does dpkg-deb writes-out tar to disk before
> compressing it or is it a pipe?

Oh, it's fairly suboptimal currently. It pipes tar's output to a
process compressing it to then write the result to disk, which gets
read back and written into the final .deb, for both tar member files.
This is pretty bad for big packages. But I already started reworking
the code to fix it, so this will be better in dpkg 1.17.x.

Similar badness happens on unpack, although at least it does not go
through a temp file on disk, also being reworked.

thanks,
guillem


-- 
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/20121109190127.gb32...@gaara.hadrons.org

Re: Something like nocompress DEB_BUILD_OPTION

[Guillem Jover]

Hi!

On Fri, 2012-11-09 at 15:52:53 +0100, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
> > | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in 
> > `test.gzip.deb'.
> > | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb  
> > 62.96s user 1.78s system 101% cpu 1:03.77 total
> 
> Some further tests show clearly why this is the case:
> 
> | gzip -c data.tar > /dev/null  6.51s user 0.04s system 99% cpu 6.548 total
> | gzip -9c data.tar > /dev/null  61.46s user 0.08s system 99% cpu 1:01.54 
> total
> 
> dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all
> for an negligible advantage of 1% smaller package.

There used to be a single global default level (9) for all compressors,
which got changed in 2010 to be backend specific, but only xz and lzma
were reduced to 6. I don't have any problem with changing gzip (to its
upstream default!) if as shown it's a vast improvement speed vs space.

I can certainly do that for dpkg 1.17.x, some more numbers would be
nice though, as in different types of data.tar, for example, but I
would not expect any surprises here, mostly just for reassurance.

thanks,
guillem


-- 
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/20121109184822.ga32...@gaara.hadrons.org

Re: What is the use case for Policy §7.6.2 ?

[Don Armstrong]

On Fri, 09 Nov 2012, Russ Allbery wrote:
> That makes sense to me on first glance. I can't think of a case
> where I'd want to use Provides/Conflicts/Replaces with non-virtual
> packages rather than using a transitional package.

I'm currently using this in the case of unscd and nscd.

It's useful to be able to do this when there are not any versioned
dependencies on the provided package, and one needs to take over the
configuration files of the package that is being conflicted with.

Just forbidding P/C/R in when there are (potentially) versioned
dependencies should be enough, I think.


Don Armstrong

-- 
life's not a paragraph
And death i think is no parenthesis
 -- e.e. cummings "Four VII" _is 5_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121109183941.gh11...@rzlab.ucr.edu

Re: What is the use case for Policy §7.6.2 ?

[Russ Allbery]

Josselin Mouette  writes:

> the Debian policy makes a special case of the
> Provides/Conflicts/Replaces combination, allowing to replace a package
> by another.

> The document mentions the case of a virtual package, for which this is
> nice and all, but it is still allowed for other packages.

> However, any versioned dependency is broken when you handle upgrades
> this way. Even worse, APT does not handle such situations very well. Bug
> #691160 is a good example of what happens in a bad case (the old package
> not being installable anymore). Arguably this is a bug in APT, but we
> are more prone to such bugs by allowing arcane relationships between
> packages.

> It looks to me that we should strictly favor the transitional package
> approach instead. Shouldn’t we entirely forbid the
> Provides/Conflicts/Replaces combination way of handling upgrades, except
> for virtual packages?

That makes sense to me on first glance.  I can't think of a case where I'd
want to use Provides/Conflicts/Replaces with non-virtual packages rather
than using a transitional package.

-- 
Russ Allbery (r...@debian.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/87obj63axy@windlord.stanford.edu

Re: major linux problems summary 2012

[Philipp Kern]

On Fri, Nov 09, 2012 at 02:36:24PM +0200, Riku Voipio wrote:
> Perhaps we should stop pretending Linux runs on any random hardware, and
> tell people to buy machines with Linux pre-installed? System76 [1],
> Google [2], Dell, HP, Acer, and others do already so.

Dell's shipping a "heavily patched"[1] Ubuntu to cope with the issues on that
particular Dell laptop. I.e. a kernel patch for the touchpad which is not
acceptable for inclusion upstream because it sends "magic numbers" to the
touchpad. Even then it works badly.

Kind regards
Philipp Kern

[1] Might be in the eyes of the beholder.


-- 
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/20121109180850.ga6...@hub.kern.lc

Re: IPv6, tentative addresses, bind(), wheezy

[Marc Haber]

On Sun, 04 Nov 2012 15:34:26 +, Ben Hutchings
 wrote:
>This wouldn't solve the problem that the UDP servers have, which is that
>they need to be able to send replies from the same address the request
>was sent to.

Right.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1twsmt-00084i...@swivel.zugschlus.de

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[Jon Dowland]

On Fri, Nov 09, 2012 at 05:27:03PM +0100, John Paul Adrian Glaubitz wrote:
> Yes, that's correct. But that's only one of the points of my
> criticism. I am in general not very much convinced by the quality of
> the packages in Linux Mint.

Neither am I. I did look at cinnamon and muffin briefly, saw many of the same
issues you describe for mdm (muffin a regex-change-only version of mutter) and
I couldn't see the point of muffin at all (why couldn't cinnamon be a client
of mutter?) plus lots of copyright and documentation issues. However I expect
things will improve given time, and/or input from people who care (Debian
packagers).


-- 
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/20121109171711.GE23696@debian

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[Michael Banck]

Hi,

On Fri, Nov 09, 2012 at 05:47:56PM +0100, John Paul Adrian Glaubitz wrote:
> On Fri, Nov 09, 2012 at 05:39:40PM +0100, Michael Banck wrote:
> > If people think it is worth keeping the nautilus codebase around, I
> > think it would be ok to  have it packaged,
> 
> Hmm, are the GNOME developers eventually dropping nautilus altogether?

Well, they GNOME'd it in the sense that quite a few options and features
are gone now in order to provide a streamlined usability.
 
> I don't know, shouldn't these users just not use Linux Mint itself
> then? The version in Debian will be quickly outdated then anyway, so
> that most users will probably complain.

That's a strawman argument which works for every package in Debian
(except that upstream is in this case a distribution itself, but I don't
see the point - what about all the packages that Red Hat is upstream
of?)


Michael


-- 
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/20121109165215.gb19...@nighthawk.chemicalconnection.dyndns.org

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[John Paul Adrian Glaubitz]

On Fri, Nov 09, 2012 at 05:39:40PM +0100, Michael Banck wrote:
> You critized their packaging, but this appears to be an upstream fork
> which is not just a sed regexp to replace the name. 

I am just sharing my experiences so far. I tried to help them to fix
issues in mdm and my commits were reverted, even though other people
agreed with me.

I am just worried with the quality of packages in Debian. I choose
Debian over everything else because of its high quality standards.

> If people think it is worth keeping the nautilus codebase around, I
> think it would be ok to  have it packaged,

Hmm, are the GNOME developers eventually dropping nautilus altogether?

> there is worse bloat in Debian

Sure, but that doesn't mean we should introduce more mess. We should
rather clean up what's messed up.

> and the default file manager of a very prominent desktop environment
> can be a personal thing to users.

I don't know, shouldn't these users just not use Linux Mint itself
then? The version in Debian will be quickly outdated then anyway, so
that most users will probably complain.

Adrian




-- 
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/20121109164756.ga29...@physik.fu-berlin.de

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[Michael Banck]

Hi,

On Fri, Nov 09, 2012 at 05:27:03PM +0100, John Paul Adrian Glaubitz wrote:
> On Fri, Nov 09, 2012 at 04:23:16PM +, Jon Dowland wrote:
> > On Fri, Nov 09, 2012 at 05:06:57PM +0100, John Paul Adrian Glaubitz wrote:
> > > I don't think it is currently a sensible decision to introduce
> > > duplicate GNOME3 packages into Debian. Nautilus 3.4 is currently
> > > available through GNOME3, so this would introduce redundancy.
> > 
> > wheezy will have 3.4 but 3.6 is already in experimental. So uploads
> > targetting experimental only until post-freeze should address your
> > concern.
> 
> Yes, that's correct. But that's only one of the points of my
> criticism. I am in general not very much convinced by the quality of
> the packages in Linux Mint.

You critized their packaging, but this appears to be an upstream fork
which is not just a sed regexp to replace the name.  If people think it
is worth keeping the nautilus codebase around, I think it would be ok to
have it packaged, there is worse bloat in Debian and the default file
manager of a very prominent desktop environment can be a personal thing
to users.


Michael


-- 
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/20121109163940.ga19...@nighthawk.chemicalconnection.dyndns.org

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[John Paul Adrian Glaubitz]

On Fri, Nov 09, 2012 at 04:23:16PM +, Jon Dowland wrote:
> On Fri, Nov 09, 2012 at 05:06:57PM +0100, John Paul Adrian Glaubitz wrote:
> > I don't think it is currently a sensible decision to introduce
> > duplicate GNOME3 packages into Debian. Nautilus 3.4 is currently
> > available through GNOME3, so this would introduce redundancy.
> 
> wheezy will have 3.4 but 3.6 is already in experimental. So uploads
> targetting experimental only until post-freeze should address your
> concern.

Yes, that's correct. But that's only one of the points of my
criticism. I am in general not very much convinced by the quality of
the packages in Linux Mint.

Adrian


-- 
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/20121109162703.ga29...@physik.fu-berlin.de

Re: RFC on MBF (non-freeness of "The Software shall be used for Good, not Evil")

[Jon Dowland]

CCing Ansgar

On Thu, Nov 08, 2012 at 04:25:51PM +0100, Leo 'costela' Antunes wrote:
> Ansgar has recently made an MBF against all packages including the
> problematic JSON license term "The Software shall be used for Good, not
> Evil".

I've found one of these - #692614 - is the whole set collected together
under a common usertag or similar?


Thanks!


-- 
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/20121109162543.GD23696@debian

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[Jon Dowland]

On Fri, Nov 09, 2012 at 05:06:57PM +0100, John Paul Adrian Glaubitz wrote:
> I don't think it is currently a sensible decision to introduce
> duplicate GNOME3 packages into Debian. Nautilus 3.4 is currently
> available through GNOME3, so this would introduce redundancy.

wheezy will have 3.4 but 3.6 is already in experimental. So uploads
targetting experimental only until post-freeze should address your
concern.


-- 
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/20121109162316.GC23696@debian

Re: Bug#692830: ITP: nemo -- File manager for cinnamon

[John Paul Adrian Glaubitz]

On Fri, Nov 09, 2012 at 03:59:00PM +0100, Nicolas Bourdaud wrote:
> 
> Nemo is a complete fork of Nautilus 3.4 and its goal is to extend the Cinnamon
> user experience to desktop and file management.

I don't think it is currently a sensible decision to introduce
duplicate GNOME3 packages into Debian. Nautilus 3.4 is currently
available through GNOME3, so this would introduce redundancy.

Also, I am not really convinced of the quality of the packages by
Linux Mint. The mdm display manager in the current Linux Mint release
is a dirty fork of the original gdm 2.20 code with the word "gdm"
regexp-replaced by "mdm" (the readme [1] refers to
"ftp://ftp.gnome.org/pub/GNOME/sources/mdm/"; as the download location,
for example). Also, the debian directory contains a control.in
template which is never used (since this was part of the original
Debian package). The package doesn't cleanly co-install with gdm nor
gdm3, contains tons of lintian errors and uses a completely outdated
version of debhelper. I don't think such packages would meet the
quality standards of Debian.

Also, last time I checked, Linux Mint Debian itself mixes packages
from unstable with their own repository and I have seen many package
conflicts with this setup. I think a derivative distribution should
always maintain their own complete repository.

Cheers,

Adrian

> [1] https://github.com/linuxmint/mdm/blob/master/README
> [2] https://github.com/linuxmint/mdm/tree/master/debian/control.in


-- 
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/20121109160657.ga28...@physik.fu-berlin.de

Re: Something like nocompress DEB_BUILD_OPTION

[Dmitrijs Ledkovs]

On 9 November 2012 14:52, Bastian Blank  wrote:
> On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
>> | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in 
>> `test.gzip.deb'.
>> | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb  
>> 62.96s user 1.78s system 101% cpu 1:03.77 total
>
> Some further tests show clearly why this is the case:
>
> | gzip -c data.tar > /dev/null  6.51s user 0.04s system 99% cpu 6.548 total
> | gzip -9c data.tar > /dev/null  61.46s user 0.08s system 99% cpu 1:01.54 
> total
>
> dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all
> for an negligible advantage of 1% smaller package.
>

Even without any option it defaults to -6, can you compare -1 as well?

Regards,

Dmitrijs.


-- 
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/canbhlujlvaexdl5wj16rmgdbq2cmb-duzxshiksu0rbu84-...@mail.gmail.com

Re: major linux problems summary 2012

[Vincent Lefevre]

On 2012-11-09 14:36:24 +0200, Riku Voipio wrote:
> On Sun, Nov 04, 2012 at 12:03:37PM +0100, Karol Szkudlarek wrote:
[...]
> > and about touchpad:
> > 
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238
[...]
> Perhaps we should stop pretending Linux runs on any random hardware, and
> tell people to buy machines with Linux pre-installed? System76 [1],
> Google [2], Dell, HP, Acer, and others do already so.
[...]

Well, the fact that Linux is pre-installed (or equivalently the vendor
provides a machine with no OS, letting the user install his favorite
GNU/Linux distribution) doesn't mean either that it will run without
any problems. For instance, I got a Dell Latitude E6400 without
Windows, but I have (had) some problems with it. Since a touchpad
recognition bug is mentioned above, I can tell you that I had a
similar problem:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622231
  Dell Latitude E6400: AlpsPS/2 touchpad sometimes misdetected as plain PS/2

and I need to run an experimental kernel to avoid this problem
(linux-image-3.2.0-4-amd64 3.2.32-1, in testing, is affected by
this bug).

> It might more expensive / difficult to acquire / less shiny, than a windows
> laptop, but at least you will get working touchpad and suspend/resume. 

Well, suspend/resume doesn't work correctly on my Dell Latitude:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619866
  ifupdown: "ifup eth0" doesn't work after suspend/resume

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849
  xserver-xorg: XKB settings lost after suspend (hibernate) / resume
  or USB keyboard plugged in

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267
  suspend takes time due to /usr/share/wicd/daemon/suspend.py

(BTW, I plan to purchase a Lemote YeeLoong 8101B, which has only
GNU/Linux support, but haven't had news from the vendor yet.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20121109150152.gi5...@xvii.vinc17.org

Re: Something like nocompress DEB_BUILD_OPTION

[Bastian Blank]

On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
> | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'.
> | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb  62.96s 
> user 1.78s system 101% cpu 1:03.77 total

Some further tests show clearly why this is the case:

| gzip -c data.tar > /dev/null  6.51s user 0.04s system 99% cpu 6.548 total
| gzip -9c data.tar > /dev/null  61.46s user 0.08s system 99% cpu 1:01.54 total

dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all
for an negligible advantage of 1% smaller package.

Bastian

-- 
No one may kill a man.  Not for any purpose.  It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6


-- 
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/20121109145253.ga31...@waldi.eu.org

Bug#692830: ITP: nemo -- File manager for cinnamon

[Nicolas Bourdaud]

Package: wnpp
Severity: wishlist
Owner: Nicolas Bourdaud 

* Package name: nemo
  Version : 1.1.1
  Upstream Author : Linux Mint Project 
* URL : https://github.com/linuxmint/nemo/
* License : GPL2+
  Programming Lang: C
  Description : File manager for cinnamon

Nemo is a complete fork of Nautilus 3.4 and its goal is to extend the Cinnamon
user experience to desktop and file management.


-- 
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/20121109145900.8835.92416.reportbug@cassetoipalemenix

Bug#692829: ITP: pbsclusterviz -- PBS Cluster Visualisation

[Paul Cochrane]

Package: wnpp
Severity: wishlist
Owner: Paul Cochrane 

  Package name: pbsclusterviz
  Version : 0.7a
  Upstream Author : Paul Cochrane 
  URL : http://pbsclusterviz.sourceforge.net
  License : GPL
  Programming Lang: Python
  Description : PBS Cluster Visualisation

 PBS Cluster Viz is a project to display information useful to admins and
 users about a computing cluster managed by a PBS-compatible resource
 manager.  Information includes load and job distribution.
 Interactive as well as static output is available.


-- 
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/20121109141401.6343.91982.report...@nb206ptc.rrzn.uni-hannover.de

Re: major linux problems summary 2012

[Andrey Rahmatullin]

On Fri, Nov 09, 2012 at 02:36:24PM +0200, Riku Voipio wrote:
> Android didn't grab 75% of the market by providing android installation
> instructions for iphones - it took the market with android preinstalled 
> on phones[3].
> [3] and lots of other reasons too but let us not spoil a great analogue.

Comparing a specialized device like smartphone and a general purpose PC is
not that great.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: major linux problems summary 2012

[Riku Voipio]

On Sun, Nov 04, 2012 at 12:03:37PM +0100, Karol Szkudlarek wrote:
> and about graphics freeze:
> 
> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1033263
> 
> and about touchpad:
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238
> 
> and about cpu fan:
> 
> https://bugs.launchpad.net/ubuntu/+source/i8kutils/+bug/410596
> 
> https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/632228
> 
> https://bugs.launchpad.net/ubuntu/+source/i8kutils/+bug/1060096

> All I need is a stable set of tools and mobile laptop which I can
> resume/suspend without
> crashes and do my work. Secondly I'm only a user of OS not a developer. :-)

I think the real problem is that you bought a machine designed to run
Windows, and the Linux community promised that machine designed
to run Windows will run Linux just fine.

Anecdotal evidence shows that it is rarely the case.

Linux works relatively well on server hardware, but that is because
server makers know that most customers are going to install Linux on them,
and make sure to provide them a good experience. 

OTOH manufacturers don't really put any effort in Linux support in
laptops - and it shows. Over years Linux on laptops has been a
never ending hit/miss where some laptops work well, while others don't.
Especially in the power management area, where we depend on vendors good
implementation of suspend/resume in bios code.

Perhaps we should stop pretending Linux runs on any random hardware, and
tell people to buy machines with Linux pre-installed? System76 [1],
Google [2], Dell, HP, Acer, and others do already so.

It might more expensive / difficult to acquire / less shiny, than a windows
laptop, but at least you will get working touchpad and suspend/resume. 

Android didn't grab 75% of the market by providing android installation
instructions for iphones - it took the market with android preinstalled 
on phones[3].

Riku

[1] https://www.system76.com/
[2] http://www.google.fi/intl/en/chrome/devices/chromebooks.html#ss-cb
[3] and lots of other reasons too but let us not spoil a great analogue.


-- 
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/20121109123624.ga21...@afflict.kos.to

Re: What is the use case for Policy §7.6.2 ?

[Henrique de Moraes Holschuh]

Hi Josselin!

On Fri, 09 Nov 2012, Henrique de Moraes Holschuh wrote:

> On Fri, 09 Nov 2012, Josselin Mouette wrote:
> > It looks to me that we should strictly favor the transitional package
> > approach instead. Shouldn’t we entirely forbid the
> > Provides/Conflicts/Replaces combination way of handling upgrades, except
> > for virtual packages?
> 
> And instantly break even further the upgrade path of lots of
> already-published packages?  This is the sort of thing that might need a
> deployment plan over two stable releases, it is probably better to find a
> way to fix apt.

Meh, never mind, it was a major thinko on my part, and I apologise.

We could certainly keep the current support in the tools, but forbid the
usage of the fields in that way for the future.

-- 
  "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: http://lists.debian.org/20121109125322.gb8...@khazad-dum.debian.net

Re: What is the use case for Policy §7.6.2 ?

[Henrique de Moraes Holschuh]

On Fri, 09 Nov 2012, Josselin Mouette wrote:
> It looks to me that we should strictly favor the transitional package
> approach instead. Shouldn’t we entirely forbid the
> Provides/Conflicts/Replaces combination way of handling upgrades, except
> for virtual packages?

And instantly break even further the upgrade path of lots of
already-published packages?  This is the sort of thing that might need a
deployment plan over two stable releases, it is probably better to find a
way to fix apt.

-- 
  "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: http://lists.debian.org/20121109124628.ga8...@khazad-dum.debian.net

Re: Something like nocompress DEB_BUILD_OPTION

[Bastian Blank]

On Thu, Nov 08, 2012 at 04:33:42PM -0800, Russ Allbery wrote:
> Oh, okay.  It would actually be much easier to standardize a way to switch
> to gzip compression than it would be to add a new concept of uncompressed
> packages.

The problem is: dpkg-deb with gzip is much slower than with bzip2 and xz
does not really add much. So you want none in this case.

| dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.none.deb'.
| dpkg-deb -Znone -b debian/linux-image-3.6-trunk-amd64 test.none.deb  0.12s 
user 1.56s system 108% cpu 1.539 total

| dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'.
| dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb  62.96s 
user 1.78s system 101% cpu 1:03.77 total

| dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.bzip2.deb'.
| dpkg-deb -Zbzip2 -b debian/linux-image-3.6-trunk-amd64 test.bzip2.deb  12.48s 
user 1.76s system 108% cpu 13.165 total

| dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.xz.deb'.
| dpkg-deb -Zxz -b debian/linux-image-3.6-trunk-amd64 test.xz.deb  103.27s user 
2.66s system 101% cpu 1:44.35 total

Bastian

-- 
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2


-- 
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/20121109112619.ga28...@waldi.eu.org

Re: Something like nocompress DEB_BUILD_OPTION

[Dmitrijs Ledkovs]

On 9 November 2012 09:37, Simon McVittie  wrote:
> On 08/11/12 19:31, Dmitrijs Ledkovs wrote:
>> I would like to have a nocompress Debian build option that will skip
>> any compression/optimisation at build time.
>

I am sorry if this was misleading. I am aware of the noopt option and
I am aware that disabling compiler optimisations gives you a different
(possibly broken) binaries.

>
> If what you want is a DEB_BUILD_OPTIONS option for "don't compress
> source or binary packages", nocompress seems a fine name for that; or to
> minimize side-effects by preserving the structure of the package, it
> could be something like quickcompress to keep the packager's choice of
> gzip or xz but use the fastest possible presets. (It's possible that
> "faster" presets don't actually give you more performance if the time to
> write out the .deb is dominated by I/O, though.)
>

This is what I want. And not currently available.

True about I/O. Does dpkg-deb writes-out tar to disk before
compressing it or is it a pipe?

> If what you want is a general shortcut option for "cut corners to get me
> a binary sooner, I (am|am not) willing to accept functional changes as a
> result" then it should have a different name, perhaps
> DEB_BUILD_OPTIONS=quick or something (or two different names, if there
> are valid uses for both versions).
>

I don't think this one is needed, as noopt + the above nocompress will
result in this shortcut, more or less.

Regards,

Dmitrijs.


-- 
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/canbhlujzd7fweq-oervzjqj6uj67f5-cdaxxkdud61ptdjt...@mail.gmail.com

Re: Bits from the release team - Freeze update

[Neil McGovern]

On Fri, Nov 09, 2012 at 06:54:23AM +0100, Christian PERRIER wrote:
> Quoting Benjamin Drung (bdr...@debian.org):
> > Am Donnerstag, den 08.11.2012, 20:35 + schrieb Jon Dowland:
> > > On Thu, Nov 08, 2012 at 08:29:02PM +0100, Benjamin Drung wrote:
> > > > Hm, I filed two unblock requests after that deadline, but before reading
> > > > the announce mail about it.
> > > 
> > > You don't state whether the decision impacts them or not, but so it goes…
> > 
> > The requested updates (for vlc and devscripts) fix bugs, but not release
> > critical bugs. I am unsure whether these updates get unblocked even
> > after the reduced acceptance criteria.
> 
> 
> Well, I bet that our estimated colleagues in the Release Team are not
> robots, so discussing with them might be possible..:-)
> 

Additionally, the mails didn't make it to the list due to the size of
the attached diff. You may want to consider that an indication of our
willingness to review the provided diff.

Neil
-- 


signature.asc
Description: Digital signature

Re: Bits from the release team - Freeze update

[Cyril Brulebois]

Christian PERRIER  (09/11/2012):
> Well, I bet that our estimated colleagues in the Release Team are not
> robots […]

[ OK ] Turing test.

Mraw,
KiBi.


signature.asc
Description: Digital signature

What is the use case for Policy §7.6.2 ?

[Josselin Mouette]

Hi,

the Debian policy makes a special case of the
Provides/Conflicts/Replaces combination, allowing to replace a package
by another.

The document mentions the case of a virtual package, for which this is
nice and all, but it is still allowed for other packages.

However, any versioned dependency is broken when you handle upgrades
this way. Even worse, APT does not handle such situations very well. Bug
#691160 is a good example of what happens in a bad case (the old package
not being installable anymore). Arguably this is a bug in APT, but we
are more prone to such bugs by allowing arcane relationships between
packages.

It looks to me that we should strictly favor the transitional package
approach instead. Shouldn’t we entirely forbid the
Provides/Conflicts/Replaces combination way of handling upgrades, except
for virtual packages?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1352454210.3618.794.camel@pi0307572

Re: Something like nocompress DEB_BUILD_OPTION

[Simon McVittie]

On 08/11/12 19:31, Dmitrijs Ledkovs wrote:
> I would like to have a nocompress Debian build option that will skip
> any compression/optimisation at build time.

That seems like mixing two orthogonal things: an uncompressed or
fastest-possible-compression .deb or source package, and speeding up
compilation by not optimizing code.

> Similarly other tools can optionally listen on that variable e.g.
> skipping pkgmangler and dh_scour.

This is mixing in yet more things. dh_scour runs a lossy SVG "optimizer"
(so, it has observable side-effects). pkgbinarymangler is an
Ubuntu-specific package which does various things, mostly with
observable side-effects, including:

* optimize (some) PNGs (losslessly, I assume?)
* optimize other files with advancecomp? (losslessly?)
* truncate changelogs
* strip translations
* adjust Maintainer

> In particular it would be useful during:
> * change-rebuild-test cycles

... unless your package changes its observable behaviour when not
optimized (yes, this does happen, particularly if some C or C++ code has
undefined behaviour).

> * (local) archive rebuilds (when debs are not published, e.g. testing
> a transition / binNMUs)

... unless one of your packages is miscompiled when (not) optimizing, in
which case you can get false positives or negatives in your rebuild.
(I've seen this happen too.)

If what you want is a DEB_BUILD_OPTIONS option for "don't compress
source or binary packages", nocompress seems a fine name for that; or to
minimize side-effects by preserving the structure of the package, it
could be something like quickcompress to keep the packager's choice of
gzip or xz but use the fastest possible presets. (It's possible that
"faster" presets don't actually give you more performance if the time to
write out the .deb is dominated by I/O, though.)

If what you want is a general shortcut option for "cut corners to get me
a binary sooner, I (am|am not) willing to accept functional changes as a
result" then it should have a different name, perhaps
DEB_BUILD_OPTIONS=quick or something (or two different names, if there
are valid uses for both versions).

S


-- 
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/509ccecb.6070...@debian.org