For some reason beyond my understanding, we have the cups useflag
enabled by default in profiles. This has started to generate circular
dependencies, at least for desktop profile users (gtk -> cups ->
poppler -> gtk). I propose we no longer enable the cups useflag.
Cheers,
--
Ben de Groot
Gentoo
On 03/01/2010 01:24 PM, Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles. This has started to generate circular
> dependencies, at least for desktop profile users (gtk -> cups ->
> poppler -> gtk). I propose we no longer enable
On Mon, Mar 1, 2010 at 22:24, Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles.
I'm +1 on disabling it by default.
Cheers,
Dirkjan
On 03/01/2010 11:24 PM, Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles. This has started to generate circular
> dependencies, at least for desktop profile users (gtk -> cups ->
> poppler -> gtk). I propose we no longer enable
On Monday 01 of March 2010 22:24:56 Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles. This has started to generate circular
> dependencies, at least for desktop profile users (gtk -> cups ->
> poppler -> gtk). I propose we no l
.
Sylvain
> Date: Tue, 2 Mar 2010 00:06:10 +0200
> From: ssuomi...@gentoo.org
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] [RFC] Remove cups from default profile to solve
> circular deps
>
> On 03/01/2010 11:24 PM, Ben de Groot wrote:
> > For some reason beyo
On 3/1/10 11:09 PM, Maciej Mrozowski wrote:
> On Monday 01 of March 2010 22:24:56 Ben de Groot wrote:
>> For some reason beyond my understanding, we have the cups useflag
>> enabled by default in profiles. This has started to generate circular
>> dependencies, at least for desktop profile users (gt
On 03/02/2010 07:53 AM, "Paweł Hajdan, Jr." wrote:
> On 3/1/10 11:09 PM, Maciej Mrozowski wrote:
>> On Monday 01 of March 2010 22:24:56 Ben de Groot wrote:
>>> For some reason beyond my understanding, we have the cups useflag
>>> enabled by default in profiles. This has started to generate circular
On Monday 01 March 2010 23:24:56 Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles. This has started to generate circular
> dependencies, at least for desktop profile users (gtk -> cups ->
> poppler -> gtk). I propose we no long
On E, 2010-03-01 at 13:40 -0800, Zac Medico wrote:
> On 03/01/2010 01:24 PM, Ben de Groot wrote:
> > For some reason beyond my understanding, we have the cups useflag
> > enabled by default in profiles. This has started to generate circular
> > dependencies, at least for desktop profile users (gtk
On Thu, Mar 4, 2010 at 12:15 AM, Mart Raudsepp wrote:
> I don't think there was any such problem until poppler maintainers
> decided to unsplit poppler into one big packages with USE flags again
> instead of the nice split poppler, poppler-glib (that should have been
> named poppler-cairo probably
On 3 March 2010 19:45, Mart Raudsepp wrote:
> I don't believe we should selectively cripple one GUI toolkit with not
> having proper printing support out of the box on a desktop profile,
> while others do, just because maintainers are lazy.
I'm not talking about selectively disabling cups. My pro
On 3 March 2010 19:54, Nirbheek Chauhan wrote:
> Also of note is that we've made efforts to split packages to avoid
> circular dependencies[1]. So it's really silly to add circular deps by
> un-splitting packages.
I think it's silly to split packages for no good reason. And doing it to
avoid circ
On 03/03/10 15:51, Ben de Groot wrote:
> On 3 March 2010 19:45, Mart Raudsepp wrote:
>
>> I don't believe we should selectively cripple one GUI toolkit with not
>> having proper printing support out of the box on a desktop profile,
>> while others do, just because maintainers are lazy.
>>
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/10 15:51, Ben de Groot wrote:
On 3 March 2010 19:45, Mart Raudsepp wrote:
I don't believe we should selectively cripple one GUI toolkit with not
having proper printing support out of the box on a desktop profile,
w
I'm not talking about selectively disabling cups. My proposal is
>>> to no longer enable the cups useflag in the base profile. I don't
>>> think cups should be part of the base profile, and as a result
>>> cascading to the desktop profile. And a lot of people seem to
>>> agree. Users can always ena
chrome://messenger/locale/messengercompose/composeMsgs.properties:
I'm not talking about selectively disabling cups. My proposal is
to no longer enable the cups useflag in the base profile. I don't
think cups should be part of the base profile, and as a result
cascading to the desktop profil
On 03/03/10 20:17, Dale wrote:
> chrome://messenger/locale/messengercompose/composeMsgs.properties:
>> I'm not talking about selectively disabling cups. My proposal is
>>
> to no longer enable the cups useflag in the base profile. I don't
> think cups should be part of the base profile,
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/10 20:17, Dale wrote:
chrome://messenger/locale/messengercompose/composeMsgs.properties:
I'm not talking about selectively disabling cups. My proposal is
to no longer enable the cups useflag in the base profile. I don'
On 03/03/2010 09:41 PM, Dale wrote:
So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?
Agreed that there should be better ways of handling things.
However, at the very least if so
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/2010 09:41 PM, Dale wrote:
So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?
Agreed that there should
On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
> On 3 March 2010 19:45, Mart Raudsepp wrote:
> > I don't believe we should selectively cripple one GUI toolkit with not
> > having proper printing support out of the box on a desktop profile,
> > while others do, just because maintainers are
> On 3 March 2010 19:45, Mart Raudsepp wrote:
> > I don't believe we should selectively cripple one GUI toolkit with not
> > having proper printing support out of the box on a desktop profile,
> > while others do, just because maintainers are lazy.
>
> It is not something that is necessary for r
On Wed, Mar 03, 2010 at 11:08:07PM -0800, Joshua Saddler wrote:
>
> > On 3 March 2010 19:45, Mart Raudsepp wrote:
> > > I don't believe we should selectively cripple one GUI toolkit with not
> > > having proper printing support out of the box on a desktop profile,
> > > while others do, just beca
2010/3/4 Dawid Węgliński :
> On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
>> I'm not talking about selectively disabling cups. My proposal is
>> to no longer enable the cups useflag in the base profile.
>
> How is that going to fix circular dependency problem? What will you do if
> ever
On 4 March 2010 08:27, Zeerak Mustafa Waseem wrote:
> Isn't the split of the desktop profile, into KDE and gnome profiles, whilst
> leaving a base Desktop profile, exactly meant for the purpose that if you're
> not building KDE/Gnome, then you don't need to set the qt flags, unless some
> appli
On 4 March 2010 08:08, Joshua Saddler wrote:
> Your logic is very thin here. By that same line of reasoning, neither are the
> gtk or qt flags, since you don't need 'em if you're building, say, a *box
> desktop.
Toolkits are more directly useful to a desktop than printing.
> Printing is someth
At Wed, 03 Mar 2010 21:19:42 -0600,
Dale wrote:
> Now watch some geek find a really simple solution next week. ;-)
I'm not very expirienced at gentoo development, but I just thought of (I
hope) a possible solution to this.
A circular dependency should always be caused by some USE flags (otherwis
On 03/03/2010 07:45 PM, Mart Raudsepp wrote:
> I don't think there was any such problem until poppler maintainers
> decided to unsplit poppler into one big packages with USE flags again
> instead of the nice split poppler, poppler-glib (that should have been
> named poppler-cairo probably instead),
On N, 2010-03-04 at 12:50 +0100, Ben de Groot wrote:
> 2010/3/4 Dawid Węgliński :
> > On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
> >> I'm not talking about selectively disabling cups. My proposal is
> >> to no longer enable the cups useflag in the base profile.
> >
> > How is that goi
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 4 March 2010 08:08, Joshua Saddler wrote:
Your logic is very thin here. By that same line of reasoning, neither are the
gtk or qt flags, since you don't need 'em if you're building, say, a *box
desktop.
Toolkits
On Thu, Mar 4, 2010 at 21:01, Dale wrote:
> Sounds like your argument is more like a opinion. I built my desktop about
Since people keep talking about not wanting cups disabled for the
desktop profiles, can we at least agree that it should be disabled by
default for the non-desktop profiles?
Ch
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On Thu, Mar 4, 2010 at 21:01, Dale wrote:
Sounds like your argument is more like a opinion. I built my desktop about
Since people keep talking about not wanting cups disabled for the
desktop profiles, can we at least
On 4 March 2010 21:01, Dale wrote:
> Removing the cups USE flag still doesn't fix the problem I pointed out in
> another reply. If you unpack the tarball and set the USE line as you
> should, the circular dependency is still there. Correct? So nothing is
> "fixed" by doing this.
What it fixes
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 4 March 2010 21:01, Dale wrote:
Removing the cups USE flag still doesn't fix the problem I pointed out in
another reply. If you unpack the tarball and set the USE line as you
should, the circular dependency is still ther
On 4 March 2010 23:34, Dale wrote:
[...]
>> What it does not fix is the case of users who enable both cairo and
>> cups useflags on a system where neither gtk+ nor cups is present
>> yet. [...]
>
> In the other post, I explained how this will not fix this at all.
So we agree there. You did not se
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 4 March 2010 23:34, Dale wrote:
[...]
What it does not fix is the case of users who enable both cairo and
cups useflags on a system where neither gtk+ nor cups is present
yet. [...]
In the other post, I explained
On 5 March 2010 00:27, Dale wrote:
But this issue can be discussed separately from whether cups
should be enabled in profiles.
>
> Actually, it is the problem. You want to remove cups to solve the problem
> of circular dependencies.
What I wrote was:
>> What it fixes is (1) the circul
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 5 March 2010 00:27, Dale wrote:
But this issue can be discussed separately from whether cups
should be enabled in profiles.
Actually, it is the problem. You want to remove cups to solve the problem
of circul
Hi,
On 2010-03-05 00:00 UTC Dale wrote:
> chrome://messenger/locale/messengercompose/composeMsgs.properties:
> > On 5 March 2010 00:27, Dale wrote:
> > But this issue can be discussed separately from whether cups
> > should be enabled in profiles.
> >>
> >> Actually, it is the problem.
On 03/04/2010 08:57 PM, Patrick Nagel wrote:
Obviously, users who "re-install" Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just following
the guide and getting their first Gentoo experience.
I think that the cups issue is probably worth m
chrome://messenger/locale/messengercompose/composeMsgs.properties:
Hi,
On 2010-03-05 00:00 UTC Dale wrote:
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 5 March 2010 00:27, Dale wrote:
But this issue can be discussed separately from whether cups
sho
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/04/2010 08:57 PM, Patrick Nagel wrote:
Obviously, users who "re-install" Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just
following
the guide and getting their firs
Richard Freeman writes:
> I think that is separate from the circular dependency issue. As long
> as we have an unresolved circular dependency I think cups should be
> off the list. However, I'd be the first to agree that this is a
> short-term solution.
>
> The problem is that we only have two
chrome://messenger/locale/messengercompose/composeMsgs.properties:
Richard Freeman writes:
I think that is separate from the circular dependency issue. As long
as we have an unresolved circular dependency I think cups should be
off the list. However, I'd be the first to agree that this i
On Thu, Mar 04, 2010 at 10:19:05PM -0600, Dale wrote:
> chrome://messenger/locale/messengercompose/composeMsgs.properties:
> > Richard Freeman writes:
> >
> >
> >> I think that is separate from the circular dependency issue. As long
> >> as we have an unresolved circular dependency I think cu
On 5 March 2010 04:18, Graham Murray wrote:
> Is there not a third, maybe obvious, solution to circular dependencies
> on initial install?
>
> 3. Include one or both of the packages in the stage tarball.
None of the packages involved (gtk+, cups and poppler) is in any
shape or form essential, so
On 2010.03.04 02:17, Dale wrote:
[snip]
>
> Let just think of it this way. I have to reinstall say from a dead
> hard
> drive. I have copies of my make.conf and world file. I install my
> new
> drive, download the tarball and unpack it. I copy over make.conf and
> world. Naturally cups wi
On Friday 05 March 2010 17:12:23 Roy Bamford wrote:
>
> That's not a new install as per the handbook. Neither are you a new
> user as you have a premade make.conf and world file and some experience
> with Gentoo.
>
> Put yourself in the place of a brand new Gentoo user doing his/her
> first inst
El vie, 05-03-2010 a las 19:03 +0100, Dawid Węgliński escribió:
> On Friday 05 March 2010 17:12:23 Roy Bamford wrote:
>
> >
> > That's not a new install as per the handbook. Neither are you a new
> > user as you have a premade make.conf and world file and some experience
> > with Gentoo.
> >
> >
chrome://messenger/locale/messengercompose/composeMsgs.properties:
El vie, 05-03-2010 a las 19:03 +0100, Dawid Węgliński escribió:
On Friday 05 March 2010 17:12:23 Roy Bamford wrote:
That's not a new install as per the handbook. Neither are you a new
user as you have a premade make.c
On Monday 01 of March 2010 22:24:56 Ben de Groot wrote:
> For some reason beyond my understanding, we have the cups useflag
> enabled by default in profiles. This has started to generate circular
> dependencies, at least for desktop profile users (gtk -> cups ->
> poppler -> gtk). I propose we no l
On 5 March 2010 21:51, Maciej Mrozowski wrote:
> poppler[utils] are just pdfto*sth converters, and they're most likely pure
> runtime depedencies for net-print/cups. Could someone from printing herd
> verify?
> If so, then it's sufficient to fix cups dependencies (move poppler[utils] from
> COMMON
On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot wrote:
>> If no, I can split off utils from poppler - with CMake it's effortless.
>
> We just rejoined the split poppler into one package again. So if you
> are going to split it up again, you will have some explaining to do to
> our users. I would like
On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot wrote:
> On 5 March 2010 21:51, Maciej Mrozowski wrote:
>> If no, I can split off utils from poppler - with CMake it's effortless.
>
> We just rejoined the split poppler into one package again. So if you
> are going to split it up again, you will have
El vie, 05-03-2010 a las 22:06 +0100, Ben de Groot escribió:
>
> > If no, I can split off utils from poppler - with CMake it's effortless.
>
> We just rejoined the split poppler into one package again. So if you
> are going to split it up again, you will have some explaining to do to
> our users.
On 6 March 2010 10:11, Nirbheek Chauhan wrote:
> On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot wrote:
>>> If no, I can split off utils from poppler - with CMake it's effortless.
>>
>> We just rejoined the split poppler into one package again. So if you
>> are going to split it up again, you will h
On 03/05/2010 08:06 AM, Ben de Groot wrote:
On 5 March 2010 04:18, Graham Murray wrote:
3. Include one or both of the packages in the stage tarball.
None of the packages involved (gtk+, cups and poppler) is in any
shape or form essential, so you will have a very hard time convincing
people th
On 03/06/2010 04:24 AM, Richard Freeman wrote:
> On 03/05/2010 08:06 AM, Ben de Groot wrote:
>> On 5 March 2010 04:18, Graham Murray wrote:
>>> 3. Include one or both of the packages in the stage tarball.
>> None of the packages involved (gtk+, cups and poppler) is in any
>> shape or form essenti
On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot wrote:
> Would it be possible to make cups a PDEPEND in gtk+ or is it really
> needed at compile time?
>
cups is definitely needed at compile-time
> The same for cups: can we make poppler a PDEPEND? Maciej, did
> you get any further with looking into
On Saturday 06 of March 2010 18:05:20 Nirbheek Chauhan wrote:
> On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot wrote:
> > Would it be possible to make cups a PDEPEND in gtk+ or is it really
> > needed at compile time?
>
> cups is definitely needed at compile-time
>
> > The same for cups: can we ma
On Sex, 2010-03-05 at 19:03 +0100, Dawid Węgliński wrote:
> On Friday 05 March 2010 17:12:23 Roy Bamford wrote:
>
> >
> > That's not a new install as per the handbook. Neither are you a new
> > user as you have a premade make.conf and world file and some experience
> > with Gentoo.
> >
> > Put y
* Maciej Mrozowski schrieb:
Hi,
> Apart from PDEPEND, one change needed as well in cups ebuilds:
> --with-pdftops pdftops
> needs to be replaced with
> --with-pdftops=/usr/bin/pdftops
>
> as otherwise it will fail during configure phase (giving absolute path
> disables autodetection)
Hardcodi
* Nirbheek Chauhan schrieb:
> On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot wrote:
> > Would it be possible to make cups a PDEPEND in gtk+ or is it really
> > needed at compile time?
> >
>
> cups is definitely needed at compile-time
Does anyone know what exactly for ?
Didnt have the time for an
On Thu, Apr 8, 2010 at 4:13 AM, Enrico Weigelt wrote:
> * Nirbheek Chauhan schrieb:
>> On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot wrote:
>> > Would it be possible to make cups a PDEPEND in gtk+ or is it really
>> > needed at compile time?
>> >
>>
>> cups is definitely needed at compile-time
>
* Nirbheek Chauhan schrieb:
> If it turns out there is no easier way of properly fixing this,
> we may have to split poppler-utils out from poppler.
ACK. Having separate packages for public libraries and utils
which just happen to use these libs should be the default case.
Not just because of
* Ben de Groot schrieb:
> Or maybe the gtk+ maintainers want to split up their package...
Actually, that would be a big step forward ...
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
---
Why are you replying to a thread that has already been resolved? Please stop.
On Thu, Apr 8, 2010 at 4:43 AM, Enrico Weigelt wrote:
> * Nirbheek Chauhan schrieb:
>
>> If it turns out there is no easier way of properly fixing this,
>> we may have to split poppler-utils out from poppler.
>
> ACK.
* Nirbheek Chauhan schrieb:
> > Does anyone know what exactly for ?
> > Didnt have the time for an deeper investigation, but if an widget
> > toolkit requires an printing service, something really strange
> > is happening, IMHO ... ;-o
> >
>
> Download the gtk+ tarball and take a peek inside ./m
69 matches
Mail list logo
