IRC Logs for #crux-devel Monday, 2012-06-11

Romsterah that would be handy01:20
Romsterjaeger, but to only warn that there is deps not installed for said port and list them deps before some short pause to continue01:21
Romstersomething like that?01:21
*** mike_k_ has joined #crux-devel01:43
*** mike_k has quit IRC01:43
*** deus_ex has quit IRC02:21
*** deus_ex has joined #crux-devel02:37
*** pitillo has quit IRC07:01
*** pitillo_ has joined #crux-devel07:04
*** pitillo_ is now known as pitillo07:34
*** pitillo has joined #crux-devel07:34
*** sepen has joined #crux-devel07:51
sepenjaeger: I wrote a patch for prt-get a bit similar, to depupdate a port when new deps appeared (http://crux.nu/~sepen/devel/depupdate.notes) http://www.mail-archive.com/crux-devel@lists.crux.nu/msg02256.html07:53
sepenmaybe it would be useful to you07:53
Romstermot to mention one dep removed as well liboil08:00
Romsternot*08:01
jaegersepen: will check it out, thanks08:01
Romsterarch has a required and optional dependencies to solve this another way. but that may be too much for crux to do.08:03
sepennp08:04
Romsterif optional and required dependencies were listed then the minimalist and those that want/need the extra ports for extra functionality could add them in.08:04
Romstershame there is no simple way to grep in configure.in to find required optional and build time deps.08:05
juesepen: Johannes' comment is exactly what I've thought about the way the new option is integrated into prt-get08:06
jaegerMy preference would be for 'prt-get sysup' to notice the new dep and prompt the user to install it or ignore it08:07
jaegerNo need to learn/remember another command that way08:08
Romsterwhat if oyu on pourpose did not install one of the deps and then the port got updated with another new dependency, depupdate would install both, not just the newly seen ones. you'd need some cache to see if it's new than the ones not installed already.08:09
Romsterprompting would be the easiest solution but if it's scripted we don't want it to wait on a selection either.08:10
jaegerIf the port gets updated the dep shows up in the new Pkgfile, unless the maintainer makes a mistake08:10
jaegerThat would be a choice for each user to make08:10
jaegerI'd like a prompt when I run the sysup, so before it even started building packages08:11
Romsterthat would require prt-get to parse the dependency list twice, once to see if any deps are new, second when it builds, though you could reuse that list for the second run saving time.08:12
jaegerwhy would it require parsing twice?08:12
jaeger1) get list of deps   2) if any of these ports are not installed, prompt to install them   3) run08:13
Romsterto see if port foo has a new dependency, hmm maybe it wont need todo that...08:13
jaegera new dep will show up in Pkgfile, prt-get doesn't need to do any special processing to find them besides what it can already do08:13
Romsterget lsit of deps is the same as looking though deptree which reads all the Pkgfiles to find the dependencies.08:14
jaegerI see no reason it would have to do so twice, though08:14
Romstersecond time to install but it can keep the list in an array or struct so it wont need to run twice.08:15
Romsterwont have to parse a second time, i noticed parsing time is a few seconds.08:15
Romsterbest bet is to make it and get testers to try it i guess.08:16
juejaeger: I'd prefer not having interactive features within prt-get ;)08:17
Romsterjue, i'm testing your libffi glib bumps and i bumped atk gtk libsoup ... few new deps and now building webkit.08:20
Romsterseems now it may be fine to bump those up.08:20
Romsteri'll know for sure later.08:20
jueRomster: you had old libffi installed before?08:22
Romsteryes but our of my romster repo before you made yours. http://romster.dyndns.org/linux/ports/crux/romster//libffi/Pkgfile08:24
Romsteri'm only testing in a chroot at compile time atm.08:24
Romsterwith your libffi and glib08:25
juekeep in mind that the update includes a so-name change08:25
Romsteri haven't moved to yours on my system yet. so when i do i'll have to do a rebuild with revdep.08:25
jueeven if it looks like a minor change (3.0.10 -> 3.0.11)08:26
teK_newer gtk would be cool, we're stuck with gimp 2.6.x because of the too old gtk08:26
jueteK_: you mean gtk 3?08:26
Romsteris someone working on gtk3 to install alongside gtk2?08:26
Romsteror could we make gtk = gtk3 and move gtk to gtk208:26
juewouldn't do that, it breaks a lot of things08:27
Romsteri could bump sakura to gtk3 if that was in the ports, i've been debating if i should build a gtk3 port but i read others have done already so i'm hanging off. waiting for someone to make a move.08:27
teK_I dont think it required gtk08:27
teK_308:27
teK_gtk3 is on the roadmap for gimp 3.008:28
Romsterwebkit can use gtk3 i force it to use gtk208:28
teK_the update in question is 2.6.x -> 2.8.x08:28
teK_but I can check on that08:28
teK_./n08:28
Romsterah later 2 branch hmm08:28
Romster2.24.10 is the last gtk2 afaik teK_08:29
jueteK_: that's not a problem at all, I'm running 2.24.10 here08:29
jueand updated friends oc08:29
Romsteroh you mean 2.28 on glib? for gimp to use?08:29
jueno, gtk 2.24.10 and glib 2.32.3 etc.08:30
teK_jue: I dont know who maintains gtk but I've been waiting for an update for a bit now :)08:30
Romstertilman, does gtk08:30
juewell, prt-get info gtk will tell ;)08:30
Romsterit's only .2 revisions behind.08:30
teK_not on a (curent) CRUX box right now as I'm @office08:31
Romster2.http://romster.dyndns.org/version_sort/opt-Tilman-Sauerbeck.html#gtk08:31
teK_as a matter of fact I cannot push the gimp update :)08:31
jueI've sent him patches, but got no response yet08:31
teK_he's such a busy boy :p08:31
Romsteri'm hoping he'll pick up on my xorg fork and merge it in when he has time.08:32
Romsterjue, if i have no issues on testing glib libffi could you push them to core? i want to test more before i give the all clear.08:33
juewell, would do that but our current atk doesn't build with glib 2.3x08:34
jueso we have to update gtk+friends in the same run08:35
Romsteri tested the 2 branch and it buolds fine but that requires tilman to bump that at the time of glib being pushed to core.08:35
Romsteratk 2.4.008:36
Romsterbut i am in the process of testing if that breaks any other ports.08:36
Romstergtk seems happy with atk 2.4.008:36
jueyeah, that's what I'm using here since quite some time08:37
Romsteri've been a bit busy (under statement). else i'd have done that sooner here too.08:37
Romstermonday is a Holiday so i've spent some time on crux stuff. back to work tomorrow.08:38
Romsternearly is tomorrow too 23:38 here.08:38
Romsteris tilman really busy in real life or just needs some space from the computer lately?08:39
Romsteri'm concerned that ports are starting to became stale.08:40
Romstersome are jsut simple bug fix bumps.08:40
Romsterdamn webkit died need to see why.08:41
sepenjue: +1 about cptn notes08:45
juesepen: we, frinnst and me, had some talks about mdev the last days, have you seen that in the logs?09:07
sepenyep but maybe not all09:35
mike_k_teK_: can't get powertop 2.0 to build. will try later. http://paste.lisp.org/+2SA009:38
rmullprt-get sysup wants to update xorg-font-msttcorefonts, but it's not also downloading the cabextract dependency10:01
rmullso building msttcorefonts fails because cabextract doesn't exist10:01
rmullAm I doing something wrong?10:01
rmullaccording to the manpage sysup should resolve the deps...10:02
teK_mike_k_: you have to add -lresolv to the linker flags10:03
teK_rmull: no that's standard behaviour, sepen has a patch10:03
rmullThat's contrary to what the manpage says10:04
rmull"If you don't want prt-get to resolve the dependencies,  use  the  --nodeps  switch"10:04
jaegerthe language there is misleading10:05
jaegerif port a depends on port b, 'prt-get sysup' updates b first, then a10:05
jaegerif port a gains a new dep c after being installed, 'prt-get sysup' ignores c10:05
rmullah.10:05
rmullI think that should be fixed, IMHO10:06
rmullmaybe. Hm.10:06
jaegerIt's not a popular idea10:06
rmullYeah, I started thinking about it more10:06
rmullSeems like feature creep would be harder to detect and avoid10:06
rmullAlright, no big deal, except the manpage seems to avoid the topic10:07
mike_k_teK_: tried that with no visible effect already. will look into that again.10:07
mike_k_teK_: nevermind, fixed that10:09
teK_:)10:11
sepenjue: were you talking about new evdev driver (2.7.0) which requires udev flags, right?10:22
mike_k_teK_: just pushed the new verison. can you test it? I have no CONFIG_DEBUG_FS enabled atm and it fails to start (10:29
teK_I will give it a try10:30
teK_later.10:30
mike_k_thanks. sure.10:30
teK_thank you too10:30
mike_k_np. I am way too bad at keeping port up to date. still hoping to get some time for them.10:31
mike_k_*ports10:31
*** mike_k_ has quit IRC10:40
juesepen: not really, but the discussion from 9 Jun until 9:2011:24
sepenyep I saw that11:27
sepenwhen packaged I saw mdev_fat.conf but just later I picked up the one from alpine, there is no special reason11:29
sepenwhich one are you using now?11:29
sepenI'm not sure that I can tests all devices/inodes, I tried for now to get X running with dri support, and I want to try alsa, usb, etc.11:30
juesepen: mdev_fat.conf currently11:31
sepennote also that those /lib/mdev scripts are from alpinelinux too, just as initial import for tests11:31
jueyes, I noticed that11:32
sepenjue: can I switch directly to mdev_fat.conf or it requires a tweak?11:32
sepenI saw your notes about console11:32
sepenjue: and what kind of config are you using to solve X issue with evdev?11:33
jueyes, should work11:33
jueusing the kbd adn mouse driver ATM11:34
sepennow here I'm using keyboard+mouse (don't like that xorg people adopted udev as a must to have)11:35
jueyeah, that's a pain, mainly because it means that you are more or less forced to use systemd now11:38
sepenwell for 2nd release of mdev port I'll add mdev_fat.conf and a line to /lib/mdev scripts (export PATH...)11:45
sepenon the other side I think we can live without those scripts11:46
jueyes, looks good at all11:51
rmullThe default hashing algorithm for shadow passwords on crux is md5. md5 has known issues. Do we care enough to upgrade to a SHA, or even a bcrypt, although bcrypt is not as simple as a config change?14:00
rmullhttp://sourceware.org/bugzilla/show_bug.cgi?id=13286#c6 relevant reading14:02
rmullulrich says no, but he's always got a bee in his bonnet14:02
rmullabout bcrypt at least.14:03
rmullbut surely a SHA with a large number of rounds makes practical sense?14:03
jaegerIt's come up several times but it seems like people don't agree on which way to go14:03
rmullI've seen the debate about sha/md5 for packages, but not for shadow passwords14:04
rmullSorry if it's repetitive14:04
jaegerAh, fair enough. I think it's come up for both but I could be wrong, maybe it was only for packages14:07
*** Romster has quit IRC16:26
*** Romster has joined #crux-devel16:52
frinnstchanging for passwords is a practical pain on systems with more than one user18:41
frinnstI've changed it on my desktop, only two passwords :)18:41
frinnstjust tweak login.defs (ENCRYPT_METHOD)18:42
*** sepen has quit IRC18:52
*** tilman has quit IRC21:06
*** tilman has joined #crux-devel21:08
*** ____________mavr has quit IRC21:27
*** ____________mav has joined #crux-devel21:28
*** joe9 has quit IRC21:59
*** deus_ex has quit IRC23:13

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!