Monday, 15 October 2007

svn-buildpackage 0.6.22 released to experimental

Thanks to Damyan Ivanov for the upload, svn-buildpackage 0.6.22 is now in experimental. The upload was done to experimental due to the big number of changes affecting it and because I wanted to get a fairly significant amount of testing of the major fixes before propagating the code to unstable.

This release should fix 15 (yes, fifteen) bugs[0], most of which were important bugs or bugs affecting usability.

The major fixes are:
  • mkdir -p like functionality in the repo for the tags and other possibly missing directories - this means that even repositories created with older broken versions should be fixed automatically[1]
  • .svn/deb-layout is no longer a broken cache, but only a real local override for the layout information; .svn/deb-layout is created only on express request via --svn-savecfg; note that although .svn/deb-layout is no longer created automatically, old checkouts should be purged of this cruft (unless the override is wanted)
  • build dependencies are not required on --svn-export
  • automatic creation of the origDir when using origUrl
  • some code clean up
Installing the package on an etch, lenny or sid system should be straight forward: just get the deb from experimental and install it (no backporting is necessary).


If you usually use svn-buildpackage, please install the experimental version and report any bugs and/or success stories. I am particularly interested in feedback related to the behaviour around .svn/deb-layout and the other methods of specifying layout information.

Please send success stories to me directly eddy.petrisor @ gmail.com. Bugs should be directed to the BTS, but I hope there will be mail just directly to me :-) .


[0] I wonder, does the thickness of the yellow area on these graphs ever decreases?
[1] as soon as the breakage would have been visible in the past

Saturday, 13 October 2007

SELinux: MLS/MCS support

When getting this error message:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
libsepol.link_modules: Tried to link in a non-MLS module with an MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!


You have to go back to the checkmodule step and type the same command, but add also the -M parameter:

bounty:~/usr/src/selinux/localpolicies/resolvconf# checkmodule -m -M -o localresovconf.mod *.te
checkmodule: loading policy configuration from resolvconf.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to localresovconf.mod

After that is all OK:

bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule_package -o localresovconf.pp -m *.mod
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -i localresovconf.pp
bounty:~/usr/src/selinux/localpolicies/resolvconf# semodule -l | grep localresolv
localresolvconf 1.0

Friday, 12 October 2007

SELinux: unusable from a newbie perspective

Thanks Russell for the explanations on the execmem bits.

Now I am trying to go further and set up my system to really work with SELinux enabled because, although the promise of the targeted policy is to allow you to do your job mostly as you did before, that "mostly" has a really wide meaning, more than you'd think you bargained for.

Examples from my laptop: hald does not start by default (various denials), resolvconf is denied some getattr operations on tmpfs, hald-addon-dell-backlight is denied access to some character device I just know it should have access to, etc. Of course, this means that automatic mounting does not work anymore and there is a decrease in usability just because of the "mostly" part.

I am sure that some of the denials are correct (see the execstack stuff or the memexec), but there are cases where this "mostly" is stretched way too much. IMHO, desktop installs should suffer no restrictions when using the targeted policy (and I mean "no restrictions that would make my system less than it was before enabling and enforcing SELinux").


But let me tell a reason why SELinux sucks without any help from others:

The interface sucks big time.

Probably there is are good reasons, but if you need to create and use a new policy based on the denials found in the logs, you need to use no less than 4 (four) different tools with the right incantation (although you can use just 2, if you don't want to customize the rules[1]):
  • audit2allow -m local -l
  • checkmodule -M -m -o local.mod local.te
  • semodule_package -o local.pp -m local.mod
  • semodule -i local.pp
In the end, you still hit the bad interface:

bounty:~# semodule -i local.pp
libsepol.check_assertion_helper: assertion on line 0 violated by allow hald_t memory_device_t:chr_file { read };
libsepol.check_assertions: 1 assertion violations occured
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!

Now what? That error message doesn't tell me much, except that some assertion failed. But where does the assertion come from? Why is it an assertion? What is bad about that line?
To me that really looks like an internal error or an inconsistency in what the SELinux tools generate.


[1] still, why advertise the longer path as the Fedora FAQ does? I would have done it the other way around.

Tuesday, 9 October 2007

selinux darcs policy; same for oolite

If you enable and enforce the targeted policy in Debian and you use darcs you need to allow it to use execmem:

chcon -t unconfined_execmem_exec_t /usr/bin/darcs


This allows to overcome these denials:

type=AVC msg=audit(1191957463.678:108): avc: denied { execmem } for pid=14811 comm="darcs" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process

And get this ugly message:

$ darcs w -l
darcs: internal error: getMBlock: mmap: Permission denied
(GHC version 6.6.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted



Since oolite complained of the same issue I also ran this:
chcon -t unconfined_execmem_exec_t /usr/lib/GNUstep/System/Applications/oolite.app/oolite




Update: If you want to know the reasons why darcs (a VCS) to need execmem read the RedHat bugs related to this and the upstream bug report on GHC: https://bugzilla.redhat.com/show_bug.cgi?id=195820
https://bugzilla.redhat.com/show_bug.cgi?id=195821
http://cvs.haskell.org/trac/ghc/ticket/738

SELinux is enabled. Now what?

Disclaimer: I am 100% newbie on SELinux, so any inaccuracies, mistakes or fallacies are almost sure due to this fact.

After reading Russell's latest post on SELinux, and reading the 5 minutes tutorial on SELinux I decided I should try SELinux on my laptop, too.

Now I have it enabled/enforcing/permissive/refpolicy-targeted.

First issue, hal didn't start in my GNOME session, although the hal module appears to be loaded:

bounty:/emul/ia32-linux/usr/lib/dri# semodule -l | grep hal
hal 1.4.0


It seemed that gdomap indirectly required execstack. I cleared the execstack bit (or whatever it is) on libcallback.so.0.0.0 and libavcall.so.0.0.0 and gdomap started.

OTOH, oolite failed to start since it required execmem:

0 eddy@bounty ~ $ oolite
trampoline: cannot make memory executable
Aborted

And after allowing execmem it worked:
# setsebool allow_execmem=1

0 eddy@bounty ~ $ oolite
2007-10-09 01:42:04.686 oolite[26717] initialising SDL
open /dev/sequencer: No such file or directory
2007-10-09 01:42:04.789 oolite[26717] init: numSticks=0
2007-10-09 01:42:04.789 oolite[26717] CREATING MODE LIST
2007-10-09 01:42:04.789 oolite[26717] Added res 1024 x 768
...

I also seem to have some other denied messages, but I hope I'll understand this soon enough to make it work.

I would like to know if is possible to allow execmem only for oolite, and since I suspect it is, how can I accomplish this?

So, now my question is, where is the fine manual on setting SELinux? I digged the whole evening to get oolite to start.

Saturday, 29 September 2007

trains are my coding anti-cryptonite

Another weekend trip to my parents' meant another successful svn-buildpackage coding session.

I worked on expanding the svnMkdirP functionality to svn-buildpackage and checked svn-upgrade. So when the testing is done (don't know when that will happen :-( ) I'll merge the work done in the svnmkdir-p branch[1] into trunk and ask for a sponsor - I don't think that will be a problem :-P.


If you want to test, don't try trunk yet[*], your should try the svnmkdir-p branch[1]. Don't forget to bump down the version.


BTW, svn-buildpackage 0.6.22 should close .....


0 eddy@bounty ~/usr/src/svn-buildpackage/svnmkdir-p $ dpkg-parsechangelog | grep ^Closes | sed -r -e 's#Closes:##' -e 's#[0-9]{6}#1 +#g' -e 's#\+$##' | bc
13

13 bugs.

Here are the bastards:
  1. 408690
  2. 411666
  3. 414581
  4. 419996
  5. 423487
  6. 428225
  7. 428689
  8. 433404
  9. 433536
  10. 434932
  11. 435746
  12. 436133
  13. 436554




[1] svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/branches/svnmkdir-p or svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/branches/svnmkdir-p

[*] the branch is not yet merged into trunk because it needs more thorough testing

Thursday, 27 September 2007

Invariant sections...

Thanks to Holger's post I saw this really educational comic strip.

To those who don't get the joke: the invariant sections could put you in that exact position. Please read the chapter about "Invaraint sections" from the "Draft Debian Position Statement about the GNU Free Documentation License(GFDL)"

Wednesday, 26 September 2007

svn-buildpackage pending changes

Just a few snippets:

Author: eddyp-guest
Date: Wed Sep 26 02:14:15 2007
New Revision: 4959

URL: http://svn.debian.org/wsvn/collab-maint/?sc=1&rev=4959
Log:
create a special branch for the svn "mkdir -p" like functionality until all scripts are converted to use this function and more tests are done

Added:
deb-maint/svn-buildpackage/branches/svnmkdir-p/
- copied from r4958, deb-maint/svn-buildpackage/trunk/

0 eddy@bounty ~/usr/src/svn-buildpackage/svnmkdir-p $ dpkg-parsechangelog
Source: svn-buildpackage
Version: 0.6.22
Distribution: UNRELEASED
Urgency: low
Maintainer: Eddy Petrișor
Date: Wed, 26 Sep 2007 05:24:59 +0300
Closes: 408690 411666 414581 419996 423487 428225 428689 433404 433536 434932 435746 436133
Changes:
svn-buildpackage (0.6.22) UNRELEASED; urgency=low
.
[ Eddy Petrișor ]
* IMPORTANT: changed default behaviour of saving the configuration in
.svn/deb-layout by default to avoid stale data to override the
configuration options that were updated in the repository.
(Closes: #414581)
As a consequence, a new option --svn-savecfg was added to allow a
mechanism for easily overriding options locally
.
[ Gonéri Le Bouder ]
* SDCommon::sd_exit: read the parameter correctly is SDCommon::nosave=1
(Closes: #428225)
.
[ Eddy Petrișor ]
* s-u: when importing options from ~/.svn-buildpackage.conf, filter in
only the valid options (Closes: #428689)
* s-u: replace retcode with retval for consistency with svn-bp
* s-i: manpage still claimed layout 2 was not implmented (Closes: #433404)
* s-i: now really supports injects for layout 2 (with the disadvantage of
not creating the tag directory)
* s-i: no longer fails on initial checkout (Closes: 411666)
* when using origUrl, make sure the origDir exists before downloading
in it
* s-i: man page: document the missing -o option (Closes: 419996, 435746)
* s-u: complete the man page synopsis section (Closes: 436133)
* s-b: do not require the build deps to be present when exporting
(Closes: 423487); thanks Stefano Zacchiroli for the patch
* SDcommon.pm: enhance the guessing algo of the layout to make svn-upgrade
guess correctly on layout 2 repos; thanks Gregor Herrmann for the patch
(Closes: 434932)
* Makefile: the version of the package is placed quoted in "SDCommon.pm" so
that versions like "0.6.22~bpo40+1" don't cause s-b to barf
* SDCommon.pm: implemented a function that emulates a 'mkdir -p'
functionality for svn; this will allow a fix for #434932
* s-i: based on the mkdir-p functionality create missing directories on
inject (Closes: 433536, 408690)


Friday, 21 September 2007

software for managing finances

Dear lazyweb,

I decided to track our (mine and my finceé's) expenses more closely and I am in search of some software for this task.

The requirements for the software:
  • not to hard to use (I don't want to read a whole manual to know how to use it)
  • possibility to assign a category for a given expense (so I can locate problematic type of expenses)
  • can easily extract statistics (e.g.: top last month's expenses, expenses split per category)
  • appropriate for domestic (small scale) accounting
  • available in Debian (or will be soon :-) )
  • preferably GNOME/GTK based
I have never used such software before, so I am a total noob in this area. Please be gentile if I might have naively described the problem.

Thanks in advance!

Monday, 17 September 2007

svn-buildpackage:development, RFH

Although slow, development on svn-buildpackage still continues. Sorry for the delays, but both myself and Eduard Bloch have been unable to assign more time to svn-buildpackage development in the last few months.

From the changelog of the trunk package (unreleased 0.6.22):
  [ Eddy Petrișor ]
* IMPORTANT: changed default behaviour of saving the configuration in
.svn/deb-layout by default to avoid stale data to override the
configuration options that were updated in the repository.
(Closes: #414581)
As a consequence, a new option --svn-savecfg was added to allow a
mechanism for easily overriding options locally

BTW, did you know that svn-buildpackage is maintained in collab-maint and welcomes contributions and committers/reviewers (especially those)?

In case you want to help, this is the place to start from:

svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

or

svn co svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

If you don't have commit access to collab-maint yet (just make a request on the alioth tracker and that will be fixed ;-) ).

Thursday, 13 September 2007

hmm, I was here before

I am stumbling again on the problem of not being able to install libgnome-dev and libsvn-dev side by side, namely bug #429025.

For some reason, I was under the impression that the bug was fixed... but apr-util is behind :-(.

Wednesday, 12 September 2007

is easy to let yourself manipulated

There is this guy whose blog I found about a week ago. He does some really nice and funny sketches mostly with issues regarding Bucharest and things he finds out/encounters.

The fact that he is smart to see some of the rudeness happening in Bucharest doesn't help him notice he is manipulated by the press (and himself) and writes:

"La 6 ani de la 11 septembrie 2001, Osama bin Laden a scos capu' din vagauna cu o noua inregistrare video in care da lumii intregi 2 alternative: convertirea la Islam sau moartea!"

Which translates approximately to:

"Six years after September 11, 2001, Osama bin Laden shows his face out from his hiding place and makes a new video in which gives the whole wolrd 2 alternatives: converting to Islam or death!"

(I won't take into discussion the correct translation of the message from Osama, if the message is authentic, if Osama is payed by somebody interested in keeping the conflict open, if Osama's forces are actually active in Iraq, if Bush is Osama himself, if we're actually living in 1984 and Osama is already dead but the American manipulative government is using all sorts of recordings from him to keep people inside a cage and fed them propaganda, < insert your theory/idea here >....)

He links to this article, whose title might make one to think what the guy said is true (according to the article)...

But, if read carefully is clear that there are a few twists (in order of apparition):
  • the alternatives were given to the American people ("urged the American people")
  • the alternatives were for the ending of the war in Iraq ("there are two ways to end the war in Iraq")
  • the first alternative is escalation of the conflict, not death; that would translate, IMHO, into "we will be fighting in Iraq and you can give up, but we will not", so I'd say surrender/retreat/keep fighting and probably die are all viable alternatives for the first one
  • apparently he says converting to Islam is an alternative ("The second way, he continues, is to reject America's democratic system and convert to Islam.")
  • but, if we read on we see that he actually says just to acknowledge that democracy is not at all a successful model, unless by success one thinks in terms of a system that achieves the interests of the corporations ("It has now become clear to you and the entire world the impotence of the democratic system and how it plays with the interest of the peoples and their blood by sacrificing soldiers and populations to achieve the interests of the major corporations")
  • and more importantly, converting to Islam is not actually a condition, but there is an invitation to do that ("I invite you to embrace Islam,")

So, the conclusion is that it's really easy to fall into the trap of believing what the titles and headlines suggest, rather than what the articles actually say, especially if you keep your head open only to single stream of ideas (I guess you, my dear reader, are smart enough to see what I mean here).


Disclaimer, my analysis might be off, my English sucks, I might be Osama, I might be Bush, I didn't saw the recording, there's a cat on a freezer...

Tuesday, 11 September 2007

dpkg i18n going backwards?

Now in dpkg I found this:

dpkg: no, cannot proceed with %s (--auto-deconfigure will help):\n
%s

Before there was something like:

dpkg: no, cannot remove %s (--auto-deconfigure will help):\n
%s


This is going backwards wrt to i18n since one of the basic rules of i18n is to have complete sentences, while keeping the verb covered behind some parameter is not a good way of doing that.

Monday, 10 September 2007

debian lenny on my laptop

I did this Friday night:

cat /etc/debian_version
lenny/sid

The good:
  • the upgrade was pretty painless, including the kernel upgrade (I just spent about an hour to resolve/force the upgrade path for some packages since aptitude was stubbornly refusing to upgrade since some recommends were not satisfied)
  • the kernel doesn't seem to need any options to make the headphones work
  • I can use a free driver for the wlan (bcm43xx instead of ndiswrapper)
  • as a bonus, now I can suspend-to-disk while the wlan interface is turned on (with ndis+2.6.18-5 the system hanged during suspend)
The bad:
  • the two icons I got on the desktop for the crypto partition I have mounted under /crypto are still both there (the worse thing is that I don't remember/can't find the bug number)
  • suspend-to-ram still doesn't work - I suspect flgrx being the culprit
  • there are now two icons for xchat in the systray. Should I be removing xchat-systray? Apparently yes, although there are a few things that xchat-systray had which are not available in the native systray thingie:
This is xchat-systray's menu:


And this is xchat's native menu:
By the way, the Hide menu entry there hides xchat itself, not the tray icon.



Update:
one more bad: this is still not fixed.


Update++:
I am a moron: apparently this is a known problem and a workaround exists. Now I can have my sincle xchat-systray icon :-) .