Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 16 22:57
    Jamim edited #244
  • Oct 16 22:38
    Jamim synchronize #244
  • Oct 10 17:33
    Akm0d commented #177
  • Aug 28 00:31
    Jamim commented #244
  • Aug 19 14:15
    Jamim commented #244
  • Aug 19 13:18
    Jamim commented #244
  • Aug 19 13:16
    Jamim synchronize #244
  • Aug 19 13:04
    nir0s commented #228
  • Aug 19 13:03
    nir0s commented #237
  • Aug 19 13:02
    nir0s commented #244
  • Aug 19 13:01

    nir0s on master

    distro.py: include_name => incl… (compare)

  • Aug 19 13:01
    nir0s closed #245
  • Aug 16 06:02
    ferdnyc commented #222
  • Aug 16 05:33
    ferdnyc opened #245
  • Aug 15 10:09
    Jamim edited #244
  • Aug 15 10:08
    Jamim synchronize #244
  • Aug 14 22:58
    Jamim opened #244
  • Aug 06 10:08
    mrhania opened #243
  • Jun 04 04:06
    nir0s commented #242
  • Jun 03 16:36
    ian-kelling opened #242
Seth Michael Larson
@sethmlarson
future thinking but a thing for sure
i don't know if being one file is a thing that is required.
I'll read that issue as well and start thinking about how to fix the issue
Seth Michael Larson
@sethmlarson
Opened that issue, pretty short explanation. Reading up on all those issues your posted to me. nir0s/distro#177
Seth Michael Larson
@sethmlarson
Real question: On Linux Mint the "Best Version" should still be 7.3?
Not 14.04.3
Honestly that's the biggest problem I've run into.
Seth Michael Larson
@sethmlarson
Resolved it in the most sane way possible, still feels pretty hacky.
Seth Michael Larson
@sethmlarson
I'm working on CloudLinux 5-7 test cases.
using virtualbox to get the results
Seth Michael Larson
@sethmlarson
Got those test cases added.
CloudLinux 5 and 6 require some help from the distro inconsistencies PR. They both appear as 'rhel' because they only have redhat-release file in /etc.
no lsb-release either
lsb_release*
Seth Michael Larson
@sethmlarson
Now working on Mandriva Linux #79
Seth Michael Larson
@sethmlarson
Currently we figure out what the "distro_release" file is by just taking the earliest entry from os.listdir(), maybe we could make something that knows about links so we get better ids?
For instance Mandriva Linux has mandrake-release, mandriva-release, redhat-release, and mandrivalinux-release
And even though the ID should be mandrivalinux, the file that comes first is mandrake.
Seth Michael Larson
@sethmlarson
Sorry for causing chaos on your repo @nir0s :P
Seth Michael Larson
@sethmlarson
Pushed a pretty big PR for a good chunk of work for v2 and a roadmap checklist
Would love reviewers. :)
Todd Gamblin
@tgamblin
Does distro have any information on whether distro versions are binary compatible? This would be really useful for Spack (github.com/llnl/spack)
Miroslav Suchý
@xsuchy
@tgamblin distro -j | grep like
Todd Gamblin
@tgamblin
@xsuchy: thanks. I guess that's all the info that is available from the OS release attributes. It doesn't guarantee binary compatibility or tell me what versions of this OS are binary compatible with versions of another.
Nir Cohen
@nir0s
@tgamblin working on https://github.com/cloudify-cosmo/wagon I realized that you can't rely on binary compatibility. Even changing the RPATH and including system dependencies within your binary doesn't promise that.
Your best bet though would be to try out auditwheel of you want to distribute cross platform python packages.
Which is exactly the what wagon does.
Todd Gamblin
@tgamblin
Depends on the distro, but in general you're right. Centos and RHEL is the case that comes up frequently... centos at least promises 100% RHEL compatibility. That may be the one special case though.
In spack at least we will be relying on a very minimal set of system dependencies because we can build the others ourselves.
Nir Cohen
@nir0s
I would guess Ubuntu does the same with debian
At least it seems like it.
Todd Gamblin
@tgamblin
Not sure how close but for a "core" enough set of deps I believe so
Nir Cohen
@nir0s
The trick is to compile binaries on the earliest version of the core distribution.
Since glibc etc retains backwards compat
Todd Gamblin
@tgamblin
yep
currently we’re not distributing binaries. this mostly comes up on clusters where the front-end is RHEL and the compute nodes run CentOS
they share a filesystem, so the CNs see binaries compiled on the front-end.
planning eventually to provide binaries, though.
so distro is very useful
Nir Cohen
@nir0s
Cool. Happy to hear.
Seth Michael Larson
@sethmlarson
Going to be working hard on v2 for distro again now that I have time.
Matěj Cepl
@mcepl
trying to run tests on openSUSE/Tumbleweed and results are quite disaster https://paste.gnome.org/p14ddmzbb any idea what's going on?
Seth Michael Larson
@sethmlarson
I see mentions of Python 2.7.15 from pytest and Python 3.6
is mentioned in the tracebacks. That would be something to look at.
Matěj Cepl
@mcepl
SethMichaelLarson: what do you mean? Aren't these two supported?
(it's Python 3.6.4, BTW, the standard Python3 on Tumbleweed)
or should I just file a ticket at https://github.com/nir0s/distro/issues ?
well, and python2 seems to be passing, isn't it?
Seth Michael Larson
@sethmlarson
Couldn't tell from the paste, I thought there was a conflict and it was using 3.6 libs during the execution of 2.7. I'm on vacation and limited to a phone screen. I'd open an issue and only post the 3.6 failures.
Nick Wilburn
@ragingpastry
I'd love to help get nir0s/distro#185 started up again (windows+macos support). What has to be done here?