Re: tasksel's task-kde-desktop seems to be outdated
>> - Does anybody really uses dragonplayer? Shouldn't we recommend vlc >> instead? > > I personally like smplayer a lot +1 -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Request for importing repositories to Salsa group
>>> Could anyone with enough access permissions import git repo [1] to >>> subgroup >>> KDE extras [2] and git repo [3] to subgroup Qt extras [4] and give me >>> Master level of access to these new repos? >>> >>> [1] https://anonscm.debian.org/git/pkg-kde/kde-extras/qtcurve.git >>> [2] https://salsa.debian.org/qt-kde-team/kde-extras >>> [3] https://github.com/tehnick/qconf-debian.git >>> [4] https://salsa.debian.org/qt-kde-team/qt-extras > > qtcurve should be ready. With respect to qconf-debian ¿should it be called > just qconf or qconf-debian is better? "qconf" please. (Other part of URL is enough to inform that this is a debian packaging rules.) Thanks! -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Request for importing repositories to Salsa group
Hi team, Could anyone with enough access permissions import git repo [1] to subgroup KDE extras [2] and git repo [3] to subgroup Qt extras [4] and give me Master level of access to these new repos? [1] https://anonscm.debian.org/git/pkg-kde/kde-extras/qtcurve.git [2] https://salsa.debian.org/qt-kde-team/kde-extras [3] https://github.com/tehnick/qconf-debian.git [4] https://salsa.debian.org/qt-kde-team/qt-extras Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Access level for members of Debian Qt and KDE Team group at Salsa
Hi, >> Ok. In this case I may suggest you to use workflow similar to one in Debian >> Perl Group [1]. They do not add extra members to the main group [2], but >> allow members joining to specific sub-groups (for example, [3]). Though >> it is only in plans; they have not done the migration from Alioth and it >> is not even documented yet. > > Well, as far as we do understand if someone wants to provide a branch for > reviewing then [s]he should be at least Developer, which means commit access. > Not ideal, but a trade off. Of course, feel really free to correct me if I'm > wrong. This is only for a case when member should have push access to the main git repo. But now this is not necessary if we use GitLab feature Merge Requests. Any member of Salsa may "fork" any public git repo in one (or two) mouse clicks. Then do any necessary changes in this "fork" and send Merge Request (MR) in two mouse clicks from web-page of this "fork". Let's look at an example of git repository AliothRewriter [1]: 1) Go to page [1] and click on "Fork". (One more click will be required if you have at least Master level of access in any Salsa group.) 2) Next, in local system: git clone g...@salsa.debian.org:/AliothRewriter.git cd AliothRewriter # For the future: git remote add upstream https://salsa.debian.org/salsa/AliothRewriter.git git pull --all # git checkout -b qt-kde-team nano definitions/qt-kde-team.conf git add definitions/qt-kde-team.conf git commit -m "Update qt-kde-team.conf" git push origin qt-kde-team 3) Go to page [2] --> "Branches" --> "Merge request" --> "Submit merge request" And it is ready! 4) If during reviewing of MR "upstream" has requested any changes, then: nano definitions/qt-kde-team.conf git commit --amend -a git fetch upstream git push origin qt-kde-team -f And thus MR is updated automatically. Very fast and simple way from my point of view. Salsa members who have write access to this git repo may push their commits directly into working branches. In case of independently maintained package a write access should have al least Maintainer and Uploaders. In case of team maintained packages it depends on team rules. If you have another workflow in mind, please share your thoughts in more details. [1] https://salsa.debian.org/salsa/AliothRewriter [2] https://salsa.debian.org//AliothRewriter >> But with *-extras sub-groups the situation is a bit different. For example, >> the "Debian KDE Extras Team" is not a real Debian team where package >> maintainers discuss packaging issues, ask for package "sponsoring", etc.. >> This is just a set of packages in which maintainers decided to to set >> "Debian KDE Extras Team" as Maintainer to accent that package is somehow >> related to KDE (or Qt) and to see it at page [4]. (But nevertheless even >> such approach is more convenient and solid in a long perspective than >> maintaining such packages singly [5].) > > Well, we are shifting a little from this definition (which still needs > writing). The idea would be to follow the python's team rule on > Maintainership: if the Maintainer field has a human being then ask that human > being before comitting, if it has the team then everyone is entitled to > commit. Hmm, a nice idea. I will adopt it in my next uploads. >> 3) As for packages for KDE-extras and Qt-extras: apart from >> described not "core" projects there are a number of projects which are >> developed outside of KDE (or Qt) infrastructure [8], but closely related >> with KDE (or Qt). And they also could (or should) be maintained in Qt/KDE >> Extras Team. > > Mostly "could". As long as it does not interferes with the main reasons of > being (qt and KDE stuff), it's could. Some of them really "should". Few examples from my personal experience: 1) Package xembed-sni-proxy [1]. Project initially have been developed on GitHub [2], but later it was moved in KDE and has become the part of plasma-workspace. 2) Package qtcurve [3]. Project initially have been developed without VCS, then its development was moved to GitHub [4] and now it is a part of KDE [5]. [1] https://tracker.debian.org/pkg/xembed-sni-proxy [2] https://github.com/davidedmundson/xembed-sni-proxy [3] https://tracker.debian.org/pkg/qtcurve [4] https://github.com/QtCurve [5] https://cgit.kde.org/qtcurve.git Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Access level for members of Debian Qt and KDE Team group at Salsa
Hi, >> I think that package maintainers should have a Master level of access >> to be able to create or to import git repos in the group [1]. >> Al least DDs. See Debian Science Team group [2] at Salsa as example. > > Yesterday we decided that, at least for now, only admins will be able to > create repositories. We will grant Master access to the whole group to > people who require it and we admins do trust him/her. Again this is for the > time being, we can always review this decitions later. Ok. In this case I may suggest you to use workflow similar to one in Debian Perl Group [1]. They do not add extra members to the main group [2], but allow members joining to specific sub-groups (for example, [3]). Though it is only in plans; they have not done the migration from Alioth and it is not even documented yet. [1] https://salsa.debian.org/perl-team [2] https://salsa.debian.org/groups/perl-team/-/group_members [3] https://salsa.debian.org/groups/perl-team/modules/-/group_members > I think it is possible to give Master access to specific repos, that should > be the case for people maintaining specific packages in *-extras. I think the Developer level of access or even per-package permissions are fine for packages in KDE, Qt and Third-party sub-groups, because they are maintained by a small group of members. But with *-extras sub-groups the situation is a bit different. For example, the "Debian KDE Extras Team" is not a real Debian team where package maintainers discuss packaging issues, ask for package "sponsoring", etc.. This is just a set of packages in which maintainers decided to to set "Debian KDE Extras Team" as Maintainer to accent that package is somehow related to KDE (or Qt) and to see it at page [4]. (But nevertheless even such approach is more convenient and solid in a long perspective than maintaining such packages singly [5].) Currently in Debian we have a tendency to maintain new packages in teams since the beginning. And I believe that the number of packages in *-extras will be growing in the future. Do you really want to be pulled each time when new git repo is asked to be created there? Or when new uploaders will ask for push access to specific git repos... [4] https://qa.debian.org/developer.php?email=pkg-kde-extras%40lists.alioth.debian.org [5] Main maintainers of a package may be busy or MIA and "team uploads" are more flexible than MNUs. > I did not yet got to publish our results from yesterday, so info might be > missing. I hope to do it soon. Now I see changes at [7]. It has enough info for common idea about results. Few questions and comments: 1) Are you going to import all git repos from [6] to [7] (semi-)automatically? Or package maintainers should do it them-self? 2) I am glad to see that pkg-kde-talk and pkg-kde-extras MLs will stay alive. 3) As for packages for KDE-extras and Qt-extras: apart from described not "core" projects there are a number of projects which are developed outside of KDE (or Qt) infrastructure [8], but closely related with KDE (or Qt). And they also could (or should) be maintained in Qt/KDE Extras Team. . From other side, there are some projects developed inside KDE, which do not use KF5 libraries but are based on pure Qt. . So I suggest do not use the location of source files as a criteria for directing packages into KDE-extras or Qt-extras sub-group, but use their dependencies for this purpose. [6] https://anonscm.debian.org/git/pkg-kde/kde-extras/ [7] https://salsa.debian.org/qt-kde-team/kde-extras [8] Yes, quite often such projects sooner or later are moved to KDE, and sometime even become a part of "core" projects. But this is completely another question... >> As a side note: could you add small description for the main Debian Qt >> and KDE Team group at Salsa? (There are descriptions only for subgroups >> for now.) At least a hyperlink [3] would be useful. (Until it will be >> moved to Salsa pages.) > > We noted this today. I wrote down some ideas in gobby/Teams/KDE/salsa, but > we might need to reconsider the use of kde-extras or at least define exactly > what each subgroup is for. > > Yes, we missed that point yesterday I'm afraid. > > Thanks for chiming in! Thanks for fixing this. And few more side notes/questions: Last night I have updated Debian Science Policy Manual [9] to reflect the changes after moving git repositories from Alioth to Salsa. It might be interesting to you. The question is: do we have a similar policy manuals for Debian Qt/KDE Maintainers and Debian KDE Extras teams? I failed to find them. Could you give me a link? [9] https://science-team.pages.debian.net/policy/ Best wishes, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Verdigris - header only Qt moc replacement
Hi, > I was wondering if Verdigris would be suitable for this team. > Here's RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886514 > > It has just reached 1.0, > and I am thinking about Debian packaging. > Your team and sponsorship would be very helpful. I have seen this article [1] long time ago (about 2016 IIRC). And provided library was just a proof of concept. Have anything changed since that time? Are developers going to support this library on constant basis? Do you have examples of applications which use this library? [1] https://woboq.com/blog/verdigris-qt-without-moc.html Best wishes, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Access level for members of Debian Qt and KDE Team group at Salsa
Hi, I think that package maintainers should have a Master level of access to be able to create or to import git repos in the group [1]. Al least DDs. See Debian Science Team group [2] at Salsa as example. As a side note: could you add small description for the main Debian Qt and KDE Team group at Salsa? (There are descriptions only for subgroups for now.) At least a hyperlink [3] would be useful. (Until it will be moved to Salsa pages.) [1] https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions [2] https://salsa.debian.org/groups/science-team/-/group_members [3] https://pkg-kde.alioth.debian.org/ Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Moving to salsa: IRC meeting coordination?
> We had no replies, so let's keep saturday 13 UTC except someone chimes in. Do you have a list of questions to discuss? -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Mailing List Continuation
Hi team, Some news about the future of mailing lists on Alioth: https://wiki.debian.org/Alioth/MailingListContinuation#Announcement -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Adding salsa to our food^w workflow
> I mean: we could create "qt-kde-team" group ourself and then ask for > its rename (if necessary) instead of asking of creating group "pkg-qt-kde" > and waiting then it is done. A number of groups have been created since public announce of Salsa. Looking at current situation [1] with their names I think that "qt-kde-team" name of group is the better choice for this team. [1] https://salsa.debian.org/explore/groups?sort=created_desc -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Adding salsa to our food^w workflow
>> This is not mutually exclusive, see [1] as example. >> >> [1] https://salsa.debian.org/salsa/support/issues/1 > > As I understand here is either qa or qa-team, but not both (and this is what > I had in mind when I wrote the previous mail) I mean: we could create "qt-kde-team" group ourself and then ask for its rename (if necessary) instead of asking of creating group "pkg-qt-kde" and waiting then it is done. -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Adding salsa to our food^w workflow
>> That depends on the name. If we are ok with a -team suffix then we can do it >> ourselves, else we need to ask for a special name (pkg-kde). This is not mutually exclusive, see [1] as example. [1] https://salsa.debian.org/salsa/support/issues/1 >> If we go with the renaming I would suggest using qtkde-team. > > Err, I meant pkg-qtkde-team. Why not "pkg-qt-kde-team"? It looks better. Also why the prefix "pkg-" is so important? -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Adding salsa to our food^w workflow
Hi, >> salsa.d.o (alioth's replacement for git at least) is up in beta state. >> >> I think we should ask for the pkg-kde team group. I think ACLs will be back >> with this. >> >> What do you think? > > s/ask for/create ourselves/, otherwise +1. Also do not forget to create pkg-kde-extras group. And how about Qt-extras (pkg-kde/qt-extras) sub-team which was announced earlier in this year? > I don’t think there is any migration from Alioth, so we will need to add > members to the team manually. Will we add maintainers with available accounts once after creation of group or will we wait personal requests to join group? -- Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: How to update kdeconnect
Hi Lisandro, > Today I talked with David and wanted to update kdeconnect. But found out that > we have two separate repos for it. Thank you for working on this! Bug #794499 is quite annoying despite of available workaround. > The original had the source code in it, which is normal considering it is part > of kde-extras. > > The new one does not has sources on it, but all the branches have ubuntu- > specific stuff, even master. > > I would simply remove the ubuntu specific stuff from master and use the > necesaary updates in the other branch, but before breaking someone else's > workflow I would really love to know how this should be handled. As far as I see only one (initial) commit was done into master branch and all other changes were done in Ubuntu-specific branches. So it is unlikely that you break someone's workflow. But probably you may ask Jonathan directly if it is necessary. Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Keeping the Qt5 stack together: some ideas
Hi everyone, > So basically we need a way to ensure the Qt 5 stack gets tied together. I can > think in two possible ways of doing it: > > a) Suggested by Adam Majer and improved by Felix Geyer: if package A gets > built against any qtbase x.y.z lib make it depend upon the version used to get > the package built by using Build-Depends-Package from deb-symbols(5). > > With this solution we ensure that the libs gets tied together, but also apps > rebuilt against this version. I don't know if there is a real use case for > apps migrating faster than Qt itself except for simplifying transitions (and > we still don't know how safe that could be). > > We can't use this solution for arch:all packages. > > b) Somehow (I think KDE does this) create a variable to be used in > debian/control so it get substituted at build time against whatever we set up > in, let's say, qtbase. We can use that variable in the whole Qt stack > including source packages that build arch: all binaries like translations. > Docs should not depend on binaries so maybe we need something different there. > > With this solution apps building against qt 5.5.1 which use symbols < 5.5.1 > should migrate whenever they are ready, although it's not clear to me we > really want this. On the other hand it let us tie up arch:all packages. > > So before rushing I would like to know if someone sees something I don't here. > > I somehow like option b more than a, but I would be glad to be show that a is > superior (if it is). How about more simple solution? c) Provide special empty package with current Qt5 version and add it into dependencies of all Qt5-related packages with strict or non-strict requirements for a version depending on the situation. Best regards, Boris -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
