Re: Signature for a released source code package

[Federico Mena Quintero]

On Sat, 2017-10-14 at 22:08 +0200, Uwe Scholz wrote:
> Now after I thought about it I was wondering how a user can be sure
> that he gets the same source code which I uploaded to the Gnome
> servers. The thing is, when I do a release with "make distcheck" as
> described in the gnome wiki(*), a tar.bz2 file is generated locally
> on my PC. This file is then copied via scp to the gnome server. But
> when executing "ftpadmin install" on the gnome server I see that the
> server is doing some magic and converts the tar.bz2 archive into a
> tar.xz one. Why does this happen?

Normally automake creates .tar.bz2.  I had to do the following in
librsvg's configure.ac to make it spit .tar.xz files:
AM_INIT_AUTOMAKE([1.9 foreign no-dist-gzip dist-xz])
  Federico___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Hashem Nasarat]

On Thu, Dec 7, 2017 at 12:01 PM, Milan Crha  wrote:

>
>
> a) See the second comment of
>https://gitlab-test.gnome.org/mcrha/test/issues/2
>It shows like three lines of text (one line, then empty line, then
>third line). When you edit that comment you'll see I made it
>several lines, not only three - the interface is ignoring my
>Enter-s. Am I supposed to use some crazy tag when I want to divide
>paragraphs and/or write simple lines?
>

I was confused but figured out how to insert line breaks using Markdown:
just end the line with two spaces then a newline

For example this is on
a new line.

http://markdown-guide.readthedocs.io/en/latest/basics.html#line-return
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[philip . chimento]

On Thu, Dec 7, 2017 at 2:36 PM Carlos Soriano  wrote:

> Hey Michael,
>
> On Thu, Dec 7, 2017 at 9:04 PM, Michael Catanzaro 
> wrote:
>
>> I've been rewriting this email again and again to try not to be too
>> impolitic... and I don't think I've succeeded, but I want to try to express
>> the importance to me of some of the missing issue tracker features.
>>
>>
> I'm pretty sure you succeed, appreciated you spent the time to not be over
> the top.
>
>
>> On 12/07/2017 12:07 PM, Carlos Soriano wrote:
>>
>>> Said that, add your comments about specific improvements to issue #8
>>> too in a new comment so we can track them.
>>>
>>
>> It looks like everything I care about is actually already tracked there
>> in issue #8. (Except that the quote button needs to work like 'r'... good
>> to know about the 'r' shortcut, I can live with that.) Looking over #8, I
>> think duplicate issues, canned replies, and dependencies between issues
>> should all be considered blockers to issue tracker migration.
>
>
>> I assume I don't need to explain why tracking duplicate issues is
>> important. Just look at the state of the closed issues in gnome-calendar's
>> issue tracker right now.
>>
>
>
> I understand the importance of this, and we discussed them in the past. We
> have discussed also with the people trying GitLab, and the balance keep
> being positive. I agree better UI experience for duplicates is something we
> should see in the near future, but I think the general consensus is that we
> can move forward without it and eventually have a better experience.
>

I admire Carlos' restraint here but I'm going to say it more bluntly: in my
opinion, it is unfair to expect that any individual person's opinion on
their preferred must-haves should be able to block the migration from
moving forward. This is part of the monumental job Carlos has been doing:
gathering everyone's requirements, evaluating them, checking the
feasibility with GitLab, and deciding which ones are blockers for GNOME _as
a whole_ before we move the migration forward. By demanding that your
personal blockers take precedence, you are undermining Carlos' hard work
and the balancing act he has to perform to get this to happen at all. It's
impossible for him to make everyone happy and I think he's done a fine job
of representing different perspectives, I dare say even ones that he
doesn't agree with. We need to trust that he is including all the factors
and making the right decision.

I use a long canned reply to close probably half the bugs I receive ("here
>> is how you report a WebKit bug..."), and bug management would be extremely
>> frustrating without it. I could keep it in a text file and copy/paste for a
>> couple months, as long as upstream has promised the feature is on the way.
>> But I really would rather stay on Bugzilla forever rather than give up
>> canned replies forever. I am going to be thinking "I hate GitLab" every
>> other time I close a bug... we don't want that.
>>
>
> Like everything, it's a balance. I hope you see as you hate GitLab there
> are others that hate Bugzilla, including most of new contributors. It's
> impossible to make everyone happy with such a change, but I hope you trust
> me when I say that I didn't take any steps on this lightly, and that I
> tried to take a representation of the whole community. In no moment I
> though about myself when taking these decisions, and I went far beyond the
> possible to try to make sure we are taking the best decision for GNOME and
> that our community agrees with that decision.
>

I have to think "I hate Bugzilla" every time I use Bugzilla, but that
didn't seem to bother anybody. I became a GNOME maintainer 395 days ago and
have had to deal with Bugzilla for most of those days, so let's say 500
times I SMHd including patches that I filed before I became a maintainer. I
even _used Google Chrome as my primary browser_ because it was the only
browser that had an extension that would turn Bugzilla bugs into Trello
cards which I found easier to deal with. Michael, I don't mean to single
you out, this is just an example, but If you think "I hate GitLab" every
other time you close a bug, then you will have to close 1000 bugs before
you approach my level of Bugzilla-rage.

Coming from GitHub, Bugzilla was like regressing to the stone age. If I
were to insist that my opinion take precedence in the same way that has
happened multiple times on this thread, I'd demand that all activity on
Bugzilla cease immediately. I don't think that would be very fair for me to
do either.


>
>>
>> And I would also insist on a schedule for open sourcing dependencies
>> between issues. That such an important feature is being kept closed source
>> indicates we are going to have further problems collaborating with upstream
>> down the road. We should be prepared to stay with Bugzilla indefinitely if
>> GitLab remains unwilling to open source basic issue tracker functionality.

Re: GitLab update: Moving to the next step

[mcatanzaro]

On Fri, Dec 8, 2017 at 3:40 AM, Emilio Pozuelo Monfort 
 wrote:
Can't you write a simple greasemonkey script to add canned replies to 
gitlab, until they are implemented upstream?


No, because our web browser does not support Greasemonkey yet. (Should 
be possible to do using WebKitUserContentManager, if anyone has an itch 
to scratch.)


But thanks for your suggestion, because it reminded be that our custom 
CSS feature (which is under the hood implemented in the same way that 
user scripts would have to be) is broken under flatpak... it works by 
launching gedit to edit a text file, and that's hard to do under 
flatpak. I will fix that


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: g_object_ref() now propagates types

[Emmanuele Bassi]

On 8 December 2017 at 11:26, Philip Withnall  wrote:


> If anybody encounters any problems with this, please comment on the bug
> report:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=790697

As a side note: I've started a full Continuous rebuild, so if there
are projects that indeed break with this change, we should be notified
pretty quickly.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: g_object_ref() now propagates types

[Christian Hergert]

On 12/08/2017 03:26 AM, Philip Withnall wrote:

child_type = CHILD_TYPE (g_object_ref (parent_type));


Or my personal preference:

  g_object_ref (CHILD_TYPE (parent_type))

I was skeptical that this would catch many issues, but it actually 
caught a copy pasta for me a couple of days ago with something like:


 a->foo = g_object_ref (baz);
 a->bar = g_object_ref (baz);

when i changed foo to bar and forgot to modify baz.

So +1 already.

-- Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

g_object_ref() now propagates types

[Philip Withnall]

Hi all,

We just landed a patch in GLib which propagates the type from the
argument of g_object_ref() to its return type:

https://git.gnome.org/browse/glib/commit/?id=3fae39a5d
https://bugzilla.gnome.org/show_bug.cgi?id=790697

The idea here is that it will catch invalid implicit casts which the
compiler otherwise wouldn’t have noticed because g_object_ref()
previously operated entirely on gpointers. This will eliminate a whole
class of bugs: bugs which are unlikely to exist, but are a complete
pain to track down if they do.

The downside of this is that some legitimate implicit casts may now
cause compiler warnings with -Wincompatible-pointer-types. For example,
in the situation below, a warning will be introduced since parent_type
isn’t guaranteed to be an instance of child_type:

ParentType *parent_type;
ChildType *child_type;

child_type = g_object_ref (parent_type);

To fix this warning, first double-check that parent_type is actually
guaranteed to always be an instance of child_type at runtime, and then
change the ref to:

child_type = CHILD_TYPE (g_object_ref (parent_type));

That will add a compile-time explicit cast, and a runtime type check.
(As always, the runtime type check is disabled if GLib is built without
debugging enabled (or with G_DISABLE_CAST_CHECKS defined.)

Note that the new behaviour requires GCC, and is only enabled if you
have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56.

If anybody encounters any problems with this, please comment on the bug
report:

https://bugzilla.gnome.org/show_bug.cgi?id=790697

Thanks,
Philip
on behalf of the GLib maintainership cabal

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: GitLab update: Moving to the next step

[Emilio Pozuelo Monfort]

On 07/12/17 21:04, Michael Catanzaro wrote:
> I use a long canned reply to close probably half the bugs I receive ("here is
> how you report a WebKit bug..."), and bug management would be extremely
> frustrating without it. I could keep it in a text file and copy/paste for a
> couple months, as long as upstream has promised the feature is on the way. 
> But I
> really would rather stay on Bugzilla forever rather than give up canned 
> replies
> forever. I am going to be thinking "I hate GitLab" every other time I close a
> bug... we don't want that.

Can't you write a simple greasemonkey script to add canned replies to gitlab,
until they are implemented upstream?

Cheers,
Emilio
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list