[gentoo-amd64] Tracking down dependencies - x11-proto/printproto x11-apps/xdpyinfo

[gentoo-amd64] Tracking down dependencies - x11-proto/printproto x11-apps/xdpyinfo

[Daiajo Tibdixious]

I don't have a printer, and never expect to have one, so I try to
remove any print related packages,
and I'm currently targetting x11-proto/printproto.

This package is conditional on the "xprint" USE flag in
x11-base/xorg-server which is OFF in emerge --info.

I recenly installed 64 bit firefox (thought I'd give it another go,
not working so hot that that's another rant) which includes
www-client/mozilla-launcher which has a hard dependency on
x11-apps/xdpyinfo.

x11-apps/xdpyinfo has a hard dependency on x11-proto/printproto
despite the code being conditional on xprint via the config
HAVE_X11_EXTENSIONS_PRINT_H, which will always be
true since the ebuild pulls it in.

Now I think there is a bug in the x11-apps/xdpyinfo ebuild. I changed
xdpyinfo-1.0.1.ebuild
34c34
<       xprint? ( x11-proto/printproto )"
---
>       x11-proto/printproto"
# ebuild xdpyinfo-1.0.1.ebuild digest

and tested it
# xdpyinfo > ~/tmp/xdpyinfo-before
# emerge -aC x11-proto/printproto
# emerge -a1 x11-apps/xdpyinfo
# xdpyinfo > ~/tmp/xdpyinfo-after
# diff ~/tmp/xdpyinfo-before ~/tmp/xdpyinfo-after
54d53
<   print screen:    no

The compile was clean, the baseline/regression test (rudimentary) worked well.

So my question is: is this enough to submit as a bug/feature request?
I ask because I've submitted quite a few bugs and gotten unpolite
responses on occassion, left out obvious information, and generally
looked like the dumb user I'm tring not to be.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Tracking down dependencies - x11-proto/printproto x11-apps/xdpyinfo

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On Saturday 24 February 2007 00:49, Daiajo Tibdixious wrote:

[snip: good info re: making a dependency optional]

Also, make that, when the use flag is disabled, the package refuses to link 
against xprintproto.  Otherwise, you can have a situation where xprintproto 
is unmerged by --depclean, but xdpyinfo is using it dispite the -xprint USE 
flag.

E.g.
xprintproto is merged as a dependency of X
xdpyinfo is merged (-xprint), but finds the appropriate header and links 
against xprintproto.
X is removed.
emerge --depclean thinks it can remove xprintproto, since xdpyinfo doesn't 
depend on it, despite being linked against it.

> The compile was clean, the baseline/regression test (rudimentary) worked
> well.

If the package comes with a testsuite, make sure to run that against both 
the 
old and new versions and hopefully you get similar results.

> So my question is: is this enough to submit as a bug/feature request?

Absolutely.  I've seen feature requests with much less info that eventually 
found a sympathetic developer. 

> I ask because I've submitted quite a few bugs and gotten unpolite
> responses on occassion, left out obvious information, and generally
> looked like the dumb user I'm tring not to be.

Unpolite responses "just happen".  The developers and bug-wrangler don't 
act 
with a single mind, so the unpolite ones aren't "checked" by the polite 
ones.  
In any case, I think you've done most of the work, so it shouldn't be too 
hard to get your feature-request approved.

*DO* give your emerge --info, although it may not seem relevant.
*DO* make the bug as a feature request, and set it's priority 
appropriately.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
New GPG Key!  Old key expires 2007-03-25.  Upgrade NOW!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Tracking down dependencies - x11-proto/printproto x11-apps/xdpyinfo

[Daiajo Tibdixious]

On 2/24/07, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> On Saturday 24 February 2007 00:49, Daiajo Tibdixious wrote:
> [snip: good info re: making a dependency optional]
> Also, make that, when the use flag is disabled, the package refuses to link
> against xprintproto.  Otherwise, you can have a situation where xprintproto
> is unmerged by --depclean, but xdpyinfo is using it dispite the -xprint USE
> flag.
> E.g.
> xprintproto is merged as a dependency of X
> xdpyinfo is merged (-xprint), but finds the appropriate header and links
> against xprintproto.
> X is removed.
> emerge --depclean thinks it can remove xprintproto, since xdpyinfo doesn't
> depend on it, despite being linked against it.

Okay, I don't understand enough about how USE flags modify compilation.
e.g.  x11-apps/xdpyinfo xdpyinfo.c (the only source file)
has
#ifdef INCLUDE_XPRINT_SUPPORT
#include <X11/extensions/Print.h>
#endif /* INCLUDE_XPRINT_SUPPORT */
yet this is defined by
# if HAVE_X11_EXTENSIONS_PRINT_H
#  define INCLUDE_XPRINT_SUPPORT
# endif
earlier in the program.
It may be because xdpyinfo doesn't have proper xprint conditionality
that it wasn't made
conditional in the ebuild.

Anyway good point with depclean, I have 2 other packages depending on
printproto:
x11-libs/libXp-1.0.0 XpNotifyPdm.c uses printproto, and its not conditional
x11-libs/openmotif  uses printproto in 3 includes, unconditionally
so the change to xdpyinfo doesn't get rid of printproto.

> If the package comes with a testsuite, make sure to run that against both
> the
> old and new versions and hopefully you get similar results.

Not that I can see, I'll remember.

> *DO* give your emerge --info, although it may not seem relevant.
> *DO* make the bug as a feature request, and set it's priority
> appropriately.
 Yeah, I'll include the source code snippets to.
xdpyinfo has some other dependencies, I'm going to check them as well,
just for 'fun'. :)

Actually xdpyinfo also depends on libXp and that explains why
printproto is unconditional,
I would have to go through it, and any others, and make printing
optional on xprint.

Hmm, I might shelve this until I understand how USE flags work, as I
have no idea how to implement conditionality with USE/configure.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] unsubscribe

[GizVee]

unsubscribe

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unsubscribe

[dustin]

Here's how to unsubscribe:

First, ask your Internet Provider to mail you an Unsubscribing Kit.
Then follow these directions.

The kit will most likely be the standard no-fault type. Depending on
requirements, System A and/or System B can be used. When operating
System A, depress lever and a plastic dalkron unsubscriber will be
dispensed through the slot immediately underneath. When you have
fastened the adhesive lip, attach connection marked by the large "X"
outlet hose. Twist the silver-coloured ring one inch below the
connection point until you feel it lock.

The kit is now ready for use. The Cin-Eliminator is activated by the
small switch on the lip.  When securing, twist the ring back to its
initial condition, so that the two orange lines meet.  Disconnect.
Place the dalkron unsubscriber in the vacuum receptacle to the rear.
Activate by pressing the blue button.

The controls for System B are located on the opposite side. The red
release switch places the Cin-Eliminator into position; it can be
adjusted manually up or down by pressing the blue manual release button.
The opening is self-adjusting. To secure after use, press the green
button, which simultaneously activates the evaporator and returns the
Cin-Eliminator to its storage position.

You may log off if the green exit light is on over the evaporator.  If
the red light is illuminated, one of the Cin-Eliminator requirements has
not been properly implemented. Press the "List Guy" call button on the
right of the evaporator. He will secure all facilities from his control
panel.

To use the Auto-Unsub, first undress and place all your clothes in the
clothes rack. Put on the velcro slippers located in the cabinet
immediately below. Enter the shower, taking the entire kit with you. On
the control panel to your upper right upon entering you will see a
"Shower seal" button. Press to activate. A green light will then be
illuminated immediately below. On the intensity knob, select the desired
setting. Now depress the Auto-Unsub activation lever. Bathe normally.

The Auto-Unsub will automatically go off after three minutes unless you
activate the "Manual off" override switch by flipping it up. When you
are ready to leave, press the blue "Shower seal" release button. The
door will open and you may leave. Please remove the velcro slippers and
place them in their container.

If you prefer the ultrasonic log-off mode, press the indicated blue
button. When the twin panels open, pull forward by rings A & B. The knob
to the left, just below the blue light, has three settings, low, medium
or high. For normal use, the medium setting is suggested.

After these settings have been made, you can activate the device by
switching to the "ON" position the clearly marked red switch. If during
the unsubscribing operation you wish to change the settings, place the
"manual off" override switch in the "OFF" position. You may now make the
change and repeat the cycle. When the green exit light goes on, you may
log off and have lunch. Please close the door behind you.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unsubscribe

[Thomas Rösner]

dustin@v.igoro.us schrieb:
> Here's how to unsubscribe:
>   
[...]

It's getting funnier every single time.

Regards,
    Thomas
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unsubscribe

[Ryan Sims]

On 4/2/07, Thomas Rösner <Thomas.Roesner@digital-trauma.de> wrote:
> dustin@v.igoro.us schrieb:
> > Here's how to unsubscribe:
> >
> [...]
>
> It's getting funnier every single time.
>
> Regards,
>     Thomas

Maybe we should set up a rotation so we all get a turn at being snarky. ;)

-- 
Ryan W Sims
--
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] unsubscribe

[Guillermo A. Amaral]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Monday 02 April 2007, dustin@v.igoro.us wrote:
> Here's how to unsubscribe:
>
> First, ask your Internet Provider to mail you an Unsubscribing Kit.
> Then follow these directions.
>
> [snip]
>

Bloody hell... so that's what got mailed to me by mistake...	
 
-- 
Guillermo A. Amaral, CSE
# Free & Open Source Advocate
& nick: guillermoamaral
@ blog: http://blog.guillermoamaral.com/
@ site: http://www.guillermoamaral.com/
$  irc: guillermoamaral@freenode
%  gpg: http://downloads.guillermoamaral.com/public.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]