[00:04] cyphermox, robru: updated the bug: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/646798 [00:04] Launchpad bug 646798 in Eye of GNOME "eog window size exceeds screen height" [Medium,Confirmed] [00:04] Is it ok? [00:05] lol thanks ubot2` [00:05] LeartS, yes, I like it. the simplified description is much easier to understand ;-) [00:08] thanks cool [00:09] Should i attach the patch on launchpad? [00:09] well, it's not necessary [00:09] it's clear on the upstream bug :) [00:10] * cyphermox prepares the upload for the fix [00:10] Or shall I? I've never understood the difference [00:10] to do what? [00:11] cyphermox: there is a whitespace/tab only line on the first patch I uploaded (I don't know how much you care given it should be temporary) [00:11] I mean when to use shall [00:11] English in not my mother tongue [00:11] oh [00:12] well, nah that's not big deal, I'll just fix it as I make the package [00:12] LeartS: I meant, if you want to learn packaging I can also let you do it, but that may be more reading for you to do ;) [00:15] No, I'll let you do it. I had enough fun for today.. [00:16] hehe alright :) [00:17] hmm, seems it's one that is slightly bugged in UDD too [00:20] Yeah, I had problems branching the latest realease [00:20] It would branch 3.2 :/ [00:21] 3 days learning baazar, and the first bug I try to fix I can't use it.. [00:34] LeartS: that's because lp:ubuntu/eog is out of sync [00:35] we package many gnome desktop thingies in lp:~ubuntu-desktop//ubuntu [00:36] fix verified... [00:36] so now I'll build the source package and upload [00:39] Cool. cyphermox: would you mind uploading a screenshot of eog open with an image that was giving you problems before? I'd like to see if the new behavior is consistant [00:40] ok [00:40] it's pretty agressive with the scaling but that's fine [00:42] http://people.ubuntu.com/~mathieu-tl/Capture%20du%202013-05-09%2020:40:39.png [00:44] LeartS: uploaded to saucy. [00:45] once we get the review I'll upload to raring as well [00:45] but yeah, I expect I'll wake up tomorrow with the email in my inbox [00:45] Yeah, I fear that is a remark they could do upstream. I actually never liked how eog would open large images almost maximized and prefer the size now, but I understand that it is subjective and with smaller resolutions it may be a little too much [00:46] good job anyway [00:46] scaling to 0.75 is reasonable anyway [00:47] Thanks :) [00:47] otherwise you could possibly try to calculate the scale factor needed to match to the actual screen size [00:47] but yeah, this is fine [00:47] well, I already know how to do that.. it came in mind when finding the bug formula [00:48] ok [00:48] bbl, I need to get back home. [00:48] Just need to change 0,75 to the inverse of the aspect ratio [00:48] Bye! [01:06] Bye all! [01:20] cyphermox, home yet? ;-) [01:33] now I am, yes [01:37] robru: want to review one change for me? https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/autopilot-tests-autopilot/+merge/162463 [01:39] robru: also https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/unity-gtk-module/+merge/163247 for attente [01:42] robru: rev 299 in stacks/head/webapp.cfg seems very very wrong to me [01:45] hmm [01:45] on the other hand I guess this hook stuff is just for CI [01:47] cyphermox, which one seems wrong? vrruiz did actually make a mistake in there recently, but he reverted it... [01:48] hooks: D09add-ppa~webapps~staging [01:48] it seems to be CI [01:48] it's still a symptom of a badly configured CI setup imho [01:50] cyphermox, yeah, that was for CI. we were having a terrible issue getting the webapps to do CI properly because of a really heinous build-dep/bootstrapping issue. [01:50] robru: so I'm going to start the webapp run now; but still pointing to the next/daily-build-next PPAs with saucy [01:50] cyphermox, eah [01:50] yeah [01:51] cyphermox, I am not certain about that particular line; if you feel it's wrong you should raise that with vrruiz and fginther, they worked on that quite a bit today and that's a small part of what they had to do to get CI even working at all. or maybe that was just a failed attempt that didn't get reverted; I'm not sure [01:51] I brought it up [01:51] I'm sure it's something that can be avoided by changing the CI logic slightly [01:51] ie. grabbing the right build-depends first. [01:52] hmm [01:52] cyphermox, I think probably it won't be an issue once unity-webapps-common 2.4.15 is more widely distributed (eg, once it hits distro). because that version was necessary to have in the CI environment in order for CI to function on webapps (webapps packages need that dep in place even if you're just making the source package) [01:52] though I guess it's build-depends between source packages of a similar stack, so it's fine [01:53] yeah, basically all of the lp:unity-webapps-* branches can't even do a source package build without unity-webapps-common in place (because unity-webapps-common provides the shared debian/rules file used by all webapps packages). so this situation is wreaking havoc on a lot of the tooling; nobody expected that there would be such a thing as a build dep that was needed at source-package-creation time, only at build time ;-) [01:57] ok running now [01:57] cyphermox, so yeah, let me know if any of the stack fails. I'm pretty sure I fixed everything, but there could be a new issue now ;-) [02:06] sure [02:06] well, things are running now [02:06] but all the other stacks triggered, too [02:06] wanna watch webapps yourself? you'll see what explodes in jenkins directly [02:06] is that bad? or just slow? [02:06] yeah [02:06] ok [02:07] here's another for review: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/master-job-template-sync/+merge/163249 [02:07] well, it's not slow [02:07] but all the other stacks started, and some triggered before the prepare jobs started [02:08] I don't understand this review. what's that token and why are we changing it [02:08] ? [02:08] if you look at the queue, before webapps reaches the build stage, it will have to be done triggering a few of the other prepare jobs for things like unity [02:08] robru: it's the issue with cu2d-run [02:08] cyphermox, clearly the original is just a placeholder. is the token not supposed to be secret? [02:09] it's just configuration; I had made an initial fix (the value you see removed) and properly fixing it here [02:09] robru: it's already not secret. [02:09] cyphermox, alright then [02:12] hmm wtf [02:12] what in the hell is libeatmydata? [02:12] for some reason some jobs actually trigger with cu2d-run anyway ?! o.O? [02:13] robru: it's a library that makes things not fsync() and sync() to make them go faster [02:14] cyphermox, well it's awfully broken in jenkins right now [02:14] is it? [02:14] http://10.97.0.1:8080/job/cu2d-webapp-head-1.1prepare-unity-webapps-facebookmessenger/11/console like 80% of this log is errors from it. it's spamming madly [02:18] fun [02:19] well it's not hugely damaging as it is right now [02:19] I'll take note and look into this tomorrow [02:20] I wish I understood what's happening with jenkins... someone must have made changed because starting jobs was definitely failing yesterday, and I could only get them to run with the token change [02:21] I truly don't understand [02:22] cyphermox, uh, go back to that link I just linked... there's some error about saucy there [02:22] someone had to go back and fix the bug [02:22] ok [02:23] cyphermox, it seems the PPA itself is not built for saucy? hrm... with friends stack we didn't encounter this because we just skipped straight to distro [02:23] *sigh* [02:23] it should just work... [02:24] cyphermox, to be honest I'm quite weary of all these jenkins issues, maybe we should just push directly to distro and then fix whatever breakages we may find. [02:24] cyphermox, I don't think anybody could blame us for breaking the dev series in the first month ;-) [02:25] cyphermox, plus, webapps is hardly mission-criticial infrastructure. it's just web chrome ;-) [02:27] right, but I suspect it would fail just as much [02:27] well... [02:28] that shouldn't actually be failing the build either [02:30] cyphermox, are there any saucy packages in the PPA? maybe pushing a saucy package manually would help jenkins along [02:30] meh [02:31] it probably would [02:31] but that's a really crappy way of fixing this ;) [02:31] cyphermox, it would create the index file that jenkins is puking about not having [02:31] yes [02:34] this is so ugly. [02:35] yep. [02:35] alright, I copied ubuntu-unity-next ;) [02:35] hehe [02:36] just waiting until it's actually published and then I'll rerun [02:37] I don't want to just upload to distro -- we have all this tooling to avoid pushing broken stuff, so we might as well use it ;) [02:37] cyphermox, yeah, but it's not the stuff that's broken, it's the tooling ;-) [02:37] only part of it [02:37] only the parts didrocks didn't write himself :P [02:38] actually, scratch that [02:38] this bug we're hitting is one in the scripts didrocks wrote [02:38] possibly even a feature, but I'll track it down tomorrow and file a merge [02:39] cyphermox, fair enough. must be late there [02:42] robru: getting late yet [02:42] *yes [02:42] ok, trying again [02:48] robru: you know, this could actually be caused by the hook.. [02:48] which hook? and how? [02:49] oh, the libeatmydata thing? [02:49] oh wait no, it's a different ppa [02:49] cyphermox, yeah, was gonna say, webapps/staging shouldn't have too much crap in it... just webapps stuff [02:53] well, it wasn't about eatmydata [02:56] cyphermox, you lost me. you think having an extra PPA enabled causes jenkins to die of a 404? [02:56] no [02:57] it's just late, I'm tired [02:58] cyphermox, haha, get some sleep. I'm watching the build. it looks like it just got past that 404 now at least [03:02] yeah [03:02] cyphermox, BAH, it's not done yet, but I just saw in the log that it downloaded unity-webapps-common 2.4.14, so basically I can already tell that this is going to fail... [03:02] ok, why? [03:03] things should just work by building from this PPA [03:03] well [03:03] by building from the same archive that it does right now [03:03] otherwise we'll need to do bootstrapping magic [03:03] because all of lp:unity-webapps-* *require* having unity-webapps-common 2.4.15 in order to even think about building. 2.4.14 does not provide rules.mk, and therefore none of the webapps have a debian/rules file. [03:04] well, that's fine for the prepare task [03:04] actually [03:04] cyphermox, does the prepare task build a source package? [03:04] what's that rules.mk file for? [03:04] right [03:04] cyphermox, rules.mk *IS* debian/rules [03:04] so you need it for the OH [03:05] cyphermox, I just provide it from unity-webapps-common since it's identical across all 41 webapps and I didn't want it to be a copy&paste nightmare [03:05] yeah, we'll need to first upload unity-webapps-common to the ubuntu-unity/daily-build-next ppa in that case [03:05] cyphermox, so every webapp just has a 1-line debian/rules that imports rules.mk [03:05] hmm [03:05] cyphermox, yeah, but I thought didrocks did that already. [03:05] ah, maybe for raring [03:06] crap [03:06] ok, yeah it's there for raring [03:06] unity-webapps-common 2.4.15 is so utterly critical that we should really bump it to version 3.0 [03:07] that's up to you [03:07] yeah, I'll talk that over with webapps guys tomorrow [03:07] ok, so there will be some magic needed to properly depend on that package then for the build [03:08] cyphermox, by magic do you mean "we need to upload a saucy build of 2.4.15"? [03:11] well, that too :) [03:11] cyphermox, what else is required? [03:11] no issues here with eatmydata btw, so it's got to be special to the pbuilder chroot used or whatnot [03:17] in the daily-build-next all of this should depwait until u-w-c is built, but it won't because I'll need to upload a copy of u-w-c to the ppa first in order for things to successfully prepare [03:17] cyphermox, yep [03:20] robru: I guess it's fine, yeah I'll have to copy the package to saucy in that ppa as well [03:24] robru: actually, I don't [03:24] robru: http://10.97.0.1:8080/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-1.1prepare-webapps-applications/13/ [03:24] watch this one; at the end, it should upload directly to ubuntu-unity/daily-build-next [03:24] in which case you'll get the package in saucy properly [03:24] cyphermox, right, then just run the whole stack again? [03:25] then we can do another run again, yes [03:25] cyphermox, but wait, won't it fail the whole stack? [03:25] it will fail everything else yeah, and not run through the build task [03:25] cyphermox, jenkins will hold back the whole stack upon any single failure, so webapps-applications won't get publisehd [03:25] it will still be uploaded and actually build on the ppa [03:25] nah, it will [03:25] ok.... [03:26] in ubuntu-unity/daily-build-next only [03:26] not in ubuntu-unity/next [03:26] daily-build-next is just scratch space for the builds [03:26] everything is copied to their final destination after, and IIF the autopilot tests pass [03:27] ok [03:27] that said, I'll do a rerun in my morning [03:28] in 6-7 hours [03:28] cyphermox, great [03:28] cyphermox, thanks [03:28] np [03:28] so, if anything happens send me an email [03:28] cyphermox, ok. just about dinner time for me, I'll check it when I get back [03:29] ok [03:29] as for the token stuff, I don't know what happened [03:29] I'll need to ask retoaded in the morning, I'm convinced something was modified, I could trace the packets and see that something wasn't right [03:30] jenkins was definitely telling me to bugger off and that I had wrong credentials [03:30] maybe the extra permissions they gave me are now kicking in and didn't before [03:34] cyphermox, no idea [04:51] Good morning [04:59] pitti, hello! [04:59] hello [04:59] hey robru, how are you? [04:59] pitti, getting by I suppose [04:59] pitti, how's germany treating you? [05:00] robru: that doesn't sound too good? [05:00] pitti, yeah, things are rough now, not gonna lie. gf of 4 years just broke up with me. :-/ [05:00] robru: pretty well; we had a nice hike yesterday (national holiday) [05:00] robru: argh, I'm sorry to hear that; that's terrible! [05:00] it's ok [05:01] hike sounds sweet. I've always wanted to visit germany. we should plan the next sprint for there! [05:03] I'd go for a Berlin sprint. [05:03] RAOF, yeah! [05:05] we had one there, although in the least fashionable part of the cicy [05:05] city [05:06] but the go-kart race was awesome :) [05:06] pitti, yes, well, that seems to be the modus operandi around here ;-) [05:06] (i mean, oakland is the least-fashionable part of SFO ;-) [05:07] heh, yes [05:07] as long as it's easy to get to the good parts [05:33] are the category labels (left-hand pane) in software-center, required to have text wrapping? [05:39] darkxst: I uploaded the systemd SRU you requested FYI [05:46] pitti, thanks ;) [05:49] pitti, I will add the SRU paperwork a little later [06:15] pitti, robru, sprint in Montreal where you could not do it anywhere near the least fashionable parts [06:15] ;) [06:16] hehe -- UBZ in 2005! [06:16] ("Ubuntu Below Zero") [06:16] yeah [06:16] except ATM its ua35 [08:47] cyphermox: hi! Did you re-deploy the QA stack in the end? [08:47] cyphermox: since I want to know if I forgot something in the config or not... ;) === vrruiz_ is now known as rvr [09:15] sil2100: did you figure out which version of autopilot is being run via jenkins? [09:15] I now see some autopilot 1.3 test changes have been merged in trunk, and some not [09:16] Mirv: it *should* use 1.3 now, since that's what's in the PPA and Francis fixed the jenkins job to do a proper upgrade [09:16] Mirv: and from one job I saw, it seems that it's indeed using 1.3 already [09:18] Mirv: yep, at least the OIF stack is using 1.3 - so I think it's the same for all [09:24] sil2100: ok, good, better that way, now we just need to merge remaining fixes / do more fixes to run on 1.3 [09:24] * sil2100 just got a failure by success [09:31] attente_: hi! Once you're here, I re-merged trunk into that 1.3 autopilot branch -> https://code.launchpad.net/~sil2100/unity-gtk-module/autopilot_1.3_modifications/+merge/163203 [09:31] attente_: if you want to test it with autopilot 1.3, we have the latest autopilot in our daily-build-next PPA [09:32] attente_: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next [09:32] attente_: if you want to test it on 1.3, after adding that PPA install/upgrade autopilot-desktop and unity-autopilot [10:23] fginther: ping once you're here === tkamppeter__ is now known as tkamppeter [11:33] When trying to connect to pad.ubuntu.com, It says: "PAD has requested some personal information. Please choose what you would like to share:" but there is nothing I can check, and if I click on "Yes, log me in" it says that I have not granted access .. [11:38] LeartS: are you part of the etherpad team ? [11:38] LeartS: https://launchpad.net/~ubuntu-etherpad [11:39] No, I just saw the link in the channel topic and paid a visit :) [11:39] What's the etherpad team? [11:40] It has a lot of members! [11:40] it does we use it for UDS for note takig [11:40] *taking [11:41] UDS = Ubuntu Development ? [11:42] summit [11:43] uds.ubuntu.com [12:51] sil2100, pong [12:51] sil2100, thanks === attente_ is now known as attente === greyback is now known as greyback|lunch [12:56] czajkowski, robru: the patch has been accepted upstream. [12:56] nout to do with me [12:56] sil2100, i'm getting the following: ImportError: cannot import name get_compiz_option [12:57] this is with a 1.3 version of autopilot-desktop [12:58] and python-autopilot [12:58] ops, sorry czajkowski ! I meant cyphermox [13:02] attente: did you install latest unity-autopilot? [13:03] ah, that's still coming from archive, thanks [13:03] Can I force a remote bug watch update on launchpad? [13:06] sil2100, ping? [13:06] fginther: ah! [13:06] fginther: morning! [13:07] Didn't notice your pong ;) Sorry, been eating [13:07] fginther: ok, so, I actually have two things related to generic job again... :< [13:08] fginther: let me pastebin the question I poked Martin with already [13:08] fginther: http://paste.ubuntu.com/5651092/ [13:08] sikon, ok [13:08] sikon, sorry, wrong id [13:08] sil2100, ok [13:08] fginther: it's related to the recent AP test runs failing quickly, in mid-test [13:13] sil2100, have you talked to the utah guys? [13:14] fginther: not yet, but you think it's mostly utah at fault? Since it's happening since like a few days already maybe [13:15] sil2100, I don't know yet, just wondering if they've had a look yet [13:18] sil2100, did #328 fail for the same reason? [13:19] fginther: I checked and I'm not sure, as it was able to execute all tests it was said to [13:19] Since there aren't too many for the OIF stack [13:19] fginther: probably yes, as there's the same message: "Build step 'Execute shell' marked build as failure" === greyback|lunch is now known as greyback === olli_ is now known as olli [13:34] sil2100: i'm still having the same problem, even with the updated python-autopilot [13:34] can you tell me what versions of autopilot-desktop, python-autopilot and unity-autopilot you're using? [13:37] autopilot-desktop: 1.3daily13.05.08ubuntu.unity.next-0ubuntu1, python-autopilot: 1.3daily13.05.08ubuntu.unity.next-0ubuntu1 and unity built locally yesterday from trunk, so actually 7.0.0daily13.05.08ubuntu.unity.next-0ubuntu1 should be fine [13:37] As it's working for the auto-builders [13:40] attente: I saw an error message like this before, but it disappeared when the new unity-autopilot package appeared in the PPA [13:46] sil2100, the index for the packages in saucy has the unity-autopilot package fixed to an older one 7.0.0daily13.05.01.1ubuntu.unity.next-0ubuntu1 [13:47] is there a way for you to update it? [13:47] Ah, saucy! [13:47] * sil2100 is still on raring [13:48] ;) [13:48] Since the daily-release machines are still running on raring ;) [13:48] Ok, but that explains all - you can simply do a bzr bd on lp:unity and temporarily install unity-autopilot from the generated packages [13:49] sure [13:49] Thanks! I would put it up somewhere, the package that is, but I just recently removed it when cleaning up my workspace ;p [13:49] I wonder if anyone can advise me on how to get an application into the messaging menu [13:55] robru: give me a ping when you're around [14:15] I'm basing the messaging code on http://developer.ubuntu.com/resources/technologies/messaging-menu/ [14:15] with appropriate .desktop file and window showing function [14:15] but nothing appears on the messaging menu [14:15] any ideas on why not? [14:16] (tumbleweeds roll by) === m_conley_away is now known as m_conley [14:22] (wind whistles gently) [14:24] ;) [14:25] bashrc: patience people are working and may not be looknig at irc [14:25] * ogra_ hands bashrc a kite ... [14:25] ok, I'll try not to disturb the sleep [14:25] bashrc: or work :) [14:25] people do work [14:26] oh an ogra_ ello [14:26] (mars rover moves slowly across the landscape) [14:26] hey czajkowski [14:26] hehehe [14:27] bashrc: that guide is outdated, one should use libmessagingmenu instead [14:27] ok [14:27] (probably dpm can remove/update that) [14:29] hi mitya57, what's up? [14:29] bashrc: there is some HTML documentation in libmessaging-menu-dev package [14:29] ok [14:29] well hidden [14:29] dpm: code on http://developer.ubuntu.com/resources/technologies/messaging-menu/ is outdated and does not work in >= quantal [14:30] I see [14:30] mitya57, ah, thanks. Would you mind filing a bug and pointing to the changes required? [14:31] ok [14:31] dpm: just remove that page. I can try to write a better example if you want, but not today [14:34] To be clear, what should I file a bug against in Launchpad? [14:35] I'm filing it myself [14:35] ok [14:39] bashrc, dpm: bug 1178700 [14:39] Launchpad bug 1178700 in Ubuntu App Developer site "Python code snippets are outdated and don't work" [Undecided,New] https://launchpad.net/bugs/1178700 [14:43] Thanks. https://github.com/Bitmessage/PyBitmessage/issues/135#issuecomment-17724056 [14:43] thanks mitya57 [14:44] bashrc: I can suggest you to use https://code.launchpad.net/unity-mail as an example of working code [14:46] ok I'll check it out === vrruiz_ is now known as rvr [16:08] fginther: can I have one more request? In some free moment - since lp:unity-gtk-module doesn't seem to have autolanding enabled [16:08] fginther: we want to add it to daily-release [16:09] sil2100, I think cyphermox was working on that [16:13] sil2100: there's a merge for that [16:13] or did I forget to file the merge and just do the change locally [16:37] cyphermox: awesome [16:40] robru: piiing? [16:42] cyphermox: about the QA stack redeployment... did you redeploy in the end? [16:42] I missed that it seems [16:42] I was fighting issues with webapps [16:42] sil2100: it ran today though [16:51] cyphermox: ok, since in the morning I didn't see the check job I added, so I was wondering if I screwed something up in the config [16:59] mterry: so... ~/.cache/music is a thing now [16:59] my music library from my media server, so i can carry it around with me [16:59] symlinked from ~/Music/Library -> ~/.cache/music [17:00] desrt, ok. you see a problem? [17:00] no [17:00] it's glorious [17:00] i love it [17:00] desrt, ah :) A happy tale [17:00] well [17:00] i'll see a problem if dejadup decides to follow that symlink :) [17:00] but i think it doesn't [17:00] desrt, that's nice. Is that a setup you made or something a program does for you? [17:01] mterry: i made it... i'm thinking about scripting it a bit, though [17:01] desrt, no it won't, unless you point directly at a symlink in includes/excludes [17:01] most of my music collection is flac [17:01] sil2100: what job? === alan_g is now known as alan_g|EOW [17:01] i have this program called flacsync that whacks it down to .ogg files [17:01] and i have only the oggs on my laptop [17:02] desrt, ah nice [17:05] cyphermox: in the QA stack, since I added autopilot tests so theoretically cu2d-qa-head-2.2check should appear in QA Head, but I don't see the job there [17:10] cyphermox: are we ready for announcing the touch components daily-releasing, or are there some problems still? [17:10] robru: ^ ? [17:17] sil2100: not everything is done being prepared [17:19] sil2100: sorry, guess i misunderstood -- I updated the qa stack you'll have the check job now [17:19] I'll do a rerun now [17:19] do you know what python-upa is? [18:41] cyphermox, I see you ran webapps again this morning and it's failed again. I'm looking at the logs though and I don't see it even trying to do anything useful -- it just pukes early on, before all the deps are even installed. [18:41] cyphermox, so I think something is really fishy with the jenkins server. who should we ping on that? mmrazik? === ricotz_ is now known as ricotz [18:57] jasoncwarner, hi [19:02] robru: it fails in many ways. retoaded may be able to help [19:03] cyphermox, ok. well I'm officially off today so if you could try to pester some people about that it would be super. I'm still reasonably confident that the stack is in good shape for landing, it's just jenkins itself that is very broken [19:04] yes [19:05] off to the beach! === lool- is now known as lool [19:33] kenvandine: around? [19:33] kenvandine: I need help with a few MPs if you have time [19:33] https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/python-upa-daily-false/+merge/163348 [19:35] cyphermox, sure [20:02] Making progress on the messaging menu [20:03] is there a way to prevent an application selected on the messaging menu from opening more than one instance? [20:06] bashrc: yes, make the app single instance [20:06] is there a way to do that in python? [20:06] certainly. Are you using gapplication? [20:07] oh wait, are you using gtk at all? [20:07]