Posts Tagged ‘unstable’

Jan Lübbe: Going to DebConf ‘08

Monday, March 31st, 2008


I'm going to DebConf8, edition 2008 of the annual Debian<br />
     developers meeting

I’ve just booked my plane tickets for my first DebConf and if everything goes according to plan, i’ll be there for the whole camp and conference. During the camp i’ll work on getting E17 into unstable and on kvm/libvirt integration if there’s still time left.

Some of the E17/EFL libraries are currently available in experimental. E-DBus and Efreet are next, then we can upload E17 itself.

Neil Williams: deb-gview, dpkg and emdebian-tools

Sunday, March 30th, 2008

OK, been quiet for a few days, at least on the blog, but in accordance with typical behaviour (for me at least) a quiet blog means a lot of things going on elsewhere. The smallest was a fix for deb-gview – combining a fix for opening files in the current working directory with a fix for the imminent dpkg 1.14.17 which modified the .changes file format a bit. That was relatively easy and I’ve uploaded 0.2.1 to unstable. gvfs hasn’t made testing yet so there’s no point in waiting for deb-gview to migrate before 0.2.1.
The largest change? Depends how you define large:

  1. Large number of changes to package files – emdebian-tools 1.0.0
  2. Large effect on Emdebian workload – dpkg 1.14.17

dpkg

dpkg bugs closed – emdebian-tools 1.0.0 pending – dpkg-shlibdeps is now able to look into directories containing libraries used by cross-built binaries provided that the right environment variable are set. Closes: # 453267. dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing value) in case of cross-compilation so that pkgconfig finds .pc files in the directory specific to the target architecture. Closes: # 439979.
These two changes will have a major effect on the overall workload required within Emdebian and give us a sane cross-building environment in Lenny which is ABSOLUTELY £$^£@&*! FANTASTIC. -) Currently, 1.14.17 is in experimental but I’ve installed it on my system for testing purposes so that I can complete emdebian-tools 1.0.0:

emdebian-tools 1.0.0

Now here, I’m making some progress. A bug has been bothering me for some time with how emdebian-tools needs a Debian primary mirror to calculate various dependency information and other apt cache stuff whilst taking into account the host architecture. Simon and I now think that we can do the dependency stuff with a continually updated dpkg-cross repository and I can use libcache-apt-perl for the rest. So whereas dpkg-cross might still exist into Lenny, it is looking like apt-cross might not – at least not as an application. However, I’m not taking that step with emdebian-tools just yet. In the meantime, I’m simply using debconf to replace the automated selection of a Debian Primary Mirror and passing that mirror to apt-cross – something I should probably have setup a while ago.
As well as that bug fix, I’ve added a check to emchain so that users are warned if they don’t actually need to run it, added the mirror support to the various scripts and removed the workarounds now fixed by dpkg.
dpkg-buildpackage -ais usable for nearly all packages once you have dpkg-dev >= 1.14.7. emdebuild >= 1.0.0 is only necessary IF:

  1. You want to modify/update Emdebian patches (not just apply them) – i.e. if you have commit access to Emdebian SVN.
  2. You need the one remaining wrapper: ‘X-Build-Cross-Libtool: yes‘ which is my next main target. This is a package-specific problem and each incidence needs a package-specific solution via an appropriate patch. As such, the wrapper is likely to stay in place in emdebuild for some considerable time – at least until someone can rebuild the entire archive with a test that can identify which packages are still affected.
  3. You want the build checks currently implemented by emdebuild but which I plan to spin out during the life of emdebian-tools 1.x. I want to standardise those build checks and abstract them into possibly a lintian-compatible check set.

Also, there should now be no need for any wrapper scripts that anyone may have devised to mangle LD_LIBRARY_PATH or PKG_CONFIG_LIBDIR – indeed,
explicit support for these within dpkg means that it is to be considered harmful from now on to touch these variables, except possibly in some specific corner cases.

Enrico Zini: OpenStreetMap party at Kaohsiung, Taiwan

Sunday, March 30th, 2008

OpenStreetMap party at Kaohsiung, Taiwan

Apparently, yesterday we had the first OpenStreetMap event in
Taiwan!

We met in a café/restaurant equipped with power plug, wireless
network and overhead projector and we had a bit of an introduction,
chat and lunch.

Then we split in groups and exploited the fact that the newly
built underground (KMRT) system is still free of charge, to spread
around and map around the stations.

Finally, we reconvened at someone’s house to see how to put the
data together, draw roads, tag and upload.

Highlights of the day:

  • Homemade GPS logger How to turn a
    serial GPS into a data logger with 6 hours battery life . Then attach it to your bike using
    magnets from broken hard drives. Totally rocks!
  • Previous OpenStreetMap data was collected by only one person,
    who took the fancy new High Speed Rail from the
    opposite side of the country and joined the party. This also made
    discussion
    about standardising tags for Taiwan
    rather easy.
  • A group of people appeared wielding a number of
    “totally insane in every regard” Garmin GPSMAP units
    : it turns
    out they are a civil action group that goes around mapping
    historical trails, abandoned railroads, aboriginal routes and
    mountain crosses and so on. Apparently, they did not know about
    OpenStreetMap: hopefully they’ll join in.

Technical bits:

  • People with the eeePC The eeePC
    was very popular, and very handy for going around storing tracks,
    as you can just chuck it in one bag. JOSM runs fine, although it
    could really use an interface redesign to fit in the small screen.
    In fact, it could really use an interface redesign to fit in the
    standard 1024×768 screen of my laptop.
  • We could not use the tracks made with the Garmins because we
    did not know we had to do “Setup -> Map -> Lock On Road =
    Off” and it was on by default. Now we know it for next time.
  • Something like a SirfStarIII really helps in a city made mainly
    of very tall buildings with lots of steel and glass. My Sony-based
    cheap gps receiver that worked ok in the Bolognese countryside was
    next to useless here, continously losing the fix and producing a
    crazy zigzagging track of doom, only useful to figure out big long
    straight roads.
  • Geocorrelation of digital camera pictures rocks! Who needs to
    store waypoints when you can just take pictures with the digital
    camera and have them show up as waypoints in JOSM? The trick of
    taking a picture of the GPS time and use that to compute time
    offset is great. Also, we found it easier to just fire up gpscorrelate
    to do the geocorrelation rather than figuring out how the tools in
    JOSM work.

Issues to address:

  • There is a strong need for a zh_TW translation
    plugin of JOSM; I’ll try to find out how to do it and pass on the
    information to who can do it.
  • Road names could be written either in English or in Chinese
    characters. Currently English has been used for the
    name tag because osmarender cannot render Chinese
    characters. There is some planining to create an OSM mirror in
    Taiwan which renders twice, and allows to choose the rendering
    language for the map. I will try to get a planet.osm
    extract for Taiwan that people can use to experiment with this;
    thanks to people in #osm for giving me names of people
    to contact. I will try later after Europe wakes up from this
    even-earlier-than-usual sunday morning.