gmane.linux.debian.curiosa

Re: razor-qt

Adam Borowski — 2013-05-22T12:31:37

Are we speaking about text console, or X?

For the former:

# echo "deb http://angband.pl/debian sid main" >>/etc/apt/sources.list
# apt-get install vtgamma
Run "vtgamma -e" to get a template (you can't get either orange nor green by
any combination of R/G/B gamma) then adjust the colours to your taste, then
output the given string, putting it into /etc/issue or bash's prompt if you
want that permanent.

For the latter:

# apt-get install compiz
$ compiz --replace
Enable the color filters and play with them, there's no orange/green monitor
emulation in the presets but you can make one.

Too bad, the user interface for compiz config is badly acting up in unstable
right now, but the functionality itself works fine.



stty olcuc

(Quick hint: "stty -olcuc" restores sanity.)

Re: razor-qt

Enrico Zini — 2013-05-21T06:03:19


When I finally got my new fangled EGA screen, it was *configurable*: you
could use a button to choose to have it in orange, green, or with actual
colours. Back in the good old days when you were actually given a
choice.

Nowadays, if I type my login name all uppercase, I don't even get an
uppercase "PASSWORD:" prompt anymore :(


Ciao,

Enrico

Re: razor-qt

Zenaan Harkness — 2013-05-21T04:25:35

Back in the day ... our panel was THE WHOLE screen, it was all green
on black text and we lusted after those new fangled EGA screens - it
was orange! not green!

Heady technology indeed.


Nahh, surely not... dunno what makes you think that :)

Prova tutto per tutta l'estate e poi decidi

Mediaset Premium Freedom — 2013-05-10T06:05:44

http://adgo.solution.weborama.fr/fcgi-bin/performance.fcgi?ID=460578&A=1&L=948539&C=37262&f=13&P=64244&T=E&URL=

Prova tutto per tutta l'estate e poi decidi

Re: Debian in space

Bart Martens — 2013-05-09T16:10:51

Interesting question, although it more belongs in debian-curiosa, in my
opinion.  I don't think I'll ever go to space myself. :-)  Even when I win the
lottery, there are plenty things on earth I want to do first. :-)

Regards,

Bart Martens

Re: DPA instead of PPA

Arnt Karlsen — 2013-05-09T13:02:13

On Thu, 9 May 2013 12:40:28 +0100, Justin wrote in message 
<20130509114028.GA1750< at >xibalba.demon.co.uk>:


...and the Optional SOUP... ;o)

Re: DPA instead of PPA

Justin B Rye — 2013-05-09T11:40:28

Or a portmanteau instead of an initialism: SUP(plementary re)POSITORY.

Re: DPA instead of PPA

Jakub Wilk — 2013-05-09T10:15:41

* Raphael Hertzog <hertzog< at >debian.org>, 2013-05-09, 08:38:

You forgot the most catchy:

DSA = Debian Special Archive

Re: Bug#706605: ITP: macfanctld -- Fan control daemon for Apple MacBook computers

Adam Borowski — 2013-05-02T10:50:54

Well, Mac fans _are_ often rabid and annoying, but throttling them might be
an overreaction.

Re: [Debconf-team] Tomorrow's f2f meeting: 25th April 1900 localtime

Christian Perrier — 2013-04-25T12:55:12

Le 25/04/2013 14:51, Gunnar Wolf a écrit :

Ho, fun to see that a typo can turn out into a very smart play on 
words...:-)


I hereby confirm this...

Re: [Debconf-team] Tomorrow's f2f meeting: 25th April 1900 localtime

Gunnar Wolf — 2013-04-25T12:51:39

Christian PERRIER dijo [Thu, Apr 25, 2013 at 07:12:40AM +0200]:

Is the "Bell Époque" something related to the days before the AT&T
breakup (in the USA)?


Yeah, that starts to sound like an addiction to me...

Re: Bug#706029: ITP: libxxx-perl -- debug viewer for Perl data structure

Adam Borowski — 2013-04-23T20:57:42

While in Perl, unlike lesser languages, you can code with "use utf8", and
Unicode has done big strides forward especially with the emoji block, I
don't think it has the right characters yet to warrant using this tag.

Re: FINAL release update

Gunnar Wolf — 2013-04-19T00:52:19

Neil McGovern dijo [Thu, Apr 18, 2013 at 03:22:21PM +0100]:

What? Does this mean this is our high point? That from now on we will
just go downhill?

/me is severely disappointed.

Re: archive rebuilds wrt Lucas' victory

Goswin von Brederlow — 2013-04-18T08:21:08

Anything exponential will not work. And for O(n^c) the c must be
rather small to still find a solution in time. Fun stuff indeed. After
all, if we search 4 weeks for an optimal solution we might as well
just build everything like now and be quicker.
 

I don't think that is a good simplification. The chance that for two
packges like A and B there is a third package C that only
Build-Depends on X is rather small. And then you wouldn't get a common
node for A and B.


That somewhat fixes what the first one broke. Since now B can be a
child of A by purging Y and installing Z. Still wastefull though.

It makes the graph a lot smaller though.


Luckily minimal spanning tree is well researched. :)

Note: the graph would be directed and should have weights according to
the (estimated) complexity of installing/purging a package.
 

Even if the trigger is incremental we don't loose anything if delay
running the trigger. It will do more work for that later run but not
more than the individual runs put together. On th

Re: archive rebuilds wrt Lucas' victory

Adam Borowski — 2013-04-16T20:22:20

So you would include intermediate states as nodes in the graph as well? 
Interesting -- this could indeed optimize cases like that, at the cost of
making the problem a good deal harder algorithmically.


You mean, an algorithmical challenge?  In our kind of crowd?  That's the fun
stuff!

If we reduce the problem by two simplifications:

* can snapshot only before building a package (no intermediate states)
* the cost of purging a package is same as installing it

a solution is to find a minimal spanning tree, possibly with a
constraint on the tree's height.  And with the graph not being malicious,
I have a hunch the tree would behave nicely, not requiring too many
snapshots (random graphs tend to produce short trees).

The full problem may take a bit more thinking.


Ie, edges that purge should have a lesser cost than edges that install.


Again, parameters to the edge cost function.


Could be worth looking at.  Not sure how many triggers can work
incrementally, and how many rebuild everything every time l

Re: bits from the DPL: March-April 2013

Dmitrijs Ledkovs — 2013-04-16T14:53:09

Minor mistakes are not acceptable for a DPL, we should totally fire
that Stefano from that position.....

Regards,

Dmitrijs.

Re: archive rebuilds wrt Lucas' victory

Goswin von Brederlow — 2013-04-16T09:29:43

I think snapshoting is a good idea there. Or rather forking the
filesystem. Say you have 2 packages:

Package: A
Build-Depends: X, Y

Package: B
Build-Depends: X, Z

You would start with the bare build chroot and install X. Then you
create snapshots SA and SB from that. In SA you install Y and in SB
you install Z. Now both packages can be built.

BUT:

- Easy with 2 packages. But how do you do that with 30000?
- Y and Z may both depend on W. So initialy we should have
  installed X and W.
- Package C may Build-Conflicts: X but depend on most of the stuff X
  depends on. So taking the filesystem with X installed and purging X
  will be faster than starting from scratch.
- Doing multiple apt/dpkg runs is more expensive than a combined one.
  A single run will save startup time and triggers.
- Could we install packages without running triggers and only trigger
  them at the end of each chain? Or somewhere in the middle?
- There will be multiple ways to build the tree. We might install U
  first and then V or V

archive rebuilds wrt Lucas' victory

Adam Borowski — 2013-04-14T22:30:43

So this means that if you are messing with an archive rebuild¹, you risk that
being viewed as sucking up to the elect?

Kind of reminds me of a time when, at a keysigning, I mentioned that "I
wonder why do we care about a name printed on an easily faked id, shouldn't
we instead prefer »this is a guy whom a bunch of debconf attendees recognize
as The Dear Leader«", and the last words were instead taken as a personal
compliment².


[1]. I got a fast armhf box that turned out useless for its intended purpose
due to GFX card/monitor issues.  Around two years ago, Lucas mentioned you
need around 340 core-hours for a rebuild, this box compiles roughly half as
fast (no idea how I/O will scale), so with 4 cores it should be a week in
the best case.  I have a hunch it'd be more like a month, but hey, a rebuild
can be paused if the box finds an use after all.

Too bad, I see what seems to be most of the time being spent in dpkg
installing dependencies -- how could this be avoided?  One of ideas would
be to reform

Re: DPL 2013: Lats call for votes

Paul Wise — 2013-04-13T11:00:26


Perhaps they are practicing radical transparency.

Re: Crypto export

Don Armstrong — 2013-04-11T16:04:54

Welcome to the wonders of bureaucracy.


Don Armstrong

Re: so long, and thanks for all the fish

Martin Bagge / brother — 2013-04-05T14:13:35

The Woody freeze.