Re: Matrix IRC bridge considered harmful
Hi, On Wed, 2020-02-12 at 15:32 -0800, Britt Yazel wrote: > Can you explain to me what the big issue with web clients are? I keep > hearing over and over again that developers don't want to use web > clients, either in browser or with Electron, but I don't recall ever > hearing a "why" in there. One of my reasons for disliking anything Browser-based is economic. It takes noticeably longer to scratch all the bits of a Web browser off my disk than anything else that has been tailored for the purpose. A corollary is the gigantic trusted computing base. Not only do the Web projects that I have to deal with pull in ridiculous amounts of dependencies (most of which of questionable quality or reputation), they ultimately also require a fully fledged Web browsing engine with all bells and whistles. The number of lines of code used for some mundane functionality as IRC is staggering. And as big code bases tend to produce big binaries, we also need to have a lot of memory to run those apps. I'm happy to be able to run my Firefox and Evolution in parallel. I'm dreading to open any other Browser-based thing because I know that my machine will start swapping (yes, I do have swap space, because I sometimes I need to have Firefox, Evolution, and something else running..). So I'd rather have a bad Gtk (or "native") client than a good Web client. Also because fixing Gtk-based apps is well within our skill set. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
Hi, On Wed, 2020-02-12 at 14:09 -0800, Britt Yazel wrote: > this is not going to be an academically backed response, just my > personal take. > > I have had horrible experiences with Matrix/Riot.im. Too bad you missed out on actually mentioning what your experience was. So it's very hard to relate to anything you're mentioning in this thread. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
Hi, On Fri, 2019-04-26 at 11:12 -0500, mcatanz...@gnome.org wrote: > Shall we install our own inclusive symlink for git now, to avoid > potentially-unpleasant connotations? Would we be in the position of doing so? My feeling is that we can control the branch names more easily than the third-party binaries people execute. But I've suggested a random string as the branch name which would avoid the problem of somebody interpreting anything into the name, I believe. I'm curious to learn whether it's an option and why. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
Hi Adel, On Fri, 2019-04-26 at 04:29 +0200, drago01 via desktop-devel-list wrote: > Assuming there is a problem in the first place which I doubt. I never > heard of a case where someone refused to contribute to a project just > because the default branch is called master. > > I'd suggest to focus on real world problems instead instead of > creating some by fixing a non existing one. I think this is too short sighted, because just because you don't see a problem does not imply that there is none. It's not implying the opposite either, which makes it more complicated than just saying "I don't know what you're talking about, leave me alone". Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
Hi, On Fri, 2019-04-26 at 11:07 +1000, Peter Hutterer wrote: > Which is the crux of the matter really: whatever you're going to pick > will have different connotations in other languages. Many ESL > speakers > will primarily think in their own language and substitute the words > to > English. So if you want to change terminology, I suggest getting a > domain expert involved rather than 'randomly' picking something that > sounds good to a small set of developers. That's how the original > master/slave wording was decided on after all. That's an interesting point. I wonder what the acceptance criteria for a new word are. Has someone come up with a metric already? How would a random string perform with such a metric? Like, say, the SHA256 hash of the module's name. Or the first few bytes thereof. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Gravatar vs libravatar
Hi, On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote: > I'm surely not > the only one that isn't going that extreme in keeping control over > couple of my pictures flying around and won't go that far. This is much less about you than it is about other people visiting our Web site. AFAIU, we trick those people into telling a third party (i.e. Gravatar) that they are visiting our Web site. While people can patch their browsers to disable such behaviour, we might feel better when not doing that by default. Because.. you know.. we claim to value their privacy. Someone was going wild about the GPDR and claimed that GNOME would be affected. If that's the case then we better not make ship code to our visitors that exposes them to third parties. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved and 'tips of the week'
Hi. On Tue, 2018-01-23 at 00:09 +0800, 藍挺瑋 wrote: > Is it possible to get a private bug migrated to GitLab? I have a bug > report which was marked as private by a libgtop developer, but there > is > no confidential information in the bug and I don't know why it became > private. > > https://bugzilla.gnome.org/show_bug.cgi?id=744890 > I've unchecked the private box. Cheers, Tobi ___ 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
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". Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab migration status and roadmap
Hi. On Fr, 2017-08-11 at 14:37 +0200, Carlos Soriano wrote: > Also I hope in the time frame of 3-4 months the pilot program is successful For completeness sake: Are we still considering to *not* move to Gitlab if that pilot is not successful? How do we measure "success"? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
Hi. On Di, 2017-06-27 at 14:23 +0100, Emmanuele Bassi wrote: > Please, let's stop this fetish about non-ff merges. Thanks for writing this. I've been confused by people insisting on "linear history" and the relatively strict configuration of GNOME's git servers. I hope that modules will be able to configure their preference. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
Hi. On Di, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote: > However, understand that participating in the pilot program means a > commitment of moving to GitLab with your project for the time being How does that affect translations? Will the module not receive translations then? Cheers, Tobi ___ 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
Hi. I welcome the proposal to modernise our development infrastructure. On Di, 2017-05-16 at 10:38 -0400, Carlos Soriano via desktop-devel-list wrote: > You can take a look at their "changelogs" between releases (one each month). This seems to be the most risky part about moving to GitLab: Having to maintain it. Maintaining Bugzilla is not an easy task, but they don't release every month. Also, we have learnt (more or less...) how to block bots DoSing or spamming us. I know a few people who moved away from GitLab because it was too painful to keep it running. I hope we don't end up with a system that we don't know how to operate. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Stackexchange community for GNOME/GTK+
Hi. On Mi, 2017-05-10 at 08:04 -0500, Michael Catanzaro wrote: > Looks like if you want to do this, we'd have to host it Or use Stackoverflow. Sri's motivation was: > We need to have a search engine index-able library of knowledge on > our platform. Modern programmers today frequently use stackexchange > and google to ask questions and to look for answers for questions.\ I tend to think that Stackoverflow perfectly matches that. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitHub Development Platform for GNOME
Hi. On So, 2017-04-09 at 15:44 -0400, Walter Vargas wrote: > > Canonical's recent decision about not maintaining unity for Ubuntu makes it > quite clear that Desktop is not the priority anymore, IoT and Mobile are the > priority now, Hah. Before it was the Cloud™, SOA, IVI, other form factors, ... I think it's fair to say that we've felt this threat for at least a decade. Now that doesn't necessarily make your point moot, but it may give a perspective on why people seem to be relatively calm about the newest coolest kid on the block. > > and now GitHub is the world leading development platform. True. But it wasn't the case five years ago and it might not be the case anymore in five years. I interpret your statement such that we should focus more on being on Github, because it's where everybody else is and we surely want them to make GNOME better. I don't think we want to pay any price associated with getting the maximum number of potential contributors. The question then becomes whether we are willing to pay the price associated with "switching to Github". For certain values of "switching to Github", the answer is probably no; see below. > > Since the primary goal is to provide a developer experience that does not act > as > a barrier to new contributors, I believe our primary goal is to produce excellent Free Software to enable as many people as possible to do their computing. But there will surely be someone who would argue otherwise and the more people you ask the more answers you will get. Providing a smooth contribution experience is certainly a means to achieve that goal. And I think we have to work on making it much more smooth for people to produce code. > > Should we be more pragmatic about that and reconsider GitHub as an option? That's a fair question to ask. I am wondering about that myself for a while now. I believe we are reluctant to accept having to rely on a party sitting between us and the people wanting to make GNOME better. The reasons are manyfold. My personal objection is that requiring someone to agree to the ToS of a third party is a lot to ask for. We don't control the third party and it may very well decide to not conduct business with certain people we would want to be able to contribute. Just to invent a scenario: American companies may not be allowed to deal with embargoed countries or people living there. Now that's not a concrete issue right now (AFAIK) but it may well become one. (Also, the Github ToS, in particular, have stirred up some debate recently) On the other hand, it's probably fair to say that most people do have a Github (Google, Facebook, ...) account already, so we're arriving here: > > Is it a dogmatic foundational decision not to evaluate GitHub because it is > not > Free Software? To me, not being Free Software feels like the straw that breaks the camel's back. But it's not that we're not using Github. We have invested some time to have our self-hosted git mirrored to Github. Some people also accept patches via Github. Are you thinking of using Github more? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker as a security risks
Hi. On Mo, 2016-12-05 at 16:42 +0100, Carlos Garnacho wrote: > And I should add... Tracker is not alone here, if it's not Tracker > stumbling on infected content, with varying but still rather low > levels of interaction it may be a thumbnailer, a previewer like sushi, > or the web browser itself streaming content which hit this. So there's > more places in need of further isolation when dealing with untrusted > content. > > And still, the chain is only as strong as its weakest link, as soon as > there is anything opening that file with wide enough permissions to > cause any harm, you're essentially screwed. True. Which is why operating on untrusted input with regular privileges is a bad idea™. The cases you've listed require some degree of user intervention though. The blog post described a way which described very little user intervention which makes is more scary than the attacks that you've just described. > This might sound like an > argument to running every app through flatpak, although I think the > long term answer always is "fix the vulnerability!". Hah! That'd be great! Let's work hard on making that happen. However, I think by now it's safe to assume that we cannot fix all the C code there is. We've tried for the last decade or so. I like the engagement reg. Rust. I hope it'll be successful. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker as a security risks
Hi Hanno. Thanks for bringing it up. On Mo, 2016-12-05 at 14:03 +0100, Hanno Böck wrote: > The core problem here is that tracker automatically parses files of > potentially unknown origin with parsers that haven't been built with > security in mind. This happens without any sandboxing. Right. But sandboxing the parsers properly would mitigate most of the problems, right? I know too little about Tracker's architecture to be able to estimate how much of a problem it would be to have the parsers run in a sandbox. I hope it's an easy change to make and it may be even planned already. Let's hope someone from the Tracker team can comment. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing for memory safety issues with Address Sanitizer
Hi. On Mi, 2016-09-21 at 11:27 -0500, Michael Catanzaro wrote: > > Then, setting LD_PRELOAD=/usr/lib64/libasan.so worked for me. > > For some reason, Fedora doesn't seem to have a libasan-devel package, hm. On my system, I have: $ dpkg -S /usr/lib/gcc/x86_64-linux-gnu/5/libasan.so libgcc-5-dev:amd64: /usr/lib/gcc/x86_64-linux-gnu/5/libasan.so $ dpkg -S /usr/lib/x86_64-linux-gnu/libasan.so.2 libasan2:amd64: /usr/lib/x86_64-linux-gnu/libasan.so.2 > so there's no plain libasan.so. Really strange. I tried changing it to > libasan.so.3 in my jhbuildrc but actually couldn't figure out how to do > that; jhbuild is playing with LD_PRELOAD as well. :( I know little about jhbuild. I think you could try to jhbuild shell into your environment, look at $LD_PRELOAD, prefix it with the path to libasan, and then do "make" or whatever command it intended to execute. If that works, it needs to be made nicer, though. Another option altogether may be to statically link ASan with -static-asan. I haven't tried that yet, however. I also don't know how well it actually works in the particular case of ld_opened libraries that you are describing. Cheers, Tobi signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing for memory safety issues with Address Sanitizer
Hi. On Wed, Sep 21, 2016 at 08:17:03AM -0500, Michael Catanzaro wrote: > undefined symbol: __asan_option_detect_stack_use_after_return > > Is anything special needed for dlopened modules? Try LDFLAGS+=-lasan Another source of inconvenience is when compiling any library that GCC needs itself, like gnome-calculator does. Then, setting LD_PRELOAD=/usr/lib64/libasan.so worked for me. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: To GSoC mentors, period for selecting proposals open until the end of next week
Hi! :-) On Fr, 2016-04-01 at 13:16 -0400, Carlos Soriano Sanchez wrote: > You have a comment box there, which is only visible to other mentors > and admins, in case you want to discuss the validity or quality of > proposals. Ah. Just to make sure: Discussions with the students are supposed to be done out of band, correct? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Builder] Developer experience (DX) hackfest 2016
Hi! On Mon, Dec 28, 2015 at 07:31:19PM +0100, Olav Vitters wrote: > Is there an existing (hosted) solution alternative to hangouts? Pretty > much as simple as: "go to this URL"? I know talky.io, appear.in, opentokrtc.com, appr.tc, meetme, japkin, and others. I think all of them are not Free Software though. So essentially Skype in a Web browser. Firefox Hello is probably the freest implementation. I haven't used it, though. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Atomix maintenance
Hi! On Tue, Jan 13, 2015 at 08:22:56PM +0200, Robert Roth wrote: > In lack of active maintenance (last release 9 years ago, namely 2.14.0) I > intend to take over the maintenance of the Atomix [1] game from gnome > git[2]. Cool, thanks! Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi. On Fri, Aug 22, 2014 at 08:47:50AM +0100, Allan Day wrote: > A new version of the HIG is in the works, to be released along with > GNOME 3.14 [1]. I'm currently looking for feedback. I've pushed an HTML version here for your convenience: http://people.gnome.org/~tobiasmue/hig3 Please note that this a one-shot effort and will likely not see any updates. Do we have automatically compiled versions somewhere? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of privacy features in GNOME
Hi. On Thu, Mar 06, 2014 at 04:41:32PM +0100, Stef Walter wrote: > Andreas or Tobias would know definitively ... but I don't think that any > implementation has been undertaken by GNOME as of yet. that is correct. Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]
Hi. On 25.08.2013 10:54, fr33domlover wrote: > which is why I suggest a switch: Let maintainers > turn off the mirroring. I think it is safe to assume that your suggestion was heard. You are free to implement that. And in case it wasn't clear: You are very welcome to implement the relevant logic to push to more destinations to "fight centralization". I also think that this approach will be more successful than reiterating the suggestion you make. Cheers, Tobi signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BugBuddy uselessness
Aloha, Andre Klapper wrote: Am Mittwoch, den 11.02.2009, 22:58 +0100 schrieb Tobias Mueller: I'd say it'd be the best to remove that whole crash.gnome.org thing from bugbuddy as there is obviously nobody who is able to manage that platform. I assume that bugbuddy would then send to b.g.o only. Before I'd be interested to know how many additional reports per week this would mean (but we probably can't find out as it's down). Indeed. I can't even access the database anymore (which I could on last GUADEC). The whole postgres deamon seams to be down on crash.gnome.org. Currently I assume that the additional reports will be mostly useless stack traces resulting in a much higher workload for the bugsquad, with very limited benefit. Maybe. But assuming that Cosimo is right with bugbuddy only sending to c.g.o if the stacktrace is missing debug symbols, we could replace that c.g.o logic with a dialog asking the user to install debug symbols instead of sending to b.g.o in every case. Cheers, Tobi signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BugBuddy uselessness
Ahoi, Mathias Hasselmann wrote: Am Mittwoch, den 11.02.2009, 12:00 -0500 schrieb Hubert Figuiere: Is there any plan to remove Bug Buddy now that it has been made useless? Your reasoning is strange. Wouldn't it make more sense to fix crash.gnome.org? Or did we gave up on software quality? I can understand that reasoning: It might be better to remove a broken automatic bug reporting, because the user might think that somebody takes care about her issue, but in fact the reports land in a black hole where nobody can see or work on them. Also I don't see how we could reliably retrace the minidumps if we don't ship binaries at all. But that might be due to my limited knowledge of the used technologies. I'd say it'd be the best to remove that whole crash.gnome.org thing from bugbuddy as there is obviously nobody who is able to manage that platform. I assume that bugbuddy would then send to b.g.o only. Cheers, Tobi signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
