Re: Inactive mailing lists
On Freitag, 28. April 2023 00:10:25 CEST Nicolas Fella wrote: > Am 27.04.23 um 23:42 schrieb Joseph P. De Veaugh-Geiss: > > Cross-posting to the relevant mailing lists. > > > > To discuss, please answer to kde-community@kde.org. > > ## Currently Inactive With Almost No Previous Activity [5 lists] > > > > * Heaptrack: https://mail.kde.org/mailman/listinfo/heaptrack This list sees basically no traffic, but in general is the recommended channel to talk about heaptrack. Many people instead just contact me directly, which is unfortunate but c'est la vie. I would like to keep the list open, it doesn't hurt anyone, does it? Thanks -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Montag, 16. Januar 2023 11:12:58 CET Tarcísio Fischer wrote: > Hey, yes, I did start working on an update for the website, but got myself > busy with other things and never finished it (sorry about that). No worries, thanks for your work already! > AFAIR, it was in early stages, since I got trouble making it work with > Hugo. It was not usable since most information was outdated, but the Hugo > part (AFAIR) was working. What is "it" in this context? The drupal to hugo export tool? > I don't know how easy it is to run drupal2hugo, but if hugo's version from > my branch is up to date enough, my branch should be usable. What is the stage of your branch in general - did you take the old website and port it to hugo directly, or did you recreate a new website based on the modern hugo themes other kde websites are using? Did you import any content from the old website yet? Thanks -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Montag, 16. Januar 2023 09:59:51 CET Alexander Zhigalin wrote: > In data 16/01/2023 09:27:59 CET, Milian Wolff ha scritto: > > On Sonntag, 15. Januar 2023 08:04:18 CET Ben Cooksley wrote: > > > Hi all, > > Hello > > > > > > > > In the case of KDevelop and Skrooge, it would make the most sense to > > > convert them both into Hugo websites to minimise the long term > > > maintenance > > > cost and to make them part of the KDE family of sites. > > > If anyone would like to work on this please contact me and I will > > > arrange > > > for a sanitized database copy to be made available to you. > > > > > > In the event that doesn't happen, converting them into static sites > > > seems > > > like the best path forward. > > > > I agree, we really need to make the kdevelop website a static one. One way > > or another, can you please send me the database copy already such that we > > keep that state archived at least? > > > > Do we have a tool or someone with basic knowledge of converting from > > Drupal > > 8 to Hugo? I have limited time for this, but before the website gets nuked > > completely, I'll try to find some time to at least get a basic static > > version out and up and running. But any help would be really appreciated > > on > > that front. > > There are tools or rather helpers because they require manual operations > either before and after the conversion. > I don't have conversion to Hugo experience but I worked both on Hugo and on > Drupal sites and it seems like a reasonably fast job to do so if you need > someone I'm here. > Btw, is someone already working on it? Because all the pages besides home > and downloads are in maintenance right now. I got reminded that Tarcisio (CC'ed) started work on it. But the maintenance mode was enabled to prevent security issues due to the usage of the old drupal installation by Ben. https://invent.kde.org/tarcisiofischer/kdevelop-www Tarcisio, what's the status on that front? Is that already usable to some degree as a quick replacement for the old KDevelop website? What's missing? Thanks -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Sonntag, 15. Januar 2023 08:04:18 CET Ben Cooksley wrote: > Hi all, > In the case of KDevelop and Skrooge, it would make the most sense to > convert them both into Hugo websites to minimise the long term maintenance > cost and to make them part of the KDE family of sites. > If anyone would like to work on this please contact me and I will arrange > for a sanitized database copy to be made available to you. > > In the event that doesn't happen, converting them into static sites seems > like the best path forward. I agree, we really need to make the kdevelop website a static one. One way or another, can you please send me the database copy already such that we keep that state archived at least? Do we have a tool or someone with basic knowledge of converting from Drupal 8 to Hugo? I have limited time for this, but before the website gets nuked completely, I'll try to find some time to at least get a basic static version out and up and running. But any help would be really appreciated on that front. Thanks -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: request | are you keeping (unsupported) hardware in use by running Plasma?
On Freitag, 9. Dezember 2022 14:01:48 CET Joseph P. De Veaugh-Geiss wrote: > - Distro and desktop environment you use, Kubuntu 22.04 LTS with KDE Plasma 5.24 LTS > - hardware information (RAM, etc.), and MacBook Pro from 2009, I forgot the exact model but something along the lines of https://support.apple.com/kb/SP544 > - bonus points if you know that other operating systems have > discontinued support for that hardware (and if possible a link). Afair that machine turned EOL in 2019 with macOS 10.10 Yosemite > Also, feel free to share any stories that may be relevant. For instance, > I convinced my parents some years ago to switch to GNU/Linux when their > previous OS was pushing an update that gave them the unfortunate news > that "This device doesn’t meet minimum system requirements...". They did > not want to buy new hardware since the hardware was still new and worked > just fine. In fact, I believe the laptops were only 3 years old! I got > this email from my mom recently, and I quote: "I am glad that I switched > 95% of the time." It is pretty much that story for me too. The machine above belongs to my father (82 years old) who simply ignored the security issues with running an EOL software for as long as 2022. At some point, a security update on our email provider required a new cypher which was not supported by macOS Yosemite anymore, so he was not able to read emails anymore. Firefox also stopped delivering updates to that OS. I haven't heard anything really bad from him. The biggest issue is probably "it doesn't look exactly like what I used for the last ten years", but he's doing a great job at adapting :) Cheers > Some information about e-waste (to be included in the handbook): > > - E-waste is considered the "fastest-growing waste stream in the world", > with 44.7 million metric tons generated in 2016. [1] This is roughly > equivalent to 4,500 Eiffel towers. [2] > > - In 2018, an estimated 50 million metric tons of e-waste was reported, > motivating the UN to refer to a "tsunami of e-waste rolling out over the > world". [3] > > - The numbers continue to rise: in 2021 an estimated 57 million metric > tons of e-waste was generated globally, a ~25% increase in just 5 years > from 2016. [4] > > - Less than 20% of e-waste is collected and recycled. [5] > > - Although it makes up only 2% of trash in landfills, e-waste > contributes to almost 70% of the toxic waste there. [6] > > [1] > https://www.weforum.org/reports/a-new-circular-vision-for-electronics-time-f > or-a-global-reboot/ [2] > https://www.itu.int/en/ITU-D/Climate-Change/Documents/GEM%202017/Global-E-wa > ste%20Monitor%202017%20.pdf [3] https://news.un.org/en/story/2015/05/497772 > [4] https://www.bbc.com/news/science-environment-61350996 > [5] https://weee-forum.org/ws_news/international-e-waste-day-2021/ > [6] > https://www.forbes.com/sites/vianneyvaute/2019/04/23/with-love-from-an-orego > n-prison-how-eric-lundgren-is-going-to-help-you-recycle-all-your-electronics > / -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Help with sorting out unmaintained repos in the playground
On Dienstag, 7. April 2020 12:14:35 CEST Ben Cooksley wrote: > On Tue, Apr 7, 2020 at 8:48 AM Milian Wolff wrote: > > On Montag, 6. April 2020 11:52:57 CEST Ben Cooksley wrote: > > > On Mon, Apr 6, 2020 at 7:38 PM Milian Wolff wrote: > > > > On Sonntag, 5. April 2020 14:00:50 CEST Bhushan Shah wrote: > > > > > On Sun, Apr 05, 2020 at 04:43:32PM +0530, Bhushan Shah wrote: > > > > > > Hello community, > > > > > > > > > > > > In preparation for upcoming move of KDE repositories to Gitlab we > > > > > > sysadmins wants to move the unused/inactive repositories to > > > > > > unmaintained/. > > > > > > > > > > > > Current list of all repositories: > > > > > > https://phabricator.kde.org/T12916 > > > > > > > > > > Sorry for wrong wording here, but this list contains *all* > > > > > playground > > > > > repositories, idea is to remove the maintained repos from this list, > > > > > so > > > > > in end only unmaintained remains. > > > > > > > > What will happen to unmaintained repos? Will they be removed? There > > > > are > > > > quite a few in there, which are dead but I would like to keep for > > > > archiving purposes. If KDE's repositories are not the right place for > > > > this, I'll move them to GitHub? Or is there a better solution? > > > > > > They will be imported into Gitlab, and then archived. > > > Archiving a project in Gitlab makes it read-only and removes it from > > > the normal search processes but still leaves it accessible should you > > > be looking for archived projects (or have the url for that project to > > > hand) > > > > And where could we place repos that may just see a commit every few months > > to keep them compiling but being otherwise unmaintained? I.e. read-only > > won't cut it for e.g. kdev-css as apparently it's otherwise somewhat > > usable or so I heard. > > Then that isn't really unmaintained, as people are looking after it > still, even if it is very infrequently. > > The repositories we are trying to eliminate are those that: > a) Haven't been touched in a very long time; or > b) Never made the move to Qt 5 / KF5; or > c) No longer compile and have nobody interested in fixing this > > The ones you say are 'dead' should meet the criteria above, while the > KDevelop ones you are talking about (like kdev-css) do not meet that > criteria. > > > What's the advantage of making a repo read only and archived compared to > > keeping it a "normal" playground app? Is CI or similar being run > > regularly? > > Could this be disabled instead on these repos? > > The advantage of archiving a repository is that it no longer clutters > up the normal list of repositories people view. > Once archived, it is being kept as a historical record (including > reviews, tasks, etc associated with it), with the possibility of it > being restored to being active again easily enough. > > The objective of this is to make active projects more discoverable and > visible while preserving our history for future reference. > > The projects you are discussing here do not meet the criteria of being > unmaintained, and should in an ideal world (if they're usable) transit > through KDE Review to Extragear. Perfect, thanks for the explanation Ben. With all the above said, I think from the list I had initially, only the following repos are truly dead then (at least in my eyes). > > > > devtools/quanta > > > > devtools/plugins/kdev-control-flow-graph > > > > devtools/plugins/kdev-embedded The others are different levels of undead :) So please keep them in playground: > > > > devtools/plugins/kdev-krazy2 > > > > devtools/plugins/kdev-verapp > > > > devtools/plugins/kdev-valgrind > > > > devtools/plugins/kdev-ruby > > > > devtools/plugins/kdev-xdebug > > > > devtools/plugins/kdev-upload > > > > devtools/plugins/kdev-css > > > > devtools/plugins/kdev-executebrowser > > > > devtools/plugins/kdev-mercurial Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Help with sorting out unmaintained repos in the playground
On Montag, 6. April 2020 11:52:57 CEST Ben Cooksley wrote: > On Mon, Apr 6, 2020 at 7:38 PM Milian Wolff wrote: > > On Sonntag, 5. April 2020 14:00:50 CEST Bhushan Shah wrote: > > > On Sun, Apr 05, 2020 at 04:43:32PM +0530, Bhushan Shah wrote: > > > > Hello community, > > > > > > > > In preparation for upcoming move of KDE repositories to Gitlab we > > > > sysadmins wants to move the unused/inactive repositories to > > > > unmaintained/. > > > > > > > > Current list of all repositories: https://phabricator.kde.org/T12916 > > > > > > Sorry for wrong wording here, but this list contains *all* playground > > > repositories, idea is to remove the maintained repos from this list, so > > > in end only unmaintained remains. > > > > What will happen to unmaintained repos? Will they be removed? There are > > quite a few in there, which are dead but I would like to keep for > > archiving purposes. If KDE's repositories are not the right place for > > this, I'll move them to GitHub? Or is there a better solution? > > They will be imported into Gitlab, and then archived. > Archiving a project in Gitlab makes it read-only and removes it from > the normal search processes but still leaves it accessible should you > be looking for archived projects (or have the url for that project to > hand) And where could we place repos that may just see a commit every few months to keep them compiling but being otherwise unmaintained? I.e. read-only won't cut it for e.g. kdev-css as apparently it's otherwise somewhat usable or so I heard. What's the advantage of making a repo read only and archived compared to keeping it a "normal" playground app? Is CI or similar being run regularly? Could this be disabled instead on these repos? Thanks a lot > > There are a few in there which should probably transition through > > kde-review since they are already used by people. But there is noone with > > the resources to maintain them for real... So what should we do? > > > > devtools/plugins/kdev-verapp > > devtools/plugins/kdev-valgrind > > devtools/plugins/kdev-ruby > > devtools/plugins/kdev-xdebug > > devtools/plugins/kdev-upload > > devtools/plugins/kdev-css > > devtools/plugins/kdev-executebrowser > > devtools/plugins/kdev-mercurial > > devtools/plugins/kdev-embedded > > devtools/plugins/kdev-krazy2 > > devtools/plugins/kdev-control-flow-graph > > devtools/quanta > > > > Having them in playground was a nice way to create something that may or > > may not work, quasi the "use on your own risk" place for code with no > > guarantees... Or something which only worked for the person working on it > > at some time. > > Cheers, > Ben > > > Cheers > > -- > > Milian Wolff > > m...@milianw.de > > http://milianw.de -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Help with sorting out unmaintained repos in the playground
On Sonntag, 5. April 2020 14:00:50 CEST Bhushan Shah wrote: > On Sun, Apr 05, 2020 at 04:43:32PM +0530, Bhushan Shah wrote: > > Hello community, > > > > In preparation for upcoming move of KDE repositories to Gitlab we > > sysadmins wants to move the unused/inactive repositories to > > unmaintained/. > > > > Current list of all repositories: https://phabricator.kde.org/T12916 > > Sorry for wrong wording here, but this list contains *all* playground > repositories, idea is to remove the maintained repos from this list, so > in end only unmaintained remains. What will happen to unmaintained repos? Will they be removed? There are quite a few in there, which are dead but I would like to keep for archiving purposes. If KDE's repositories are not the right place for this, I'll move them to GitHub? Or is there a better solution? There are a few in there which should probably transition through kde-review since they are already used by people. But there is noone with the resources to maintain them for real... So what should we do? devtools/plugins/kdev-verapp devtools/plugins/kdev-valgrind devtools/plugins/kdev-ruby devtools/plugins/kdev-xdebug devtools/plugins/kdev-upload devtools/plugins/kdev-css devtools/plugins/kdev-executebrowser devtools/plugins/kdev-mercurial devtools/plugins/kdev-embedded devtools/plugins/kdev-krazy2 devtools/plugins/kdev-control-flow-graph devtools/quanta Having them in playground was a nice way to create something that may or may not work, quasi the "use on your own risk" place for code with no guarantees... Or something which only worked for the person working on it at some time. Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Applications Lifecycle Policy
On Wednesday, July 5, 2017 12:06:50 AM CEST Ingo Klöcker wrote: > On Tuesday 04 July 2017 23:34:20 Christian Mollekopf wrote: > > What I meant to propose was more that instead of being initially in a > > temporary location, > > and then having to choose one of "proper" ones and go through review, > > we would instead > > start with a permanent location and then you "could" become part of a > > release with requirements > > and therefore review. In general I just think the barrier to release a > > project from KDE infrastructure > > should be lowered not raised. > > To me this sounds as if you want the KDE infrastructure to become a > dumping ground for low-quality, untranslated stuff, i.e. just like > github except with the KDE badge. Yes, I'm exaggerating, but essentially > that's how I understand what you are saying. > > I agree with Albert, Ben, and Luigi, that we (at least the four of us) > don't want this. +1 -- Milian Wolff m...@milianw.de http://milianw.de
Re: [kde-community] Changes to mailing list behaviour
On Dienstag, 2. August 2016 19:56:33 CEST Jos van den Oever wrote: > On Tuesday 02 August 2016 14:16:35 Milian Wolff wrote: > > > We'll therefore be disabling stripping of any attachments or html > > > bodies, modification of mail subjects, and removing any mail headers > > > or footers which the list is adding into any mails. This will be made > > > globally across all lists on kde.org infrastructure some time in the > > > next week or two. > > > > Does this include the List-Id headers etc. used for filtering of mailing > > list emails? > > Adding headers such as List-ID to mails is not a problem for DKIM. A DKIM > singed mail will have a header DKIM-Signature which contains a field 'h'. > For example: > > h=from:to:subject:date:keywords:keywords; > > Only the headers listed in the 'h' field are part of the DKIM signature. > Those headers may not be changed and no additional header with the same > name may be added. In the above example there should be two headers > 'keywords', no more no less. > > If the original sender includes 'list-id' in the 'h' field the mail should > be rejected by the mailing list. Thank you for the explanation. Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Changes to mailing list behaviour
On Tuesday, August 2, 2016 10:49:18 PM CEST Ben Cooksley wrote: > Hi all, > > Just a heads up on an upcoming change. > > As mentioned in an earlier thread, we'll need to change a series of > settings on our mailing lists in order to maximise compatibility with > mail providers which have enabled DMARC for their domains. > > Any changes the mailing list makes to an email, such as to the > subject, mail body or certain headers (which varies from provider to > provider) can cause breakage of DKIM signatures, and therefore a DMARC > validation failure. > > Validation failures can result in messages being bounced or bulk > (spam) foldered by recipients of messages, and likely harms the > reputation of KDE.org mail infrastructure as well (impacting > deliverability for all email). By altering messages and causing these > failures, we effectively exclude people from our community simply > because of decisions taken by their mail provider. > > We'll therefore be disabling stripping of any attachments or html > bodies, modification of mail subjects, and removing any mail headers > or footers which the list is adding into any mails. This will be made > globally across all lists on kde.org infrastructure some time in the > next week or two. Does this include the List-Id headers etc. used for filtering of mailing list emails? Thanks -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] thank you for Akademy
On Wednesday, July 29, 2015 01:39:18 PM Carl Symons wrote: > Thanks to everyone who contributed to making Akademy happen. > > I especially appreciate Kenny Duffus (seaLne) and Kenny Coyle > (automatical) who devote a lot of time and effort on Akademy throughout > the year. > > Both of them work on the registration system, although it's mostly Kenny > Coyle's baby. The responses to questions and glitches were quick and > effective. > > Kenny Duffus... > The mainspring of Akademy. For years. Working on all manner of Akademy > stuff. Especially looking out for making the experience unforgettable > for attendees. Yes, thanks to everyone involved. Once again, it was a pleasure to attend and it was extremely productive, with food being taken care of and such. 10/10, would attend again :) Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Your Akademy take-away?
On Friday 12 September 2014 14:02:39 Lydia Pintscher wrote: > Hey folks :) > > What are the most important things you took away from this year's Akademy? Personally, I think our community is highly social, inclusive and diverse - i.e. awesome. And while I also think that technically our software is of relatively high quality as well, I agree with Kevin O. that all of us should try to aim for an even higher quality. We have many extremely talented people in our community, which teach others to the best of their abilities. The trend of doing more code reviews is going into the right direction there, and I hope to see more of that happening. We should all strive for concise, clean code with many unit tests, which ensures our code stays working and greatly simplifies the maintenance burden. And, while working on new shiny things is often very gratifying, I hope to see more people working on cleaning up our old heritage code base. Cheers everyone, rock on! I'm looking forward to see you all next year again :) Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday 26 August 2014 09:29:02 Thiago Macieira wrote: > On Tuesday 26 August 2014 15:28:09 Aaron J. Seigo wrote: > > > Simple frameworks > > > support list for random people who are not involved with KDE in any way > > > and > > > don't care about development (of any kind) inside of the community, but > > > are > > > just looking for support and possibly willing to offer support too, > > > > Yes, that's what kde-devel is supposed to be for. If we take away the > > review board email, much of the traffic is exactly that. > > My suggestion: use qt-inter...@qt-project.org for supporting people who want > to just use KF5, without developing it. > > That would leave kde-devel for what it's been used for the past 15 years: > discussing development of applications that are tightly integrated with > KDE's desktop environment (i.e., Plasma desktop). I like that suggestion! -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Berlin - Brno road trip
On Wednesday 18 June 2014 11:00:00 Patrick Spendrin wrote: > Am 10.06.2014 20:28, schrieb m...@milianw.de: > > Hey all, > > > > those of you who plan to go to ackademy this year and wants to go > > by train from berlin, please raise your hand. There is apparently > > at least 4 of us who also need to attend the general assembly. What > > about sharing the trip? > > > > Interested are at least : Lydia Andreas Patrick (from Dresden) > > Paul > Mirko > Volker > > > Me > > > > Bye > > I looked at Deutsche Bahn and there is a direct train from Berlin to > Brno on the 4th (thursday, remember on friday is e.V. GA) > starting at 12:46 > Dresden at 15:06 > arrival at 20:19 > > cost 41,60 EUR p.P. > > I don't think the train has WIFI access and enough power though (we > might have to find a solution for that :-D). > > If everybody is ok with that, I can go get those tickets at the > counter (and you reimburse me later via bank transfer). > If somebody else wants to take part, please speak up soon! I just booked this via the Bahn.de website for ~60€ (with a Bahncard 25): Berlin Hbf (tief) 04.09. ab 12:46 3 EC 177 Brno hl.n. 04.09. an 20:19 Brno hl.n. 12.09. ab 13:39 EC 170 Berlin Hbf (tief) 12.09. an 21:15 6 I did not reserve a seat yet. If more people book this connection, we should/could reserve multiple seats in one go to ensure we sit next to each other on the trip :) Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Monday 04 August 2014 20:36:44 Vishesh Handa wrote: > Hello people > > Random Idea: How about we close the k-c-d mailing list? It's main purpose > used to be to discuss kdelibs changes, but now since we have > kde-frameworks, the mailing list seems less useful. We already have > kde-devel for other generic kde stuff. So far, kdelibs is still open for patches, no? So I'd say let's keep it until we stop accepting patches for kdelibs. Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Berlin - Brno road trip
On Wednesday 18 June 2014 11:00:00 Patrick Spendrin wrote: > Am 10.06.2014 20:28, schrieb m...@milianw.de: > > Hey all, > > > > those of you who plan to go to ackademy this year and wants to go > > by train from berlin, please raise your hand. There is apparently > > at least 4 of us who also need to attend the general assembly. What > > about sharing the trip? > > > > Interested are at least : Lydia Andreas Patrick (from Dresden) > > Paul > Mirko > Volker > > > Me > > > > Bye > > I looked at Deutsche Bahn and there is a direct train from Berlin to > Brno on the 4th (thursday, remember on friday is e.V. GA) > starting at 12:46 > Dresden at 15:06 > arrival at 20:19 > > cost 41,60 EUR p.P. > > I don't think the train has WIFI access and enough power though (we > might have to find a solution for that :-D). > > If everybody is ok with that, I can go get those tickets at the > counter (and you reimburse me later via bank transfer). > If somebody else wants to take part, please speak up soon! Sounds good. I have a Bahncard 25. What about the way back though? Isn't it cheaper to book both directions in one go? If so, maybe all of us should just book this on our own? Or is there a group rebate? Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
