[Tails-dev] Please review bugfix/fix_slow_offline_documentation

[Ague Mill]

Hi!

It looks like I have a fix for the slow operation of Yelp while browsing
our offline documentation:


For the record, here is how I tracked down the issue: I felt something
was wrong with the specifics of our documentation, as Yelp was working
fine on other documents in Tails. So I've tried with an empty
`local.css`. And then it was fast. This lead me to do a binary search
(removing half, then half of half, etc.) to find which parts of the CSS
were making the whole thing slow.

7 iterations later, I found the culprit: '*box-shadow' properties.
Removing them was enough to make Yelp fast again. This makes the look a
little bit flat, but it does not make the website ugly.

Therefore the fix in `bugfix/fix_slow_offline_documentation` is trivial:

--- /dev/null
+++ b/config/chroot_local-hooks/18-fix_offline_website_css_for_yelp
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+# Yelp becomes awfully slow when 'box-shadow' properties are used.
+# So let's just remove the bling-bling to get a better offline browsing
+# experience.
+
+sed -e '/box-shadow/d' -i /usr/share/doc/tails/website/local.css

(Unfortunately, I have discovered in the process that Yelp crashed when
clicking an inline link. This is totally unrelated. New bug page
added.)

Again, candidate for 0.13~rc2.

-- 
Ague


pgpuwMKffqQW6.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Tails Server Edition

[emgent]

Hello People,

I'm thinking to start my contribute working on Tail Server Edition(1).
Is someone already active and involved in this project or like join it as me?

I'm up on IRC with emgent` nickname


(1) https://tails.boum.org/todo/server_edition/___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review bugfix/fix_background_readahead

[Ague Mill]

On Sat, Sep 01, 2012 at 01:52:04PM +0200, berta...@ptitcanardnoir.org wrote:
> On Sat, Sep 01, 2012 at 11:02:22AM +, Ague Mill wrote:
> > On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote:
> > > Also I haven't found a corresponding ticket in the wiki, appart from the
> > > old todo/improve_boot_time_on_cd, which is marked as done.
> > 
> > What should be written in there?
> 
> Like you described in your previous mail I guess, something like "Since
> 0.12, a regression was introduced in the readahead mechanism that
> makes the bloot slower because it pauses" (rephrase this lame words as you
> want).

Done: 

Can someone else test the changes, now? :)

-- 
Ague


pgpbNP0bhYr8p.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review bugfix/fix_background_readahead

[bertagaz]

On Sat, Sep 01, 2012 at 11:02:22AM +, Ague Mill wrote:
> On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote:
> > Also I haven't found a corresponding ticket in the wiki, appart from the
> > old todo/improve_boot_time_on_cd, which is marked as done.
> 
> What should be written in there?

Like you described in your previous mail I guess, something like "Since
0.12, a regression was introduced in the readahead mechanism that
makes the bloot slower because it pauses" (rephrase this lame words as you
want). I don't know, I'm not the one who worked on this.

Sorry if you feel I'm behaving like an asshole, but I'm just doing my job
of nitpicker like we decided, and try to push the process we decided about
how we document our changes in tickets. At least you'll have the joy to
tagging it pending if no one opposes to its inclusion in RC2. :)

bert.


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] When should we fix regressions?

[bertagaz]

On Sat, Sep 01, 2012 at 10:59:04AM +, Ague Mill wrote:
> On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote:
> > > I still would like to see this reach 0.13~rc2.
> > 
> > Given we're supposed to be freezed, I'm not sure this is a good idea,
> > unless there is has been tested a lot before being merged, and there is a
> > strong commitment to test this in the 0.13~rc2. Is the goodness of this
> > patch worth the effort or risk to include this so lately in the release
> > process?
> 
> Ok. Maybe this should had been discussed some more. The process I know
> the best about time-based releases is the Linux kernel. What happens
> there is that there is a window of time where new features get merged
> in. When this window is closed, a first release candidate is made.
> Then, what goes in are fixes for bugs and regressions. Then a second
> release candidate is made, followed by more bug fixes. Repeat until
> kernel is deemed stable enough for a release.

Sure we should have discussed about this before.

I understand the Linux kernel comparison, but this release cycle is a bit
different from the one we made. We for example didn't really planned to do
a RC3. I recognize it doesn't mean it won't happen. But our release
schedule is tight.

Also I guess that the bug/regressions fixes that get into the Linux code
after the feature freeze are more related to this features than old
regressions/bugs that for most of them probably did get fixed before the
feature freeze.

> This delay on boot is a regression (which appeared in 0.12, IIRC).
> I don't see why it should not be fixed as soon as possible. There is a
> second release candidate planed. If it appears to cause problem, then it
> can be reverted before the final image.

Well, it also depends if we'll be able to see if it causes problems.
That's why I was highlighting the need for careful tests of this patch and
asking for commitment on this. It's a regression, but quite a minor one, so
that's why I was wondering if including it was worse the risks at this
stage. I would have preferred to see this included before RC1, given it
was a known regression not that related to the 0.13 testing process.

But I guess you already did test it. If you feel comfortable enough, I
won't block, also because it seems that the first round of tests have
proven that this release doesn't contains so many problems (not to say
none at the moment), so we might be able to take time to test this.

But still, we would have to be careful and extensively test it.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Disabling 'PC speaker'?

[bertagaz]

On Fri, Aug 24, 2012 at 10:23:54PM +0200, sajol...@pimienta.org wrote:
> On 24/08/12 11:19, Ague Mill wrote:
> > Hi!
> > 
> > I would like to blacklist the 'pcspkr' module. It is responsible for
> > making the old-style 'PC speaker' work. On some computers, having the
> > module loaded means loud beep at bootup, shutdown and when using the
> > console.
> > 
> > The idea is already to start Tails with a muted soundcard. Does anyone
> > see a reason not to kill the 'PC speaker' as well?
> > 
> > Implementation is straightforward, it's a new file in
> > /etc/modprobe.d/no-pcspkr.conf with:
> > 
> > blacklist pcspkr
> > 
> > (I'll push that change after 0.13 is released if no one cares.)
> 
> We're not shipping the `beep` package so that's fine with me ;)

Can't see a reason not to include this change actually, so I'm fine with
it.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review bugfix/fix_background_readahead

[Ague Mill]

On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote:
> Also I haven't found a corresponding ticket in the wiki, appart from the
> old todo/improve_boot_time_on_cd, which is marked as done.

What should be written in there?

-- 
Ague


pgpYBXWDDArQE.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] When should we fix regressions?

[Ague Mill]

On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote:
> > I still would like to see this reach 0.13~rc2.
> 
> Given we're supposed to be freezed, I'm not sure this is a good idea,
> unless there is has been tested a lot before being merged, and there is a
> strong commitment to test this in the 0.13~rc2. Is the goodness of this
> patch worth the effort or risk to include this so lately in the release
> process?

Ok. Maybe this should had been discussed some more. The process I know
the best about time-based releases is the Linux kernel. What happens
there is that there is a window of time where new features get merged
in. When this window is closed, a first release candidate is made.
Then, what goes in are fixes for bugs and regressions. Then a second
release candidate is made, followed by more bug fixes. Repeat until
kernel is deemed stable enough for a release.

This delay on boot is a regression (which appeared in 0.12, IIRC).
I don't see why it should not be fixed as soon as possible. There is a
second release candidate planed. If it appears to cause problem, then it
can be reverted before the final image.

-- 
Ague


pgpaPHZoeS0KS.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Please review bugfix/fix_background_readahead

[bertagaz]

On Fri, Aug 31, 2012 at 11:15:41AM +, Ague Mill wrote:
> On Mon, Aug 27, 2012 at 12:51:04AM +0200, intrigeri wrote:
> > As you know, I tend to think the problem fixed by this patch is not
> > worth the risks involved at this stage of the release process, but my
> > extra-carefulness does not extend to vetoing if there is a general
> > agreement with applying this patch before rc2.
> > 
> > > +  start-stop-daemon \
> > > + --start --background --pid /var/run/background-readahead.pid 
> > > --startas /bin/sh -- \
> > > + -c "$BG_FILES | xargs cat >/dev/null 2>&1")
> > 
> > I assume you wanted to write --pidfile, as --pid does not exist in my
> > copy of start-stop-daemon. Beware before s/pid/pidfile/, though:
> > given --pidfile presence/absence changes quite drastically the
> > behavior of start-stop-daemon, if the proposed patch works, then this
> > option is probably not needed, is it?
> 
> Actually, this works due to GNU getopt magic:
> 
> $ /sbin/start-stop-daemon --start --background --pidfile /tmp/test.pid \
>   --startas /bin/sh -- -c 'date > /tmp/test'
> $ /sbin/start-stop-daemon --start --background --pid /tmp/test.pid \
>   --startas /bin/sh -- -c 'date > /tmp/test'
> $ /sbin/start-stop-daemon --start --background --pi /tmp/test.pid \
>   --startas /bin/sh -- -c 'date > /tmp/test'
>  
> This fails:
> 
> $ /sbin/start-stop-daemon --start --background --p /tmp/test.pid \
>   --startas /bin/sh -- -c 'date > /tmp/test' 
> /sbin/start-stop-daemon: option '--p' is ambiguous
> 
> Getting rid of `--pidfile` also fails:
> 
> $ /sbin/start-stop-daemon --start --background \
>   --startas /bin/sh -- -c 'date > /tmp/test'
> /sbin/start-stop-daemon: need at least one of --exec, --pidfile,
> --user or --name
> 
> What this made me realize, though, is that `--pidfile` is useless
> without `--make-pidfile` in this context.
> 
> So I have updated the branch to fully spell `--pidfile` and to also
> create that pid file. The broken sed invocation was also fixed, and as
> added bonus, the foreground progress bar now goes to 100%.
> 
> I still would like to see this reach 0.13~rc2.

Given we're supposed to be freezed, I'm not sure this is a good idea,
unless there is has been tested a lot before being merged, and there is a
strong commitment to test this in the 0.13~rc2. Is the goodness of this
patch worth the effort or risk to include this so lately in the release
process?

Also I haven't found a corresponding ticket in the wiki, appart from the
old todo/improve_boot_time_on_cd, which is marked as done.

bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev