Bug 3044

If I'am not wrong the script use curl:
http://svnweb.mageia.org/packages/cauldron/flash-player-plugin/current/SPECS/flash-player-plugin.spec?revision=152544&view=markup

Assignee: bugsquad => anssi.hannula

It's not really clear why curl is used here instead of aria2c which is used by urpmi itself: if the necessary proxy input is already in the environment, re-using aria2c could maybe help?

Anyway, here comes at least a manual and practical workaround in 3 steps, would it be useful for anyone, one day. :-)


* download the proposed .tar.gz file, example for 64 bits:
http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_11_linux.x86_64.tar.gz
* store it under that precise name and location:
/var/lib/flash-player-plugin/flash-plugin-11.0.1.152-release.x86_64.rpm
* re-run the update procedure
It will still fail to download the file, but it will find the manually placed one: install done.


Actually, the SPEC file is greatly helpful to explain how to proceed.
As suggested in the SPEC file, the .tar.gz file is the preferred byte-pack to retrieve for 64bits systems due to its more complete content.

That .tar.gz file is to be downloaded using curl and saved as %file.
But what is %file really?
Inside the SPEC file, we see (example here for a 64bits system):
%define tarname flash-plugin-%{version}-release.x86_64.rpm 
%define file %{_localstatedir}/lib/%{name}/%{tarname}

Hence for this version of the plug-in, the final filename must be:
/var/lib/flash-player-plugin/flash-plugin-11.0.1.152-release.x86_64.rpm

Well, urpmi specifies the proxy via a command-line parameter to aria2, so simply switching the script to use aria2 wouldn't directly work AFAICS.

I'll have to think about the best solution to this, maybe just calling the urpmi perl functions for getting the proper proxy commandline.

BTW, for anyone using the workaround described in comment #2 in the meantime, with the next updated package (which is shortly pushed to nonfree/updates), you need to use the URLs
http://linuxdownload.adobe.com/linux/i386/flash-plugin-$FLASHVER-release.i386.rpm
http://linuxdownload.adobe.com/linux/x86_64/flash-plugin-$FLASHVER-release.x86_64.rpm
with $FLASHVER replaced by the flash version, instead of the tarball.

Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

@ Anssi

Please set status to ASSIGNED. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

CC: (none) => marja11

The new 11.1.102.62 packages just submitted to mga1 nonfree/updates_testing now use the proxy settings of urpmi/RPMDrake. Please test if possible. This update is followed in bug #4561.

I'm sorry for the delay. I had already applied a fix for this in December and intended for the fix to be shipped with the next version update. Had I known it would take this long, I would've submitted it immediately...

Just tested it a few seconds ago, works like a charm!

I also has look at the changes there:
http://svnweb.mageia.org/packages/cauldron/flash-player-plugin/current/SPECS/flash-player-plugin.spec?revision=210094&view=markup
Very elegant. :-)

OK, it might require more testing with different kinds of proxies (FTP, HTTP, ...) and authentications (anonymous, specific user & password) before closing the bug, to be on the safe side. However, in my case (HTTP proxy + user&password), that's perfect.

Thank you very much for this update Anssi!

(In reply to comment #6)
> Just tested it a few seconds ago, works like a charm!
> 
> I also has look at the changes there:
> http://svnweb.mageia.org/packages/cauldron/flash-player-plugin/current/SPECS/flash-player-plugin.spec?revision=210094&view=markup
> Very elegant. :-)
> 
> OK, it might require more testing with different kinds of proxies (FTP, HTTP,
> ...) and authentications (anonymous, specific user & password) before closing
> the bug, to be on the safe side. However, in my case (HTTP proxy +
> user&password), that's perfect.
> 
> Thank you very much for this update Anssi!

Thank you for the feed back

There is no one using a different proxy or authentication in the cc of this bug report, so closing

Of course, when needed, anyone is free to reopen this report

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

Not my cup of tea, but thinking... 

What if urpmi is set to use urpmi-proxy on one machine, and the general proxy (e.g squid) is on another machine?

I guess urpmi-proxy can not fetch the adobe content?

(It worked for me now, having urpmi-proxy and squid on same LAN server.)

CC: (none) => fri

Good points.

Fabien, what are the contents of your /etc/profile.d/proxy.sh ?

(In reply to comment #9)
> Good points.
> 
> Fabien, what are the contents of your /etc/profile.d/proxy.sh ?

reopening and setting NEEDINFO keyword

Keywords: (none) => NEEDINFO

(In reply to comment #10)
> (In reply to comment #9)
> > Good points.
> > 
> > Fabien, what are the contents of your /etc/profile.d/proxy.sh ?
> 
> reopening and setting NEEDINFO keyword

again reopening

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED

(In reply to comment #9)
> Good points.
> 
> Fabien, what are the contents of your /etc/profile.d/proxy.sh ?

I'm afraid I don't have any /etc/profile.d/proxy.sh file...

So, in my specific case, I have similar data in /etc/urpmi/proxy.cfg (somehow root settings) and in my firefox configuration (regular user settings).
Hence, for me, it's a bit similar to Morgan Leijström's configuration.

Would I have a urpmi-proxy specific configuration differing from the "squid-proxy" dubbed configuration, I'm afraid the only way would be to process the download manually, as described when the retrieval fails, placing the file under the name and location I mentioned at comment #2 in my personal workaround...

A possible alternative is having a second set of proxy parameters in the /etc/urpmi/proxy.cfg file... but it might be the purpose of that /etc/profile.d/proxy.sh file I don't have. :-)

/etc/profile.d/proxy.sh is a file set by 'MCC => Network and Internet => Proxy server', I think. Can you confirm you have nothing set there?

If so, I'm a bit unsure what to do... Some other users like Fabien may also not have set their proxy settings there, so just using /etc/profile.d/proxy.sh would not work for them.

But no one has yet confirmed that using /etc/urpmi/proxy.cfg breaks something. So, Morgan, I'm not sure I understand, how does having 'squid' on the same host as 'urpmi-proxy' affect urpmi-proxy working for adobe content? Does 'urpmi-proxy' somehow forward the request to 'squid'?

Now i know this update in question worked for my main machine as it do not *need* to go through the http proxy (it is intended just to save gigabytes per month). This my main machine have each client proxy setting set individually (I could not make BOINC-manager happy despite exceptions in proxy settings) so BOTH /etc/urpmi/proxy.cfg and /etc/profile.d/proxy.sh are empty.

It worked on my other machines where on all my machines which are set to use proxy through /etc/profile.d/proxy.sh set by 'MCC => Network and Internet => Proxy server'.

On all machines i set urpmi sources with the adress of my urpmi-proxy; i actually have not set any proxy settings for urpmi. ( the IP included in media setting IS the proxy; ( I used urpmi.addmedia --distrib http://my.urpmi-proxy.IP/mageia/distrib/1/x86_64 )

I have urpmi-proxy on same host as squid and have no problems with it.

_____BUT i was thinking:

1) What if some user set their urpmi proxy setting to some proxy that is not capeable of serving http generally? (only intended for urpmi)
Maybe that is a long shot not needed to take into account?

2) What if some user similar to me do not set general proxy (/etc/profile.d/proxy.sh is empty, and set all their browsers etc proxy settings manually), set their repo sources like me pointing directly to their proxy (/etc/urpmi/proxy.cfg is empty), AND they can only reach internet through the special proxy they set up in the clients.  How to make flash installer know that proxy?


I believe by 1) that /etc/urpmi/proxy.cfg should not be considered, but settings should optimally be gathered from browser settings... looking for any browser that the plugin supports... but it seems too complicated and not future proof...

And if i understand correctly: proxy is set by /etc/profile.d/proxy.sh, then it is used by the adobe installer automatically?

I believe this bug in current state is not completely fixed, but could be set low pri as i believe very few user may experience problem from it.

Anssi, as your code is looping to try downloading the Adobe software from different sources, maybe one possibility could be multiple loops: one per set of proxies (provided they are different ones), stopping if at least one download is successful.

Would each download attempt fail, like it would happen for case 2) in the comment above, then remains the manual workaround: suggesting the user to download the software, to place it under the expected name at a designed place, and to re-run the update.

Somehow, this is a best effort solution. Not having a way to feed urpmi with the right proxy input (by means of /etc/urpmi/proxy.cfg or /etc/profile.d/proxy.sh) is making it too complex for the tool to search for the data. Starting to guess by inspecting potential web browser configurations of root or tons of users is not a good idea...

removing the NEEDINFO keyword

Keywords: NEEDINFO => (none)

There is another problem here (still valid in mga2 package).  flash-player-plugin Requires(pre): curl, which means it forces curl onto your system to install it.  curl does not seem to respect the no_proxy environment variable of the proxy settings.  For me with my setup at work on some VMs that use a local mirror (which is not accessible through the proxy), having curl installed breaks urpmi.  I always uninstall it so that it uses wget.  I can imagine a reverse situation for some people where curl will not work for some people for a downloader in this package if they need to bypass the proxy to get to the internet.  For me it's just annoying having to uninstall curl again after each time upgrading flash (yes I know you can set the urpmi downloader in its settings, but I don't want to have to keep doing that on every new VM here).

It would be better if flash-player-plugin would Requires(pre): webfetch and the %pre script would detect if curl's not available and then use wget instead.

CC: (none) => luigiwalser

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

Maybe a look at this forum thread may be useful. It affects not only flash itself, but proxy configuration at all, impairing download of all packages:

https://forums.mageia.org/en/viewtopic.php?f=25&t=4780

I noticed urpmi does not follow some parameters, despite you instruct it to do so.

CC: (none) => luzemario

There are a bunch of different issues noted in that forum thread.

One is that curl doesn't work very well with proxy settings, as I noted in Comment 17, so it'd be good to not use curl in the scriplets in this package (or at least have it use wget if that's available).

The other issues from that thread have no relevance to this bug.  One is that you said gurpmi isn't respecting the urpmi configuration.  If that's true, you should file a bug for that.

The other is that if you use mirrorlist mirrors, it will use rsync for some of them, which doesn't work if you have to use a proxy, as rsync doesn't use the normal proxy settings which are only for http, https, and ftp.  rsync does have an environment variable it can use for its own proxy settings, but you have to set that yourself.

The point is the "dynamic" management of mirrors by urpmi. If current mirror is a rsync:// protocol, urpmi does not obey --curl or --wget parameter nor changes mirror to one wich is inside curl or wget protocols. It still keep trying with current mirror and using rsync. It will keep failing until urpmi detects the actual mirror has failed. It can be forever if you do not allow urpmi/downloader to timeout, wasting a bunch of time.

IMHO, urpmi could be more flexible in it's "dynamic" mirror management, allowing the user to change mirror via a future "--use-next-mirror" or "--use-http-mirror", "--use-ftp-mirror" or so parameter, or marking a checkbox of mirror possibilities grouped by protocol in gurpmi.

(In reply to David Walser from comment #21)
> There are a bunch of different issues noted in that forum thread.
> 
> One is that curl doesn't work very well with proxy settings, as I noted in
> Comment 17, so it'd be good to not use curl in the scriplets in this package
> (or at least have it use wget if that's available).
> 

I did make no testing with no_proxy environment variable yet, since all proxy traverse here is only possible by authenticating with proxy, as most restrictive IT admins do. AFAIK, curl is the only downloader to authenticate sucessfully with NTLM auth scheme. If you live in a Windows world as I do at work, you can't use other downloaders.

(In reply to Luzemário Dantas from comment #22)
> The point is the "dynamic" management of mirrors by urpmi. If current mirror
> is a rsync:// protocol, urpmi does not obey --curl or --wget parameter nor
> changes mirror to one wich is inside curl or wget protocols. It still keep
> trying with current mirror and using rsync. It will keep failing until urpmi
> detects the actual mirror has failed. It can be forever if you do not allow
> urpmi/downloader to timeout, wasting a bunch of time.

The downloader option only applies to the http and ftp protocols.  curl and wget don't support rsync.  The rsync command is the only one that can be used for the rsync protocol.  (and BTW curl and wget are programs, not protocols)

But yes, as I said, using rsync mirrors when you're behind a proxy causes issues that the tools aren't designed to help you work around, you have to do it manually.

*** Bug 5212 has been marked as a duplicate of this bug. ***

CC: (none) => tukozaki

Assigning to maintainer.

CC: (none) => stormi
Keywords: (none) => Triaged

(In reply to David Walser from comment #17)
> There is another problem here (still valid in mga2 package). 
> flash-player-plugin Requires(pre): curl, which means it forces curl onto
> your system to install it.  curl does not seem to respect the no_proxy
> environment variable of the proxy settings.  For me with my setup at work on
> some VMs that use a local mirror (which is not accessible through the
> proxy), having curl installed breaks urpmi.  I always uninstall it so that
> it uses wget.  I can imagine a reverse situation for some people where curl
> will not work for some people for a downloader in this package if they need
> to bypass the proxy to get to the internet.  For me it's just annoying
> having to uninstall curl again after each time upgrading flash (yes I know
> you can set the urpmi downloader in its settings, but I don't want to have
> to keep doing that on every new VM here).
> 
> It would be better if flash-player-plugin would Requires(pre): webfetch and
> the %pre script would detect if curl's not available and then use wget
> instead.

This bug report saw no action since over 2¾ years ago.

Is it still valid?

Whiteboard: MGA2TOO, MGA1TOO => (none)
Keywords: Triaged => NEEDINFO

Nothing has been done to address it.

curl seems to respect no_proxy now, so it's not as big of an issue most likely, but it still does force curl onto your system when it could be written to use either curl or wget, which would still be better.

Closing this.
Not worth looking into because few users are affected and flash is hard EOL after new years eve when it is supposed not to be able to be downloaded at all.

Resolution: (none) => OLD
Status: REOPENED => RESOLVED