Search Results: "will"

13 March 2006

Joerg Jaspert: Cebit 2006

I was at that event from Friday til now (13 March). That together with a job I am doing at the moment got the NEW queue big enough to start another pointless thread on the lists about it. Seems the threshold for that is around 200 packages. Oh well, lets get much below that tomorrow after some sleep… Cebit itself was nice, especially the thing that Tolimar and myself talked to a lot of people from different businesses and got some positive statements for donations for DebConf and Debian. That includes a new machine, including hosting, for debconf.org, which will then take the gallery. It was also nice to meet some people again which you dont see elsewhere, but where it helps to have some reallife contact and talk a bit about various things. Sometimes RL is just easier.

Jesus Climent: Debconf: bring a laptop to south america.

Those of you visiting debconf this year might consider asking their friends, workmates,... (even their boss at work) to give away that old laptop that is not used anymore, and with a battery which does not hold more than few minutes. The purpose? Bring it/them to debconf and give them away to people working for Debian in one way or another who dont even have a proper desktop to work with. I will be leaving from Finland, so if you have anything you want to give away, send me an email: mooch () debian ! org

Martin F. Krafft: Brief touchdown at Chemnitzer Linux-Tage

It's now been over a week since I visited my brother in Leipzig, with the intention to head over to Chemnitz on Saturday morning to attend the Chemnitzer Linux-Tage. It turned out that Saturday was just too nice a day (and Friday night too long), so I skipped the fair on that day and stayed with my brother, which wasn't a problem as my only required appearance in Chemnitz was Sunday morning for a talk on the Debian package lifecycle. So Saturday we ate an extensive breakfast, hung around, took a walk, met some folks, listened to a bunch of tunes, played countless Stratego games (this will have to be my favourite board game), and generally had a marvelous chilling time. So Sunday morning I got up early, hopped on a train and arrived in Chemnitz around 9:40 with ample time to make it to the campus where my talk was to be held at 11:00. Ample time -- or so I thought. Public transport in Chemnitz doesn't really wake up until 10:30, and the train schedule isn't descriptive of what actually happens on the track. So with a bunch of running, I finally ended up on a train to the south station, from where I walked. My talk went very nicely. I talked about what happens to a package between the developer's machine and Debian stable, giving insights into dak, the various parallel archives (such as stable-proposed-updates and experimental), and describing how security updates as well as volatile and backports fit in. The slides are accessible through your browser (but are German-only, sorry), thanks to the wonderful magic of docutils and S5 -- a great presentation system based on XHTML and CSS2 (it's written by one of the CSS gods). You can get my template with bzr. It and the slides are available under the terms of the Artistic Licence. Also in Chemnitz, my publisher Open Source Press officially released the German translation of my Debian book. It's good to see that finally out of my way. :) I left the campus early because I was too tired. I regret it because the Chemnitzer Linux-Tage seem like a nice event, and there were a bunch of talks I really wanted to see, but I simply couldn't. Till next year.

Eric Dorland: watch files considered helpful

I spent some time yesterday putting watch files in most of my packages. Watch files have been around for a long time in Debian, but hasn't reached the exposure it perhaps deserve. They're used by uscan to check for newer upstream versions of the source. What's even more useful than running uscan is the Debian Watch Health Status pages (which are also helpfully linked from the QA developer's page, but that functionality appears to be broken at the moment) which parse the watch files as well and provide a nice web interface to look up your packages and others and see where upstream is at. Unfortunately, for this to work properly the package needs a watch file, and according to the statistics, only 1/3 of all packages have watch files. So here's a quick tutorial, just plop a suitably modified version of these examples into the debian/watch file in your package and you're off to the races. If you're packaging foo and the source tarballs are on ftp.foo.org your watch file will look something like this: 
version=3
ftp://ftp.foo.org/pub/foo/foo-(.*)\.tar\.gz
Some things to note: the version line is just there to allow for future enhancements without breaking backwards compatibility. For the location specifier, the last part after the final / is a regular expression (notice the .'s are escaped). The pattern inside the parentheses is what gets parsed as the upstream version number. For HTTP the syntax is almost identical: 
version=3
http://www.foo.org/files/foo-(.*)\.tar\.gz
This snippet will download http://www.foo.org/files/ and look for href's corresponding to the rest of the pattern. For projects hosted on Sourceforge, there's a handy syntax for that, and uscan will take care of figuring out its annoying mirror system. If it's project bar, and the source is called libbar: 
version=3
http://sf.net/bar/libbar-(.*)\.tar\.gz
There are many more details in the uscan man page. I think it would be great if more maintainers put watch files in their packages. It's one of those touches that really sets Debian apart from the rest.

Jos Parrella: FLISOL Caracas

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

12 March 2006

Jose Carlos Garcia Sogo: Gnome 2.14 is "almost" out!

In a very few hours from this post, Gnome 2.14 will be out. Looking the last releases it seems that releasing each 6 months is working pretty well, allowing people to have software with nice features soon. One of the interesting ones is Ekiga. Formerly known as GnomeMeeting it integrates SIP support now and I am quite confident it will be expanded to other VoIP technologies as well. Avahi support is other of the nifty features. It has a lot of interesting uses in both corporate and home networks. And looking at what other people is writing in their blogs, it seems that next release will focus more on improving the software we have and enhace performance than in adding new features, which is great if we don't want to die of success. Congratulations!

Junichi Uekawa: How costly is a shared library function call compared to a static library function call?

Linux/glibc/ELF shared library function calls are said to be slower than static library function calls, because function calls a redirected through plt/got section, which jumps to addresses specified by the offset in GOT.The background for this indirection is that ELF specification implies that load address of a shared library is not pre-determined, and addresses are decided after load.To make this happen, allowing write to the whole text segment (where all the code is, includingjump addresses and other things) will disallow read-only mmap of executable binary.That means backing store is required in terms of swap space.To minimise the effect of modified jump instructions, the modifiable jump instructions are split off into another section, which is writable all the time, called GOT.(this is my understanding, if you find any corrections, please send me a mail, so I can secretly update this page).Anyway, there's an extra jump instruction involved for shared library function calls.I made a short micro-benchmark and measured the time required to make sure that was the case.I called function call for 1G times on a 500MHz powerpc.Apparently, it takes 2 clock-cycles of overhead.

Aigars Mahinovs: Bounce-O-Meter

This link is mostly for women doing some sports - you like when you are doing some sports activity and sometimes breasts get in the way of your performance? So this website features a Flash application that lets you choose you cup size, type of activity you plan to do and then shows what type of sports bra you should use for that. There will also be a realistic visualization of how that sports bra will perform, how a regular bra would perform and how it would look to do that au-naturel. http://www.shockabsorber.co.uk/bounceometer/shock.html Note: The link is NOT work safe! P.S. Guys that love Baywatch should also check out that link too. You will not be disappointed ;) P.P.S. Geeks should check out the wireframe mode :D

Ross Burton: Slicing Tree Models

Sometimes there is a need to take a slice of a GtkTreeModel, for example if you have a tree of data and want to show a particular layer of it in a GtkIconView. GtkIconView widgets will only work on list models so there needs to be a way of taking a slice of a tree model and presenting it as a list model. I hereby present OwlTreeModelSlice. OwlTreeModelSlice in action The tree view on the left is a GtkTreeStore. The icon view on the right is displaying a OwlTreeModelSlice, that has been told to use the Applications node as the root. There are a few methods left to implement, and I need to get someone masterful in tree model fu to review the code, but hopefully I'll be releasing the source shortly. NP: Motion, The Cinematic Orchestra

Mirco Bauer: Mono 1.1.9.1, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9

I uploaded last night Mono 1.1.9.1, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9 to Debian/Unstable and debian.meebey.net. mono-tools for Debian/Unstable is now in the NEW queue though, so it will take some days before it hits the Debian archive. Gnunit and the famous monodoc-browser package is part of mono-tools now.
Warning about Gtk# 2.3.91, it breaks ABI means all Gtk# 2 applications must be recompiled against Gtk# 2.3.91 in order to work again, for example f-spot and muine. MonoDevelop 0.7 is already recompiled and uploaded too, f-spot and muine will follow tonight. The package dependencies will force a removal of f-spot and muine when Gtk# 2 will be upgraded, so nothing will break silently. Thanks to Eduard Bloch (aka Zomb) and Ingo Saitz (aka Salz) for sponsoring the uploads of the packages to the Debian archive.

Mirco Bauer: Mono 1.1.9, Gtk# 2.3.91 and Gecko# 0.11 Preview Packages

I made preview packages for Mono 1.1.9, Gtk# 2.3.91 and Gecko# 0.11. I also had to recompile GtkSourceView# and Gecko# against Gtk# 2.3.91 for MonoDevelop. If you run into problems please report them on the pkg-mono-devel mailing list, thanks. If I don't get reports in the next days, the packages will be uploaded to Debian/Unstable.
The packages are avialable as usual under:
deb http://debian.meebey.net/ ./

Mirco Bauer: Removal Requests for Mono are Processed!

"WTF, removal requests?" you may think now. There was Mono packages in Debian for architectures that don't work (not with Mono at least), it compiled at some time though. Whenever a package got build for an architecture, the debian/unstable -> debian/testing system will only add or update packages in testing when there are current versions of all build packages. This means the packages that should not be there must be removed from the archive by the ftp.debian.org crew via a removal request, to allow going in debian/testing. This happened for Mono with s390, sparc and alpha.
Short version: Mono can now enter debian/testing and should be in it, in the next days!

Mirco Bauer: Mono 1.1.8.1, Debian/Etch, CLI Policy, CLI Applications Update

Mono 1.1.8.1 was uploaded to Debian/Unstable on Wednesday and is now waiting in the NEW queue (because of the new packages like mono-classlib-1.0/2.0 which I blogged already about).
I also uploaded the packages to debian.meebey.net (versioned as preview packages), which are the same packages, so if you can't wait use the preview repository please. I just filed all removal requests that are needed to get Mono into Debian/Etch, when those are processed, it should go in. Also the CLI Policy draft is almost complete to be official, it defines basic rules now which are required for an user friendly, unified and stable CLI integration in Debian with Mono (and other CLRs like dotGNU) and CLI applications.
With the CLI Policy and Mono in Debian/Etch soon, the Mono Debian Plan is almost complete, only backports for Debian/Sarge are left then. On those I will work when the 1.1.8.1 packages are in the archive and some other packages are updated to the latest version (like Gtk# 1.0.10 and MonoDoc 1.0.7). Currently the following CLI applications are in Debian/Unstable:
MonoDevelop, MonoDoc, Muine, Blam, F-Spot, Tomboy, Nant, Kurush and last but not least IKVM Upcoming CLI applications going in Debian soon or later:
NUnit, NDoc, GFax, Sonance, Beagle and Smuxi Ready to use preview packages we have for:
GFax and MonoDevelop with Boo support
They are on debian.meebey.net, you can use:
deb http://debian.meebey.net/$package ./
or to get all:
deb http://debian.meebey.net/ ./ I personally think this is a big list of CLI applications being in Debian already (or go in when the packages are ready), it shows that Mono/CLI/C# is accepted in the opensource development community!

Mirco Bauer: Mono 1.1.8 Debian Packages

Mono 1.1.8 released, and here they are the debian packages for it. It took 1,5 days for them because they have some major changes. Mono 1.1.8 has C# 2.0 support by default now and I didn't want to bloat mono-assemblies-base with all the 2.0 stuff. So we have now new packages: mono-gmcs (containing the C# 2.0 compiler), mono-classlib-1.0 (contains 1.0 libraries, this was mono-assemblies-base before), mono-casslib-2.0 (contains 2.0 libraries), mono-classlib-1.0-dbg (contains the *.mdb files used for debugging purposes) and last but not least mono-classlib-2.0-dbg. This reduces the download size of normal Mono users from 15.2MB to 3.4MB. Because of this drastic changes, the packages are _not_ yet uploaded to debian/unstable, but to debian.meebey.net instead. If no real bugs are found till monday, they will be uploaded on monday to the debian/unstable archive. So please go test them! The repository as usual: deb http://debian.meebey.net/pkg-mono ./

Mirco Bauer: Mono 1.1 Suite Uploaded to Debian/Unstable

The invasion of the Mono 1.1 suite has reached the archive of Debian/Unstable!
All packages were accepted within minutes (because of the preparation in Debian/Experimental and the good work of the ftp-master).
Here the full list of uploaded source packages with version:
cli-common (0.1.3.0), mono (1.1.6-4), monodoc (1.0.6-3), libgdiplus (1.1.7-2), gtk-sharp (1.0.8-2), gtk-sharp2-unstable (1.9.5-1), gecko-sharp (0.6-3), gecko-sharp2 (0.10-2), gtksourceview-sharp (0.5-6), gtksourceview-sharp2 (0.10-1) and last but not least monodevelop (0.7-1) The mission of the master Debian Mono Plan is almost completed with this step.
The Debian CLI Policy draft is now in work and an announce to all maintainers of Mono based applications will follow soon. The new packages use a different layout and allows easier packaging for maintainers. The existing packages should be migrated (if you have such package please visit #debian-mono on freenode or/and read/comment the new CLI policy draft), the main rules are already known but not written down yet (a discussion on #debian-mono is desired). When CLI policy draft is finished and all current packages follow those, it's ready for going in Debian/Etch (Sarge must be released before that of course).
At that time we will work on backports for Debian/Sarge and provide them via the official Mono project page. I have to send some special thanks to the Debian Developer who allows that all my work is actually hitting Debian (because I am not an official Debian Developer yet), it's the man called Ingo Saitz (aka Salz) who is sponsoring all my uploads to debian and pointing me sometimes to issues he may see. Thank you Ingo for all work you did to make this possible! [/Academy Awards speech]

Mirco Bauer: Ups, I did it again...

Yeah I did... Mono updates, what else? I packaged Gtk# 1.9.5, GtkSourceView# 0.10 and MonoDevelop 0.7 (you will probably think now: wheeeeee!). I didn't upload those yet to experimental, I will just leave them for a few days on debian.meebey.net. So just apt-get update/upgrade and you should get the new packages. My next plan is to upload the current Mono 1.1 suite to debian/unstable soon, maybe this Sunday. After that I will package Mono 1.1.7 for experimental, 1.1.7 broke some applications because the IO-Layer changed completly, so I wait a bit with this release to enter the debian/unstable archive, I don't want to break anything for just beeing cool^Wbleeding edge^WWup2date. MonoDevelop 0.7 seems to have some nice GUI improvements, the toolbar now has animations and changes with current file context. Now the bad news: no mono debugger yet in 0.7. Well, it has debugger support but we can't use that yet, the debugger itself requires features of Mono which are only in a SVN Mono version. I packaged the mono debugger anyhow for a long time now, some months ago I think. Anyone who wants to try the console (gdb-like) version of it, good luck! smile.png just install it from the debian.meebey.net repository with "apt-get install mono-debugger" the debugger is called "mdb". That's it for now...

Mirco Bauer: Mono 1.1 Suite in debian/experimental

Here we go, the whole Mono suite is uploaded to debian/experiemental. Here the full list: Mono 1.1.6, MonoDoc 1.0.6 (NEW), Gtk# 1.0.8, Gtk#2 1.9.3 (NEW), Gecko# 0.6, Gecko#2 0.10 (NEW), GtkSourceView# 0.5 (NEW), GtkSourceView#2 0.7 (NEW), libgdi+ 1.1.7, MonoDevelop 0.6 As you can see many packages are in the new queue, that's because I separated the documentation into own packages (monodoc-*-manual). When all packages are accepted (/me looks slightly to the ftp-master) we can upload to unstable, the 1.1 packages are now tested by about 300 users, and no major bugs were found. I merged all packages to http://debian.meebey.net means it will always contain the latest packages, this is specially good for non-debian users and experimental afraid users. Have fun Monoing!

Mirco Bauer: Mono 1.1 in Debian update, I can use it already

After 2 days hardcore packaging the rest of the Mono suite, like Gtk#, Gtk#2, MonoDoc, Gecko#, Gecko#2, GtkSourceView#, GtkSourceView#2 and MonoDevelop I am kinda exhausted. But the packages work and everybody is happy. libgdiplus though causes problems to work with libcairo1 (0.4.0), it expects the 0.3.0 API, and even ships cairo 0.3.0, but that means I can not use extra features like glitz. A mono developer is trying currently to port libgdiplus for the 0.4.0 API, hope it will work out. If you like to try those new preview packages here is the APT source: deb http://debian.meebey.net/ ./
It contains the whole Mono 1.1 suite. The 1.1 suite will be uploaded to debian/experimental as soon I got a some positive or negative feedback (latest next weekend), have fun monoing wink.png

Mirco Bauer: Mono 1.1 in Debian, I can feel it already

I am working hard on the new generation of the Mono packages, the 1.1.x branch is a lot different than 1.0.x (that's what we got currently in debian). With Mono 1.1 we drop also the "Mono Conventions" and stick to upstream's directory layout (layout of 1.0.x was not FHS-conform). I will publish preview packages via pkg-mono.alioth.deban.org as soon as I believe they are ready for testing. Noticable is, that upstream tried for cooperation (finally), in fact Miguel de Icaza did. So I hope everything becomes better now between the Debian Mono Group and upstream. More about the status and the actual plan how we bring the new suite into Debian you can read at MonoDebianPlan

Wouter Verhelst: Ten ways to make a buildd admin's life miserable.

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'. To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.
  1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
  2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
  3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
  4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
  5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
  6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
  7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
  8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
  9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.
    10. And, last but not least:
  10. Take all of the above too seriously. No, really. It's only a joke.

Next.

Previous.