teamwork, or: why I love the Debian Perl Group:

elbrus has introduced a (very untypical) package into the Debian Perl Group in 2022.

after changes of the default compiler options (-Werror=implicit-function-declaration) in debian, it didn't build any more & received an RC bug.

because I sometimes like challenges, I had a look at it & cobbled together a patch. as I hardly speak any C, I sent my notes to the bug report & (implictly) asked for help. – & went out to meet a friend.

when I came home, I found an email from ntyni, sent less than 2 hours after my mail, where he friendly pointed out the issues with my patch – & sent a corrected version.

all I needed to do was to adjust the patch & upload the package. one more bug fixed, one less task for us, & elbrus can concentrate on more important tasks :)
thanks again, niko!

high noon in 2023, from my webcam's point of view:

in the Debian Perl Group we are maintaining a lot of packages (around 4000 at the time of writing). this also means that we are spending some time on improving our tools which allow us to handle this amount of packages in a reasonable time.

many of the tools are shipped in the pkg-perl-tools package since 2013, & lots of them are scripts which are called as subcommands of the dpt(1) wrapper script.

in the last years I got the impression that not all team members are aware of all the useful tools, & that some more promotion might be called for. & last week I was in the mood for creating a short demo video to showcase how I use some dpt(1) subcommands when updating a package to a new upstream release. (even though I prefer text over videos myself :))

probably not a cinematographic masterpiece but as the feedback of a few viewers has been positive, I'm posting it here as well:

(direct link as planets ignore iframes …)

high noon in 2022, from my webcam's point of view:

high noon in 2021, from my webcam's point of view:

high noon in 2020, from my webcam's point of view:

high noon in 2019, from my webcam's point of view:

I plan to go to two upcoming debian/FLOSS events, & I'd rather go by train than by plane or car. & that's quite difficult, in central europe, in 2020.

the events I want to go to are:

• FOSDEM, the "free & open source developers' european meeting", the probably hugest FLOSS conference in europe, held in bruxelles, belgium; with a MiniDebCamp before.
• SnowCamp, a small cosy DIY MiniDebCamp in laveno-mombello, italy.

now what about the trains? bruxelles is the capital of europe, & laveno-mombello is just approx. 400 km from here (i.e. closer than the capital of my country). still, no train company would sell my a ticket to these destinations.

no train company? well that's slightly exaggerated. for one of the destinations (bruxelles), one company (DB) would sell me a ticket, if I trick the web interface into showing me the connection I want by adding some 'via' entries with appropriate durations. ÖBB fails because it doesn't sell thalys tickets, & also no ICE tickets, for the last leg. – so either DB with some trickery, or ÖBB plus either thalys or DB, & hope that there are no delays.
ÖBB is also very proud of their new nightjet connection to bruxelles (from vienna & innsbruck), starting in january 2020. what they don't announce widely is that this train goes only 2 times per week. (of course not the days I need.)

for the trip to laveno-mombello I could either go via verona/milano & buy a ticket from ÖBB until verona & a ticket (actually three) from trenitalia for the rest; or go via switzerland & buy a ticket from ÖBB until bellinzona, a ticket from SBB for the 10+ minutes to cadenazzo, & a ticket from trenord from cadenazzo until laveno-mombello. (that's already the summary; neither ÖBB nor DB nor SBB nor trenitalia nor trenord would sell me a ticket for the whole journey. trenitalia also doesn't know cadenazzo, btw. ÖBB would also sell me a ticket to cadenazzo, it's just roughly 100 EUR more expensive than the sparschiene-ticket to bellinzona.)
two years ago I did the former; & 8 of the 8 trains were delayed on departure or arrival or both. obviously the trip with its three changes per direction took almost twice the time of just taking the car.
last year, a friendly soul picked me up with their car after one train trip, & probably we'll do it the same way again this year.

so what is it that I want to say?

first of all I'm looking forward to the MiniDebCamp+FOSDEM & to SnowCamp, & I thought I should promote those events a bit more :)

& second, the state of train companies in europe is a big FAIL:

• ÖBB & DB on the one hand, & trenitalia on the other hand have some fight since a couple of years; they don't even list each others' train connections in their respective online schedule, let alone offer tickets; & there are also less&less connections on the münchen/innsbruck/verona route;
• ÖBB (in its terrible new app/website) happily shows connections for which they then don't sell tickets ("attention: ticket only covers part of the journey");
• SBB & DB happily let you spend lots of time in their online ticket webapps, & then are very sorry in the end that they can't sell you the ticket you've clicked together;
• I'm aware that there are still "national" train companies, & that there are still so-called "borders" between so-called "nation states" but frankly, I don't care about either;
• mostly because those virtual lines on the maps have no significance to me; but also practically because in a part of the world where there are so many of them close to each other it's just ridiculous that they have any practical impact on travelling by public transport (remember, going to laveno-mombello via the "west route" I go through austria, liechtenstein, switzerland, & italy; for just roughly 400km);
• I mean there's schengen, & at least until 2015 noone asked for any passports on these routes; still the train companies have the tunnel vision of their "national" territory;
• I don't want to spend literally hours on more or less (typically more) broken train company websites to find out about possible connections & typically find no possible tickets for those connections;
• if I want to go from A to B in europe, I want to go to one website & just buy the <insert-appropriate-adjective-here> ticket there;
• either one of the legacy national ones or a combined european train system website (btw, rail_dot_eu & train_dot_eu are both squatted);
• & don't tell my about trainline.eu etc., they don't know about half of the existing connections;
• interim summary: can I please just buy a train ticket? could you please just take my money?;
• in the end this is a political question. the EU has regulated roaming mostly successfully (crossing the swiss border: calls 2 EUR/min. out, 1 EUR/min. in, sms: 0.4 EUR, data: 1.5 EUR/100kb (!));
• it's about time that the EU regulates "cross-border" train travel as well;
• & I'm not talking about prices, I JUST WANT TO BUY A TICKET FROM A TO B ON ONE WEBSITE; pretty please; in europe; in 2020.

ok, end of rant.
& I'm looking forward to the aforementioned events, even if it's a major pain to sort out the transportation to get there.
(could we have teleportation please? the quantum physicists say no. too bad.)

update 2020-01-06: for the trip to bruxelles, I ended up buying a nightjet ticket from ÖBB, & a thalys ticket directly from thalys. let's hope I don't miss a connection …

finally – the third call for vote has already gone out – I took the time to cast my vote in the debian init system GR (General Resolution), the vote of debian members about the project's further course with regard to init systems.

for those you care about others' opinions before the poll closes: I voted H > G = D > F = E > FD > B > A, & here's why (note that I don't claim that this is necessarily 100% logically consistent):

• H is a combination of guillem's principles, which I share, & ian's rather detailed guidance on how to proceed in the spirit of enabling a compromise & make progress together. that makes most sense to me.
• G is guillem's proposal with his original principles & a short guidance section that explains why no more detailled guidance makes sense. on the one hand, I prefer more guidance in order to help e.g. the policy editors (that's why I ranked H higher), on the other hand, I still agree with the text & think that it could work, at least if we concentrate on cooperation.
• D is ian's proposal with the detailed processes; since I liked them in option H, I still like them even without the principles, just a bit less :)
• why did I rank G & D equally? I guess that was basically my gut telling me to do so … in any way, I prefer H & G & D clearly more than the other options:
• F & E are the "extreme" positions in this vote ("focus on sytemd" vs. "all init systems must work"). I'm not a big fan of of either of them, as I favour a future which gives everyone their space within debian. still I ranked them over FD (further discussion) because a clear direction seems more useful to me than dragging this discussion on. & I ranked them equally because personally I could live with both of them (yes, init systems are not a matter totally close to my heart …).
• B & A ended up below FD in my ballot (i.e. "better no result than this one") because I don't see what new they would bring to the ballot, not already covered in the other options; I find them a bit hard to read (as in "what consequences would they really have?"); & I much dislike the mingling of NMUs (non-maintainer uploads) with a GR about init systems in option A.

finally, thanks to all the people who worked hard to prepare this GR & did the work to come up with the various options; let's see if I change my vote (& this blog post) in the remaining days; & in any case, we'll soon (after Friday 2019-12-27 23:59:59 UTC) see the results, first on the secretary's voting page & on the debian-vote mailing list.

this was 2018, from my webcam's point of view: