Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor
On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote: > I have been considering adding some explicit switch like `--unsafe` to > the checkout command to allow users to do this "at their own risk", but Sounds like you need to use reflink. Safe _and_ fast. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote: > Hi. > > On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > > By attaching a patch to a bugtracker ticket, we loose the information of > > > the parent commit: where the commit has been initially created in the > > > git history. > > If the patch is created by git format-patch, it contains the hash of > > the parent, so git knows the original parent > I couldn't find the hash of the parent commit in my git format-patch > exported patch, e.g. https://bug778584.bugzilla-attachments.gnome.org/a > ttachment.cgi?id=345698. > Do I need to do anything special in order to export the parent also? > The man page for git-format-patch does not show anything useful for > "parent". Any patch formatted by git format will things like this: diff --git a/file.c b/file.c index e14a869321..0a8628c26a 100644 --- a/file.c +++ b/file.c @@ -847,7 +847,6 @@ int function_name( Where e14a869321 is the old version of the file, and 0a8628c26a is the new one. This allows git to see the evolution of the file from e14a869321 to the one in HEAD. (I shouldn't have said "hash of the parent", since it's the "hash of the version of the file that a hunk of the patch was based on".) Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote: > >> Hi, > >> > >> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano > >> wrote: > >> > Ah, I see what you mean now. But then you can rebase yourself in master > >> > right? And the build time would be exactly the same no? > >> > >> Not sure what you mean. You don't want to rebase master under any > >> circumstances (unless you rebase over origin/master to be able to push > >> new commits of course). Anyway you usually won't be able to, since > >> force push should be forbidden in master. And in any cases, this does > >> not solve the issue I was talking about. > >> > >> What I want is rebasing a patch branch over master. And no, you cannot > >> do it *from* master. You have to first checkout the branch so that you > >> can rebase. Once you checked out, it's too late. Timestamps of various > >> files are changed even though they didn't change between master and > >> the rebased branch (but they changed in the in-between step). > > > > 'git cherry-pick ..branch' ? > > That's what I said I would likely do indeed a few emails ago. :P > But I was answering about the problems of rebasing for timestamp as an > alternative. > > cherry-pick still has a problem though. Unless the patch is trivial > and looks like it's totally good from reading the diff (I would still > do a quick build just to be sure), I don't really like to work on > master with commits. You never know, some day, just a reflex, you git > push… Hopefully it has never happened, but still. That's like working > on a production server. Yeah, I have pushed to master a few times by mistake… Embarrassing *and* permanent ;( There's always git cherry-pick -n. That works as long as the PR has only one commit. Apart from that, I don't think there's a general solution to this problem… You could always play with setting branch.master.pushRemote to your private repo, so that an explicit 'git push origin' is required to actually push. But once you get into the habit of doing that, you're back to square one. So I don't think any automatic solution is possible. > That's why I like to work on master (so that I don't checkout outdated > branches and have long builds), but with git apply as a first step. One option is to improve the build system… Gnome is in the process of switching to meson, and meson does much better in this regard. So that might make this issue moot — by the time gitlab is implemented, branching might be cheap again. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:23:43PM +0200, Christoph Reiter wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> wrote:
> > The only thing I am annoyed at is this forking workflow. Both as a
> > contributor, and as a code committer/reviewer. Having to fetch a new
> > remote for every single-commit contribution out there is terrible.
>
> In case you didn't know, just like with github you can fetch the PRs
> from the main remote if you adjust the git config accordingly:
> https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally
>
> $ git fetch
> $ git branch -a # look for PR branch
> $ git checkout origin/merge-requests/42
> $ git checkout master
I have the following config (for github):
[alias]
pr-fetch = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1;
}; f"
pr = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git
checkout pr/$1; }; f"
pr-merge = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1
&& git merge pr/$1 --no-ff --edit -m 'Merge pull request #'$1; }; f"
pr-clean = "!git for-each-ref refs/heads/pr/* --format=\"%(refname)\" |
while read ref ; do branch=${ref#refs/heads/} ; git branch -D $branch ; done"
(git pr checks out the PR as a new branch, and git pr-fetch
just creates the new branch but does not check out.)
IIUC, you want to rebase the PR onto your master to do a ff-merge. This should
be
fairly easy to do with 'git cherry-pick ..pr/'.
From another mail:
> When it's a separate remote, I even wonder if git will still make the
> link between the 2 remotes? Will it try to rebuild everything from
> scratch? This would be absolutely terrible.
I think there's some confusion as to what git is doing when you switch branches.
All it does is:
1. compare the two trees from the old commit and new commit,
2. write out the files that are different, delete files that are missing from
the new tree.
So it does not touch any files that are identical between two trees.
When git writes out files, it doesn't do anything special, so the os updates
the mtime to "now". This means that the build system will rebuild everything
which has the updated files as deps. How much is rebuilt is depends on the
build system and the changeset... autotools will usually rebuild almost
everything
if configure.ac was touched, but that's an issue with autotools, and git just
dumbly updates the files it is told to. (In particular, whether the commits
you are switching between are from the same remote, or different remotes, or
even from two trees which do not share a common parent — doesn't matter. Only
the SHA1 of the contents is relevant.)
Zbyszek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano > wrote: > > Ah, I see what you mean now. But then you can rebase yourself in master > > right? And the build time would be exactly the same no? > > Not sure what you mean. You don't want to rebase master under any > circumstances (unless you rebase over origin/master to be able to push > new commits of course). Anyway you usually won't be able to, since > force push should be forbidden in master. And in any cases, this does > not solve the issue I was talking about. > > What I want is rebasing a patch branch over master. And no, you cannot > do it *from* master. You have to first checkout the branch so that you > can rebase. Once you checked out, it's too late. Timestamps of various > files are changed even though they didn't change between master and > the rebased branch (but they changed in the in-between step). 'git cherry-pick ..branch' ? Zbyszek > This is a very common git issue, you can look it up. :-) > There are workarounds. The best one is to create a second working tree > attached to the same local repository (git help worktree), to do the > rebase there without touching the main working tree (the one you > build). Then when you are done, you can checkout the rebased branch. > This is possible and not too bad if you have to do it often, actually. > Though it's still going through a lot of hoops. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > By attaching a patch to a bugtracker ticket, we loose the information of > the parent commit: where the commit has been initially created in the > git history. If the patch is created by git format-patch, it contains the hash of the parent, so git knows the original parent. > I've already had the problem that git-bz apply fails (there was a > conflict), while git was able to resolve automatically the conflict when > rebasing the branch. 'git am -3' is the same as a rebase. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Including content ratings in games
On Wed, Mar 09, 2016 at 01:57:07PM +, Richard Hughes wrote: > I've uploaded my prototype generator here: > http://apps-xdgapp.rhcloud.com/oars and I'd appreciate any feedback on > that. Some of the categories may be difficult to translate or may need > further (or better) examples, and so any comments on or off-list are > very welcome. Also, don't actually add anything to AppData files yet, > as the categories are nowhere close to being finalised. Thanks! I think something like this could work, but it's just way too complicated. If this is to be used for self-evaluation by projects for purely informational purposes, categories can be merged. So "Cartoon Violence" can be merged with "Fantasy Violence", "Realistic depictions of bloodshed" and "Depictions of bloodshed and the mutilation of body parts" can be replaced with "Depictions of bloodshed or mutilation of body parts". I think you can drop "Humor" totally, it's legal in most jurisdictions after all. Likewise, everywhere where there's four choices three would suffice. Actually I think it'd be really great to reduce all questions to binary choice, "no or negligible", "noticable i.e. yes". And there's no need to ask separately about intersection of categories, e.g. "sexual violence" could go away. This would remove the number of questions by 50-70% and make it possible to fill in with a few clicks. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: system Desktop notifications
On Mon, Jun 23, 2014 at 11:10:14PM +0200, Rolf Fokkens wrote: > Thanks for the feedback. I can understand that it may not always be > helpful indeed. > > Let me refrase my question: Wouldn't it be useful that some system > related messages (backups, SMART...) are presented to "whom it > concerns"? The users whom it conserns could be: > > - The (workstation) owner. So most likely the graphical console, the > local X server should present the messages. And maybe even when no > user is logged on, so a message popup on top of the login screen? > Could be helpful. > - The sysadmin. That might be whoever is in the wheel group. And it > doesn't matter if he's working remote or local; > - Subscribers? Maybe users should be able to subscribe to this kind > of information. > > It's like when working in character mode: kernel messages show up on > (local) consoles. With wall it's possible (for the sysadmin) to > write a message to all users (who allow this). Something like that, > but then in the wordt of graphical consoles. I think this might be > useful in general, and maybe for backups in particular. > > I was thinking about (system) dbus as the solution: the session > manager, the (local?) login screen or the notifier deamon can > subscribe to a notification service on the system dbus. > > But considering dbus may have been wrong. Maybe there are good > alternatives, suggestions are welcome. Dbus would be equivalent to a "push mode". Users watching the journal (and e.g. having notifications pop up in their graphical environment) is a "pull mode". Both have merits, but "pull mode" is almost there. One of the advantages is that the privilege separation is working already by adding the users who are allowed to view logs to adm group, and/or settings facls on /var/log/journal/. This would update the classical "log messages of critical priority" to all logged in users for the modern era of graphical desktops. I'm pretty sure that using Gnome Logs source as a basis of a simple applet which pops up notifications is doable. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: system dbus and Desktop notifications
On Mon, Jun 23, 2014 at 11:38:43AM +0100, Simon McVittie wrote: > On 22/06/14 19:31, Rolf Fokkens wrote: > > For a udev driven backup script (connect the USB the disk, and the > > backup starts) I'd like to have desktop notifications that say when the > > backup starts and when the backup is finished so users can disconnect > > the USB disk. > > Consider, for instance: > > * Alice is a sysadmin, Bob is an unprivileged user. Alice is logged-in > locally, Bob is logged-in remotely. Who should be notified? > (I think "Alice but not Bob".) > > * The same users, but now Alice is remote and Bob is local. Who should > be notified? (I'm not sure.) > > If you think the answer to the second is "Bob, because, most likely, > he's the one physically plugging in the USB disk" then something at the > level of gvfs (running inside Bob's session) might be a better solution. > > If you think the answer to the second is "Alice, because she's the > sysadmin" then the Unix syslog, or the systemd Journal that extends and > partially supersedes syslog on systemd systems, might be a good basis > for an answer. Something similar has been requested for SMART messages [1]. The implementation should be quite similar. [1] https://bugzilla.gnome.org/show_bug.cgi?id=723108 Zbyszek > > Google is helpful, but seems to tell me that these notifications work > > via the session dbus, not the system dbus. Apparently a solution is to > > identfy any logged on user, find the related DBUS_SESSION_BUS_ADDRESS > > and use that to notify the user. > > System-level components injecting events into an arbitrarily-chosen user > session, or (slightly better) into each user session, is not how the > system/session split in D-Bus is intended to work. The intended way to > do this within D-Bus is to run some process in each user session, which > does something on the system bus (subscribes to broadcast notifications, > or explicitly requests unicast notifications if there's private data > involved) and produces popups or whatever. > > There is currently no spec for a generic notification-receiving daemon > that does that on the system bus. > > Consider whether every logged-in user should get these notifications > regardless of their level of privilege - broadcasts on the system bus > are not access-controlled, and anyone (or anything - system users too) > can see them. > > Also consider what should happen if nobody is logged in... > > S > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
