#archlinux-ports | Logs for 2017-12-01

Back
[00:15:42] <guys> deep42thought: that's fine, I would expect any deletion list to be manually confirmed if there is any chance of anything going wrong.
[00:29:27] -!- guys has quit [Ping timeout: 240 seconds]
[01:11:13] -!- guys has joined #archlinux-ports
[02:32:35] -!- isacdaavid has joined #archlinux-ports
[03:10:15] -!- fsckd_ has joined #archlinux-ports
[03:11:00] -!- fsckd has quit [Remote host closed the connection]
[03:15:18] -!- qrwteyrutiyoup_ has joined #archlinux-ports
[03:15:46] fsckd_ is now known as fsckd
[03:22:43] -!- r00t^2 has quit [*.net *.split]
[03:22:43] -!- qrwteyrutiyoup has quit [*.net *.split]
[03:22:43] qrwteyrutiyoup_ is now known as qrwteyrutiyoup
[03:24:00] -!- r00t^2 has joined #archlinux-ports
[03:30:22] -!- e1z0 has quit [Ping timeout: 260 seconds]
[03:33:01] -!- e1z0 has joined #archlinux-ports
[03:38:11] -!- p71 has quit [Read error: Connection reset by peer]
[04:44:10] -!- mocplayer has joined #archlinux-ports
[04:46:40] -!- mocplayer has quit [Client Quit]
[04:58:33] -!- dantob has joined #archlinux-ports
[05:51:32] -!- hringriin_ has joined #archlinux-ports
[05:54:27] -!- hringriin has quit [Ping timeout: 260 seconds]
[05:54:27] hringriin_ is now known as hringriin
[06:47:47] -!- deep42thought has joined #archlinux-ports
[07:48:08] -!- abaumann has joined #archlinux-ports
[07:48:28] -!- xes__ has joined #archlinux-ports
[07:50:01] -!- xes_ has quit [Ping timeout: 240 seconds]
[07:50:49] <deep42thought> abaumann: https://arch.eckner.net
[07:52:01] <deep42thought> I will use this to redraw the database graph - tyzoid (correctly) complained, that he could not see what is linked by what id
[07:52:20] <abaumann> good idea :-)
[07:53:18] <abaumann> oh, dbmodel is only in AUR, if you like it, give it a vote.
[07:53:26] <deep42thought> I was quite surprised, that this 7-year old piece of software compiled w/o complaining :-)
[07:53:28] <deep42thought> oh
[07:54:02] <abaumann> It's really well done.
[07:54:28] <abaumann> Current build errors are caused by jsoncpp
[07:54:45] <abaumann> current github version compiles, release not (this is not on 32-bit).
[07:58:03] -!- deep42thought has quit [Quit: Leaving.]
[08:04:44] <abaumann> works without trouble in a "normal" build environment..
[08:04:51] <abaumann> ..on the build slaves cmake: error while loading shared libraries: libjsoncpp.so.11:
[08:05:18] <abaumann> so the problem is: cmake depends on libjsoncpp, libjsoncpp has a SONAME bump, the package is installed and cmake fails to work
[08:05:46] <abaumann> so the idea of installing packages for testing in the chroot is not correct for essential build tools IMHO
[08:06:21] <abaumann> similar problem as with icu and pacman
[08:07:22] <abaumann> Can we have an option for certain packages to skip the "install in chroot" test?
[09:05:05] -!- deep42thought has joined #archlinux-ports
[09:22:22] <deep42thought> abaumann: that's what staging is for
[09:22:34] <deep42thought> packages will be installed from testing, but built packages will land in staging
[09:23:09] <deep42thought> so the only thing that may fail are the namcap tests
[09:24:07] <abaumann> mmh. so the cmake/jsoncpp cycle should unbreak itself?
[09:24:16] <deep42thought> yes
[09:24:23] <deep42thought> at least for building and packaging
[09:24:35] <abaumann> let's see :-)
[09:25:23] <deep42thought> namcap is a different story - because for that the new package will be installed
[09:26:20] <deep42thought> so if, for example, a pacman-relevant library gets a soname bump and breaks pacman, then the namcap generation will fail
[09:26:27] <deep42thought> but the build should not
[09:27:38] <abaumann> cmake: error while loading shared libraries: libjsoncpp.so.11
[09:28:02] <abaumann> what I don't get: why should cmake not work, it's linked against the old version of libjsoncpp (libjsoncpp.so.11)
[09:28:15] <abaumann> unless something updates libsoncpp (to libjsoncpp.so.19)
[09:28:54] <deep42thought> hmm, strange indeed
[09:29:00] <deep42thought> jsoncpp is in staging
[09:29:05] <deep42thought> so it should _not_ get installed
[09:29:20] <deep42thought> ah no
[09:29:23] <deep42thought> crap
[09:29:28] <abaumann> mmh?
[09:29:33] <deep42thought> it _will_ get installed
[09:29:53] <deep42thought> the idea behind staging is, to install stuff which is potentially broken and compile against that
[09:30:26] <deep42thought> e.g. it's the "build tools should not be inside the chroot"-issue
[09:30:54] <deep42thought> so, actually you want build tools from testing and libraries and dependencies from staging
[09:31:23] <abaumann> ..and as almost everything is used as a build system nowadays (java, python, meson, cmake, ...) ... :-(
[09:31:51] <deep42thought> shouldn't we schedule cmake, then?
[09:31:55] <deep42thought> and build that first?
[09:32:07] <abaumann> yeah, might help.
[09:32:21] <deep42thought> cmake-3.10.0-3.0 is in staging
[09:33:29] <abaumann> this one is still linked against libjsoncpp.so.11
[09:33:39] <deep42thought> ok, so _that's_ the issue
[09:33:40] <deep42thought> then
[09:34:02] <deep42thought> yeah, they were uploaded at the same time :-)
[09:34:22] <abaumann> ups.
[09:35:14] <deep42thought> circular dependency ...
[09:35:19] <deep42thought> jsoncpp <-> cmake
[09:35:33] <deep42thought> so the buildmaster breaks it anywhere ...
[09:35:37] <abaumann> like pacman <> icu
[09:35:48] <deep42thought> icu depends on pacman?
[09:35:56] <abaumann> indirectly, I thought
[09:36:12] <deep42thought> w/o base?
[09:36:16] <abaumann> no, libpsl
[09:36:18] <abaumann> sorry
[09:36:21] <deep42thought> ah, ok
[09:36:40] <abaumann> so, a build cycle can only be solved with a temporary jsoncpp11 package or so?
[09:36:49] <deep42thought> no
[09:37:10] <deep42thought> we need to break the cycle by ignoring that jsoncpp depends on cmake
[09:37:18] <deep42thought> because it does not care about the cmake version
[09:37:34] <deep42thought> ah, wait
[09:37:36] <deep42thought> you're right
[09:38:14] <deep42thought> maybe, makedepends should not be installed from [staging]?
[09:38:44] <abaumann> it's like using the staging binutils (ld) when compiling gcc. :-)
[09:38:51] <deep42thought> right
[10:00:55] <abaumann> just compiled jsoncpp locally on by slave, works :-)
[10:03:27] <deep42thought> :-)
[10:06:23] <deep42thought> btw, I updated https://buildmaster.archlinux32.org to include all the columns, too
[10:09:46] <deep42thought> the problem, I see with resolving dependencies on "provides=" or "group=", is, that then we rely on upstream moving the packages in the right order and the build master to detect the movement in the right order (e.g.: what happens if the build master sees moving packages and their dependencies within one step?)
[10:11:35] <deep42thought> abaumann: regarding build cycle breaking: the cycle is not the problem - the problem is, that cmake is broken as soon as jsoncpp is updated
[10:11:53] <deep42thought> it's not a big deal, because cmake is not compiled with cmake
[10:12:00] <deep42thought> but for e.g. pacman it's a problem
[10:27:10] <abaumann> deep42thought: tyzoid will be happy with the DB schema. :-)
[10:27:23] <deep42thought> :-)
[10:27:38] <deep42thought> still, the arrows don't start at the precise row/column
[10:28:13] <deep42thought> one thing, I'm absolutely unsure about, is the 'install_targets' table
[10:28:19] <abaumann> yeah. put the FK and the naming of the attribute should be enough
[10:28:36] <abaumann> s/put/but
[10:28:47] <deep42thought> binary_packages.architecture -> package_sources.id ... obviously ;-P
[10:29:24] <abaumann> :-)
[10:43:44] -!- dantob has quit [Quit: dantob]
[13:07:24] -!- dluciv has joined #archlinux-ports
[14:28:22] <tyzoid> deep42thought: What is repository stabilities?
[14:28:44] <tyzoid> is that just a enum type of {STABLE, NONSTABLE} ?
[14:29:14] <deep42thought> a little more
[14:29:32] <deep42thought> stable, staging, testing, standalone, unbuilt, unstable
[14:30:10] <deep42thought> this shall reflect the flow of a package (unbuilt -> staging -> testing -> stable; unbuilt -> standalone; unbuilt -> unstable)
[14:30:18] <tyzoid> Would that change over time?
[14:30:28] <deep42thought> for a single binary package: yes
[14:30:35] <tyzoid> No, I mean the categories
[14:30:44] <deep42thought> not really
[14:30:49] <deep42thought> most probably
[14:30:50] <tyzoid> Then why not use an enum field?
[14:30:58] <deep42thought> a what?
[14:31:00] <deep42thought> :-)
[14:31:07] <tyzoid> https://dev.mysql.com
[14:31:08] <phrik> Title: MySQL :: MySQL 5.7 Reference Manual :: 11.4.4 The ENUM Type (at dev.mysql.com)
[14:31:48] <tyzoid> If it won't change, then it makes more sense to me to use an enum instead of a separate table.
[14:31:51] <deep42thought> this can also be extended, (like I can change from mediumint to bigint)?
[14:31:58] <deep42thought> yeah, sure
[14:32:09] <deep42thought> same for architectures
[14:32:30] <tyzoid> architecture I could see changing. Adding i486/i586 for ex.
[14:32:44] <deep42thought> well, but it's still not "dynamic"
[14:32:52] <deep42thought> e.g. we add it manually and that's it
[14:33:22] <tyzoid> deep42thought: Yeah, but it beats a schema change over the binary_package table
[14:33:40] <deep42thought> hmm, right
[14:33:45] <tyzoid> up to you, though. I'd be fine with enum there. I'm just playing devil's advocate here :)
[14:33:52] <tyzoid> Making sure we consider all cases
[14:33:54] <deep42thought> it's fine
[14:34:10] <deep42thought> problem might be, that we might want to add some logic to the repository_stabilities table
[14:34:22] <tyzoid> such as?
[14:34:31] <deep42thought> e.g. parameters for connecting to the bug tracker
[14:34:39] <deep42thought> or which state becomes which on which conditions
[14:36:02] <tyzoid> True, but if the different states don't change, then it won't be necessary
[14:36:09] <tyzoid> If they do change, then we can leave it as a table
[14:36:24] <deep42thought> so you want to have the same ENUM in different tables?
[14:36:47] <tyzoid> Originally, my idea for the bugtracker/database was to have a table that tracked lifecycle
[14:37:02] <tyzoid> only one table references repository_stabilities rn.
[14:37:10] <deep42thought> yet
[14:37:40] <deep42thought> what exactly do you mean by "track lifecycle"?
[14:38:03] <deep42thought> "have a record of each and every package in the state it ever had"?
[14:38:19] <tyzoid> Sort of
[14:38:28] <tyzoid> Because the bugtracker keeps bugs around in perpetuity
[14:38:34] <deep42thought> wouldn't that grow indefinitely?
[14:38:35] <deep42thought> hmm
[14:38:43] <tyzoid> It might be nice to see what bugs were fixed/reported at each stage of the package
[14:38:59] <tyzoid> i.e. staging -> testing -> <repo> -> archive
[14:39:22] <tyzoid> and the benefit of tracking lifecycle is that you can set different conditions for different packages
[14:39:32] <tyzoid> and use those conditions for advancement
[14:40:22] <tyzoid> Ex: package apache. Current lifecycle: staging -> testing -> extra -> archive
[14:40:23] <deep42thought> I would like to separate the "current tracking" from the "history book keeping"
[14:40:47] <tyzoid> so use a separate table for history?
[14:40:56] <deep42thought> probably
[14:41:09] <deep42thought> I'm not yet sure, what would be in that table :-/
[14:41:45] <tyzoid> That was essentially my 'revision' table idea from earlier: https://imgur.com
[14:41:46] <phrik> Title: Imgur: The most awesome images on the Internet (at imgur.com)
[14:41:56] <tyzoid> but I didn't finish adding all the fields I wanted
[14:42:04] <tyzoid> plus, keeping track of the dependency tree gets a bit messy.
[14:42:16] <tyzoid> esp. with virtual packages
[14:43:39] -!- drathir has joined #archlinux-ports
[14:46:01] -!- Cthulu201 has quit [Quit: WeeChat 1.9.1]
[14:46:43] <deep42thought> I think, *_archive tables (or an archive db) would suffice, where all entries are moved, that would be deleted otherwise
[14:47:02] <deep42thought> ah, no
[14:47:15] <deep42thought> then you wouldn't track if a package traverses the repositories ..
[14:47:15] <tyzoid> deep42thought: I think we should consider what sorts of questions we'll be asking the database.
[14:47:32] <deep42thought> the recent-state or the history-state one?
[14:47:36] <tyzoid> both
[14:47:50] <tyzoid> Design the db around the questions you're going to ask.
[14:48:10] <deep42thought> my questions are centered around dependency resolving
[14:48:12] <tyzoid> Because it may turn out that we're interested in a particular question, and the design would make that ineffecient
[14:48:28] <tyzoid> so do you need to build out the whole dependency tree?
[14:48:34] <tyzoid> or just direct dependencies?
[14:48:50] <deep42thought> "what does this package depend on, that's currently in one of the following repositories?"
[14:49:13] <deep42thought> tree is necessary, I think
[14:49:33] <deep42thought> but it's only the tree consisting of packages in certain repositories
[14:49:54] <tyzoid> that would require two joins in the current schema, which isn't bad
[14:50:11] <tyzoid> but the whole tree requires a recursive query
[14:50:15] <deep42thought> it's more
[14:50:16] <tyzoid> and circular dependencies are a thing
[14:50:31] <deep42thought> circular dependencies don't concern me at this point
[14:51:07] <tyzoid> oh, wait, depending_on goes to install_target
[14:51:08] <tyzoid> :/
[14:51:16] <deep42thought> yes
[14:51:19] <tyzoid> so yeah, that's at least 4-5 joins
[14:51:34] <deep42thought> 3 or 5
[14:51:42] <deep42thought> and then unified over these
[14:51:46] <deep42thought> (3,5,5)
[14:51:46] -!- jemadux has joined #archlinux-ports
[14:51:47] <tyzoid> both trees need to be evaluated
[14:51:58] <tyzoid> s/trees/branches/
[14:52:05] -!- jemadux_ has joined #archlinux-ports
[14:52:18] <tyzoid> deep42thought: I thought group dependencies weren't allowed?
[14:52:37] <deep42thought> I'd like to keep this around for base and base-devel
[14:52:50] <deep42thought> they're not mentioned in the PKGBUILD
[14:52:53] <deep42thought> but still dependencies
[14:53:26] <tyzoid> I'd prefer you toss those. Not everyone has all of base/base-devel installed
[14:53:52] <deep42thought> bad idea
[14:54:22] <deep42thought> base-devel is a makedependency for everything
[14:54:56] <deep42thought> and especially library changes should be scheduled in the correct order
[14:55:02] <deep42thought> e.g. base-devel before the rest
[14:55:22] -!- jemadux_ has quit [Client Quit]
[14:55:33] -!- jemadux has quit [Remote host closed the connection]
[14:55:37] <tyzoid> deep42thought: But even at that point, you always are going to depend on those groups, why encode that?
[14:55:49] <tyzoid> Your application logic can introduce that, no?
[14:55:54] -!- jemadux has joined #archlinux-ports
[14:56:01] <deep42thought> it _can_
[14:56:15] <deep42thought> but I already got enough extra cases for base and base-devel
[14:56:20] <deep42thought> it becomes annoying
[14:56:32] <tyzoid> makedependency, sure, but the only thing in base-devel that's actually handy for a system that's not doing builds is sudo.
[14:57:16] <tyzoid> regardless, that's one monster query
[14:57:45] <deep42thought> this database is not solely for run-dependencies of packages
[14:57:54] <deep42thought> it should also correctly schedule builds
[14:57:56] <tyzoid> plus what even is the logic for virtual packages?
[14:58:08] <tyzoid> since it may or may not be any number of other things
[14:58:25] <tyzoid> I'll agree with you there
[14:59:20] <tyzoid> deep42thought: Is a relational database even the best option here?
[14:59:40] <tyzoid> The more I think about it, an object dabase like mongodb might make more sense.
[15:00:27] <deep42thought> we could merge "virtual_packages" "groups" "virtual_package_providers" "unknown_install_targets" and "group_members" into a "install_target_providers" table between install_targets (which would need a "name" column, then) and "binary_packages"
[15:02:04] <deep42thought> what property of an object database would we use, that isn't also present in a relational database?
[15:02:33] <tyzoid> polymorphism?
[15:03:11] <tyzoid> And mongodb is a document database which operates on json objects. You can have arrays/other datatypes in there.
[15:03:53] <tyzoid> That said, my training has only been in relational dbs, but this sounds like a problem that's not suited towards rdbms
[15:04:46] <deep42thought> I think, relational is fine
[15:04:56] <tyzoid> ok
[15:06:37] <tyzoid> deep42thought: https://github.com appears to be a thing
[15:06:38] <phrik> Title: GitHub - markzz/php-alpm: A PHP extension to use Arch Linux's ALPM (based on pyalpm) (at github.com)
[15:06:53] <tyzoid> unrelated, but interesting nonetheless
[15:07:28] <drathir> tyzoid: may i pm?
[15:09:04] <tyzoid> drathir: Go ahead
[15:18:43] <deep42thought> tyzoid: I changed the proposed database layout, but I'll leave now for the weekend
[15:18:45] <deep42thought> cu later!
[15:18:52] -!- deep42thought has quit [Quit: Leaving.]
[15:24:51] -!- tonystark has joined #archlinux-ports
[15:27:41] -!- dluciv has quit [Quit: Page closed]
[15:33:14] -!- guys has quit [Ping timeout: 250 seconds]
[15:52:23] -!- abaumann has quit [Quit: leaving]
[15:58:44] -!- Cthulu201 has joined #archlinux-ports
[15:59:37] fsckd is now known as achillion
[15:59:43] achillion is now known as fsckd
[16:12:15] -!- guys has joined #archlinux-ports
[16:17:24] fsckd is now known as {OvO}
[16:18:21] -!- tonystark has quit [Ping timeout: 240 seconds]
[16:38:36] -!- jemadux has quit [Remote host closed the connection]
[16:52:53] -!- mode/#archlinux-ports [+o tyzoid] by ChanServ
[17:58:10] -!- yokel has quit [Remote host closed the connection]
[18:00:45] -!- yokel has joined #archlinux-ports
[19:14:27] -!- guys has quit [Ping timeout: 240 seconds]
[20:30:55] -!- isacdaavid has quit [Quit: Leaving.]
[20:45:11] -!- jemadux has joined #archlinux-ports
[20:54:23] -!- jemadux_ has joined #archlinux-ports
[20:54:42] -!- jemadux_ has quit [Remote host closed the connection]
[20:54:59] -!- jemadux has quit [Remote host closed the connection]
[20:55:35] -!- jemadux has joined #archlinux-ports
[20:59:24] -!- jemadux has quit [Remote host closed the connection]
[22:39:16] -!- isacdaavid has joined #archlinux-ports
[23:50:06] -!- zaungast has joined #archlinux-ports
[23:56:30] -!- yokel has quit [Remote host closed the connection]
[23:57:13] -!- yokel has joined #archlinux-ports