Add spdx slug to all files

Is this a common and documented pattern?
It works quite well right now with all files supporting XML comments but I worried it won't scale very well. Considering future formats not supporting XML comments and potential issues related to comments being retrained in production environments where files could be compressed, merged, etc. It might be easier to explicitly list everything not under CC0 in the README.

Is this a common and documented pattern?
It works quite well right now with all files supporting XML comments but I worried it won't scale very well. Considering future formats not supporting XML comments and potential issues related to comments being retrained in production environments where files could be compressed, merged, etc. It might be easier to explicitly list everything not under CC0 in the README.

Yes, spdx is common and documented. It can also take any sort of comments, as explained on: https://spdx.dev/ids/
It's mandated for all public software in Italy and recommended by Standard for Public Code and many license compliance apps (like REUSE by FSFE) use it. The spdx specification is maintained by Linux Foundation.

SPDX-identifiers/the SPDX vocabulary I'm familiar with, however the comment practice is new to me.
It appears to be almost exclusively used within kernel development and I don't think it's a good fit for high-level development such as websites. Here are a few reasons that comes to mind:

Depending on file format the comment needs to be in particular locations (HTML is a great example)
It's not possible to ensure it's machine readable (comment syntax changes across files)
It only works in text files
Some formats doesn't support comments

Let's close this one now and perhaps come back to a complete solution later.

FSFEs REUSE project appears to be aimed at addressing the exact issues I'm outlining above:
https://reuse.software/
https://reuse.software/spec/#dep5

Yes. I suggest we keep this issue closed and create a new one for making the project REUSE compliant instead.


🗃 Setup Tables in the Database for User

Database Tables for User

[x] Coordinates
[x] Timezone
[x] Location
[x] Address
[x] Name
[x] Photo
[x] Identification
[x] Tenure
[x] Social Connections
[x] User

Closed in https://github.com/usamazansari/itinerary-assistant/commit/5f8ea2ee278a1692ffd79cec79db91b926bdb255

Raising a PR with proper table names


package removal ui issue

i have removed one version of package from Baget but  UI showing the deleted package name but not showing the next click options of the package ... please do the needful thanks

I'm also seeing this. Looks like it could be a serious issue as it seems to have rendered my entire nuget repository unusable.

nuget delete My.Package 9.9.9 -source baget
My.Package 9.9.9 will be deleted from the 'https://nuget.sbaylor.com'. Would you like to continue? (y/N) y
WARNING: Deleting My.Package 9.9.9 from the 'https://nuget.sbaylor.com'.
DELETE https://nuget.sbaylor.com/api/v2/package/My.Package/9.9.9
NoContent https://nuget.sbaylor.com/api/v2/package/My.Package/9.9.9 732ms
My.Package 9.9.9 was deleted successfully.

In visual studio when I now try to browse the source, in the manage nuget packages screen, it only shows "Error occured" in the window and this is in the package manager output;

[baget] 'doctype' is an unexpected token. The expected token is 'DOCTYPE'. Line 1, position 3.

Please take a look. My organization has lost access to all nuget packages!!

Yes , please give the solution for this..(facing package conflict issue after delete)

Hi, what are your PackageDeletionBehavior and AllowPackageOverwrites config values? What are your database and storage providers?

I wasn't able to reproduce this. Could you use a tool like Fiddler to see the request Visual Studio makes to BaGet that fails?

I haven't changed those from the defaults. I'm running the docker container.
baget.env
ApiKey=myapikey
Storage__Type=FileSystem
Storage__Path=/var/baget/packages
Database__Type=Sqlite
Database__ConnectionString=Data Source=/var/baget/baget.db
Search__Type=Database

(from docker inspect)

        "Env": [
            "ApiKey=myapikey",
            "Storage__Type=FileSystem",
            "Storage__Path=/var/baget/packages",
            "Database__Type=Sqlite",
            "Database__ConnectionString=Data Source=/var/baget/baget.db",
            "Search__Type=Database",
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "ASPNETCORE_URLS=http://+:80",
            "DOTNET_RUNNING_IN_CONTAINER=true",
            "ASPNETCORE_VERSION=2.2.7"
        ]

I think the visual studio problem might be something different. I omitted the "/v3/index.json" from my nuget source. The nuget and dotnet CLIs seem to be OK with that, but it seems visual studio doesn't like it. I think the bug to look for is in the web page. When you soft delete a version of a package, the page for that package doesn't render.

I think the bug to look for is in the web page. When you soft delete a version of a package, the page for that package doesn't render.

I'm unable to reproduce this issue. What version of BaGet are you on? What logs do you see? Can reproduce this using a clean installation? If so, please let me know the full steps.

I omitted the "/v3/index.json" from my nuget source.

Please be explicit and include /v3/index.json. The client has weird heuristics to try to make this work, but I wouldn't trust that.

I was able to reproduce it on both windows and linux. Here's how to reproduce it.

Create two versions of a nuget package.

 PS C:\baget> dir

     Directory: C:\baget

 Mode                LastWriteTime         Length Name
 ----                -------------         ------ ----
 -a----       10/23/2019   9:22 PM           3315 MyAwesomeLib.1.0.0.nupkg
 -a----       10/23/2019   9:22 PM           3314 MyAwesomeLib.1.0.1.nupkg

Spin up baget in docker.

PS C:\baget> docker run -d --name baget `
   -p <IP_ADDRESS>:80:80
   -e Storage__Type=FileSystem
   -e Storage__Path=/var/baget/packages
   -e Database__Type=Sqlite
   -e 'Database__ConnectionString=Data Source=/var/baget/baget.db'
   -e Search__Type=Database
   -v baget-vol:/var/baget
 loicsharma/baget:a96c134b8368fbf04b56400faa91aea2892bcf74
4bff3f2bf0cba3d4295dfd197263412a9cc56add1c02aca8637624e13638a893

Push both versions of the library

PS C:\baget> dotnet nuget push -s http://localhost/v3/index.json .\MyAwesomeLib.1.0.0.nupkg
warn : No API Key was provided and no API Key could be found for 'http://localhost/api/v2/package'. To save an API Key for a source use the 'setApiKey' command.
info : Pushing MyAwesomeLib.1.0.0.nupkg to 'http://localhost/api/v2/package'...
info :   PUT http://localhost/api/v2/package/
info :   Created http://localhost/api/v2/package/ 877ms
info : Your package was pushed.
PS C:\baget>
PS C:\baget> dotnet nuget push -s http://localhost/v3/index.json .\MyAwesomeLib.1.0.1.nupkg
warn : No API Key was provided and no API Key could be found for 'http://localhost/api/v2/package'. To save an API Key for a source use the 'setApiKey' command.
info : Pushing MyAwesomeLib.1.0.1.nupkg to 'http://localhost/api/v2/package'...
info :   PUT http://localhost/api/v2/package/
info :   Created http://localhost/api/v2/package/ 177ms
info : Your package was pushed.

Browse to http://localhost/packages/MyAwesomeLib
All is well. Should see both versions of the package.

Delete one of the versions:

PS C:\baget> nuget delete MyAwesomeLib 1.0.1 -s http://localhost/v3/index.json
WARNING: No API Key was provided and no API Key could be found for 'http://localhost/api/v2/package'. To save an API Key for a source use the 'setApiKey' command.
MyAwesomeLib 1.0.1 will be deleted from the 'http://localhost/api/v2/package'. Would you like to continue? (y/N) y
WARNING: Deleting MyAwesomeLib 1.0.1 from the 'http://localhost/api/v2/package'.
  DELETE http://localhost/api/v2/package/MyAwesomeLib/1.0.1
  NoContent http://localhost/api/v2/package/MyAwesomeLib/1.0.1 81ms
MyAwesomeLib 1.0.1 was deleted successfully.

Refresh page at http://localhost/packages/MyAwesomeLib

Only the header is rendered. :(

yes this is the issue please resolve,and how we can access the data base. please help out the problem.

Hi Stevenbaylor ,
Please give solution for above issue.
Thanks in advance.

please remove header rendering.. :-(

@gowtham4gs, I don't have the solution. I'm in the same boat as you.
As a work around you can open the baget.db file in Sqlite and delete rows in the tables that reference the unlisted package.

Ah the issue is that BaGet doesn't display unlisted packages, but, it displays the latest package regardless of whether it is listed or not. If the latest package happened to be unlisted, the UI would never show anything at all. This is fixed by https://github.com/loic-sharma/BaGet/issues/398

This should be fixed now. Please let me know if you run into any other issues!


Improve colors

This looks kinda funny

Also not sure these colors contrast enough to be accessible #23

Let's just do a white BG then.

I wonder if we could make the code blocks syntax highlighted 🤔

Or even better, instead of code blocks, most of them could be ReactLive right?

There are options in marked, and I think we can do highlighting.
We can make them react-live but it won't have that codepen-style like you linked. It'll have the preview above it like on the homepage. If we want that style we need to style it differently.
Also, if we do live embeds we're embedding a component in the markdown, so that's something someone will have to get done and might make the docs harder to maintain.

Yeah my bad for the pink background. It's because of the way I needed to implement the "g + pink background" in the main layout. So you need to specify a white background for every main container in a page :/

Yeah my bad for the pink background.

No worries, we're moving fast and breaking things :)
I really like the React Live stuff so yeah, let's make that happen. I wonder if we could do something with https://github.com/threepointone/markdown-in-js

Put the background color on the pseudo element?
Or make the markdown wrapper have the background color white.

@kentcdodds https://github.com/threepointone/markdown-in-js/issues/9

I feel no shame in basically taking heavy inspiration with regards to design from the styled-components website:

I'd like to move nav to the left (I think we've got an issue for that) on desktop and this experience for mobile:

Ah, gotcha with that markdown issue. We'll have to come up with something else then. 🤔  Definitely want to make it easy to translate :)

I hear you on the translation. This is why I went the way I did for the markdown, but I'm cool with a better solution if we can find one.
As for the nav and links, I agree with @kentcdodds. We can add links to the markdown in the webpack config for marked. The nav itself will have to be creative to be dynamic. (Like pull the headings out of the markdown or something).
I'm also still bothered that the markdown isn't SSR. Styled components hard coded their docs instead of .md files, and I'm super tempted to go down that road. We can do way more stuff if each section is a component.

I'd be fine putting stuff in non-.md files as long as editing the docs is simple enough. Though I'm not sure how crowdin works so that may not be possible. I'm looking into it right now.

I think using white background in the code block might also work. Do we want to give that a try first?

I tried it with a darker blue. Been busy today to keep up with the conversation!

Cool! Wonder if we can bump the font size 🤔

Would it be best to make mobile wireframes for everyone?

Yeah, more designs would definitely help 👍

On it! I should hopefully have something by tonight with anything from mobile and/or other pages. 👍

Awesome!

 1) Removed navbar and made it similar to styled-components navigation is handled after you go to the documentation.

Responsive mobile landing page.

Documentation page! This page I think I will need help on layout for where to display things from within the README and any other markdown file (CONTRIBUTING, CODE_OF_CONDUCT, and etc.)

Nice!
@jonmajorc the README and other root-level markdown documents aren't rendered in the site, so we don't need to design for them.

Thanks!
By "rendered", do you mean by verbatim the README pasted within the site? Currently docs is displaying what is inside the README.md.

You're right, it's taken from the glamorous README, but this repo's README isn't on the site. Nor would the other markdown files (CoC, license) be shown. They're just in the repo.
Also, the documentation might not stay 1-to-1 with the glamorous README. It'll likely diverge as the documentation improves.

Yeah, once this site is done, I'll update the glamorous README to be more project-information-type stuff, like babel's :)

Hey, sorry for the rework... 🙄 I think you all will like it though! (I think...) Download the zip and open each svg up in your browser! Hope you all enjoy!  I really like how Jest does their recognition for companies so ya'll will see that same idea within my designs. Anyways, check it out! I also included a design style guide (that is simple). I will try not to change anything now... 🙃
glamorous_site.zip

Sweet! Here are screenshots of those designs (for folks who don't wanna download it):

We really need to get some of those companies using glamorous ;-)

Thanks for all this work @jonmajorc! I can see a lot of thought went into it!
I do have a few issues with these new designs I'd like to discuss. I think they're fairly minor:

We lost the main omnipresent navigation, which is critical to keep. On mobile I think the hidden nav can be more obvious. Say what you will about the hamburger icon, but most people know what it is. 😀
I'm not crazy about the logos of companies that use glamorous. It's inaccurate and clashes with the design. I really liked the original way you listed them as just white text, and would be cool with a single color svg outline of the logos. The full color logos is just too much IMO. (Side note: FPOs should not use logos we don't have permission to use. I don't want to step on anyone's toes. 😉)
I'm a little lost with the navigation, and with @kentcdodds' recent translation work I think we need to revisit this separately and make a site map to clarify it all. The design of the navigation is cool! Again, on desktop the top level nav should be always visible I think. (There's so much space anyway.)
*The locale selector is super styled, and IME heavily styled selects become a11y issues. A CSS wiz might have a solution I don't, but we need to give that some thought especially in light of the implementation we started in #41. These are going to be links to the current page in available languages, so how we want to implement it I'm not 100% sure of.

Overall I think we have a great design here and implemented in the code base.  Really great work @jonmajorc! 🙌🙌
Anyone have thoughts or comments? Anyone want to tackle some of these style updates?

Thanks @paulmolluzzo ! Great feedback!

We lost the main omnipresent navigation, which is critical to keep. On mobile I think the hidden nav can be more obvious. Say what you will about the hamburger icon, but most people know what it is. 😀

I agree with you on this! I had that originally but I changed it because I had something conflicting in the same area that is no longer there.  It's inaccurate and clashes with the design. I really liked the original way you listed them as just white text, and would be cool with a single color svg outline of the logos. The full color logos is just too much IMO. (Side note: FPOs should not use logos we don't have permission to use. I don't want to step on anyone's toes. 😉)

Yeah I figured that be an issue... Babel and Jest does it the way by providing companies' actual logos. I fear the original look with the white text won't look as nice when we scale the amount of companies. i.e: Babel and Jest have at the bottom their home page the users using their tool and you can click to see additional users. I like that idea of potentially seeing more user and the ability to add your company as user through a PR like both Babel and Jest has. Side note, what is FPO?
Navigation we can keep how it was and then we can easily add more navbar items! Yeah, the locale dropdown I am unsure how to handle that as a dropdown; however, having the navbar back we can do it like Jest does!

Thanks again for the comments! 👍

I think we should push the "Used By" stuff to after initial release. We still need to get more companies using/reporting their usage of glamorous :) We can talk about how to do it then.
For language selection, I'm fine with what's in the design already. I really don't care too much actually :)
I'm going to file an issue for search. That'd be great to get. Unsure how to go about that.

I fear the original look with the white text won't look as nice when we scale the amount of companies.

Future problem. I think we can do original release with no logos at all.
FPO = For Placement Only

I think we can do original release with no logos at all.

To take it further... I think we can do the initial release with no companies at all 😉

Yes @kentcdodds, that's what I meant as well. 😀

Based on renaming this issue, I can work on Finishing designs if you are all well pleased with what I cooked up earlier. You can also let me know what I should focus on doing 👍. Also, based on the designs I currently built, if there are any examples you want to provide that you would like to see glamorous build from send me them! Let me know when you would like the designs by to 😃

I'm pretty happy with what you've got. And we can always iterate! I'm not concerned so much about focus as I am about getting whatever's next done. So work on whatever suits your fancy. It all needs to get done before we can release anyway 🙃  As for when, this is OSS so do it whenever you want. Nobody can ask any more of you than that. Just comment in here when you've started working on something (and mention what you're working on) so we don't work on the same thing at the same time :)
Thanks so much!

@kentcdodds what screenshot tool were you using on my designs? 😃

Haha, I just pulled them up in Chrome and screenshotted them there ;-)

Here are the designs that I have. Give me some feedback and I can the updates if need be. 😃
Home Page

Home Page (Mobile)

Home Page (Mobile with dropdown)
I am not feeling too ecstatic about the dropdown. The dropdown is pretty plain. I don't have the full resources for the glamorous logos either. I may have been able to do something cool with the dropdown using the resources, but If anyone has any idea of how to tackle the dropdown and locale for now, please speak up!

Documentation Page Structure
I currently have 2 ideas that fit into the current RC of the website. I basically took the current basics page and cleaned it up some more in these examples; the content of the page is FOP 😄, so you can really just ignore that part. I kept it similar so we can get the first iteration of the website out there 😃
Doc Structure 1
The design basically adheres to the same RC design out there, but I cleaned it up and added some buttons. The design should help us toward a quick release since its very similar to each RC documentation page (basics, advances examples, and etc.)
Note: I included the lipstick as an active state for navbar items. Not sure if that is what it was intended for on the RC website today -- but it seem kinda fun 😄

Doc Structure 2

💄💎!

This looks super fantastic! One thing I thought of right away is on the docs pages we should probably not have such a huge "Hero" logo etc. at the top. That's just a little much. Could we get a more compressed version?
Thanks!

Is there anywhere we could put some tasteful animation? 🤔

@kentcdodds oh sure! I agree a 100%. I will see what I can do. Can you give me an idea of how much smaller you are thinking?

Whatever looks good 😉 we can definitely iterate 😀
I think it'd be good to see a bit of content above the fold.

Would a custom 404 page provide added value?
(Right now the default nows 404 page is being used)

Yes, a good 404 would be welcome!

I tried implementing the users part, but with the logos that I found it kinda looks strange imo.
Does this need to be worked on?
(Also if I'm asking too many questions or interfering too much you can always say so :smile: )

Yeah, it does look kinda funny... I think a white background would be better. Also, we need to get official permission to use logos.
I want to do users after our initial release. Let's focus on other stuff :)

Closing this issue now. We can open new issues for specific design things we want to do...


Consider exposing api dependencies in a module

Some of the public apis depend on a specific version of Hyper. I know that work is happening to fix that. I'm building a binary and just set all dependency versions to * (I know it's not recommended, but it's worked great since Cargo.lock is committed and we update every few weeks). The only exceptions to that are for hyper and subsequently hyper-rustls (I definitely use rustls over openssl whenever possible) and they have to line up with the yup-oauth2 dependencies.
I'll try to get a pull request together, but I think that something like
pub mod deps {
    pub mod hyper {
        pub use hyper::*;
    }
    pub mod hyper-rustls {
        pub use hyper_rustls::*;
    }
}

would work and then consumers would just do something like
    use yup_oauth2::deps::*;
    let key = yup_oauth2::ServiceAccountKey { ... }
    let authenticator = yup_oauth2::ServiceAccountAccess::new(
      key,
      hyper::Client::with_connector(hyper::net::HttpsConnector::new(hyper_rustls::TlsClient::new())),
    );
    let storage = Storage::new(
      hyper::Client::with_connector(hyper::net::HttpsConnector::new(hyper_rustls::TlsClient::new())),
      authenticator,
    );

This wouldn't be a breaking change because the library already depends on these specific versions. It would reduce friction when using them.

I'm in favor of doing something like this!


RAR name mismatch message with Assembly name

Update error message with expected, actual and target Assembly name
Considered "....expected....",
    but its name "....actual....".
Didn't match the expected version  "..assembly name."

Issue #502

Looks like a good change to me; I suggested a minor edit for sentence formation.

Added fusionName from LogReference and sample output like following
Considered "C:\Paul\Assemblies\System.Runtime.dll",
	but its name "System.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
	didn't match the expected name "System.Runtime, Version=<IP_ADDRESS>".

There is a EightSpaceIndent before the message. Trying to write a test case for this but couldn't generate FusionNamesDidNotMatch, stuck somewhere before that.

@dotnet-bot test this please

Sorry it took so long to make it in. Thanks for your contribution!


WIP: 30ignition: don't run in the installer

We don't want to run Ignition when installing to disk since the
installer will nuke everything anyway. Though Ignition will still run on
reboot after installing the image to disk.

Could we put this logic in ignition-generator, rather than maintaining the condition separately in every unit?

Updated! I didn't mark this as Closes: #68 since it's not a general solution for all PXE cases.
@yuqi-zhang were you able to give this a spin?

Upon closer check the error I ran into was POST rebooting, so I initially reported and erroneous error, sorry about that. Cross-commenting in the issue as well.
Although this patch may still make sense.


Revert "[SPARK-14485][CORE] ignore task finished for executor lost an…

What changes were proposed in this pull request?
This reverts commit 695dbc816a6d70289abeb145cb62ff4e62b3f49b.
This change is being reverted because it hurts performance of some jobs, and
only helps in a narrow set of cases.  For more discussion, refer to the JIRA.

Test build #60241 has started for PR 13580 at commit 912ce5a.

Test build #60241 has finished for PR 13580 at commit 912ce5a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/60241/
Test PASSed.

Merged build finished. Test PASSed.

I don't have the strong feelings, but I still believe both cases hurt performance in different ways and in rare cases, and if that's to happen I prefer the version that yells less at the user. In any case, if you feel strongly, no worries on my side.

LGTM -- seems like the lower risk option here, especially for 2.0.

Merged into master and 2.0


While downloading a bandcamp album: ValueError: unknown url type: //popplers...

Basically this is a reproduction of the issue  #4861 with the 2015.10.09 version when I try to download the album
http://tenemosexplosivosoficial.bandcamp.com/album/la-virgen-de-los-mataderos
Weird enough, the program seems to get the stream URL, but it isn't recognized as a proper URL.
Here is the complete trace:
[foo@bar yt]$ youtube-dl --verbose http://tenemosexplosivosoficial.bandcamp.com/album/la-virgen-de-los-mataderos
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'--verbose', u'http://tenemosexplosivosoficial.bandcamp.com/album/la-virgen-de-los-mataderos']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.10.09
[debug] Python version 2.7.8 - Linux-4.1.8-100.fc21.i686-i686-with-fedora-21-Twenty_One
[debug] exe versions: ffmpeg 2.4.11, ffprobe 2.4.11
[debug] Proxy map: {}
[Bandcamp:album] la-virgen-de-los-mataderos: Downloading webpage
[download] Downloading playlist: La Virgen de los Mataderos
[Bandcamp:album] playlist La Virgen de los Mataderos: Collected 12 video ids (downloading 12 of them)
[download] Downloading video 1 of 12
[Bandcamp] violencia-y-jerarqu-a: Downloading webpage
[debug] Invoking downloader on u'//popplers5.bandcamp.com/download/track?enc=mp3-128&fsig=aa7e2246c88cd7426c386f28da4c9bf8&id=1308195415&stream=1&ts=1443681396.0'
Traceback (most recent call last):
  File "/usr/bin/youtube-dl", line 11, in <module>
    sys.exit(main())
  File "/usr/lib/python2.7/site-packages/youtube_dl/__init__.py", line 410, in main
    _real_main(argv)
  File "/usr/lib/python2.7/site-packages/youtube_dl/__init__.py", line 400, in _real_main
    retcode = ydl.download(all_urls)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1665, in download
    url, force_generic_extractor=self.params.get('force_generic_extractor', False))
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 671, in extract_info
    return self.process_ie_result(ie_result, download, extra_info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 832, in process_ie_result
    extra_info=extra)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 724, in process_ie_result
    extra_info=extra_info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 671, in extract_info
    return self.process_ie_result(ie_result, download, extra_info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 717, in process_ie_result
    return self.process_video_result(ie_result, download=download)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1335, in process_video_result
    self.process_info(new_info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1597, in process_info
    success = dl(filename, info_dict)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1539, in dl
    return fd.download(name, info)
  File "/usr/lib/python2.7/site-packages/youtube_dl/downloader/common.py", line 342, in download
    return self.real_download(filename, info_dict)
  File "/usr/lib/python2.7/site-packages/youtube_dl/downloader/http.py", line 60, in real_download
    data = self.ydl.urlopen(request)
  File "/usr/lib/python2.7/site-packages/youtube_dl/YoutubeDL.py", line 1872, in urlopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python2.7/urllib2.py", line 396, in open
    protocol = req.get_type()
  File "/usr/lib/python2.7/urllib2.py", line 258, in get_type
    raise ValueError, "unknown url type: %s" % self.__original
ValueError: unknown url type: //popplers5.bandcamp.com/download/track?enc=mp3-128&fsig=aa7e2246c88cd7426c386f28da4c9bf8&id=1308195415&stream=1&ts=1443681396.0
``

Version 2015.10.18 works for me. Could you try?

Like a charm. I didn't knew there was 10.18 version. If I ever have a problem again I'll try to force upgrade first. Thank you.

OK. Feel free to open a new issue if there are other problems.


Alpine libs not compatible with Java 8

Trying to install oracle JDK 8 and I get this error when run:
. /opt/jdk/bin/java -version
/bin/ash: /opt/jdk/bin/java: : not found
/bin/ash: /opt/jdk/bin/java: : not found
@@@@@@@?@@@@ |?@@DDP?td??@?@1Q?t/lib64/ld-linux-x86-64.so.2GNU	GNU?t?)N?ݓ??;r?Z???h nonexistent directory
/bin/ash: /opt/jdk/bin/java: line 1: ELF: not found
/bin/ash: /opt/jdk/bin/java: ?: not found
/bin/ash: /opt/jdk/bin/java: line 3: ?: not found
/bin/ash: /opt/jdk/bin/java: syntax error: unexpected end of file (expecting ")")
The ldd command give the result:
ldd /opt/jdk/bin/java
	/lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
	libjli.so => /opt/jdk/bin/../lib/amd64/jli/libjli.so (0x7f8da07e0000)
	libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
Error relocating /opt/jdk/bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found

What could be done?

This is more of a musl libc issue. The Oracle Java binaries only run on glibc at the moment. We are looking at possibly rebuilding https://aur.archlinux.org/packages/jd/jdk/PKGBUILD and making it available as a standalone package. I'll keep this issue open for now as we have had requests for Java 8 multiple times already.

Relevant to this is that the java 7 package is slightly broken too- the certstore is broken causing very hard to diagnose errors

(curious) @cultureulterior could you providde more details in your findings plz.

@AntonioMeireles the java certstore apparently is not regenerated from the CA certs on the machine itself, causing the java ssl to fail to trust certificates that should be trusted

I think I may start supporting progrium/busybox again just for Java 8 ... can you guys try that as your base image?

+1

Can anyone point me to relevant information about these musl libc limitations? I have the similar issue with Anaconda prebuilt packages on Alpine Linux:
# ldd /usr/local/miniconda/pkgs/python-2.7.9-1/bin/python
        /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libpython2.7.so.1.0 => /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0 (0x7f9d68a63000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libutil.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f9d68e45000)
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __finite: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __rawmemchr: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isinff: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: tmpnam_r: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isnan: symbol not found
Error relocating /usr/local/miniconda/pkgs/python-2.7.9-1/bin/../lib/libpython2.7.so.1.0: __isinf: symbol not found

I do understand that such prebuilt packages are evil, but there is not much I can do in this can except moving to another image for now. :(
However, I would like to understand limits of musl libc better.

/cc @flaviof @albertocsm

@cultureulterior it is possible to manually import all ca certificates to java trusted keystore, as I did it here

We have a new glibc package if anyone would like to test this out. You can grab the package at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk and install with apk add --allow-untrusted glibc-2.21-r2.apk. This should allow Oracle Java 8 and other glibc x86_64 native binaries to run on Alpine.

@andyshinn Awesome! It works for me with Miniconda, though I had to bring libz.so from my ubuntu to /usr/lib/libz.so.1 as Alpine Linux has libz.so compiled against musl...

@andyshinn
UPD: I didn't need to bring libz.so from ubuntu, but needed to create symlinks:
/usr/lib/libc.musl-x86_64.so.1 pointing at /lib/libc.musl-x86_64.so.1
/usr/lib/libz.so.1 pointing at /lib/libz.so.1
Note: For some reason, LD_LIBRARY_PATH doesn't work in this case for me.

Are you able to share a Dockerfile or repository with this? I'd like to see how this is working to better support these edge cases.

@andyshinn Sure!

@andyshinn
FROM alpine

RUN apk update && \
    apk add bash wget

WORKDIR /tmp

RUN wget --no-check-certificate "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk

RUN wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh"

# This will fail with "ImportError: libz.so.1: cannot open shared object file: No such file or directory"
#RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

# This will succeed
RUN ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1 && \
    ln -s /lib/libz.so.1 /usr/lib/libz.so.1
RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

I removed the post-install ldconfig but it might actually cover this case. Can you try adding package https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk in addition to the glibc one and then run /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib before installing and see if it works?

@andyshinn Now it works without symlinking! Great!
Just for the history (it works like a charm):
FROM alpine

RUN apk update && \
    apk add bash wget

WORKDIR /tmp

RUN wget --no-check-certificate "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk && \
    wget --no-check-certificate "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-bin-2.21-r2.apk && \
    /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib

RUN wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh"

RUN bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda

A couple of things I want to point out:

Your Python is not part glibc and part musl. Now, I'm a progressive minded person and don't have a problem with this. But Python might... A dual C library stack like this probably isn't all too common so we don't know what the pitfalls are (if any).
When you install pip and then start building more Python extensions (ones requiring build tools such as build-base) those will be linked against musl (be aware of DNS implications this has).
If you are not building additional extensions then we can probably pull in the libz.so from Arch to break the dependency on musl. Soon, i'll have an example of what a package like this looks like

@andyshinn I don't really use Miniconda it was just a project that I played with. My concern was mostly about the limits of musl libc than about running Miniconda on Alpine Linux. Anyway, thank you for your effort to get things easier in Alpine. I believe, Java people will appreciate this a lot.

Fair enough, it is something that applies to anyone trying to use glibc on Alpine so just wanted to get it out there. We are definitely more targeting the edge cases of one-off glibc binaries (think Consul) or Java 8 applications that might have all dependencies bundled in a war file already. But it is helpful to see where the limits are, so thank you for that!

@andyshinn Another example, which may be considered harmful, but nevertheless it made the shortcut possible, is my frolvlad/alpine-mono image, where I use mono package from Arch Linux.

Here is the Apline OracleJDK 8 image (352MB) - frolvlad/alpine-oraclejkd8

Thanks! I have successfully build alpine oracle JRE image — size 170MB (old, based on progrium/busybox — 162MB). https://registry.hub.docker.com/u/develar/java/

hi @andyshinn this works like a charm, please let us know once you have merged it into a released alpine version!

Thanks @frol , we're using it now.

This is fantastic news!
A slight obstacle is that I'm getting a lot of network issues out of the base "alpine" Docker image, though. APK is intermittently not able to read data. For example:
$ docker run --rm -ti alpine sh
/ # apk -U upgrade
fetch http://dl-4.alpinelinux.org/alpine/v3.1/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-4.alpinelinux.org/alpine/v3.1/main: IO ERROR
WARNING: Ignoring APKINDEX.689bb31a.tar.gz: No such file or directory
OK: 5 MiB in 15 packages
/ # apk -U upgrade
fetch http://dl-4.alpinelinux.org/alpine/v3.1/main/x86_64/APKINDEX.tar.gz
(1/7) Upgrading musl (1.1.5-r2 -> 1.1.5-r4)
(2/7) Upgrading busybox (1.22.1-r14 -> 1.22.1-r15)
ERROR: busybox-1.22.1-r15: Resource temporarily unavailable
(3/7) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
ERROR: alpine-conf-3.1.0-r4: Resource temporarily unavailable
(4/7) Upgrading libcrypto1.0 (1.0.1k-r0 -> 1.0.1m-r1)
ERROR: libcrypto1.0-1.0.1m-r1: Resource temporarily unavailable
(5/7) Upgrading libssl1.0 (1.0.1k-r0 -> 1.0.1m-r1)
(6/7) Upgrading musl-utils (1.1.5-r2 -> 1.1.5-r4)
(7/7) Upgrading alpine-base (3.1.2-r0 -> 3.1.3-r0)
ERROR: alpine-base-3.1.3-r0: Resource temporarily unavailable
4 errors; 5 MiB in 15 packages
/ # apk upgrade
(1/4) Upgrading busybox (1.22.1-r14 -> 1.22.1-r15)
Executing busybox-1.22.1-r15.post-upgrade
(2/4) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
ERROR: alpine-conf-3.1.0-r4: Resource temporarily unavailable
(3/4) Upgrading libcrypto1.0 (1.0.1k-r0 -> 1.0.1m-r1)
(4/4) Upgrading alpine-base (3.1.2-r0 -> 3.1.3-r0)
Executing busybox-1.22.1-r15.trigger
1 errors; 5 MiB in 15 packages
/ # apk upgrade
(1/1) Upgrading alpine-conf (3.1.0-r2 -> 3.1.0-r4)
Executing busybox-1.22.1-r15.trigger
OK: 5 MiB in 15 packages
/ #

When there are several dependencies (e.g. bash or ca-certificates), some of the dependencies make it, some don't.  If I keep trying, though, it eventually works.
When I do get curl, it is also having problems getting data (from a completely different site).
This may be name resolution preferring AAAA records over A records? Here you see ping failing until an IPv4 address is resolved. There is no route to IPv6 networks from the host I'm running on. The ping can subsequently fail if the IPv6 address is resolved again.
$ docker run --rm -ti canva/alpine sh
/ # ping google.com
PING google.com (2404:6800:4006:805::1009): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1008): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1008): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (2404:6800:4006:805::1005): 56 data bytes
ping: sendto: Network unreachable
/ # ping google.com
PING google.com (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=61 time=6.023 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=61 time=5.549 ms
64 bytes from <IP_ADDRESS>: seq=2 ttl=61 time=6.203 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 5.549/5.925/6.203 ms
/ #

Even supposedly "disabling" IPv6 by updating /etc/sysctl.conf seems to have no affect:
$ docker run --rm -ti canva/alpine sh
/ # cat /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
kernel.panic = 120

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:11:00:1B
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::42:acff:fe11:1b/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:578 (578.0 B)  TX bytes:578 (578.0 B)

lo        Link encap:Local Loopback
          inet addr:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

/ # ping google.com
PING google.com (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=61 time=3.537 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 3.537/3.537/3.537 ms
/ # ping google.com
PING google.com (2404:6800:4006:801::200e): 56 data bytes
ping: sendto: Network unreachable
/ #

When I do the same activity on @progrium's busybox image with the same busybox version as the Alpine image (1.22.1), no problems are experienced.

@delitescere Try to remove the image and pull it again. I've had the same issue with the base alpine image on one host and it helped.

@frol sadly, not for me.
$ docker history alpine
IMAGE               CREATED             CREATED BY                                      SIZE
b3dbab3810fc        8 days ago          /bin/sh -c #(nop) ADD file:3cca9bd4719b968870   5.03 MB

FWIW, I think it's a resolver(3) issue with gethostbyname behaving like RES_USE_INET6 has been set by default, when it shouldn't be.

@delitescere looks like some helpful information here, but can you continue this conversation over on #28 so it doesn't get lost in this discussion about Java.

For folks that might come looking, heka also appears to have this glibc requirement (at least as of 0.9.2).
The steps from the above comment did the trick though!

@matschaffer do you mean that their binaries require glibc or sources don't compile against musl libc?
Musl libc claims limited binary compatibility with glibc, but I have never seen a project that could work with musl libc without recompilation.
BTW, I've updated my comment (that you linked to) with recommended way of creating the final image.

I believe "their binaries require glibc" - though I'm a little fuzzy on the technicalities.
I haven't actually tried to build it myself so I can't speak to if the sources don't compile against musl libc or not.
I only used the RUN wget ... && apk ... part which seems to be unchanged since I copied it. That was enough to get the released hekad binary happy.

Huh... although I'm noting that once it's running it doesn't seem to resolve against /etc/hosts. Could be a side effect of this.

@marcusandre Try my OracleJDK8 fix:
# Alpine Linux doesn't use pam, which means that there is no /etc/nsswitch.conf,
# but Java relies on /etc/nsswitch.conf to check the order of DNS resolving
# (i.e. check /etc/hosts first and then lookup DNS-servers).
# To fix this we just create /etc/nsswitch.conf and add the following line:
RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf

Looking at this, it seems that it wasn't a Java bug, but glibc hack side effect...
@andyshinn You know better about glibc packages. Do you think it is possible that this nsswitch.conf issue is introduced because of them?

@frol hey thanks adding that nsswitch line did indeed get hosts resolution working again. So now with a pair of ssh tunnels I can end-to-end test from boot2docker against Amazon's email service :+1:

Where does JDK/JRE8 support stand?  I see here some folks that managed to get libc + some hacks working.  Is that the official way, or is more official support for glibc in the works?

Working great for me. See http://j.mp/tinyjvm (dockerhub)

@delitescere well you write in your own Dockerfile that this is a temporary workaround. so the question is: is it in fact a temporary workaround, and when will it be fixed in apline base image.

Well, I think the goal would be to simplify the installation of glibc, but I don't think it would be installed in the base image. It would definitely be nice to simply apk add glibc but installing it by default would increase the size of the image, and might cause confusion or issues in cases where it wasn't actually required.

@mgood agreed. It should not be in the base image, @CodingFabian, but it could be easier to install.

In the first place, the issue of OracleJDK not working on Alpine is not the issue of Alpine, but the issue of OracleJDK, which is not compiled for musl libc. Thus, if you wish to get things fixed properly, you have to ask Oracle to support musl libc. Meanwhile, everything that we implement here would be a hack either you install glibc from a repository or wget + apk add <files>. Nevertheless, there are two images that should save almost everybody from headaches: frolvlad/alpine-oraclejdk8 (167MB Oracle JDK image) and develar/java (117MB Oracle JRE image). I try to keep my image up-to-date, and I use it in production in my current projects.

Mine, using Zulu OpenJDK, are 162MB (JDK https://hub.docker.com/r/delitescere/jdk/) and 86MB (JRE https://hub.docker.com/r/delitescere/java/) respectively.

Technically I understand this thought but it's not realistic to expect a huge company like oracle to support every lib combo out there especially one that isn't the "top" one in terms of raw adoption.  (I do get the appeal of musl)
If you want to be able to support a major constituency like oraclejdk users the smaller ship not the larger needs to turn.
My thought on the matter is that busybox had this support and Alpine is positioning itself as the successor to busybox then conceptually there shouldn't be a major loss of capability.
Sent from my iPhone

On Nov 3, 2015, at 11:11 PM, Vlad Frolov<EMAIL_ADDRESS>wrote:
In the first place, the issue of OracleJDK not working on Alpine is not the issue of Alpine, but the issue of OracleJDK, which is not compiled for musl libc. Thus, if you wish to get things fixed properly, you have to ask Oracle to support musl libc. Meanwhile, everything that we implement here would be a hack either you install glibc from a repository or wget + apk add . Nevertheless, there are two images that should save almost everybody from headaches: frolvlad/alpine-oraclejdk8 (167MB Oracle JDK image) and develar/java (117MB Oracle JRE image). I try to keep my image up-to-date, and I use it in production in my current projects.
—
Reply to this email directly or view it on GitHub.

You may want to take a look at one of our production alpine/JDK8 install scripts for our alpinejava docker image:
https://github.com/garywiz/chaperone-docker/blob/master/alpinejava/setup/install.sh
We put this together quite a while ago, and it incorporates many of the suggestions in this thread as well as other threads (including the circle-artifacts glibc, nsswitch patch, etc).  We have about 10 clients using production derivatives from this and it might serve as a template, who knows.

Cool.  I'll check it out.
Sent from my iPhone

On Nov 4, 2015, at 5:08 PM, Gary Wisniewski<EMAIL_ADDRESS>wrote:
You may want to take a look at one of our production alpine/JDK8 install scripts for our alpinejava docker image:
https://github.com/garywiz/chaperone-docker/blob/master/alpinejava/setup/install.sh
We put this together quite a while ago, and it incorporates many of the suggestions in this thread as well as other threads (including the circle-artifacts glibc, nsswitch patch, etc). We have about 10 clients using production derivatives from this and it might serve as a template, who knows.
—
Reply to this email directly or view it on GitHub.

@gzoller Use frolvlad/alpine-glibc and you will feel it just like busybox.
@garywiz It is just the same as my frolvlad/alpine-oraclejdk8 image. 3.9k pulls of my image and two of my production projects shows that the image is stable.

@frol Thanks you!  Very excited it runs go scripts too, which my attempt to run a Alpine/glibc mashup did not.  This is going to be a nice base for me.

@andyshinn
I read your comments on Apr 10, and I think I met the issue you mentioned.
Since python extensions is not built with glibc, I can't make tensorflow (https://github.com/tensorflow/tensorflow) work in alpine.
The issue i raised : https://github.com/tensorflow/tensorflow/issues/103
any suggestions?

Yes, actually!   Check out frolvlad/alpine-glibc
This worked great for me.

On Nov 11, 2015, at 7:18 AM, Bill W<EMAIL_ADDRESS>wrote:
@andyshinn
I read your comments on Apr 10, and I think I met the issue you mentioned.
Since python extensions is not built with glibc, I can't make tensorflow (https://github.com/tensorflow/tensorflow) work in alpine.
The issue i raised : tensorflow/tensorflow#103
any suggestions?
—
Reply to this email directly or view it on GitHub.

Check out frolvlad/alpine-glibc

links: https://github.com/search?utf8=✓&q=alpine-glibc

@SydOps You may use Python compiled for glibc, for example Miniconda, something along the lines (not tested):
FROM frolvlad/alpine-glibc

RUN apk add --update bash wget ca-certificates && \
    wget "http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh" && \
    bash ./Miniconda-latest-Linux-x86_64.sh -b -p /usr/local/miniconda && \
    rm ./Miniconda-latest-Linux-x86_64.sh && \
    ln -s ../miniconda/bin/* /usr/local/bin && \
    apk del bash wget && \
    rm /var/cache/apk/*

Thanks @frol
I build with miniconda, now I saw different error:
  File "/usr/local/miniconda/lib/python2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 24, in swig_import_helper
    _mod = imp.load_module('_pywrap_tensorflow', fp, pathname, description)
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory

check the package libstdc++ which need musl again.

@SydOps Try adding conda install libgcc.

Thanks, @frol
I understand now, after Miniconda is enabled, all lib updates should be go through conda.
Will try and update the result later.

@frol
Yes,  the problem is fixed, thanks a lot

I pushed a new glibc package builder. The artifact is at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/glibc-2.22-r5.apk. If someone could help test it out that would be great. This one is the first step in using my own built glibc binary from https://github.com/andyshinn/docker-glibc-builder.

@andyshinn I have tried out your new artifacts with Miniconda (as there is already an example above with the old artifacts). Unfortunately, it didn't go smoothly. Miniconda-latest-Linux-x86_64.sh: line 287: /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python: No such file or directory
ERROR:
cannot execute native linux-64 binary, output from 'uname -a' is:
Linux 5c561b7d85f6 4.3.0-2-lqx #1 ZEN SMP PREEMPT Thu Nov 19 10:06:38 ICT 2015 x86_64 Linux

/ # /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python
sh: /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python: not found

/ # /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /usr/local/miniconda/pkgs/python-2.7.10-2/bin/python
Python 2.7.10 |Continuum Analytics, Inc.| (default, Oct 19 2015, 18:04:42)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>>

As you can see, I can run the Python executable if I explicitly use /usr/glibc-compat/lib/ld-linux-x86-64.so.2, but I cannot just run the executable as I could do with the old artifacts. Do you have any ideas?
BTW, ldconfig complains about missing /usr/glibc-compat/etc/ld.so.conf, which could be included into the packages.

Same thing as above with phantomjs:
# phantomjs
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/lib/libstdc++.so.6)
Error relocating /usr/lib/libstdc++.so.6: __memcpy_chk: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __cxa_thread_atexit_impl: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __sprintf_chk: symbol not found
Error relocating /usr/lib/libstdc++.so.6: __snprintf_chk: symbol not found
Error relocating /usr/bin/node: _ZSt24__throw_out_of_range_fmtPKcz: symbol not found

I'll use https://hub.docker.com/r/frolvlad/alpine-oraclejdk8/~/dockerfile/ as a test for new packages. But @antoineco what is a PahntomJS image that is currently working that I can test with? I can't get PhantomJS to work with the new or old one.

Me neither actually, on Alpine + glibc it throws bin/phantomjs: /usr/lib/libstdc++.so.6: no version information available, and when I replace libstdc++.so.6 by the Ubuntu version I get a segmentation fault. Eventually I got it working on Alpine by using dockerize on the PhantomJS binaryand pushing all the resulting libraries to my image (which includes glibc).
Long story short, PhantomJS only works with GNU libraries.

Yea, I already did a lot of work to try and build PhantomJS linked against Alpine libs. Fabio Rehm did some work on this also and has a good article about it and his image at http://fabiorehm.com/blog/2015/07/22/building-a-minimum-viable-phantomjs-2-docker-image/. Unfortunately, PhantomJS has an extremely involved compilation process that will likely require lots of hacking to compile properly on musl.
Though, a builder image, with dockerize + PhantomJS to produce an Alpine package like I am doing for glibc might be a 3rd option to explore.

Hi, I believe the issue I have might be related to the discussion here.
One of the npm modules I am trying to use uses does not work in Alpine using @frol 's frol/docker-alpine-glibc image.
At first, it failed while loading the shared library: libcrypt.so.1.
I got around that by running export LD_LIBRARY_PATH=/usr/glibc/usr/lib.
Now, I am getting the following error messages:
	libcrypt.so.1 => /usr/glibc/usr/lib/libcrypt.so.1 (0x7fc8731ea000)
	libdl.so.2 => ldd (0x7fc87561a000)
	libpthread.so.0 => ldd (0x7fc87561a000)
	librt.so.1 => ldd (0x7fc87561a000)
	libpam.so.0 => /lib/libpam.so.0 (0x7fc872fdd000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0x7fc872cb2000)
	libm.so.6 => ldd (0x7fc87561a000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fc8729bf000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fc8727ad000)
	libc.so.6 => ldd (0x7fc87561a000)
	libz.so.1 => /lib/libz.so.1 (0x7fc872597000)
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __open: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __read: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: __libc_alloca_cutoff: symbol not found
Error relocating /usr/glibc/usr/lib/libcrypt.so.1: errno: symbol not found```

Any comments or thoughts would be greatly appreciated.

@hwangbible I guess, you are trying to mix node.js from Alpine official repos, thus node.js is linked to musl libc, and an npm module that is proprietary or just has a precompiled library (which is apparently linked against glibc). This might be an unsolvable case as it is, so I suggest you either (1) recompile the npm module from sources, so the library is linked against musl libc, or (2) use node.js linked against glibc (for example, download Arch Linux packages, like I did for frolvlad/alpine-mono).
P.S. ldd that you are using is working with musl libc (and the /usr/glibc/usr/bin/ldd is simply broken), so to check libraries on a glibc binary you need to run the following command:
$ LD_TRACE_LOADED_OBJECTS=1 /usr/glibc/usr/lib/ld-linux-x86-64.so.2  "path_to_your_binary"

@frol Thank you very much for the prompt response!
I was actually recompiling node v0.12.7 sources downloaded from nodejs.org. That module with the precompiled library installed fine via npm. Is that not enough? Would I have to recompile npm separate from recompiling node?

@hwangbible If you have rebuilt node on Alpine, then nodejs is linked against musl libc and it is just the same situation as I have already described. npm is just a package manager, it delivers files to your system, but you need to make sure that those files are compatible. Recompile that prebuilt library or use NodeJS linked against glibc.

@frol I downloaded nodejs package from Arch Linux packages and untar'd it on to frolvlad:alpine-glibc:3.2. When I try to run node, the following error message appears: error while loading shared libraries: libicui18n.so.55: cannot open shared object file: No such file or directory. What am I missing this time?

@hwangbible Get libstdc++.so.6 from Arch Linux also (it is in gcc-libs package) and put it into /usr/glibc/usr/lib/ folder, and run ldconfig. Actually, as I have already warned, Alpine's packages become almost completely useless once you start using glibc since you must use glibc-targeted libraries everywhere. Still sometimes it makes some sense (i.e. when you use Java, or completely self-bundled packages like Anaconda (Python)). In your case, I think it is too troublesome.

@frol Thank you very much for all your responses! I will probably have to look for an alternative for now.

@andyshinn It would be nice to have a glibc-dev package with headers.

@andyshinn Downloaded golang binaries works on your glibc-2.21-r2.apk but not on glibc-2.22-r5.apk

@sdurrheimer see https://github.com/gliderlabs/docker-alpine/issues/11#issuecomment-160202945

@antoineco Indeed the missing /lib64/lib/ld-linux-x86-64.so.2. Kind of strange because it is in fact in the apk package building procedure : https://github.com/andyshinn/alpine-pkg-glibc/blob/master/APKBUILD#L27

But it was restored after the package was built :)
https://github.com/andyshinn/alpine-pkg-glibc/commit/f972199cf1aa781d2b862a641b7755768a6f567c

Yep just saw that. Need to use https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/13/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/ instead of https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/12/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/builder/x86_64/

Just to add my $0.02 here: I'm trying to make Alpine work as a minimal OpenStack image to run Go and Java services. I'm not looking for a docker solution since I want to run the apps directly. Therefore apk add glibc would be a welcome addition.

@magiconair I don't think glibc package will ever make to the official repo since it is a pure hack. Making a repo for glibc package is doable and, in fact, you can make the repo yourself, but at this point of time there is only one set of artifacts (2.21-r2) which works and others just don't. However, I also support the idea of having a repo for glibc in future, so it can be installed in a standard way.

I've been holding my breath since I started using Alpine as a base image, but the glibc hackery finally blew up for me today in a CI job:
01:49:46 *** Error in `java': free(): invalid size: 0x00000001009c8d50 ***
01:49:46 ======= Backtrace: =========
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x7198e)[0x7f9134e5898e]
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x76dee)[0x7f9134e5ddee]
01:49:46 /usr/glibc/usr/lib/libc.so.6(+0x775cb)[0x7f9134e5e5cb]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x622b41)[0x7f9134440b41]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x9a516c)[0x7f91347c316c]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x9a5e66)[0x7f91347c3e66]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0xab446f)[0x7f91348d246f]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0xab48f0)[0x7f91348d28f0]
01:49:46 /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so(+0x911048)[0x7f913472f048]
01:49:46 /usr/glibc/usr/lib/libpthread.so.0(+0x7374)[0x7f91355ab374]
01:49:46 /usr/glibc/usr/lib/libc.so.6(clone+0x6d)[0x7f9134ecf27d]
01:49:46 ======= Memory map: ========
01:49:46 00400000-00401000 r-xp 00000000 fd:04 1312104                            /usr/lib/jvm/java-8-oracle/bin/java
01:49:46 00600000-00601000 rw-p 00000000 fd:04 1312104                            /usr/lib/jvm/java-8-oracle/bin/java
01:49:46 01230000-01251000 rw-p 00000000 00:00 0                                  [heap]
01:49:46 c0000000-10104a000 rw-p 00000000 00:00 0
01:49:46 10104a000-140000000 ---p 00000000 00:00 0
01:49:46 7f909c000000-7f909c021000 rw-p 00000000 00:00 0
01:49:46 7f909c021000-7f90a0000000 ---p 00000000 00:00 0
01:49:46 7f90a4000000-7f90a407b000 rw-p 00000000 00:00 0
01:49:46 7f90a407b000-7f90a8000000 ---p 00000000 00:00 0
01:49:46 7f90a8000000-7f90a8021000 rw-p 00000000 00:00 0
01:49:46 7f90a8021000-7f90ac000000 ---p 00000000 00:00 0
01:49:46 7f90ac000000-7f90ac021000 rw-p 00000000 00:00 0
01:49:46 7f90ac021000-7f90b0000000 ---p 00000000 00:00 0
01:49:46 7f90b0000000-7f90b0021000 rw-p 00000000 00:00 0
01:49:46 7f90b0021000-7f90b4000000 ---p 00000000 00:00 0
01:49:46 7f90b4000000-7f90b4021000 rw-p 00000000 00:00 0
01:49:46 7f90b4021000-7f90b8000000 ---p 00000000 00:00 0
01:49:46 7f90b8000000-7f90b8021000 rw-p 00000000 00:00 0
01:49:46 7f90b8021000-7f90bc000000 ---p 00000000 00:00 0
01:49:46 7f90bce36000-7f90bcebe000 r-xp 00000000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bcebe000-7f90bd0bd000 ---p 00088000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0bd000-7f90bd0be000 r--p 00087000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0be000-7f90bd0bf000 rw-p 00088000 fd:04 1310959                    /lib/ld-musl-x86_64.so.1
01:49:46 7f90bd0bf000-7f90bd0c2000 rw-p 00000000 00:00 0
01:49:46 7f90bd0c2000-7f90bd0d3000 r-xp 00000000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd0d3000-7f90bd2d2000 ---p 00011000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d2000-7f90bd2d3000 r--p 00010000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d3000-7f90bd2d4000 rw-p 00011000 fd:04 1311863                    /usr/lib/libgcc_s.so.1
01:49:46 7f90bd2d4000-7f90bd2d7000 ---p 00000000 00:00 0
01:49:46 7f90bd2d7000-7f90bd3d5000 rw-p 00000000 00:00 0                          [stack:130]
01:49:46 7f90bd3d5000-7f90bd3d8000 ---p 00000000 00:00 0
01:49:46 7f90bd3d8000-7f90bd4d6000 rw-p 00000000 00:00 0                          [stack:129]
01:49:46 7f90bd4d6000-7f90bd4d9000 ---p 00000000 00:00 0
01:49:46 7f90bd4d9000-7f90bd5d7000 rw-p 00000000 00:00 0                          [stack:128]
01:49:46 7f90bd5d7000-7f90bd5da000 ---p 00000000 00:00 0
01:49:46 7f90bd5da000-7f90bd6d8000 rw-p 00000000 00:00 0                          [stack:127]
01:49:46 7f90bd6d8000-7f90bd6db000 ---p 00000000 00:00 0
01:49:46 7f90bd6db000-7f90bd7d9000 rw-p 00000000 00:00 0                          [stack:126]
01:49:46 7f90bd7d9000-7f90bd7dc000 ---p 00000000 00:00 0
01:49:46 7f90bd7dc000-7f90bd8da000 rw-p 00000000 00:00 0                          [stack:125]
01:49:46 7f90bd8da000-7f90bd8dd000 ---p 00000000 00:00 0
01:49:46 7f90bd8dd000-7f90bd9db000 rw-p 00000000 00:00 0                          [stack:124]
01:49:46 7f90bd9db000-7f90bd9de000 ---p 00000000 00:00 0
01:49:46 7f90bd9de000-7f90bdadc000 rw-p 00000000 00:00 0                          [stack:123]
01:49:46 7f90bdadc000-7f90bdadf000 ---p 00000000 00:00 0
01:49:46 7f90bdadf000-7f90bdbdd000 rw-p 00000000 00:00 0                          [stack:122]
01:49:46 7f90bdbdd000-7f90bdbe0000 ---p 00000000 00:00 0
01:49:46 7f90bdbe0000-7f90bdcde000 rw-p 00000000 00:00 0                          [stack:121]
01:49:46 7f90bdcde000-7f90bdce1000 ---p 00000000 00:00 0
01:49:46 7f90bdce1000-7f90bdddf000 rw-p 00000000 00:00 0                          [stack:120]
01:49:46 7f90bdddf000-7f90bdde2000 ---p 00000000 00:00 0
01:49:46 7f90bdde2000-7f90be044000 rw-p 00000000 00:00 0                          [stack:119]
01:49:46 7f90be044000-7f90be0e0000 ---p 00000000 00:00 0
01:49:46 7f90be0e0000-7f90be0e3000 ---p 00000000 00:00 0
01:49:46 7f90be0e3000-7f90be1e1000 rw-p 00000000 00:00 0                          [stack:118]
01:49:46 7f90be1e1000-7f90be1e4000 ---p 00000000 00:00 0
01:49:46 7f90be1e4000-7f90be2e2000 rw-p 00000000 00:00 0                          [stack:117]
01:49:46 7f90be2e2000-7f90be2e5000 ---p 00000000 00:00 0
01:49:46 7f90be2e5000-7f90be3e3000 rw-p 00000000 00:00 0                          [stack:116]
01:49:46 7f90be3e3000-7f90be3e6000 ---p 00000000 00:00 0
01:49:46 7f90be3e6000-7f90be4e4000 rw-p 00000000 00:00 0                          [stack:115]
01:49:46 7f90be4e4000-7f90be4e7000 ---p 00000000 00:00 0
01:49:46 7f90be4e7000-7f90be5e5000 rw-p 00000000 00:00 0                          [stack:114]
01:49:46 7f90be5e5000-7f90be5ed000 r-xp 00000000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be5ed000-7f90be7ed000 ---p 00008000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be7ed000-7f90be7ee000 rw-p 00008000 fd:04 1312249                    /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libmanagement.so
01:49:46 7f90be7ee000-7f90be9ee000 rw-p 00000000 00:00 0
01:49:46 7f90be9ee000-7f90be9f1000 ---p 00000000 00:00 0
01:49:46 7f90be9f1000-7f90becef000 rw-p 00000000 00:00 0                          [stack:113]
01:49:46 7f90becef000-7f90becf2000 ---p 00000000 00:00 0
01:49:46 7f90becf2000-7f90bedf0000 rw-p 00000000 00:00 0                          [stack:111]
01:49:46 7f90bedf0000-7f90bedf3000 ---p 00000000 00:00 0
01:49:46 7f90bedf3000-7f90beef1000 rw-p 00000000 00:00 0                          [stack:110]
01:49:46 7f90beef1000-7f90beef4000 ---p 00000000 00:00 0
01:49:46 7f90beef4000-7f90beff2000 rw-p 00000000 00:00 0                          [stack:109]
01:49:46 7f90beff2000-7f90beff5000 ---p 00000000 00:00 0
01:49:46 7f90beff5000-7f90bf0f3000 rw-p 00000000 00:00 0                          [stack:108]
01:49:46 7f90bf0f3000-7f90bf0f6000 ---p 00000000 00:00 0
01:49:46 7f90bf0f6000-7f90bf1f4000 rw-p 00000000 00:00 0                          [stack:107]
01:49:46 7f90bf1f4000-7f90bf1f7000 ---p 00000000 00:00 0
01:49:46 7f90bf1f7000-7f90bf4f5000 rw-p 00000000 00:00 0                          [stack:106]
01:49:46 7f90bf4f5000-7f90bf4f8000 ---p 00000000 00:00 0
01:49:46 7f90bf4f8000-7f90bf5f6000 rw-p 00000000 00:00 0                          [stack:105]
01:49:46 7f90bf5f6000-7f90bf5f9000 ---p 00000000 00:00 0
01:49:46 7f90bf5f9000-7f90bf6f7000 rw-p 00000000 00:00 0                          [stack:104]
01:49:46 7f90bf6f7000-7f90bf6fa000 ---p 00000000 00:00 0
01:49:46 7f90bf6fa000-7f90bf7f8000 rw-p 00000000 00:00 0                          [stack:103]
01:49:46 7f90bf7f8000-7f90bf7fb000 ---p 00000000 00:00 0
01:49:46 7f90bf7fb000-7f90bf8f9000 rw-p 00000000 00:00 0                          [stack:102]
01:49:46 7f90bf8f9000-7f90bf8fc000 ---p 00000000 00:00 0
01:49:46 7f90bf8fc000-7f90bf9fa000 rw-p 00000000 00:00 0                          [stack:101]
01:49:46 7f90bf9fa000-7f90bf9fd000 ---p 00000000 00:00 0
01:49:46 7f90bf9fd000-7f90bfafb000 rw-p 00000000 00:00 0                          [stack:100]
01:49:46 7f90bfafb000-7f90bfafe000 ---p 00000000 00:00 0
01:49:46 7f90bfafe000-7f90bfbfc000 rw-p 00000000 00:00 0                          [stack:99]
01:49:46 7f90bfbfc000-7f90bfbff000 ---p 00000000 00:00 0
01:49:46 7f90bfbff000-7f90bfcfd000 rw-p 00000000 00:00 0                          [stack:98]
01:49:46 7f90bfcfd000-7f90bfd00000 ---p 00000000 00:00 0
01:49:46 7f90bfd00000-7f90bfdfe000 rw-p 00000000 00:00 0                          [stack:97]
01:49:46 7f90bfdfe000-7f90bfe01000 ---p 00000000 00:00 0
01:49:46 7f90bfe01000-7f90bfeff000 rw-p 00000000 00:00 0                          [stack:96]
01:49:46 7f90bfeff000-7f90bff02000 ---p 00000000 00:00 0
01:49:46 7f90bff02000-7f90c0000000 rw-p 00000000 00:00 0                          [stack:95]
01:49:46 7f90c0000000-7f90c028b000 rw-p 00000000 00:00 0
01:49:46 7f90c028b000-7f90c4000000 ---p 00000000 00:00 0
01:49:46 7f90c4000000-7f90c4021000 rw-p 00000000 00:00 0
01:49:46 7f90c4021000-7f90c8000000 ---p 00000000 00:00 0
01:49:46 7f90c8000000-7f90c87ca000 rw-p 00000000 00:00 0
01:49:46 7f90c87ca000-7f90cc000000 ---p 00000000 00:00 0
01:49:46 7f90cc000000-7f90cc307000 rw-p 00000000 00:00 0
01:49:46 7f90cc307000-7f90d0000000 ---p 00000000 00:00 0
01:49:46 7f90d0000000-7f90d010a000 rw-p 00000000 00:00 0
01:49:46 7f90d010a000-7f90d4000000 ---p 00000000 00:00 0
01:49:46 7f90d4000000-7f90d4021000 rw-p 00000000 00:00 0
01:49:46 7f90d4021000-7f90d8000000 ---p 00000000 00:00 0
01:49:46 7f90d8000000-7f90d803a000 rw-p 00000000 00:00 0
01:49:46 7f90d803a000-7f90dc000000 ---p 00000000 00:00 0
01:49:46 7f90dc000000-7f90dc244000 rw-p 00000000 00:00 0
01:49:46 7f90dc244000-7f90e0000000 ---p 00000000 00:00 0
01:49:46 7f90e0000000-7f90e0bbb000 rw-p 00000000 00:00 0
01:49:46 7f90e0bbb000-7f90e4000000 ---p 00000000 00:00 0
01:49:46 7f90e4000000-7f90e4021000 rw-p 00000000 00:00 0
01:49:46 7f90e4021000-7f90e8000000 ---p 00000000 00:00 0
01:49:46 7f90e8072000-7f90e8272000 rw-p 00000000 00:00 0
01:49:46 7f90e8272000-7f90e8275000 ---p 00000000 00:00 0
01:49:46 7f90e8275000-7f90e8373000 rw-p 00000000 00:00 0                          [stack:94]
01:49:46 7f90e8373000-7f90e8376000 ---p 00000000 00:00 0
01:49:46 7f90e8376000-7f90e8474000 rw-p 00000000 00:00 0                          [stack:93]
01:49:46 7f90e8474000-7f90e8477000 ---p 00000000 00:00 0
01:49:46 7f90e8477000-7f90e8775000 rw-p 00000000 00:00 0                          [stack:92]
01:49:46 7f90e8775000-7f90e8975000 rw-p 00000000 00:00 0
01:49:46 7f90e8975000-7f90e8b75000 rw-p 00000000 00:00 0
01:49:46 7f90e8b75000-7f90e8d75000 rw-p 00000000 00:00 0
01:49:46 7f90e8d75000-7f90e8f75000 rw-p 00000000 00:00 0
01:49:46 7f90e8f75000-7f90e9175000 rw-p 00000000 00:00 0
01:49:46 7f90e9175000-7f90e9375000 rw-p 00000000 00:00 0
01:49:46 7f90e9375000-7f90e9575000 rw-p 00000000 00:00 0
01:49:46 7f90e9575000-7f90e9775000 rw-p 00000000 00:00 0
01:49:46 7f90e9775000-7f90e9975000 rw-p 00000000 00:00 0
01:49:46 7f90e9975000-7f90e9b75000 rw-p 00000000 00:00 0
01:49:46 7f90e9b75000-7f90e9d75000 rw-p 00000000 00:00 0
01:49:46 7f90e9d75000-7f90e9f71000 rw-p 00000000 00:00 0
01:49:46 7f90e9f71000-7f90e9f75000 ---p 00000000 00:00 0
01:49:46 7f90e9f75000-7f90e9f83000 r--s 00191000 fd:04 1441826                    /root/.ivy2/cache/com.h2database/h2/jars/h2-1.4.187.jar
01:49:46 7f90e9f83000-7f90e9fe9000 r--s 00669000 fd:04 1442276                    /root/.ivy2/cache/org.scalatest/scalatest_2.11/bundles/scalatest_2.11-2.2.0.jar
01:49:46 7f90e9fe9000-7f90e9fee000 r--s 00039000 fd:04 1441919                    /root/.ivy2/cache/com.typesafe.akka/akka-testkit_2.11/jars/akka-testkit_2.11-2.3.11.jar
01:49:46 7f90e9fee000-7f90e9ff1000 r--s 00010000 fd:04 1442021                    /root/.ivy2/cache/io.spray/spray-testkit_2.11/jars/spray-testkit_2.11-1.3.3.jar
01:49:46 7f90e9ff1000-7f90e9ff3000 r--s 00005000 fd:04 1442251                    /root/.ivy2/cache/org.objenesis/objenesis/jars/objenesis-1.0.jar
01:49:46 7f90e9ff3000-7f90e9ff5000 r--s 00011000 fd:04 1442197                    /root/.ivy2/cache/org.hamcrest/hamcrest-core/jars/hamcrest-core-1.1.jar
01:49:46 7f90e9ff5000-7f90ea014000 r--s 00150000 fd:04 1442244                    /root/.ivy2/cache/org.mockito/mockito-core/jars/mockito-core-1.9.5.jar
01:49:46 7f90ea014000-7f90ea01f000 r--s 0008b000 fd:04 1315921                    /root/.ivy2/cache/c3p0/c3p0/jars/c3p0-<IP_ADDRESS>.jar
01:49:46 7f90ea01f000-7f90ea021000 r--s 00006000 fd:04 1442324                    /root/.ivy2/cache/org.slf4j/slf4j-api/jars/slf4j-api-1.7.7.jar
01:49:46 7f90ea021000-7f90ea022000 r--s 00005000 fd:04 1442305                    /root/.ivy2/cache/org.slf4j/log4j-over-slf4j/jars/log4j-over-slf4j-1.7.7.jar
01:49:46 7f90ea022000-7f90ea023000 r--s 00003000 fd:04 1441913                    /root/.ivy2/cache/com.typesafe.akka/akka-slf4j_2.11/jars/akka-slf4j_2.11-2.3.11.jar
01:49:46 7f90ea023000-7f90ea03b000 r--s 001ac000 fd:04 1442168                    /root/.ivy2/cache/org.aspectj/aspectjweaver/jars/aspectjweaver-1.7.4.jar
01:49:46 7f90ea03b000-7f90ea045000 r--s 0005f000 fd:04 1315934                    /root/.ivy2/cache/ch.qos.logback/logback-core/jars/logback-core-1.1.2.jar
01:49:46 7f90ea045000-7f90ea04b000 r--s 0003d000 fd:04 1315928                    /root/.ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.2.jar
01:49:46 7f90ea04b000-7f90ea04c000 r--s 00005000 fd:04 1441959                    /root/.ivy2/cache/io.airbrake/airbrake-java/jars/airbrake-java-2.2.8.jar
<snip>

It's really a shame.  I'd say I've got thousands of invocations of docker containers with alpine:3.2 at this point since we've been using this since July, but now I have to think about whether it's back to ubuntu and skinnywhale or not.

@ralph-tice are you somehow using a 32-bit glibc on a 64-bit distro? There's something suspicious about free() complaining about 0x00000001009c8d50 being an invalid size, when that's hexadecimal for a number that's 10MB over 4GB.

I'm using the same instructions from @frol above in this issue:
RUN wget "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk" \
         "https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-bin-2.21-r2.apk" && \
    apk add --allow-untrusted glibc-2.21-r2.apk glibc-bin-2.21-r2.apk && \
    /usr/glibc/usr/bin/ldconfig /lib /usr/glibc/usr/lib

But I agree, that's suspicious.  My docker host is x86_64 though:
Linux jenkins-slave-172-18-103-186-uacf-io 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux```

and the container (after I commit and restart it) reports x86_64 also:
```$ sudo docker run -it inspect bash
bash-4.3# uname -a
Linux 22dd69d75075 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 Linux```

Based on the great work by andyshinn I built a glibc apk for arm7 yesterday. I have no idea if it's 'correct' as this stuff is all very new to me but I can successfully create a Alpine Linux docker image with Oracle Java 8 with it on a Raspberry Pi 2. It's available at https://github.com/leannenorthrop/alpine-pkg-glibc/releases/tag/glibc-2.22-r1-armhf-beta.

@andyshinn I have finaly had some time to play with your 2.22 artifacts and it turned out that there seem to be just one little missing part: there must exist /lib64/ld-linux-x86-64.so.2 file to run glibc-dependent binaries in a usual way! /lib64/ld-linux-x86-64.so.2 used to be a part of 2.21 artifacts, but it is missing in 2.22. Could you please shed some light on the issue?

@andyshinn Please, ignore my previous message, I have used the old version (# 12) of artifacts, but once I have moved on to the latest build version (# 21), everything is fine.
However, there are a couple of old issues that were around since glibc 2.21, which I have filed only today along with tested workarounds: /etc/hosts ignorance, and lack of UTF-8 locale.

Also, for anyone else confused about which artifact to be using, I started tagging and adding them to GitHub releases page (https://github.com/andyshinn/alpine-pkg-glibc/releases). You can pull from there instead and it should be a little easier to identify what versions are out there.

Hi, everyone!
With a great help of @andyshinn I have succeeded in getting OracleJDK 8 and Mono (from Arch Linux) working on glibc 2.22 artifacts!
Could you guys give a try to the new images frolvlad/alpine-oraclejdk8:experimental and frolvlad/alpine-mono:experimental?
They should behave just the same as frolvlad/alpine-oraclejdk8:slim and frolvlad/alpine-mono:latest with only one noticeable change: the default locale is now C.UTF-8 instead of C/POSIX.

@frol I forked your JDK to generate a JRE (full/clean/slim is currently defined by layering).
I'll test your great job right now. You are one of my favorite whales. :D

@leodutra Yeah, I've seen your fork. I don't know how the "layering" helps you, but the main point of having all of those rm's in one RUN command was saving the size of a final image, but in your case, you will get the size of full version with a functionality of slim. BTW, is there something wrong with develar/java image (which is the recommended Alpine + Oracle JRE image in my README)?
I was contemplating creation of alpine-oraclejava image with both JDK and JRE (separated by tags). Is somebody interested in JRE image from me?

@frol I made the JRE for a minecraft Spigot server image I made for my family's minecraft server.
I'd like to maintain a JRE as you, releasing by branch... but I'm really new into Docker and I can't ensure much quality right now.
Learned the "few layer good practice" from some nice references, including this cheat sheet. That's the part Docker seems a litttle weird, from the sense of general software stuff. VOLUME has some weird behavior. Reminds me of Internet Explorer 6 and I don't wanna live to close with this.
So, I'd love to see a well divided JRE Dockerfile repo made by @frol.
I've seen some... and they are not so cool (not on alpine 3.3/ bad rm usage/ no environment version variable).
You can pick my fork from you and start separanting the 3 layer run in 3 builds. Seems a good shortcut.
Best regards.

Well... pushing to develar/java.

In my testing, I used --volume to mount everything needed from the docker host to make the java app running in the container, I don't know if this works in production environment, I guess the glibc stuff has already been packaged in most linux distributions where the docker host is running, can somebody help confirm this?
I used below to start up the container:
docker run -t -i  -v /lib:/lib:ro -v /lib64:/lib64:ro -v /home/jdk1.8.0_66:/root/java:ro alpine:3.3

@hehailong5 Even if this would work, it just ruins the whole point of Docker containers.  Why do you need Docker or Alpine in this case at all? You can have a chroot...

@frol you made the very good point. thanks for the confirmation. I would then turn to the docker way..

@hehailong5 And is way more hard to work this way... you will have to
install Java in every machine, and have the same path forever. Using the
docker way, you just need to install docker, and your container will use
fewer memory space (cause there's less volumes).

I have updated frolvlad/alpine-mono:experimental and frolvlad/alpine-oraclejdk8:experimental to use frolvlad/alpine-glibc:alpine-3.3_glibc-2.23 (upgraded glibc from 2.22 to 2.23). In my tests and tests conducted by some users, who reached me with a confirmation, new artifacts work just fine, so I'm going to make glibc 2.23 default if there will not be reported any issues this a week.

@frol The latest glibc 2.23 build on Docker is failing.

@frol Found it. Andy removed the 2.23-r0 and added 2.23-r1
https://github.com/andyshinn/alpine-pkg-glibc/releases

@leodutra Fixed.

Forgive my ignorance, but isn't musl expected to be compatible at the binary level with glibc (to some extent)?
If so, has someone tried to contact either the dev of musl (if musl should be compatible but isn't somehow) or the devs of OpenJDK (if OpenJDK is using some glibc specific symbols that shouldn't be relied upon) to make that compatibility work out of the box?
Having to install glibc on alpine seems to be a big workaround for a problem that could be fixed at the source.

Yeah, I've made this questionar to myself. But I'd seen too many images
using glibc that I just let it go.
I'd like to know too.

@ColinHebert OpenJDK is open-source and is available in Alpine repository, so you can use it out of the box without glibc hacks (apk add openjdk8 or openjdk7). OracleJDK, on the other hand, is closed-source, so you have to ask Oracle to release separate builds for musl libc (though it is still not very popular, so they might not be interested in investing time into this).

Is musl compatible with glibc?
...
Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

FYI: The Alpine’s repository now provides package for JRuby, with compatible JNI dependencies. It may solve the issues you had (but I should admit that I haven’t read all this long thread). If not, then article JRuby on Alpine Linux may help.

@frol @andyshinn First of all thanks for this work - I am looking to use Conda in an Alpine based container and stumbled on this discussion when I started running into problems, and I'm happy to say using the frolvlad/alpine-glibc as a base works very well, thank you both!
I am looking to use this in production, and I just want to understand the implications of using this image. The containers I will be building based on this will all be using Conda and some packages installed through PIP and some through Conda. When any of these packages requiring compilation are installed, which version of the C compiler would it use? And has this meant that any program run in these containers now runs against glibc?

@elsmorian I am happy that you considered Alpine as a base image for your images. I would like to start with a warning: glibc on Alpine Linux should be considered as a hack! While it is acceptable to use glibc on Alpine, it is a hard way. I, personally, use alpine-glibc in production, but there are cases when it makes life dreadful (e.g. when you integrate a weird proprietary binaries, or deploy anything with "smart"  licensing). You have to use glibc-targeted compilers (there is gcc in Anaconda repos, but it is not considered as a best practice at all, still, I use it, and even maintain gcc-5 and gcc-6), and you should use glibc-compiled libraries (again, there are almost all of them in Anaconda). In the end, you will use not much of Alpine, which is a bit awkward. Good luck!)

And has this meant that any program run in these containers now runs against glibc?

No. Programs are fine, but, mixing shared libraries is very tricky (I don't exactly understand how, but sometimes this works fine). As a rule of thumb, try not to mix glibc and musl libc C extensions for Python modules.

@elsmorian Why exactly do you need glibc on Alpine?

@jirutka He pointed out the he wants to use Anaconda Python, which (binary) packages are build only against glibc. In fact, there is no need in glibc on Alpine; our need is mostly about small footprint image and glibc requirement. I guess, busybox would suit better here, but,  unfortunately, it was killed :(

@frol We can just make Alpine package for Anaconda (build from source against musl), can’t we?

@jiruka You will have to start with compilation of Python (or try to trick conda to use system Python distribution (which is not a bad idea, by the way)). Next, you recompile all binary packages. BTW, Anaconda has just recently opened some recipes into conda-forge initiative, yet they are still work in progress. Thus, yes, it is possible to build Anaconda infrastructure for musl, but it is a huge effort.

@jirutka @frol Thanks for the info.  Tricking conda into using Python already on the system is interesting but means you loose out on its abilities to pull in any version of python you want per env.
It would be great to have anaconda builds without glibc, but because of it being binary focused, you would have to rebuild all the packages :/
This seems to be working so far, will keep you updated!

+1

Trying to run a node-oracledb project in Alpine with glib libraries causes a number of symbol not found errors. Did anyone get it going ?
Error: Error relocating /opt/oracle/drivers/instantclient/libclntsh.so.11.1: getcontext: symbol not found
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (node_modules/oracledb/lib/oracledb.js:32:19)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (node_modules/oracledb/index.js:1:80)

The link to glibc seems to be dead.  Any alternative source that works?
I tried here, but installing it didn't fix the original problem:
https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.21-r2/glibc-2.21-r2.apk

`FROM alpine:3.2
Install cURL
RUN apk --update add wget curl ca-certificates tar &&
curl -Ls https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.21-r2/glibc-2.21-r2.apk > glibc.apk &&
apk add --allow-untrusted glibc.apk
Java Version
ENV JAVA_VERSION_MAJOR 8
ENV JAVA_VERSION_MINOR 45
ENV JAVA_VERSION_BUILD 14
ENV JAVA_PACKAGE       jdk
Download and unarchive Java
RUN mkdir /opt && curl -jksSLH "Cookie: oraclelicense=accept-securebackup-cookie"
http://download.oracle.com/otn-pub/java/jdk/${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-b${JAVA_VERSION_BUILD}/${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz
| tar -xzf - -C /opt &&
ln -s /opt/jdk1.${JAVA_VERSION_MAJOR}.0_${JAVA_VERSION_MINOR} /opt/jdk &&
rm -rf /opt/jdk/src.zip
/opt/jdk/lib/missioncontrol
/opt/jdk/lib/visualvm
/opt/jdk/lib/javafx
/opt/jdk/jre/lib/plugin.jar
/opt/jdk/jre/lib/ext/jfxrt.jar
/opt/jdk/jre/bin/javaws
/opt/jdk/jre/lib/javaws.jar
/opt/jdk/jre/lib/desktop
/opt/jdk/jre/plugin
/opt/jdk/jre/lib/deploy
/opt/jdk/jre/lib/javafx
/opt/jdk/jre/lib/jfx
/opt/jdk/jre/lib/amd64/libdecora_sse.so
/opt/jdk/jre/lib/amd64/libprism_.so
/opt/jdk/jre/lib/amd64/libfxplugins.so
/opt/jdk/jre/lib/amd64/libglass.so
/opt/jdk/jre/lib/amd64/libgstreamer-lite.so
/opt/jdk/jre/lib/amd64/libjavafx.so
/opt/jdk/jre/lib/amd64/libjfx*.so
Set environment
ENV JAVA_HOME /opt/jdk
ENV PATH ${PATH}:${JAVA_HOME}/bin
`
/ # . /opt/jdk/bin/java -version /bin/sh: /opt/jdk/bin/java: : not found /bin/sh: /opt/jdk/bin/java: : not found @@@@@@@��@@@@ |� @@DDP�td��<EMAIL_ADDRESS>GNU�t�)N�ݓ��;r�Z��?h: nonexistent directory /bin/sh: /opt/jdk/bin/java: line 1: ELF: not found /bin/sh: /opt/jdk/bin/java: �: not found /bin/sh: /opt/jdk/bin/java: line 3: �: not found /bin/sh: /opt/jdk/bin/java: syntax error: unexpected end of file (expecting ")")

@tpischke Why on Earth do you still use 2.21? The project has stabilized on 2.23-r3 and has been transferred to @sgerrand https://github.com/sgerrand/alpine-pkg-glibc/releases. Anyway, just use frolvlad/alpine-glibc or at least just copy the Dockerfile if you don't want to have "external dependency".

Tried 2.23-r2, same result.
Wasn't aware frolvlad/alpine-glibc.  Will give it a try.

Same result with alpine-glibc.  What am I missing?

@tpischke Why do you try to source (. before the command) the Java binary as sh script? Just run it as
$ java -version

Calling java directly didn't work for some reason with my original Dockerfile.  Works beautifully with your image though.  I'm up and running.  Thanks for the help!

@tpischke I still strongly recommend you use frolvlad/alpine-oraclejdk8 instead of crafting your own... There are slim, cleaned and full versions of the images, so you should be just fine.

I very strongly recommend to use package openjdk8 instead of these nasty hacks. If some software doesn’t run on OpenJDK and does on Oracle JDK (which is quite rare), then fix that software instead of crippling Alpine.

Can the java version be specified?  We test and recommend specific java versions to our customers.  Also,  'unofficial' external dependencies are forbidden by the project lead.

Our project is very complex and getting it running on OpenJDK would likely be very costly...

@tpischke Then go and fork it. Just don't copy those broken manuals, please.

I just copied the Dockerfiles from alpine-glibc and alpine-oraclejdk8 and built the images locally myself.  Works beautifully.  I'll discuss migration to OpenJDK with the team, but that's not going to happen in the near term.  Testing alone will be a major effort if we migrate.  For now I have a brilliant working solution, thanks to you guys.  Alpine Docker Images are extremely compelling.

Can the java version be specified? We test and recommend specific java versions to our customers.

No, only major version (there’s package openjdk7 and openjdk8). However, you can copy the openjdk8 abuild, adjust version (and patches if needed) and build it yourself. It’s quite easy and you’ll have it fully under your control.

'unofficial' external dependencies are forbidden by the project lead.

Then why are you trying to use that glibc package on Alpine? This is unofficial hack that is not supported by Alpine community. The only officially supported JRE/JDK are the mentioned openjdk packages built against musl libc.

Our project is very complex and getting it running on OpenJDK would likely be very costly...

Then you’re probably doing it wrong… Oracle JDK is just branded distribution of OpenJDK, the code base is nearly identical. That said, exceptions may exist, mainly in case of graphic applications.
If you really need OracleJDK, then use some glibc-based distribution, not Alpine. Adding glibc to Alpine is not a stable production-quality solution.

@jirutka I also suggest to use OpenJDK wherever possible, but 60k pulls of my OracleJDK image suggest that it is stable enough, and I have been using it in production for quite a bit. Though, it depends on how you define the "production-quality" because Docker itself might be considered as not a production ready solution.

We need to use Oracle Java, and it would sure be nice to use alpine linux.  The fact that the official docker images are moving to alpine also plays a role in the decision.  I hope alpine considers officially supporting oracle java in the future.  For many java developers, openjdk is no alternative.

…Docker itself might be considered as not a production ready solution.

Well, that’s very true! :)

I hope alpine considers officially supporting oracle java in the future.

Once again. Oracle JDK is a proprietary product, they don’t provide source-code of all their modifications to OpenJDK and build system, just binaries. These binaries are build against glibc (GNU C Library). Alpine Linux doesn’t use glibc, it’s based on (much better) musl libc.
Glibc and musl libc are (partially) incompatible (mainly because glibc doesn’t comply with POSIX standards). Therefore software built against glibc may not work on musl libc without recompiling. This is the case of Oracle JDK. Because it’s a proprietary product, we can’t recompile it and there’s nothing we can do about it!
libc is a very base system library, it’s not yet another library you can simply install along with others. Adding support for glibc would basically mean supporting another platform. The cost of this is too high. Also it doesn’t make much sense; Alpine with glibc would not be Alpine anymore! Alpine’s “motto” is: small, simply and secure. You can’t get this with glibc.
Ask Oracle for musl support, they have the key, not Alpine.

Just as musl and glibc 'should' be interchangeable, the reality is that OpenJDK and Oracle JDK also 'should' be interchangeable.  They're not, and it's irresponsible to ship hacks that enable glibc in a broken way on top of a musl-based system.

Just as musl and glibc 'should' be interchangeable, the reality is that OpenJDK and Oracle JDK also 'should' be interchangeable.

This is very different situation. glibc and musl libc are different software, they both implements POSIX standards, but the code base is totally different. Oracle JDK is just a branded distribution of OpenJDK, the source code base is the same.
Also you can easily install more JDKs side by side on one system, but not two libc.

You can't safely and stably install an Oracle JDK on a system with musl libc and it needs to be prominently admitted that such is the case instead of pushing these hacks forward.
You're also wrong about OracleJDK vs OpenJDK, there are significant differences and they do impact performance and stability.  They can exist side by side with glibc provided to them, but the whole point of this exercise is that OracleJDK isn't compiled against musl libc.

I have contacted the Oracle support and I got the following statements regarding libmusl and the JRE / JDK:

The Oracle Java product organization maintains a limited number of "standard" configurations for Java and there is no plan to build it with the libmusl library.  When customers request Java for other configurations, the Oracle Java product organization - Java Engineering  Services (JES) - can create, certify and maintain custom version of Java for alternative O/S, special libraries, embedded architectures, older code bases, etc.
A typical engagement with JES would be: JES proposes a fixed-price engagement to do a "port" which is to deliver a certified version of Java on a non-standard platform. JES could also offer 12-months of Maintenance (renewable each year) to fix bugs and give updates.

So basically, if you need OracleJDK, you'll have to use one of the "standard" configurations for Java (eg use windows or oracle linux). If you need something else you'll have to hire JES.

"Most cross-compatible platform", they say...
The only exit would be a thin glibc facade bound to musl. And maybe this would be a kick for musl usage too.

We have a new glibc package if anyone would like to test this out. You can grab the package at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk and install with apk add --allow-untrusted glibc-2.21-r2.apk. This should allow Oracle Java 8 and other glibc x86_64 native binaries to run on Alpine.

Do you provide the version compatible for ARM64 arch?

@Denusdv "no such project" at that link? :\

Hello, I took over maintenance of the glibc package from Andy. There are
more recent versions available for download and installation at
https://github.com/sgerrand/alpine-pkg-glibc/releases. I suggest you try
there.