From melchiaros at aol.com Wed Aug 1 15:11:35 2012
From: melchiaros at aol.com (melchiaros)
Date: Wed, 01 Aug 2012 17:11:35 +0200
Subject: Bugreport 682310 - third people help would be helpfull
Message-ID: <50194727.6090108@aol.com>
Hi there.
On running Quantal, I do routine checks in launchpad for programs I use.
On utilizing Geogebra(geometry software) I have found:
https://bugs.launchpad.net/ubuntu/+source/geogebra/+bug/682310
I have done by the way a recheck, because the original report was on EOL
maverik.
The recheck has shown that the original problem was still there in parts.
For further inverstigation(the original reporter has not answered) I
have contacted Giovanni Mascellani(original maintainer of GeoGebra).
He has done very valuable work on the report as you can see there.
Later on I decided to get a meaning from LibreOffice pople and have
moved the report to this packages(causes see in report).
On this penalvch has been involved.
Unfortunally penalvch and I have some differences in facing/handling a
report and we got stacked, which is not good for the report at all.
The problem may be that I see the thinks very liberal and he very
conservative. We have reached a dead point.
He is correct in the way that I have act far beside the common workflow
for bughandling/triaging, but I see this satisfied by the special kind
of the problem.
So, when there are people that have knowlede on LibreOffice and Ubuntu
clipboard function it would be helpfull when you have time to have a
look at.
Thank you
melchiaros
Giovanni and I have done this more in e-mail style, so please read the
full report first before you do on it.
<https://launchpad.net/%7Epenalvch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120801/ec826498/attachment.html>
From trekcaptainusa.tw at gmail.com Fri Aug 3 14:46:42 2012
From: trekcaptainusa.tw at gmail.com (Thomas Ward)
Date: Fri, 3 Aug 2012 10:46:42 -0400
Subject: Core vs. Non-Core definitions
In-Reply-To: <20120712221937.GP13466@murraytwins.com>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
Message-ID: <CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
Is there any other discussion we should do on this, or can we use Brian
Murray's opinion as the methods of determining core vs. non-core packages?
Or does anyone else have any other opinions on it?
Thomas
On Thu, Jul 12, 2012 at 6:19 PM, Brian Murray <brian at ubuntu.com> wrote:
> On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote:
> > I'm dredging this back up again, given a discussion with hggdh in
> > #ubuntu-bugs.
> >
> > This should *really* be defined, core vs. non core for Importance
> setting,
> > among other things.
> >
> > Core vs. Non-Core can make a bug either Low or Medium (see bold items,
> and
> > here: https://wiki.ubuntu.com/Bugs/Importance):
>
> I'd say packages that are a part of a task should be considered core and
> most other things non-core. As an example:
>
> apt-cache show empathy | grep ^Task
> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
>
> I would consider empathy as a core application.
>
> Does that help?
>
> --
> Brian Murray
> Ubuntu Bug Master
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120803/89f18bd1/attachment.html>
From hggdh2 at ubuntu.com Sun Aug 5 23:57:26 2012
From: hggdh2 at ubuntu.com (C de-Avillez)
Date: Sun, 5 Aug 2012 18:57:26 -0500
Subject: Core vs. Non-Core definitions
In-Reply-To: <CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
Message-ID: <20120805185726.15e111b9@xango3.home>
On Fri, 3 Aug 2012 10:46:42 -0400
Thomas Ward <trekcaptainusa.tw at gmail.com> wrote:
> Is there any other discussion we should do on this, or can we use
> Brian Murray's opinion as the methods of determining core vs.
> non-core packages? Or does anyone else have any other opinions on it?
For what is worth, I do agree with Brian's approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120805/da850770/attachment.sig>
From marcel.admiraal at connectfree.co.uk Mon Aug 6 10:42:11 2012
From: marcel.admiraal at connectfree.co.uk (Marcel Admiraal)
Date: Mon, 06 Aug 2012 11:42:11 +0100
Subject: Core vs. Non-Core definitions
In-Reply-To: <CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
Message-ID: <501F9F83.1040305@connectfree.co.uk>
Correct me if I'm wrong, but the "apt-cache show" command displays the
contents of the Debian package control file, and there doesn't appear to
be a standard field "Task" defined:
http://www.debian.org/doc/debian-policy/ch-controlfields.html.
IMHO, I don't consider Empathy a "core" package. In fact, as the
"Priority" field in the same output indicates, it's optional.
I think, we should use the "Priority" field is as an indicator of a
"core" application. As per the definition of the "Priority" field
values:
http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities,
any application which is "required" or "important" - necessary for the
functioning of the system, or expected on any system - should probably
be considered core.
Finally, I think if the word "core" is not defined, the wiki shouldn't
use it; especially not to define something else.
Marcel.
On 03/08/12 15:46, Thomas Ward wrote:
> Is there any other discussion we should do on this, or can we use
> Brian Murray's opinion as the methods of determining core vs. non-core
> packages? Or does anyone else have any other opinions on it?
> Thomas
>
> On Thu, Jul 12, 2012 at 6:19 PM, Brian Murray <brian at ubuntu.com
> <mailto:brian at ubuntu.com>> wrote:
>
> On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote:
> > I'm dredging this back up again, given a discussion with hggdh in
> > #ubuntu-bugs.
> >
> > This should *really* be defined, core vs. non core for
> Importance setting,
> > among other things.
> >
> > Core vs. Non-Core can make a bug either Low or Medium (see bold
> items, and
> > here: https://wiki.ubuntu.com/Bugs/Importance):
>
> I'd say packages that are a part of a task should be considered
> core and
> most other things non-core. As an example:
>
> apt-cache show empathy | grep ^Task
> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
>
> I would consider empathy as a core application.
>
> Does that help?
>
> --
> Brian Murray
> Ubuntu Bug Master
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> <mailto:Ubuntu-bugsquad at lists.ubuntu.com>
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120806/77aeeb21/attachment.html>
From trekcaptainusa.tw at gmail.com Mon Aug 6 14:55:35 2012
From: trekcaptainusa.tw at gmail.com (Thomas Ward)
Date: Mon, 6 Aug 2012 10:55:35 -0400
Subject: Core vs. Non-Core definitions
In-Reply-To: <501F9F83.1040305@connectfree.co.uk>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
<501F9F83.1040305@connectfree.co.uk>
Message-ID: <CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
Marcel,
C de-Avillez (hggdh) and I were on IRC in #ubuntu-bugs discussing your
response, and we made an observation that the "Priority" is used in Debian
to determine how important a package is to the system, not to the user,
such that if a package is Priority = Required, and you remove it, the
system is likely to misbehave.
By using the tasks approach that Brian suggested, it comes from a different
perspective, specifically that if its included in a task, its probably
considered important enough.
As well, another check is to see whether a package exists in main or not.
A universe or multiverse package is certainly non-core, but a package in
main might be.
I'm still inclined to use Brian's method, though, as a preferred method of
identifying a "core" or "non-core" package.
Thomas
On Mon, Aug 6, 2012 at 6:42 AM, Marcel Admiraal <
marcel.admiraal at connectfree.co.uk> wrote:
> Correct me if I'm wrong, but the "apt-cache show" command displays the
> contents of the Debian package control file, and there doesn't appear to be
> a standard field "Task" defined:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html.
>
> IMHO, I don't consider Empathy a "core" package. In fact, as the
> "Priority" field in the same output indicates, it's optional.
>
> I think, we should use the "Priority" field is as an indicator of a "core"
> application. As per the definition of the "Priority" field values:
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities, any
> application which is "required" or "important" - necessary for the
> functioning of the system, or expected on any system - should probably be
> considered core.
>
> Finally, I think if the word "core" is not defined, the wiki shouldn't use
> it; especially not to define something else.
>
> Marcel.
>
>
> On 03/08/12 15:46, Thomas Ward wrote:
>
> Is there any other discussion we should do on this, or can we use Brian
> Murray's opinion as the methods of determining core vs. non-core packages?
> Or does anyone else have any other opinions on it?
>
> Thomas
>
> On Thu, Jul 12, 2012 at 6:19 PM, Brian Murray <brian at ubuntu.com> wrote:
>
>> On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote:
>> > I'm dredging this back up again, given a discussion with hggdh in
>> > #ubuntu-bugs.
>> >
>> > This should *really* be defined, core vs. non core for Importance
>> setting,
>> > among other things.
>> >
>> > Core vs. Non-Core can make a bug either Low or Medium (see bold items,
>> and
>> > here: https://wiki.ubuntu.com/Bugs/Importance):
>>
>> I'd say packages that are a part of a task should be considered core and
>> most other things non-core. As an example:
>>
>> apt-cache show empathy | grep ^Task
>> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
>>
>> I would consider empathy as a core application.
>>
>> Does that help?
>>
>> --
>> Brian Murray
>> Ubuntu Bug Master
>>
>> --
>> Ubuntu-bugsquad mailing list
>> Ubuntu-bugsquad at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>>
>>
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120806/287e19b0/attachment.html>
From marcel.admiraal at connectfree.co.uk Tue Aug 7 12:39:34 2012
From: marcel.admiraal at connectfree.co.uk (Marcel Admiraal)
Date: Tue, 07 Aug 2012 13:39:34 +0100
Subject: Core vs. Non-Core definitions
In-Reply-To: <CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
<501F9F83.1040305@connectfree.co.uk>
<CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
Message-ID: <50210C86.40406@connectfree.co.uk>
If we use the "Task" field to identify whether or not an application is
"core". We should ensure that the "Task" field is defined somewhere.
This definition should explain why it can be used to define whether or
not an application is "core", and what values would define an
application as "core". Since this is part of the Debian package control
file, I would expect this to be done at a Debian level. Although it
could be made Ubuntu specific, I don't think that would be the right
approach. Personally I don't understand what the "Task" field is for, or
why it signifies that an application is important.
Clearly this discussion is based on the fact that the definition of
"core" is open to interpretation; so there will be disagreement on what
people consider "core", but personally I think the fact that an
application is important to the system is what defines an application as
core, and not whether it's important to a user. This is why I suggested
using the "Priority" field, which is defined at the Debian level, and
consider both "required" and "important" applications as "core".
I agree that all "core" packages should be in the "main" repository i.e.
they are free and supported. However, we should note that this shouldn't
be used as part of a definition, because there is a theoretical
possibility that a "core" application may not be in "main", because it's
been removed, which itself would be a bug. I know this has happened to
free applications that are removed from the universe repository for some
reason e.g. when VLC and mplayer, which are both free, were not
included. Saying that it's not "core" because it's not in "main" would
lead to a circular argument.
Marcel.
On 06/08/12 15:55, Thomas Ward wrote:
> Marcel,
> C de-Avillez (hggdh) and I were on IRC in #ubuntu-bugs discussing your
> response, and we made an observation that the "Priority" is used in
> Debian to determine how important a package is to the system, not to
> the user, such that if a package is Priority = Required, and you
> remove it, the system is likely to misbehave.
> By using the tasks approach that Brian suggested, it comes from a
> different perspective, specifically that if its included in a task,
> its probably considered important enough.
> As well, another check is to see whether a package exists in main or
> not. A universe or multiverse package is certainly non-core, but a
> package in main might be.
> I'm still inclined to use Brian's method, though, as a preferred
> method of identifying a "core" or "non-core" package.
> Thomas
>
>
>
> On Mon, Aug 6, 2012 at 6:42 AM, Marcel Admiraal
> <marcel.admiraal at connectfree.co.uk
> <mailto:marcel.admiraal at connectfree.co.uk>> wrote:
>
> Correct me if I'm wrong, but the "apt-cache show" command displays
> the contents of the Debian package control file, and there doesn't
> appear to be a standard field "Task" defined:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html.
>
> IMHO, I don't consider Empathy a "core" package. In fact, as the
> "Priority" field in the same output indicates, it's optional.
>
> I think, we should use the "Priority" field is as an indicator of
> a "core" application. As per the definition of the "Priority"
> field values:
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities,
> any application which is "required" or "important" - necessary for
> the functioning of the system, or expected on any system - should
> probably be considered core.
>
> Finally, I think if the word "core" is not defined, the wiki
> shouldn't use it; especially not to define something else.
>
> Marcel.
>
>
> On 03/08/12 15:46, Thomas Ward wrote:
>> Is there any other discussion we should do on this, or can we use
>> Brian Murray's opinion as the methods of determining core vs.
>> non-core packages? Or does anyone else have any other opinions on it?
>> Thomas
>>
>> On Thu, Jul 12, 2012 at 6:19 PM, Brian Murray <brian at ubuntu.com
>> <mailto:brian at ubuntu.com>> wrote:
>>
>> On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote:
>> > I'm dredging this back up again, given a discussion with
>> hggdh in
>> > #ubuntu-bugs.
>> >
>> > This should *really* be defined, core vs. non core for
>> Importance setting,
>> > among other things.
>> >
>> > Core vs. Non-Core can make a bug either Low or Medium (see
>> bold items, and
>> > here: https://wiki.ubuntu.com/Bugs/Importance):
>>
>> I'd say packages that are a part of a task should be
>> considered core and
>> most other things non-core. As an example:
>>
>> apt-cache show empathy | grep ^Task
>> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
>>
>> I would consider empathy as a core application.
>>
>> Does that help?
>>
>> --
>> Brian Murray
>> Ubuntu Bug Master
>>
>> --
>> Ubuntu-bugsquad mailing list
>> Ubuntu-bugsquad at lists.ubuntu.com
>> <mailto:Ubuntu-bugsquad at lists.ubuntu.com>
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>>
>>
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> <mailto:Ubuntu-bugsquad at lists.ubuntu.com>
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120807/43bb6da9/attachment.html>
From persia at ubuntu.com Tue Aug 7 13:52:22 2012
From: persia at ubuntu.com (Emmet Hikory)
Date: Tue, 7 Aug 2012 22:52:22 +0900
Subject: Core vs. Non-Core definitions
In-Reply-To: <50210C86.40406@connectfree.co.uk>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
<501F9F83.1040305@connectfree.co.uk>
<CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
<50210C86.40406@connectfree.co.uk>
Message-ID: <20120807135222.GE3199@gerdhr.shipstone>
Marcel Admiraal wrote:
> If we use the "Task" field to identify whether or not an application
> is "core". We should ensure that the "Task" field is defined
> somewhere. This definition should explain why it can be used to
> define whether or not an application is "core", and what values
> would define an application as "core". Since this is part of the
> Debian package control file, I would expect this to be done at a
> Debian level. Although it could be made Ubuntu specific, I don't
> think that would be the right approach. Personally I don't
> understand what the "Task" field is for, or why it signifies that an
> application is important.
The tasks are generated by launchpad based on the content of the
seeds used to define the flavours, by a process that is similar to
the means by which the common metapackages are generated
(e.g. xubuntu-desktop). You can compare the similarity by looking at the
output of the following commands:
`apt-cache show xubuntu-desktop` (describes the metapackage)
`apt-cache show xubuntu-desktop^' (describes the content of the task)
Note that the set of packages described by the second command
matches the set of packages listed as dependencies and recommendations
in the first command (barring the potential for intentional variation).
Packages that are included in tasks are considered important because
the developers of the various Ubuntu flavours have deemed them important:
this information is Ubuntu specific and entirely independent of any
information included in source packages imported from Debian. It ought
be safe to consider these "core" packages, because they are packages that
are specifically identified as being important to one or another flavour
of Ubuntu, or the (transitive) dependencies and recommendations of these
packages so identified.
Note that reliance entirely on tasks isn't quite sufficient, as
there exist some packages that are transitive build-dependencies of
the "core" packages that also need the same level of attention and
triage as bugs there may affect packages in tasks, but it is most
likely that most users would report bugs against packages in tasks,
which we would then reassign to packages not in tasks as they became
understood, making the use of tasks an acceptable heuristic for most
regular bug triage activity.
It is worth mentioning that during any given development cycle, there
are unavoidable delays between changes in the seeds and the availability
of updated binary metapackages, so that there may be observed skew between
the packages considered transitive dependencies of a metapackage and the
packages included in a task: this ought only be a temporary phenomenon, and
should never be the case once a given cycle as completed (release happened).
> Clearly this discussion is based on the fact that the definition of
> "core" is open to interpretation; so there will be disagreement on
> what people consider "core", but personally I think the fact that an
> application is important to the system is what defines an
> application as core, and not whether it's important to a user. This
> is why I suggested using the "Priority" field, which is defined at
> the Debian level, and consider both "required" and "important"
> applications as "core".
The issue here is that if we only consider "required" and "important"
packages as core, we end up defining nearly every package users notice or
intentionally use as "non-core". With a few exceptions, just about everything
of direct user interest is Priority: optional (as an example, xserver-xorg is
optional). Making everything that the flavours consider critical higher
than optional would mean we had no differentiation of flavours, and a >5GB
download for install, as every user would be required to install all the
packages used for all the flavours. Making all the packages not considered
critical by the flavours less than optional would involve a massive amount
of work (more than 10,000 packages affected, and needing continued maintenance
over time, as such a change would be unsuitable for Debian), and then fail
to usefully distinguish packages users are encouraged not to use (Priority:
extra).
> I agree that all "core" packages should be in the "main" repository
> i.e. they are free and supported. However, we should note that this
> shouldn't be used as part of a definition, because there is a
> theoretical possibility that a "core" application may not be in
> "main", because it's been removed, which itself would be a bug. I
> know this has happened to free applications that are removed from
> the universe repository for some reason e.g. when VLC and mplayer,
> which are both free, were not included. Saying that it's not "core"
> because it's not in "main" would lead to a circular argument.
I don't think it is appropriate to declare a package "core" or
"non-core" based on the component in which it happens to fall: if
such an approach is taken, all flavours will need to put all the
packages of direct interest into main, requiring a vast amount
of processing of main inclusion reports, and similar. While there
are historical reasons that the component definitions were interesting,
we ought not limit ourselves by adding more complexity to the currently
existing semantics surrounding them, especially when we have significantly
more flexible and richer tools available from which to select those same
semantics, and heuristics to apply those semantics.
For the avoidance of doubt, my personal definition of "core" is packages
that affect the content of shipping products, these being the ogre-model
constrained set of transitive dependencies, recommendations, and build
dependencies for all packages referenced in the seeds for all products, plus
those packages in the unconstrained transitive dependencies, recommendations,
and build dependencies of the infrastructure used to produce product images.
In practice, the use of the Task: header in local apt caches is close enough
to the above that the exceptions can often be held in the heads of those
developers with direct intrest in the production of product artifacts.
Those bugsquad members with an exclusive interest in a subset of flavours
may wish to avoid work on packages only represented in Tasks: for which they
have little interest.
--
Emmet HIKORY
From noreply at ubuntu.com Thu Aug 9 14:17:30 2012
From: noreply at ubuntu.com (Ubuntu Wiki)
Date: Thu, 09 Aug 2012 14:17:30 -0000
Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22LibreOfficeBugWrangling=22_by_bj?=
=?utf-8?q?oern-michaelsen?=
Message-ID: <20120809141730.13025.10466@mangaba.canonical.com>
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.
The "LibreOfficeBugWrangling" page has been changed by bjoern-michaelsen:
http://wiki.ubuntu.com/LibreOfficeBugWrangling?action=diff&rev1=15&rev2=16
* For instances when you are using LibreOffice and either the system hangs requiring a hard reset or you are booted to the login screen, this is a bug in either xorg or the kernel. Please follow https://help.ubuntu.com/community/DebuggingSystemCrash . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash.
=== Troubleshooting Techniques ===
- Try moving .libreoffice and ~/.config/libreoffice. If you installed any extensions, remove them and see if the problem is reproducible. Comment on the results of performing these techniques in your report.
+ Try moving .libreoffice and ~/.config/libreoffice. If you installed any extensions, remove them and see if the problem is reproducible. Comment on the results of performing these techniques in your report. Please keep these directories around -- if moving the profile helps you, developers might be interested in it to find out what was wrong with it.
== Regressions ==
* For regressions, it is helpful to perform a binary bisect ("bibisect") to narrow down which commit specifically caused the problem. For instructions please see http://sweetshark.livejournal.com/7683.html .
From costamagnagianfranco at yahoo.it Tue Aug 14 13:04:11 2012
From: costamagnagianfranco at yahoo.it (Gianfranco Costamagna)
Date: Tue, 14 Aug 2012 14:04:11 +0100 (BST)
Subject: Builders private?
Message-ID: <1344949451.74964.YahooMailNeo@web133006.mail.ir2.yahoo.com>
Hi, can I know why the builders page [1] is private?
I have this problem since one hour...
thanks
[1] https://code.launchpad.net/builders/
Gianfranco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/ef493e59/attachment.html>
From sanchitgangwar at outlook.com Tue Aug 14 13:30:05 2012
From: sanchitgangwar at outlook.com (Sanchit Gangwar)
Date: Tue, 14 Aug 2012 19:00:05 +0530
Subject: Builders private?
In-Reply-To: <1344949451.74964.YahooMailNeo@web133006.mail.ir2.yahoo.com>
References: <1344949451.74964.YahooMailNeo@web133006.mail.ir2.yahoo.com>
Message-ID: <SNT002-W73883F0B4FF1CD68109BC0DDB70@phx.gbl>
It works fine for me
Date: Tue, 14 Aug 2012 14:04:11 +0100
From: costamagnagianfranco at yahoo.it
Subject: Builders private?
To: ubuntu-bugsquad at lists.ubuntu.com
Hi, can I know why the builders page [1] is private?I have this problem since one hour...
thanks
[1] https://code.launchpad.net/builders/
Gianfranco
--
Ubuntu-bugsquad mailing list
Ubuntu-bugsquad at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/a5e14228/attachment.html>
From hggdh2 at ubuntu.com Tue Aug 14 13:58:16 2012
From: hggdh2 at ubuntu.com (C de-Avillez)
Date: Tue, 14 Aug 2012 08:58:16 -0500
Subject: Builders private?
In-Reply-To: <1344949451.74964.YahooMailNeo@web133006.mail.ir2.yahoo.com>
References: <1344949451.74964.YahooMailNeo@web133006.mail.ir2.yahoo.com>
Message-ID: <20120814085816.2f5b5933@xango3.home>
On Tue, 14 Aug 2012 14:04:11 +0100 (BST)
Gianfranco Costamagna <costamagnagianfranco at yahoo.it> wrote:
> Hi, can I know why the builders page [1] is private?
> I have this problem since one hour...
>
> thanks
Works for me, also. What, exactly, do you see when you try to reach it?
Cheers,
..C..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/b40900a5/attachment.sig>
From announcements at projectmanagementusa136.org Tue Aug 14 20:08:57 2012
From: announcements at projectmanagementusa136.org (American Project Management)
Date: 14 Aug 2012 13:08:57 -0700
Subject: Project Management Masters Certification Program (September 25 - 28,
2012: Oklahoma City, OK)
Message-ID: <20120814130855.2691E5E532A298B7@projectmanagementusa136.org>
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/5978612c/attachment.html>
From tetvet1967 at yahoo.com Wed Aug 15 20:19:00 2012
From: tetvet1967 at yahoo.com (Walrus)
Date: Wed, 15 Aug 2012 13:19:00 -0700 (PDT)
Subject: I cannot update/upgrade, get error messages about packets,
no idea how to fix it
Message-ID: <1345061940.73649.YahooMailClassic@web163506.mail.gq1.yahoo.com>
I keep getting a red dot with a white line in it and the info it conveys is as follows:
I could not get Ubuntu to let me copy and paste, so I attached the whole screen snapshot.
The part that I wanted you to see is in the upper right top area. Â A black box with writing, detailing the problem that I cannot figure out how to correct/fix, so hope you can.
rodney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120815/45f047f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2012-08-15 13:14:32.png
Type: image/png
Size: 121790 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120815/45f047f3/attachment.png>
From tetvet1967 at yahoo.com Wed Aug 15 21:13:09 2012
From: tetvet1967 at yahoo.com (Walrus)
Date: Wed, 15 Aug 2012 14:13:09 -0700 (PDT)
Subject: An unresolvable problem occurred while calculating the upgrade.
Message-ID: <1345065189.66653.YahooMailClassic@web163501.mail.gq1.yahoo.com>
Every time I try to run Update Manager, it fails and give the following message:
"An unresolvable problem occurred while calculating the upgrade."
"Could not calculate the upgrade"
Please report this bug against the 'update-manager' package and include the following error message:'E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.'
I cannot find Package Manager, I cannot figure out how to resolve the error problems.
Please advise!
rodney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120815/2f6d72fd/attachment.html>
From gale.michael at gmail.com Wed Aug 15 22:21:30 2012
From: gale.michael at gmail.com (Michael Gale)
Date: Wed, 15 Aug 2012 16:21:30 -0600
Subject: I cannot update/upgrade, get error messages about packets, no
idea how to fix it
In-Reply-To: <1345061940.73649.YahooMailClassic@web163506.mail.gq1.yahoo.com>
References: <1345061940.73649.YahooMailClassic@web163506.mail.gq1.yahoo.com>
Message-ID: <CA+YXe5=zrT-ROtrpwg8koDPNo6TvbRJ8zFwxBMXHfz0WQDk93A@mail.gmail.com>
Hello,
In a terminal can you run the following command:
`sudo apt-get update`
You should be able to select "Terminal" by right clicking on the desktop.
Thanks
Michael
On Wed, Aug 15, 2012 at 2:19 PM, Walrus <tetvet1967 at yahoo.com> wrote:
>
>
> I keep getting a red dot with a white line in it and the info
> it conveys is as follows:
>
> I could not get Ubuntu to let me copy and paste, so I attached the whole
> screen snapshot.
>
> The part that I wanted you to see is in the upper right top area. A black
> box with writing, detailing the problem that I cannot figure out how to
> correct/fix, so hope you can.
>
> rodney
>
>
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
--
Ecclesiastes 1:18
18 For with much wisdom comes much sorrow;
the more knowledge, the more grief.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120815/d10e10a8/attachment.html>
From costamagnagianfranco at yahoo.it Wed Aug 15 22:49:12 2012
From: costamagnagianfranco at yahoo.it (Gianfranco Costamagna)
Date: Wed, 15 Aug 2012 23:49:12 +0100 (BST)
Subject: Builders private?
In-Reply-To: <mailman.21.1345032006.3918.ubuntu-bugsquad@lists.ubuntu.com>
References: <mailman.21.1345032006.3918.ubuntu-bugsquad@lists.ubuntu.com>
Message-ID: <1345070952.28707.YahooMailNeo@web133001.mail.ir2.yahoo.com>
It started working well again after something like one more hour...
Many thanks anyway :)
Â
Gianfranco
>________________________________
> Da: "ubuntu-bugsquad-request at lists.ubuntu.com" <ubuntu-bugsquad-request at lists.ubuntu.com>
>A: ubuntu-bugsquad at lists.ubuntu.com
>Inviato: Mercoledì 15 Agosto 2012 14:00
>Oggetto: Ubuntu-bugsquad Digest, Vol 74, Issue 8
>
>Send Ubuntu-bugsquad mailing list submissions to
>Â Â Â ubuntu-bugsquad at lists.ubuntu.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
>Â Â Â https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>or, via email, send a message with subject or body 'help' to
>Â Â Â ubuntu-bugsquad-request at lists.ubuntu.com
>
>You can reach the person managing the list at
>Â Â Â ubuntu-bugsquad-owner at lists.ubuntu.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Ubuntu-bugsquad digest..."
>
>
>Today's Topics:
>
>Â 1. Builders private? (Gianfranco Costamagna)
>Â 2. Builders private? (Sanchit Gangwar)
>Â 3. Re: Builders private? (C de-Avillez)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 14 Aug 2012 14:04:11 +0100 (BST)
>From: Gianfranco Costamagna <costamagnagianfranco at yahoo.it>
>To: "ubuntu-bugsquad at lists.ubuntu.com"
>Â Â Â <ubuntu-bugsquad at lists.ubuntu.com>
>Subject: Builders private?
>Message-ID:
>Â Â Â <1344949451.74964.YahooMailNeo at web133006.mail.ir2.yahoo.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi, can I know why the builders page [1] is private?
>I have this problem since one hour...
>
>thanks
>
>
>[1] https://code.launchpad.net/builders/
>
>
>Gianfranco
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/ef493e59/attachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Tue, 14 Aug 2012 19:00:05 +0530
>From: Sanchit Gangwar <sanchitgangwar at outlook.com>
>To: "ubuntu-bugsquad at lists.ubuntu.com"
>Â Â Â <ubuntu-bugsquad at lists.ubuntu.com>
>Subject: Builders private?
>Message-ID: <SNT002-W73883F0B4FF1CD68109BC0DDB70 at phx.gbl>
>Content-Type: text/plain; charset="iso-8859-1"
>
>It works fine for me
>
>Date: Tue, 14 Aug 2012 14:04:11 +0100
>From: costamagnagianfranco at yahoo.it
>Subject: Builders private?
>To: ubuntu-bugsquad at lists.ubuntu.com
>
>Hi, can I know why the builders page [1] is private?I have this problem since one hour...
>thanks
>
>[1] https://code.launchpad.net/builders/
>
>Gianfranco
>--
>Ubuntu-bugsquad mailing list
>Ubuntu-bugsquad at lists.ubuntu.com
>https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad                 Â
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/a5e14228/attachment-0001.html>
>
>------------------------------
>
>Message: 3
>Date: Tue, 14 Aug 2012 08:58:16 -0500
>From: C de-Avillez <hggdh2 at ubuntu.com>
>To: ubuntu-bugsquad at lists.ubuntu.com
>Subject: Re: Builders private?
>Message-ID: <20120814085816.2f5b5933 at xango3.home>
>Content-Type: text/plain; charset="us-ascii"
>
>On Tue, 14 Aug 2012 14:04:11 +0100 (BST)
>Gianfranco Costamagna <costamagnagianfranco at yahoo.it> wrote:
>
>> Hi, can I know why the builders page [1] is private?
>> I have this problem since one hour...
>>
>> thanks
>
>Works for me, also. What, exactly, do you see when you try to reach it?
>
>Cheers,
>
>..C..
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 836 bytes
>Desc: not available
>URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120814/b40900a5/attachment-0001.pgp>
>
>------------------------------
>
>--
>Ubuntu-bugsquad mailing list
>Ubuntu-bugsquad at lists.ubuntu.com
>https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
>End of Ubuntu-bugsquad Digest, Vol 74, Issue 8
>**********************************************
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120815/badebe15/attachment.html>
From noreply at ubuntu.com Thu Aug 16 08:24:50 2012
From: noreply at ubuntu.com (Ubuntu Wiki)
Date: Thu, 16 Aug 2012 08:24:50 -0000
Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?=
=?utf-8?q?lson?=
Message-ID: <20120816082450.15809.65715@mangaba.canonical.com>
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.
The "MozillaTeam/Bugs" page has been changed by chrisccoulson:
http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=83&rev2=84
== Other specific issues ==
=== Problems with menus on systems that use a global menubar ===
- By default, the unity shell shipped in Ubuntu 11.04 and newer displays application menubars in the top panel. Some other desktop environments may also provide similar functionality (there is a plasmoid for KDE which does this).
+ By default, the unity shell shipped in Ubuntu 11.04 and newer displays window menubars in the top panel. Some other desktop environments may also provide similar functionality (there is a plasmoid for KDE which does this).
In these environments, problems with the menus are not always an application bug.
- If you experience an issue with the '''content''' of the menubar, menus or menuitems (ie, what the actual text says, what the icons display or the state of any radio or check items), then this should be reported as an application bug (against Firefox or Thunderbird). If you experience an issue with '''actions''' (ie, what happens when you click on a menuitem), then this might be an application bug too.
+ If you experience an issue with the '''content''' of the menubar, menus or menuitems (ie, what the actual text says, what the icons display or the state of any radio or check items), then this should be reported as an application bug (against Firefox or Thunderbird). If you experience an issue with '''actions''' (ie, what happens when you click on a menuitem or invoke an accelerator key), then this might be an application bug too.
In general, any problem with the '''view''' of the menubar, menus or menuitems is normally a bug with the desktop shell instead. Examples of this might include:
* Alignment of elements in the menu
@@ -271, +271 @@
* The functionality is not supported by any other components involved with providing the menubar (ie, dbusmenu, unity and even GTK), and so, there isn't any change we could make in Firefox that would add this functionality to the global menubar.
Please don't report this issue as a bug.
+
+ ==== Keyboard type-ahead feature does not work with the global menubar ====
+
+ Gecko has a feature that allows you to select bookmark items from a menu with the keyboard, using a type-ahead like feature. Other toolkits lack this feature though, so this won't work with the global menubar. Please don't report this as a bug against Firefox, as it isn't. This is functionality that needs to be added to the toolkit responsible for drawing the menu
=== The "Open with" dialog does not offer a choice of applications ===
From noreply at ubuntu.com Thu Aug 16 08:30:52 2012
From: noreply at ubuntu.com (Ubuntu Wiki)
Date: Thu, 16 Aug 2012 08:30:52 -0000
Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?=
=?utf-8?q?lson?=
Message-ID: <20120816083052.20430.72610@mangaba.canonical.com>
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.
The "MozillaTeam/Bugs" page has been changed by chrisccoulson:
http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=84&rev2=85
==== Keyboard type-ahead feature does not work with the global menubar ====
Gecko has a feature that allows you to select bookmark items from a menu with the keyboard, using a type-ahead like feature. Other toolkits lack this feature though, so this won't work with the global menubar. Please don't report this as a bug against Firefox, as it isn't. This is functionality that needs to be added to the toolkit responsible for drawing the menu
+
+ See [[https://launchpad.net/bugs/917753|bug 917753]]
=== The "Open with" dialog does not offer a choice of applications ===
From costamagnagianfranco at yahoo.it Mon Aug 20 07:45:55 2012
From: costamagnagianfranco at yahoo.it (Gianfranco Costamagna)
Date: Mon, 20 Aug 2012 08:45:55 +0100 (BST)
Subject: Launchpad doesn't build recipes anymore
Message-ID: <1345448755.50819.YahooMailNeo@web133001.mail.ir2.yahoo.com>
Hi everybody, after the latest updates on launchpad my recipes doesn't build anymore, here is a log example:
https://launchpadlibrarian.net/112991254/buildlog.txt.gz
I also filled a bug
https://bugs.launchpad.net/launchpad-buildd/+bug/1038374
Â
Does anybody know why?
Many thanks
Gianfranco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120820/9c893298/attachment.html>
From alo21 at ubuntu-it.org Tue Aug 21 20:07:09 2012
From: alo21 at ubuntu-it.org (Alessandro Losavio)
Date: Tue, 21 Aug 2012 21:07:09 +0100
Subject: Gather more details to fix a bug
Message-ID: <5033EA6D.4060404@ubuntu-it.org>
Hi, I am trying to fix a bitsize bug. If I have some problem to
understand a part of code, whom should I ask? Project manager? Developer?
Thanks in advance
--
Email: alo21 AT ubuntu-it DOT org
Wiki: wiki.ubuntu-it.org/AlessandroLosavio
LP: https://launchpad.net/~alo21
From trekcaptainusa.tw at gmail.com Wed Aug 29 16:31:49 2012
From: trekcaptainusa.tw at gmail.com (Thomas Ward)
Date: Wed, 29 Aug 2012 12:31:49 -0400
Subject: Core vs. Non-Core definitions
In-Reply-To: <20120807135222.GE3199@gerdhr.shipstone>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
<501F9F83.1040305@connectfree.co.uk>
<CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
<50210C86.40406@connectfree.co.uk>
<20120807135222.GE3199@gerdhr.shipstone>
Message-ID: <CAC9eBO29mt6uunRcNTTSPYSJ5g3HMRnLyqf5Ofxx8iRRBbDBug@mail.gmail.com>
So, now that we've pretty much agreed on using the task field in practice,
I spoke with Brian Murray (bdmurray on IRC). We just need to add to the
BugSquad documentation (https://wiki.ubuntu.com/Bugs/Importance) and
anywhere else in the documentation where we reference "core" vs. "non-core"
with footnotes on how to define them. As far as I am aware, its only in
the Importance docs where we actually have such a definition.
Now, time to do the wording. We do want to keep this somewhat non-complex,
for the newer or less experienced people who wish to suggest importances
for packages.
I came up with some wording as a start, but I'd welcome suggestions as they
come up before we throw this into the wiki's documentation (because i think
the idea is to not change that document often). If we decide to use that
wording, i'll go ahead and add this to the wiki page:
"core" | A core package can be identified as being part of a task in the
apt-cache headers. You can see the apt-cache headers by running `apt-cache
show [package]` in a terminal, and looking at the "Task: " field in the
output.
"non-core" | A non-core package can be identified as a package that is not
part of a task, and is not in 'main'. You can see the apt-cache headers by
running `apt-cache show [package]` in a terminal, and looking at the "Task:
" field in the output.
------
Thomas Ward
LPID: trekcaptainusa-tw
Ubuntu BugSquad Member
On Tue, Aug 7, 2012 at 9:52 AM, Emmet Hikory <persia at ubuntu.com> wrote:
> Marcel Admiraal wrote:
> > If we use the "Task" field to identify whether or not an application
> > is "core". We should ensure that the "Task" field is defined
> > somewhere. This definition should explain why it can be used to
> > define whether or not an application is "core", and what values
> > would define an application as "core". Since this is part of the
> > Debian package control file, I would expect this to be done at a
> > Debian level. Although it could be made Ubuntu specific, I don't
> > think that would be the right approach. Personally I don't
> > understand what the "Task" field is for, or why it signifies that an
> > application is important.
>
>
> The tasks are generated by launchpad based on the content of the
> seeds used to define the flavours, by a process that is similar to
> the means by which the common metapackages are generated
> (e.g. xubuntu-desktop). You can compare the similarity by looking at the
> output of the following commands:
>
> `apt-cache show xubuntu-desktop` (describes the metapackage)
> `apt-cache show xubuntu-desktop^' (describes the content of the task)
>
> Note that the set of packages described by the second command
> matches the set of packages listed as dependencies and recommendations
> in the first command (barring the potential for intentional variation).
>
> Packages that are included in tasks are considered important because
> the developers of the various Ubuntu flavours have deemed them important:
> this information is Ubuntu specific and entirely independent of any
> information included in source packages imported from Debian. It ought
> be safe to consider these "core" packages, because they are packages that
> are specifically identified as being important to one or another flavour
> of Ubuntu, or the (transitive) dependencies and recommendations of these
> packages so identified.
>
> Note that reliance entirely on tasks isn't quite sufficient, as
> there exist some packages that are transitive build-dependencies of
> the "core" packages that also need the same level of attention and
> triage as bugs there may affect packages in tasks, but it is most
> likely that most users would report bugs against packages in tasks,
> which we would then reassign to packages not in tasks as they became
> understood, making the use of tasks an acceptable heuristic for most
> regular bug triage activity.
>
> It is worth mentioning that during any given development cycle, there
> are unavoidable delays between changes in the seeds and the availability
> of updated binary metapackages, so that there may be observed skew between
> the packages considered transitive dependencies of a metapackage and the
> packages included in a task: this ought only be a temporary phenomenon, and
> should never be the case once a given cycle as completed (release
> happened).
>
> > Clearly this discussion is based on the fact that the definition of
> > "core" is open to interpretation; so there will be disagreement on
> > what people consider "core", but personally I think the fact that an
> > application is important to the system is what defines an
> > application as core, and not whether it's important to a user. This
> > is why I suggested using the "Priority" field, which is defined at
> > the Debian level, and consider both "required" and "important"
> > applications as "core".
>
> The issue here is that if we only consider "required" and "important"
> packages as core, we end up defining nearly every package users notice or
> intentionally use as "non-core". With a few exceptions, just about
> everything
> of direct user interest is Priority: optional (as an example, xserver-xorg
> is
> optional). Making everything that the flavours consider critical higher
> than optional would mean we had no differentiation of flavours, and a >5GB
> download for install, as every user would be required to install all the
> packages used for all the flavours. Making all the packages not considered
> critical by the flavours less than optional would involve a massive amount
> of work (more than 10,000 packages affected, and needing continued
> maintenance
> over time, as such a change would be unsuitable for Debian), and then fail
> to usefully distinguish packages users are encouraged not to use (Priority:
> extra).
>
> > I agree that all "core" packages should be in the "main" repository
> > i.e. they are free and supported. However, we should note that this
> > shouldn't be used as part of a definition, because there is a
> > theoretical possibility that a "core" application may not be in
> > "main", because it's been removed, which itself would be a bug. I
> > know this has happened to free applications that are removed from
> > the universe repository for some reason e.g. when VLC and mplayer,
> > which are both free, were not included. Saying that it's not "core"
> > because it's not in "main" would lead to a circular argument.
>
> I don't think it is appropriate to declare a package "core" or
> "non-core" based on the component in which it happens to fall: if
> such an approach is taken, all flavours will need to put all the
> packages of direct interest into main, requiring a vast amount
> of processing of main inclusion reports, and similar. While there
> are historical reasons that the component definitions were interesting,
> we ought not limit ourselves by adding more complexity to the currently
> existing semantics surrounding them, especially when we have significantly
> more flexible and richer tools available from which to select those same
> semantics, and heuristics to apply those semantics.
>
> For the avoidance of doubt, my personal definition of "core" is
> packages
> that affect the content of shipping products, these being the ogre-model
> constrained set of transitive dependencies, recommendations, and build
> dependencies for all packages referenced in the seeds for all products,
> plus
> those packages in the unconstrained transitive dependencies,
> recommendations,
> and build dependencies of the infrastructure used to produce product
> images.
> In practice, the use of the Task: header in local apt caches is close
> enough
> to the above that the exceptions can often be held in the heads of those
> developers with direct intrest in the production of product artifacts.
>
> Those bugsquad members with an exclusive interest in a subset of
> flavours
> may wish to avoid work on packages only represented in Tasks: for which
> they
> have little interest.
>
> --
> Emmet HIKORY
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120829/4440dd27/attachment.html>
From trekcaptainusa.tw at gmail.com Wed Aug 29 16:42:57 2012
From: trekcaptainusa.tw at gmail.com (Thomas Ward)
Date: Wed, 29 Aug 2012 12:42:57 -0400
Subject: Core vs. Non-Core definitions
In-Reply-To: <CAC9eBO29mt6uunRcNTTSPYSJ5g3HMRnLyqf5Ofxx8iRRBbDBug@mail.gmail.com>
References: <CAC9eBO0Ef+o_1cW+-S9h6OxixZRSKkt_MXAz-c+ovev9DeH1Lw@mail.gmail.com>
<CAC9eBO2_v5LXDs0o5Dd1UWy8GdttFiVprf=+ZMfvVEMyoW6knw@mail.gmail.com>
<20120712221937.GP13466@murraytwins.com>
<CAC9eBO1FepR0Gh4-m92L3S+MJwbEkk8=c4T8NacW+u4pjbAEnw@mail.gmail.com>
<501F9F83.1040305@connectfree.co.uk>
<CAC9eBO20bLs5+Kpkk8F54vnxG9ds=SdqeJ5w4fEHkUorQAxhvg@mail.gmail.com>
<50210C86.40406@connectfree.co.uk>
<20120807135222.GE3199@gerdhr.shipstone>
<CAC9eBO29mt6uunRcNTTSPYSJ5g3HMRnLyqf5Ofxx8iRRBbDBug@mail.gmail.com>
Message-ID: <CAC9eBO2cLsebZ93NwrBp+YTGFWxpbV9g6J+Ytvf5dUFd4gV8-Q@mail.gmail.com>
Clarification: I meant "a bug's importance" (see bold changes in the quote
below)
On Wed, Aug 29, 2012 at 12:31 PM, Thomas Ward
<trekcaptainusa.tw at gmail.com>wrote:
> So, now that we've pretty much agreed on using the task field in practice,
> I spoke with Brian Murray (bdmurray on IRC). We just need to add to the
> BugSquad documentation (https://wiki.ubuntu.com/Bugs/Importance) and
> anywhere else in the documentation where we reference "core" vs. "non-core"
> with footnotes on how to define them. As far as I am aware, its only in
> the Importance docs where we actually have such a definition.
>
> Now, time to do the wording. We do want to keep this somewhat
> non-complex, for the newer or less experienced people who wish to suggest
> importances for *a bug's importance*.
>
> I came up with some wording as a start, but I'd welcome suggestions as
> they come up before we throw this into the wiki's documentation (because i
> think the idea is to not change that document often). If we decide to use
> that wording, i'll go ahead and add this to the wiki page:
>
> "core" | A core package can be identified as being part of a task in the
> apt-cache headers. You can see the apt-cache headers by running `apt-cache
> show [package]` in a terminal, and looking at the "Task: " field in the
> output.
>
> "non-core" | A non-core package can be identified as a package that is not
> part of a task, and is not in 'main'. You can see the apt-cache headers by
> running `apt-cache show [package]` in a terminal, and looking at the "Task:
> " field in the output.
>
>
> ------
> Thomas Ward
> LPID: trekcaptainusa-tw
> Ubuntu BugSquad Member
>
>
> On Tue, Aug 7, 2012 at 9:52 AM, Emmet Hikory <persia at ubuntu.com> wrote:
>
>> Marcel Admiraal wrote:
>> > If we use the "Task" field to identify whether or not an application
>> > is "core". We should ensure that the "Task" field is defined
>> > somewhere. This definition should explain why it can be used to
>> > define whether or not an application is "core", and what values
>> > would define an application as "core". Since this is part of the
>> > Debian package control file, I would expect this to be done at a
>> > Debian level. Although it could be made Ubuntu specific, I don't
>> > think that would be the right approach. Personally I don't
>> > understand what the "Task" field is for, or why it signifies that an
>> > application is important.
>>
>>
>> The tasks are generated by launchpad based on the content of the
>> seeds used to define the flavours, by a process that is similar to
>> the means by which the common metapackages are generated
>> (e.g. xubuntu-desktop). You can compare the similarity by looking at the
>> output of the following commands:
>>
>> `apt-cache show xubuntu-desktop` (describes the metapackage)
>> `apt-cache show xubuntu-desktop^' (describes the content of the task)
>>
>> Note that the set of packages described by the second command
>> matches the set of packages listed as dependencies and recommendations
>> in the first command (barring the potential for intentional variation).
>>
>> Packages that are included in tasks are considered important because
>> the developers of the various Ubuntu flavours have deemed them important:
>> this information is Ubuntu specific and entirely independent of any
>> information included in source packages imported from Debian. It ought
>> be safe to consider these "core" packages, because they are packages that
>> are specifically identified as being important to one or another flavour
>> of Ubuntu, or the (transitive) dependencies and recommendations of these
>> packages so identified.
>>
>> Note that reliance entirely on tasks isn't quite sufficient, as
>> there exist some packages that are transitive build-dependencies of
>> the "core" packages that also need the same level of attention and
>> triage as bugs there may affect packages in tasks, but it is most
>> likely that most users would report bugs against packages in tasks,
>> which we would then reassign to packages not in tasks as they became
>> understood, making the use of tasks an acceptable heuristic for most
>> regular bug triage activity.
>>
>> It is worth mentioning that during any given development cycle, there
>> are unavoidable delays between changes in the seeds and the availability
>> of updated binary metapackages, so that there may be observed skew between
>> the packages considered transitive dependencies of a metapackage and the
>> packages included in a task: this ought only be a temporary phenomenon,
>> and
>> should never be the case once a given cycle as completed (release
>> happened).
>>
>> > Clearly this discussion is based on the fact that the definition of
>> > "core" is open to interpretation; so there will be disagreement on
>> > what people consider "core", but personally I think the fact that an
>> > application is important to the system is what defines an
>> > application as core, and not whether it's important to a user. This
>> > is why I suggested using the "Priority" field, which is defined at
>> > the Debian level, and consider both "required" and "important"
>> > applications as "core".
>>
>> The issue here is that if we only consider "required" and "important"
>> packages as core, we end up defining nearly every package users notice or
>> intentionally use as "non-core". With a few exceptions, just about
>> everything
>> of direct user interest is Priority: optional (as an example,
>> xserver-xorg is
>> optional). Making everything that the flavours consider critical higher
>> than optional would mean we had no differentiation of flavours, and a >5GB
>> download for install, as every user would be required to install all the
>> packages used for all the flavours. Making all the packages not
>> considered
>> critical by the flavours less than optional would involve a massive amount
>> of work (more than 10,000 packages affected, and needing continued
>> maintenance
>> over time, as such a change would be unsuitable for Debian), and then fail
>> to usefully distinguish packages users are encouraged not to use
>> (Priority:
>> extra).
>>
>> > I agree that all "core" packages should be in the "main" repository
>> > i.e. they are free and supported. However, we should note that this
>> > shouldn't be used as part of a definition, because there is a
>> > theoretical possibility that a "core" application may not be in
>> > "main", because it's been removed, which itself would be a bug. I
>> > know this has happened to free applications that are removed from
>> > the universe repository for some reason e.g. when VLC and mplayer,
>> > which are both free, were not included. Saying that it's not "core"
>> > because it's not in "main" would lead to a circular argument.
>>
>> I don't think it is appropriate to declare a package "core" or
>> "non-core" based on the component in which it happens to fall: if
>> such an approach is taken, all flavours will need to put all the
>> packages of direct interest into main, requiring a vast amount
>> of processing of main inclusion reports, and similar. While there
>> are historical reasons that the component definitions were interesting,
>> we ought not limit ourselves by adding more complexity to the currently
>> existing semantics surrounding them, especially when we have significantly
>> more flexible and richer tools available from which to select those same
>> semantics, and heuristics to apply those semantics.
>>
>> For the avoidance of doubt, my personal definition of "core" is
>> packages
>> that affect the content of shipping products, these being the ogre-model
>> constrained set of transitive dependencies, recommendations, and build
>> dependencies for all packages referenced in the seeds for all products,
>> plus
>> those packages in the unconstrained transitive dependencies,
>> recommendations,
>> and build dependencies of the infrastructure used to produce product
>> images.
>> In practice, the use of the Task: header in local apt caches is close
>> enough
>> to the above that the exceptions can often be held in the heads of those
>> developers with direct intrest in the production of product artifacts.
>>
>> Those bugsquad members with an exclusive interest in a subset of
>> flavours
>> may wish to avoid work on packages only represented in Tasks: for which
>> they
>> have little interest.
>>
>> --
>> Emmet HIKORY
>>
>> --
>> Ubuntu-bugsquad mailing list
>> Ubuntu-bugsquad at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120829/fb869657/attachment.html>