Re: Bringing Cantata under the KDE umbrella?
Hey, I really would love to see Cantata to be in KDE. At least try if it gets some momentum. But still you are doing the Qt6 port, so without any new features just in maintenance mode I see value in it. > features like cached lyrics, lastfm, wikipedia, serverside playlists > software written to export lyrics so that they are present when you > switch to info-mode Oh all those features can be interesting for other music players, too! So maybe together with the other music players in KDE we can form an API and library and we only have one place to write it ;) Regards, sandro
Re: Please cleanup your scratch and clone repositories
Moin, > Done. one deleted one created :) I was not that effective. But I'll hopefully can delete the last one within the next days... Best Regards, sandro
Re: Draft Policy: Dependency Changes and CI
Hey, thanks for writing this down! > this month, a heated exchange on kde-core-devel about a dep > change breaking CI has moved us to draft a new policy to better > handle situations like this in the future. Hopefully. The first two paraphrases are okay For me the whole text sounds to bureaucratic and too many "you can do this after waiting that long" . Can't the whole process described like following: * You should plan at least two weeks for a dep bump on CI. * If a developer knows or think about bumping a dep (any dependency of this software that is not created by any other KDE group) she/he should get in contact with sysadmins beforehand as soon as possible to sort things out. You can reach sysadmins, by adding the "Sysadmins" group on Phabricator to reviewers review requests or file a separate sysadmins ticket on Phabricator. * Sysadmins normally react within two weeks and can tell how long it will take to update the dep on CI. This can take some hours for very easy updates up to several weeks for deps, that affect more/nearly all packages f.ex. Qt. * Under special circumstances (e.g. urgency prior to a freeze), exception requests should be raised in an established venue such as release-team or kde- core-devel. In general, changes that fellow developers can't be convinced of are probably not a good idea. * Keep in mind if you don't get in touch with sysadmins, than the CI will be RED. Also after multiple times not informing sysadmins beforehand and giving time to sort things out, sysadmins may decide to kick the project from CI completely. Best Regards, sandro
Re: kio-stash is in KDE Review
Hey, > Not too sure what is going on with that part - I also did 'gpg2 > --send-keys 2A7D2DAE'. However, it doesn't show up when I search for > it on keys.gnupg.net Well you should maybe define the keyserver, than you know where it is :) I Personally prefere the sks-keservers.net: gpg --keyserver hkp://pool.sks-keyservers.net --send-key they also have a TLS version, to use that see: https://sks-keyservers.net/overview-of-pools.php But you are free to use any other keyserver and know what keyserver you are using :) Best Regards, sandro
Re: Easy, encrypted transfer of larger files over third party server
Hey, why using a third-party server if you can directly share a file form your computer securely without any size limit? OnionShare creates a tor hidden service and this you can share and the other can download the file directly via tor for your computer. https://onienshare.org http://elx57ue5uyfplgva.onion/ At least for many usecases it is also a nice solution, where you don't need a server to upload the file. The person who is receiving the files doesn't need OnionShare. All they need is to open the URL you send them in Tor Browser to be able to download the file. Best regards, sandro -- On Dienstag, 3. Oktober 2017 23:45:53 CEST Albert Astals Cid wrote: > El dimarts, 3 d’octubre de 2017, a les 13:36:47 CEST, gregor.mi.sw va > > escriure: > > Hello, > > > > since the day I started to use email, every now and then I would like to > > send someone a large file (big or several images, large presentation, > > audio > > or video file) that does not fit in an email or vice-versa. > > > > Nowadays, there are plenty of free online storages and transfer services > > (e.g. https://wetransfer.com/, DropBox etc.). If I don't know the owner of > > those services, from a privacy standpoint they all cannot be trusted. > > > > I would like to hear your opinion on the following idea: > > > > Why not having a local program for the sender and receiver that > > automatically does local encryption before uploading to a storage server > > and decryption upon receiving and then deleting from the remote storage > > server? The idea is to have a stable local user interface while the > > storage > > server (let's call it "exchange point") can be easily replaced when > > needed. > > > > The assumed exchange point capabilities should be minimal (list files, > > > > upload file, download file, delete file). > > > > (The exchange point could even be an IMAP email server (with shared > > credentials) which means the local program should know about maximum email > > attachment file sizes and split the file accordingly without bothering the > > user. Or a local network drive.) > > > > The basic workflow for two new users A and B would be: > > > > User A: Installs the program, setups an exchange point, sends B the > > configuration to the exchange point, uploads the file > > User B: Installs the program, imports the configuration, downloads the > > file. > > > > Once the exchange point configuration is shared, sending further files is > > only a matter of selecting the user and dropping the file. Since the > > program would have a CLI it could be integrated in other chat or email > > programs. > > > > About two years ago, I started to develop a program that should do exactly > > that. It's called "asr - async send receive" (Code: > > https://cgit.kde.org/scratch/gregormi/asr.git/tree/, some thoughts about > > it: > > https://github.com/feinstaub/feinstaub.github.io/blob/master/asr/index.md, > > "async" because sender and receiver should not be required to be online at > > the same time). Due to lack of dedicated time the development also came to > > a stop two years ago before I could refine the CLI and add a usable GUI. > > > > I am aware of this good new feature in NextCloud: > > https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-> > > > en d-encryption/. But this would restrict online storage servers to those > > which have NextCloud installed. > > > > From the server side's perspective, this could be a security nightmare > > because one way of using a service like Dropbox as exchange point is to > > share the account credentials between sender and receiver. From the user's > > perspective, in case the used account is shut off, one can switch easily > > to > > another exchange point. > > > > Target users: users who want to securely exchange files but without the > > knowledge or resources of how to setup an own online server. > > > > I wonder if it makes sense to you to further pursue this idea. Are or were > > there maybe similar approaches? > > Not sure if https://send.firefox.com/ may be something you may be interested > in? Maybe a command line client for it? > > Cheers, > Albert > > > Or existing online services that also do > > encryption in trustable fashion and have a CLI? > > > > Thanks for your feedback. > > > > Gregor
Re: Dependent review requests
Hey, I asked the same in private before and got this answer from Renato. But I haven't used it till now... > I saw that you have managed it to get something like "stack" inside a > Review Request. Like in https://phabricator.kde.org/D8434 (see attachment). > Can you tell me how to get such a nice dependency tree for Review Requests? > > Best Regards, > Sandro this was a trick that one of my co-works told me: I edited my ".gitconfig" adding: post-review = rebase -i -x \"arc diff --head HEAD HEAD~1 && arc amend\" Then I can use: git post-review that will start a rebase process and will add "arc diff ..." after each commit allowing me to remove if or not. -- On Donnerstag, 25. Januar 2018 16:04:03 CET Harald Sitter wrote: > On Thu, Jan 25, 2018 at 3:00 PM, Michael Heidelbach wrote: > > Hi! > > > > When I do > > > > git checkout -b A origin/master > > > > (changes) > > > > git checkout -b B A > > > > (changes) > > > > > > git checkout A > > > > arc diff > > > > git checkout B > > > > arc diff > > > > Will phabricator show the relation of A and B? Is that a reasonable > > approach, anyway? > > Kind of. It's a bit fiddly but better than nothing I suppose... > > See git:branch-unique(*) docs > https://secure.phabricator.com/book/phabricator/article/arcanist_commit_rang > es/ > > git co master > git co -b feature > ... > arc diff --base 'git:branch-unique(master)' > git co -b subfeature > ... > arc diff --base 'git:branch-unique(master)' > > Will create two different revisions. The first with the diff from > master to feature and the second from feature to subfeature, via the > webui you can then mark one revision as parent/child of the other > which then makes them appear in order in the 'Stack' table above the > diff. > > e.g. > https://phabricator.kde.org/D10094 > > note: for this to work you need to rebase feature onto subfeature > whenever feature changes, the commits ancestry must be identical so > arc can determine the base branch. > > HS
Re: March 15, 2018: KDE Applications 18.04 Dependency Freeze
Hey, > I should have known, but had forgotten the term 'dependency freeze'. To > be sure: I can still submit review requests but shall not land them > before 5. April? What will happen, when I (inadvertently) brake a > dependency freeze? you can do everything. Create, accept, delete review requests the whole time. You only need to make sure, that the versions of external dependencies is changing. If you summit a Review request that breaks the "dependency freeze" it is a good idea to mention this in the RR. sandro
Re: kdesrc-build and gpgme
Hey, > I have many problems with gpgme compiling and it looks like, it is not > able to use the qt5 env provided in kdesrcbuildrc, but system one. And > then, fails to compile. > > how to solve this issue ? You should first check if you are using the uptodate repo for gpgme from git://git.gnupg.org/gpgme.git As gpgme is not anymore a KDE product you do not need to build gpgme anymore from within kdesrc-build. But if you need gpgme master branch, than ask Andre as he is part of upstream gpgme. hefee > bin/sh ../../../libtool --tag=CXX --mode=compile g++ -std=c++11 > -DHAVE_CONFIG_H -I. -I/home/sancelot/kdesrc/gpgme/lang/qt/src -I../../.. > -I/home/sancelot/kdesrc/gpgme/lang/cpp/src -I../../../src > -I/usr/include/qt5/QtCore -I/usr/include/qt5 -fpic > -I/home/sancelot/kde-latest/include -I/home/sancelot/UTILS/include > -DBUILDING_QGPGME -g -O2 -Wall -Wextra -Wno-shadow -MT job.lo -MD -MP > -MF .deps/job.Tpo -c -o job.lo > /home/sancelot/kdesrc/gpgme/lang/qt/src/job.cpp > libtool: compile: g++ -std=c++11 -DHAVE_CONFIG_H -I. > -I/home/sancelot/kdesrc/gpgme/lang/qt/src -I../../.. > -I/home/sancelot/kdesrc/gpgme/lang/cpp/src -I../../../src > -I/usr/include/qt5/QtCore -I/usr/include/qt5 -fpic > -I/home/sancelot/kde-latest/include -I/home/sancelot/UTILS/include > -DBUILDING_QGPGME -g -O2 -Wall -Wextra -Wno-shadow -MT job.lo -MD -MP > -MF .deps/job.Tpo -c /home/sancelot/kdesrc/gpgme/lang/qt/src/job.cpp > -fPIC -DPIC -o .libs/job.o > In file included from /home/sancelot/kdesrc/gpgme/lang/qt/src/job.cpp:147:0: > > Regards, > > Steph
Drop Kopete from Release Service?
Hey, we as Debian maintainer team do not see kopete not more suitable to ship to users, as it does seem dead from KDE side and additionally jingle stuff seems even more dead than the rest of kopete [1]. I also heard that Ubuntu is not happy about the current state of kopete and wished, that they not shipping it. This will end with, that the next Debian stable won't ship kopete anymore. I would highly suggest to drop kopete from release service as long as nobody steps up to care about it. I'm requesting this with a big sigh as a long happy users of kopete. Many thanks for the work people put into kopete but sometimes it is time to say goodbye :( But maybe this mail will motivate people to re-accelerate the momentum. The big blockers we see are: kopete: segfaults when is using libjingle-call https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948987 kopete: FTBFS: error: template with C linkage https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979388 [kopete] crash if I try to join a groupchannel https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941117 Additionally we have some patches on top to at least keep it building, that surely should been added inside KDE. I can create MRs if someone steps up maintaining it: https://salsa.debian.org/qt-kde-team/kde/kopete/-/tree/master/debian/patches Regards, Sandro [1] https://invent.kde.org/network/kopete/-/compare/v18.12.0...v20.12.1
Re: I need some git advice
Hey, > I'd like to commit some changes to the akonadi repo, but my grasp of git is > not firm. The situation is > > * gabrielsf's commits 404bf743 and 805b31cc to master made most autotests > work. I'd like to get them onto the release branch without complicating > future merges of release to master. > > * I have MR 47 that I would like to merge to release and thence to master. > > * In my local repo's branch I cherry-picked gabrielsf's commits and changed > a test. I haven't pushed the test up to my fork of akonadi, but I'd like > to get the change into release and master. > > How should I proceed? You don't have to worry that much about merge conflicts. Because git only do merge of the commits, that were added on the release branch after the last time it was merged. That means, if you solved the merge for commits you don't have to do it afterwards again. So to keep the merge work simple, the best approach is to merge to master often. And in you case you know that the cherry-picked commits are already in master. So you just needs to make sure that the merge won't do anything in master branch. I would suggest to: * merge release to master before you cherry-pick * cherry-pick * merge to master afterwards. If this triggers merge conflicts you make sure that you select the version of master. Or you tell git directly to use the merge strategy ours, but this will simply ignore any change on release branch. git checkout master git merge release/20.12 git checkout release/20.12 git cherry-pick git checkout master git merge -s ours release/20.12 Sandro
Future of k3b - deprecation of wodim/genisoimage
Hey, Debian will stop shipping cdrkit (wodim/genisoimage) with the next but one release named bookworm [1] ( so we are talking about something like 2-3 years). Keep in mind, that Debian is the upstream author of cdrkit. They ask every user to replace cdrkit with something else like xorriso. As upstream will gone away - it will effect every distribution sooner or later. k3b is currently using wodim, but k3b is currently in low level bugfixing mode and replacing wodim/genisoimage is out of scrope for the current maintainer [1]. So any help is welcomed! hefee [1] https://bugs.debian.org/982221 [#432684] https://bugs.kde.org/show_bug.cgi?id=432684 signature.asc Description: This is a digitally signed message part.
Re: Merge stable to master vs cherry-picking
Hi, > > Fixing it in master means i have to build a zillion of repositories before > > even trying to start fixing the bug, it may also happen that once I built > > master i can't reproduce the bug because master has been fixed for various > > reasons (re-architecture, fixed the bug and forgot to cherry-pick, etc) > > Fixing it in the stable branch is much easier, just build the kmail repo > > and fix the bug. I fully agree: merge stable is much clearer and easier. > Maybe I'm missing something but in case which You described, You will still > need to build all that from master branch to propose patch from stable to > master. Otherwise how You will know if patch needs to be in master or maybe > it's already fixed in other way there? Well for kdepim master means: I need the newest KDE Frameworks available, my distro is not that fast shipping them every month. Than I need to build the complete pimstack, as you cannot mix different version. This is a lot of work just to fix one bug I know that isn't addressed ;) And the bugs are nasty when you only see them once in while, so you need to run your fix for several days to make sure something is fixed. That's why it is that hard to run it from master branch. I think that the entrace barrier is higher, when we only have cherry-picking and that means that even less people are able to fix kdepim. I think especially for newcommers and drive-by committers it is much easier to be able to just rebuilt one repo instead of a complete stack. My gut feeling is that git is smarter when you merge than cherry-pick. If there are renames or code refactoring happing in master than merge strategy is more reliable. At least I get often very small issues when merging stable. One big argument against cherry-picking is that you are never know if everything is inside master because the branches have differnt commits. When merging stable to master, than you can be sure that everything changed on stable is in master. Cheers, sandro
Genderidentity
Sorry, that follow the side discussion, that has not connected to the translation problem in first place. > yes, the aim is to have 2 distinct sets for the pedagogical point of view, > it's a bit more complicated. Me personally is not and was never ok with the gender the society gave me. And I fight hard against the binary gender thinking everywhere. And I'm very happy that we finally have a third Gender option for official documents in Germany called non-binary (German: Divers). Today I had some with public authorities about something else, but they were aware of this and didn't put me automatically into the binary gender box. I was very amazed. And than I read about this thread, that a program that is made for kids is teaching them the binary gender system and are telling me that is a good thing from a pedagogical point of view: Sorry NO! This is discriminating and making it less likely that we will overcome with the discrimination. I know it is hard but we should find a separation attribute, that is not discriminating e.g. color of cloths. Regards, sandro signature.asc Description: This is a digitally signed message part.
Re: Genderidentity
> What is going on? I need context here. In GCompris they use the sentence "Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of candy equally between them." and I am not happy that gender is used as a separation attribute of to distinct sets. GCompris wants to teach easy arithmetic in this lesson. > > Am Do., 6. Jan. 2022 um 12:20 Uhr schrieb Sandro Knauß : > > Sorry, that follow the side discussion, that has not connected to the > > translation problem in first place. > > > > > yes, the aim is to have 2 distinct sets for the pedagogical point of > > > view, > > > it's a bit more complicated. > > > > Me personally is not and was never ok with the gender the society gave me. > > And I fight hard against the binary gender thinking everywhere. And I'm > > very happy that we finally have a third Gender option for official > > documents in Germany called non-binary (German: Divers). Today I had some > > with public authorities about something else, but they were aware of this > > and didn't put me automatically into the binary gender box. I was very > > amazed. > > > > And than I read about this thread, that a program that is made for kids is > > teaching them the binary gender system and are telling me that is a good > > thing from a pedagogical point of view: Sorry NO! This is discriminating > > and making it less likely that we will overcome with the discrimination. > > > > I know it is hard but we should find a separation attribute, that is not > > discriminating e.g. color of cloths. > > > > Regards, > > > > sandro
Re: Genderidentity
Hey, > There is a time and place to teach kids about the complexity of gender > and I don't think an exercise about arithmetic/counting is the right > place. Fully ACK - I don't want to teach kids the complexity of gender. This exercise is about arithmetic/counting and should concentrate on that. But I also don't need to teach them to seperate people by gender indirectly! Why not use cats and dogs or plants and animals as distinct sets? Than we are not hurting anyone.
Re: [Kde-pim] How does projects migrates to kde5? / Patch to program that is missing in master branch
Hey, I tried to get through the git log to understand what happens to ktimetracker. git magic helps: git log master --stat --diff-filter=D points to this commit from Laurent: commit: cd0ee7e149270ce17d5fdab95b19adc960b80ad8 Author: Montel Laurent Date: Fri May 2 13:37:08 2014 +0200 No dev from very long time, there is alternative in others project. And it's buggy. ^^ So you see the current state is that nobody feels reponsible for KTT and takes care of it. The kdepim team is a very small team, so if apps have no dev that care about it a while, apps will throw away. But this must be not the end of KTT if you care and step up. Than KTT can be getting to life again. Regards, sandro -- Am Mittwoch, 25. März 2015, 18:31:44 schrieb Nikolay Shaplov: > I have, may be a stupid question. Nevertheless I will ask it. > > I have a small patch for KTimeTracker which is part of kde-pim. > > I'd like to send Review Request, but in current master branch of kde-pim > there is no KTimeTracker. There is KTimeTracker only in 4.14 branch. > > > Where should I send Review Request, and why there is no KTT in master? It > will be moved there later, or what? Or it will be abandoned? Should I offer > more pathces, or there is no use? > > I've asked in pim mail list, but got no answer... May be this time I would > be more lucky :-) signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Kde-pim] The Future or KDE PIM Releases
Hey, > What's meant by "KDE Accounts"? well we also had a look into the code. It is a resource that will adds all local users from kde to your kaddressbook. Regards, sandro signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
