issues
2 rows where repo = 13221727, state = "open" and user = 915118 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at ▲ | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1869941964 | I_kwDOAMm_X85vdQzM | 8119 | No-download mode needed for build | amckinstry 915118 | open | 0 | 2 | 2023-08-28T15:03:03Z | 2023-09-15T14:39:36Z | NONE | What is your issue?I'm Debian maintainer for xarray. https://tracker.debian.org/pkg/python-xarray Debian/Ubuntu builds packages offline, from a frozen tarball (or possibly a small <5 number tarballs). xarray requires external objects for both building documentation and testing (we can do testing on our own CI/CD pipelines). Recent releases use pooch to download/cache test objects. We need a method of stating where the cache is (/home not an option -- that is directed to /non-existant on our build systems). Can this be implemented, or how do you suggest we proceed? Best regards Alastair McKinstry |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/8119/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
xarray 13221727 | issue | ||||||||
1334835539 | I_kwDOAMm_X85Pj_lT | 6906 | regression in cftime on s390 | amckinstry 915118 | open | 0 | 10 | 2022-08-10T15:53:54Z | 2022-09-17T12:20:41Z | NONE | What happened?This is on Debian, which supports the S390/s390X archs from IBM. For the 2022.06.0 release: ======================================================================================== short test summary info ======================================================================================== FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[365_day] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[360_day] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[julian] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[all_leap] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[366_day] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[gregorian] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-14 16:00:00 FAILED xarray/tests/test_accessor_dt.py::test_calendar_cftime_2D[proleptic_gregorian] - pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: -809793270280017-04-1 Details are tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004870 What did you expect to happen?No response Minimal Complete Verifiable ExampleNo response MVCE confirmation
Relevant log outputNo response Anything else we need to know?No response Environment
Debian Sid
cftime 1.6.1
pandas 1.3.5+dfsg
python 3.10
This is in a build environment to test any possible fixes or debug.
|
{ "url": "https://api.github.com/repos/pydata/xarray/issues/6906/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
xarray 13221727 | issue |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issues] ( [id] INTEGER PRIMARY KEY, [node_id] TEXT, [number] INTEGER, [title] TEXT, [user] INTEGER REFERENCES [users]([id]), [state] TEXT, [locked] INTEGER, [assignee] INTEGER REFERENCES [users]([id]), [milestone] INTEGER REFERENCES [milestones]([id]), [comments] INTEGER, [created_at] TEXT, [updated_at] TEXT, [closed_at] TEXT, [author_association] TEXT, [active_lock_reason] TEXT, [draft] INTEGER, [pull_request] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [state_reason] TEXT, [repo] INTEGER REFERENCES [repos]([id]), [type] TEXT ); CREATE INDEX [idx_issues_repo] ON [issues] ([repo]); CREATE INDEX [idx_issues_milestone] ON [issues] ([milestone]); CREATE INDEX [idx_issues_assignee] ON [issues] ([assignee]); CREATE INDEX [idx_issues_user] ON [issues] ([user]);