#16149 closed bug (fixed)
HaikuDepot doesn't shows packages from all other repos
Reported by: | lorglas | Owned by: | apl-haiku |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta3 |
Component: | Applications/HaikuDepot | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
hrev54625 x86_64
HaikuDepot doesn't shows packages from BeSly Software solution, Kapix. It only shows packages from haiku, haikuports and fatelk repos.
Attachments (2)
Change History (24)
comment:1 by , 4 years ago
Component: | - General → Applications/HaikuDepot |
---|---|
Description: | modified (diff) |
Owner: | changed from | to
Summary: | Haikudepot doesn't shows packages from all other repo → HaikuDepot doesn't shows packages from all other repos |
by , 4 years ago
Attachment: | BeSly-Software-Solutions.png added |
---|
comment:3 by , 4 years ago
a little test: i download the .repo file from BeSly and Fatelk repository,
If i want to list the content over the terminal i get following by fatelk:
package_repo list repo.1
repository-info:
name: FatElk_64
summary: Fat Elk x86_64 package repository
base-url: http://fatelk.com/repo_64
identifier: http://fatelk.com/repo_64
vendor: Fat Elk Software
priority: 1
architecture: x86_64
packages:
beshare_info
beshare
bookmarker
helpviewer
loopdloop
vncserver
yoshi
and by BeSly Software Solutions
package_repo list repo
Error: Unable to unarchive repository info**
It seems that the problem is to unarchive the repo data.
comment:4 by , 4 years ago
repo.info for BeSly:
name "BeSly Software Solutions" vendor "BeSly Software Solutions" summary "BeSly Software Solutions - x86_gcc2 package repository" priority 2 url <https://software.besly.de/repo> architecture x86_gcc2
repo.info for fatelk:
name "FatElk" vendor "Fat Elk Software" summary "Fat Elk x86_gcc2 package repository" priority 1 url http://fatelk.com/repo architecture x86_gcc2
note: the name field has no space for fatelk, or any of the repos that work, but there is a space in the name field for all the repos that do not work. I think it fails because of the space in the name.
comment:6 by , 4 years ago
more repo.info:
clasqm's :
name "clasqm's x86_gcc2 repo" vendor "clasqm" summary "clasqm's x86_gcc2 package repository" priority 2 url http://clasquin-Johnson.co.za/michel/repo architecture x86_gcc2 any
Kapix's:
name "KapiX's Depot" vendor "KapiX's Depot" summary "KapiX's x86_gcc2 package repository" priority 2 url <http://haiku.kacperkasper.pl/repo/x86_gcc2> architecture x86_gcc2
more spaces in the name field.
comment:7 by , 4 years ago
Could you please configure your non-functioning repository and then follow the instructions here under "Diagnostic Logs" and then attach the resulting trace log to this ticket.
Another thing that you could do to test your hypothesis is to temporarily setup another repository with a simplified name containing only latin alpha-numeric characters, vend it over HTTP/S and then see if it is picked up by HaikuDepot and HaikuDepotServer.
comment:8 by , 4 years ago
It looks like the repo file , software.besly.de/repo/repo is indeed corrupted and may need to be replaced. This may not resolve the issue however
comment:9 by , 4 years ago
Interestingly, I created a repo: http://fatelk.com/repo_1
name "Fat Elk" vendor "Fat Elk Software" summary "Fat Elk x86_gcc2 package repository" priority 1 url http://fatelk.com/repo_1 architecture x86_gcc2
With this one added it showd all of the files, but the original fatelk repo : http://fatelk.com/repo would show no packages.
Once I disabeled the "Fat Elk" repo and had only the "FatElk" one enabled and refreshed the repositiorie, the original one showed the files again. hmmm :/
comment:10 by , 4 years ago
I am unable to spend time on this today, but some background; The Haiku system tends to use the name of the repository as the identifier. For example, the name is used in on-disk caches and configurations. Also in some HaikuDepot logic the name is used as a key for a repository. I can't immediately see why the name having spaces or punctuation would make any difference. If you can get that trace log from HaikuDepot that would hopefully give some insight into what is going on.
PS: The logic in Haiku where local data is married up with data frm HaikuDepotServer uses the "identifier" (formerly "url") instead of the name.
comment:11 by , 4 years ago
I would like to request a bugfix for this ticket. Using the nightly x86_64 haiku-master-hrev54282-x86_64-anyboot.iso (It was the latest on the server when I installed a couple days ago.)
HaikuDepot debug output https://gofile.io/d/8xX7Jx
Depots installed: https://gofile.io/d/jwMcSk
BeSly, clasqm, KapiX's - all of the depots with space and/or character in the name the archive fail to be loaded/decoded.
I used the x86_64 variant depots... Seems as though the string sent as the name gets cut. Please help!
comment:12 by , 4 years ago
Could you please create a tar-ball or ZIP of your /system/settings/package-repositories
and attach that to this ticket for me?
comment:13 by , 4 years ago
The issue has been caused by change e31b3cb943b1e05393b3e3e7565dd65a3404735f together with the data in the HPKR file. Inside the HPKR is a serialized BMessage
that contains a BRepositoryInfo
and inside this data is a value for the key url
;
<http://haiku.kacperkasper.pl/repo/x86_64>
Note the "<" and ">" are the problem here because the change is taking the url
key to be the identifier
and then taking the identifier
to be the baseUrl
and then it checks to make sure that the baseUrl
starts with "http", but this does not; it starts with "<" and so it fails to read.
The same applies to the Clasqm repository which has a value of;
<http://clasquin-Johnson.co.za/michel/repo>
I think if you make the url
in the HPKR a well-formed "http" URL then it will most likely work again.
---
Adrien; A couple of questions...
Would it be a good idea to also write the identifier
into the BMessage
in BRepositoryInfo::Archive(..)
so that in the future the BMessage
is populated with this field?
In BRepositoryInfo::_SetTo
things can go wrong (as is the case in this ticket) and there is no way for the user to know what happened and no way for somebody technical to diagnose what is wrong without code-level debugging. What is the best way to signal the problem -- fprintf
statements to stderr or should it return kit-specific error codes?
comment:15 by , 4 years ago
Hello, why was that changed, what was the reason for it? I am interested and I want to understand it.
comment:16 by , 4 years ago
I will take a look to see if I can see a sensible fix for this issue in code.
An error message should be shown in a popup, yes.
This is deep in the bowels of the pkg library rather than a GUI element so the information about the error needs to be signaled up to GUI code / tool / daemon. Would it be more appropriate to continue as it does and return B_BAD_DATA
and log to stderr for diagnostics or would it be better to go down the path of creating very specific response codes?
Hello, why was that changed, what was the reason for it? I am interested and I want to understand it.
This is a long and confusing story! A good ticket for some background reading is #14927.
comment:17 by , 4 years ago
I have removed the < > from the url and write new repo files. Then it works. Will be that changed in a few times back. And how can you inform other repo owner to change the files? the pop-up message is a good think.
comment:19 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:20 by , 4 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
empty software